The default value of the "dst" argument must be 0, because -1 leads to incorrect results when the given time falls into local DST. However, a "dst" argument makes no sense on a method that deals with GMT anyway, so remove it entirely.
IP addresses don't need to be unicode.
pnUtAddr is still around until we replace all NetAddress uses with
plNetAddress (they are typedef'ed to each other right now).
This probably has a bunch of bugs because of Network Order/Host Order
issues. If we intend to actually support BE architectures, these
problems are going to get much much worse :(
Prevents cheating with time based puzzles (pellets) and ensures the KI time
stays somewhat correct. The server time will be reset on the plNetMessage
received after the user changes their system clock. That might take a bit,
but it's better than nothing.
Sending dupe input state messages every 10 seconds is wasteful. They are
already sent when the fields dirty, so there's no sense in sending them
any more than that. For keeping the connection alive, we'll use
lightweight pings.
Evidently, the game connection never actually pinged. Instead, it relied
on the propagation of a redundant game message. This is evil because we
can sometimes hang out in the loading process for quite some time (eg
beyond the socket timeout on either end)
Looks like the fissure fall camera region got triggered then untriggered
during the linking process. In debug builds, this happened in one frame,
so only an exit message got sent out. In faster builds, both would be
sent, and you would plunge. To fix that, we don't send eval until we're no
longer MidLink.
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.
Adam Johnson
Darryl Pogue
Christian Walther
Bartek Bok