The previous implementation had the following bugs:
- DST was truncated to end of October
- DST start was off by one week in years where March 1st is a Monday
- DST start was off by one second (1:59:59 -> 2:00:00 -> 3:00:01 instead of the correct 1:59:59 -> 3:00:00 -> 3:00:01)
Tested against tzdata 2009g.
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.
Update the Windows 7 taskbarlist progress bar on plOperationProgress
callbacks. It's not totally nesecary, but it adds a nice bit of polish to
the experience.
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.
