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.
Based on Branan's code deliberated upon in IRC, this provides the ability
to detect CPU instruction sets and dispatch functions based on those
capabilities detected at runtime.
Win32 HACK: We wait on both the pfCrashCli handle and the crashed semaphore.
This way, we can proceed to exit pfCrashSrv when the client process exits
insanely.
pfGameScore will call you back on actions that require server ops. Also, we
ref count the score instead of using some weird hashtable manager class
because the server never actually tells us if someone else changes the
score.
This reverts commit 8da276f2e50688691b294438ed3d2bcfa218c617, a commit that
did not work as advertised and added too many chances for things to go badly
wrong.
pfCrashHandler includes a client that watches plClient for crashes. When
it detects a crash, it lets the plCrashSrv (plCrashHandler.exe) know about
it. We then produce a mninidump, then signal the client that it's OK to
show a crash dialog. See http://www.nynaeve.net/?p=128 for a good
explanation of why I split the crash logic into another process.
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.