- completely eliminated the horrible fudging that went on with players during hub travel. This means that DestroyMostThinkers and the player substitution mechanism in the object deserializer are gone now.
I wish I had realized this the last time it came up - it would have saved me a lot of trouble. But as it turns out, the more recent travelling code makes all of this completely unnecessary, working perfectly fine with deleting the player pawns along with the rest of the thinkers before loading the stored ones from the savegame (and getting rid of those in G_FinishTravel.) And with a sane savegame format that does not depend on side effects from how the thinker serializing handled linking into the lists the old code was even harmful, leaving voodoo dolls behind. I had the exact same effect when I tried to reshuffle some things for reliably restoring portals, but did not make the connection to interference between two mutually incompatible player travelling mechanisms that just worked by sheer happenstance with the original order of things.
This commit is contained in:
parent
2318db0b1a
commit
69291b9cf9
4 changed files with 1 additions and 114 deletions
|
|
@ -63,17 +63,6 @@
|
|||
#include "r_renderer.h"
|
||||
#include "serializer.h"
|
||||
|
||||
//
|
||||
// Thinkers
|
||||
//
|
||||
|
||||
void P_DestroyThinkers(bool hubLoad)
|
||||
{
|
||||
if (hubLoad)
|
||||
DThinker::DestroyMostThinkers();
|
||||
else
|
||||
DThinker::DestroyAllThinkers();
|
||||
}
|
||||
|
||||
//==========================================================================
|
||||
//
|
||||
|
|
@ -901,7 +890,7 @@ void G_SerializeLevel(FSerializer &arc, bool hubload)
|
|||
Renderer->StartSerialize(arc);
|
||||
if (arc.isReading())
|
||||
{
|
||||
P_DestroyThinkers(hubload);
|
||||
DThinker::DestroyAllThinkers();
|
||||
interpolator.ClearInterpolations();
|
||||
arc.ReadObjects(hubload);
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue