Changing the next behavior to running on every goal update causes the quabs
to skitter about one inch every five seconds. Obviously, we do not need to
start running if we are already running, so let's check that.
Manual state management in python was kind of fiddly, so let's track all
avatar clones in the NetApp and unload them as needed. This also seems to
fix a potential bug in plNPCSpawnMod (is that even used?).
Re-enables FPU/SSE3 code using the FunctionDispatcher and some quick
hacky macros to template out the two nearly-identical functions,
awaiting branan's deep-voodoo template-specialization functor-dispatcher
patch.
This reverts commit 8da276f2e50688691b294438ed3d2bcfa218c617, a commit that
did not work as advertised and added too many chances for things to go badly
wrong.
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.
Darryl Pogue
Adam Johnson
Michael Hansen
Joseph Davies
Christian Walther
Bartek Bok