plMovementStrategy classes have been reworked and completely replace all plAvatarControllers.
While based on the old implementation, plPhysicalControllerCore has essentially been rewritten.
Remnants of long gone physical "actions" have been removed.
4 files removed -
plAVCallbackAction.h & plAVCallbackAction.cpp
plAntiGravAction.h & plAntiGravAction.cpp
This revision will not compile, requires new plPXPhysicalControllerCore implementation.
In particular, the intro movie now exits immediately again rather than staying indefinitely.
The important difference is to send the completion callback in plBinkPlayer::NextFrame(), i.e. act as if we had reached the end of the movie.
Storing the filename is to keep plClient::IHandleMovieMsg() from deleting and recreating the plBinkPlayer on every message.
The changed return values are just to better match the previous behavior and probably don’t matter.
Now we test the file we're trying to write to. We still support legacy
xTEA BriceIsSmart/whatdoyousee files, but we will always make new files
unencrypted.
- plRefCnt duplicates hsRefCnt (Wtf?)
- hsNamedPipeStream nasty, unused
- VDB stuff in hsStream left over from Plasma 1 (realMyst/DIRT)
- hsColor32 moved to be less promiscuous
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.