- Fixed: Heretic and Hexen completely skip all normal Z processing on
mobjs with FLOATBOB set. To emulate that, we need to add NOGRAVITY to
everything with that flag set.
- The waiting message is now always cleared, regardless if it needed to
be in the first place. It's a rather simple for-loop so I doubt it
matters.
- Nodes are also cleared from the list if they catch up while other
nodes are still behind.
- "lastglobalrecvtime" is now bumped after the waiting loop if a tic was
successful, rather then bumping it every time a packet was received. It
appears that you can receive a packet before the game knows it stalled,
thus stalling it anyway.
- Instead of comparing the nettics to the local node, all nodes are
tested against gametic+counts (the real reason why the game has
stopped).
- More then one node can be marked as late at any one time.
- In a packet-server game, the arbitrator is now assumed slow, rather
then testing it. There is no point, seeing as we already know the game
has stalled because of it.
- Added ZDOOM_OUTPUT_OLDSTYLE (could probably use a more descriptive name) which causes CMake to vary the executable name by build type and place the exes and pk3s into the directory specified in ZDOOM_OUTPUT_DIR.
- ALL_BUILD will now launch ZDoom.
- Command-line console commands are executed before a level is entered, so
trying to use +warp to position yourself at a specific location will not
work. We now specially handle this command so that it does work.
- Added CF_INTERPVIEW flag for players. A_SetPitch/A_SetAngle and the
similar ACS APROPs set this when changing an angle. This forces the
renderer to interpolate the view angles instead of updating with the
latest mouse positions. The effect lasts one tick.
- To make camera textures pan in world units instead of texture units, you
can now add "WorldPanning" at the end of the cameratexture definition in
ANIMDEFS, after the "fit" specification. e.g.
cameratexture CAMTEX 128 128 fit 64 64 worldpanning
- Fixed: DThinker::Destroy(Most)ThinkersInList() were unreliable when
destroyed thinkers destroyed more thinkers in the same list.
Specifically, if the thinker it destroyed caused the very next thinker
in the list to also be destroyed, it would get lost in the thinker list
and end up with a NULL node. So just keep iterating through the first
thinker in the list until there are none left. Since destroying a
thinker causes it to remove itself from its list, the first thinker will
always be changing as long as there's something to destroy.
- Fixed: You could not set any CVARINFO-defined cvars from the command line
because command line console commands were executed before wads were
even loaded. Off the top of my head, I can't think of anything that would\
break by having them get executed after wads are loaded.
If an actor is already targeting a goal, and Thing_SetGoal is used on
it, it would still be left targeting the old goal instead of the new
one. This messed up checks in A_Chase for walking towards a goal vs a
real target.
- This fixes crashes when quitting multiplayer games because the default
byte-for-byte copy caused PredictionPlayerBackup and the console player
to point to the exact same userinfo data and to both try and free it
when they are deleted.
- Make wi_noautostartmap a userinfo cvar. This allows it to be
communicated across the network and saved in demos. If any player has it
set, then the intermission screen will not automatically advance to the
next level.
- Instead of tying NoDelay behavior to OF_JustSpawned, use a new actor
flag, MF7_HANDLENODELAY. This only gets cleared once it has actually
been checked by Tick(). This is necessary because freeze mode delays the
initial run of Tick() past the initial spawn, so OF_JustSpawned will no
longer be set when it does the initial tick.
- Delay NoDelay processing if an actor is spawned dormant. Actors spawned
dormant have Deactivate() called before they tick, so MF7_HANDLENODELAY
will remain set as long as an actor is dormant. This allows the NoDelay
handling to occur as expected once it is activated.
- If the current user does not have write permissions for the directory
zdoom.exe is located in, use standard folder paths located in their home
directory instead. This is a common scenario when people put ZDoom into
Program Files. (Ironically, zdoom.ini used to be in AppData, buth then
people complained when it wasn't in the same directory as zdoom.exe, so
it got turned into zdoom-<user>.ini so at least it could retain some
multi-user support. I'm not sure when the AppData support was removed,
though, since it should have still been kept around for migrating
configs to the new name.)
