Seriously? Offsetof has been around for a long time, and eap added a
compiler_assert for his crazy netcode. There's no excuse for that to be
happening at runtime.
Turns out, it was an artifact of us suspending the simulation during links
and partly because of Cyan's late adding of the avatar controller to the
sim. Now, we add the avatar as soon as the age data is loaded. This causes
the camera stack to be populated with whatever garbage PhysX decides on,
then xJourneyClothsGen2 is free to set the real stack after we get all the
SDL from the server.
Verified to fix Teledahn oddness and not display a regression in Kemo.
This should keep the avatar from getting stuck on some stupid stuff such
as on the pellet machine. A real fix would be to tweak the data, but we
cannot do that.
Previously, multiple controllers in a single age
would overlap. This adds a static positional
counter which is reset at the start of a new list.
This commit also attempts to make the list more
useful by showing the controller objects'
owner's name.
plStringification of plPXPhysicalControllerCore::IDrawDebugDisplay
and general clean-up. Also changed to only display
avatar collisions heading if any exist to show.
To better handle erroneous trigger events under the new timing method, use the number of times the simulation has actually advanced instead of the number of evals received.
Cleaned up a bit.
While based heavily on the old implementation, this is essentially a rewrite.
Notable changes -
Controllers are now updated at the same fixed frequency as the simulation.
Resulting output is interpolated between steps to precisely match the frame delta.
Physics work is only done when enough time has passed to perform a step.
The kinematic actor that followed around the controller has been removed.
The underlying kinematic actor created by the NxController is now used for triggering.
A new sim group was added for a kinematically controlled avatar.
2 unused files removed -
plPXPhysicalController.h & plPXPhysicalController.cpp
Cyan's old code was confusing and would allow you to walk on top of small
kickables. Now, we impart force to these small kickables up to a certain
point where imparting force to them becomes somewhat risky.
Looks like the Cyan modellers didn't extend the stair ramps all the way
down in some places. To compensate, we can now take higher steps but can't
walk on slopes quite as steep as before. I think this should balance out
nicely.
Now that we properly suspend/resume the simulation AND filter out false
positives in the PanicLink region, we can use the correct PhysX apis have
have regions that work 100%
PhysX is nicely capable of clamping for us without those nasty hacks, so
let's allow PhysX to do it for us. Hopefully, this will keep anything too
insane from happening when I disable the framerate limit.
Tweak the GZ marker detector region fix to only wake up kinematic detector
regions... waking up regular dynamic actors before we position them causes bad
things to happen.
This thing was pissing me off, which made me piss off a lot of other people,
which pissed off even more people, so the entire planet got pissed off and
nuclear warfare began. So, let's not do stupid crap and piss me off, okay?
Looks like Cyan never actually stopped simulating, so we simulate through
adding objects to the scene and positioning them. This is a bad thing(TM),
so now we suspend/resume the simulation on plAgeLoadedMsg.
The ladder region fixes introduced the panic link. Now we should always
verify the following when changing anything related to the stupid kinematic
actor turd:
- Linking to any Ahnoying Sphere's main LIP does not result in a panic link
- The Teledahn hatch ladder camera works as expected
- That the game doesn't crash on anything stupid, like a nil SceneNode
Rearrange some things so such that low-level CoreLib headers aren't quite
so crazy. For higher level stuff, you still need to include the
appropriate header.
As I discovered several months ago, Cyan used the incorrect
NxActor::setGlobal(Pose/Position) function(s) to transform kinematic actors.
This is incorrect but was apparently allowed in PhysX 2.6.0. PhysX 2.6.4
enforces the correct moveGlobal(Pose/Position) functionality, so we MUST use
that.
Function and macro names for endianness were previously vague,
and on big-endian systems entirely misleading. The names are
now properly descriptive of what they actually do.
Darryl Pogue
Skoader
CyanWorlds