NOTE: If you are using a version of PhysX prior to 2.6.4, then you should
test very carefully if you should keep this commit. This change fixed a
bug that caused avatars to get stuck falling against certain colliders. It
seems to no longer be needed.
Deleting an hsRefCnt is evil, we should ALWAYS hsRefCnt_SafeUnRef (we
might have a nullptr) it because someone might ref it. hsRefCnt will explictly crash if you delete it when the refcnt != 1.
Also, take this opportunity to vector-ize things.
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.
Looks like Cyan broke these when they fixed superjumps. It appears that
LinearVelocity is only good while the PhysicalControllerCore is updating,
and it stashes the result for later so nothing else can touch it.
Regardless, we need to test AchievedLinearVelocity outside of the update
proc.
On the other hand, have we ever figured out exactly what this code is
supposed to do? Mark added it for something, but it's not really clear
what the purpose is.
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%
Now, we check the armature mod to see if we're REALLY linked in (the screen
is not black). That way, we can be sure all delayed transforms and false
hits (like how we initially spawn into the AhnySphere04 panic region) don't
panic link us.
It turns out that eap (I know it was him... look at those weird comments
between the functions) was calling plClient::IDraw for every KeyedObject we
loaded in order to update the progress bar. For some reason, some stooge
added a framerate limit to the MAIN DRAW LOOP instead of this function.
*Sigh*. Either way, the framerate limit is a HACK. We should really be
loading resources in another thread.
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.
Darryl Pogue
Adam Johnson
Michael Hansen
NadnerbD
Joseph Davies