What changed in EDuke32, build by build

a boss, ensure that FinishTimer and FinishAnim are appropriately updated. This commit bumps GameVersion. Additionally, the set of FinishAnim to 0 in NewLevel had to move to a different location (InitLevelGlobals2), so it doesn't override the value stored in the saved game.

interpolation of player turning/aiming/movement, while being carried by a sector object, without SO interpolation. This is a continuation of 73a0aa394e906a65633d61f3c749c9b9b7e66aaa and bf31bc2987a3eccd31d343622327bd4ee0f9c5a1, aiming to fix a jitter in case the player is continuously getting pushed by a wall (e.g., on the boat in level 5). Basically, this moves the relevant assignments from track.cpp:MovePlayer and MovePoints to player.cpp:DoPlayerMove. Unless a call to one of these functions has been missed, pushwall and clipmove can be called from player.cpp in the following instances, which should be covered: - Via DoPlayerMove, which is the function getting the fix now. - Via DoPlayerSlide, which is called in the beginning of DoPlayerMove. - Via DoPlayerCurrent when called from DoPlayerCrawl/DoPlayerWade, followed by DoPlayerMove. - Via DoPlayerCurrent when called from DoPlayerDive, followed by DoPlayerMove if the player doesn't stop diving.

so OSD commands can have an effect from here

separate checks of the form sop->xmid == INT32_MAX

of change that camq16ang/camq16horiz gets. Such an update is possible after making sure that UpdateInputs (faketimerhandler) is never called from domovethings.

for now, due to possible jitters. Currently leaving remote-controlled SOs.

from faketimerhandler. This should fix the timing of playing an RTS file's sound and sending the corresponding message.

by the player. Make sure looking up/down is still smooth.

don't move as smooth as possible in multiplayer

Let's see if this is breaking anything.

While it is understandable that avel and horz came from Duke3D, having both q16horiz and q16horz in the updated SW_PACKET struct can be confusing, and the alternative notation is more consistent with the original struct field names of angvel and aimvel, as well as the differing uses of the name angvel still present in player.cpp.

player is dead, and also disable horizontal aiming while on a ladder.

related to the definitions of RANDOM_NEG in bunny.cpp, ripper.cpp and ripper2.cpp. Do so in a way that isn't re-introducing compiler warnings. This partially fixes compatibility with demos made for SW 1.2. Additionally, replace the 3 separate definitions of RANDOM_NEG with a common one within game.h.

brought back in r7873, this should restore the behaviors of DOS v1.2.

a bit more usable in multiplayer, hiding the engine's console.

toggling MultiPlayQuitFlag on instead of QuitFlag in multiplayer games if a player tries to close the window. Further update MNU_QuitCustom to use CON_Quit. - In RunLevel, this fixes quit of game for all players. - In MenuLevel, this leads to transmit of PACKET_TYPE_MENU_LEVEL_QUIT. However, the work isn't complete, since the game isn't shut down on the peers' sides, leading to possibly undesired side-effects. Currently known issue: - If the master closes the window, the scores won't be shown for the master. Reason is that waitforeverybody will terminate the app.

quitevent in the game, and further call getpackets within StatScreen.

all players after level change. This is done by adding calls to getpackets within the BonusScreen and StatScreen while loops. It is related to a change from the DOS versions of 1997. Basically, dosendpackets immediately sends all packets via the commit driver under DOS, while in the mmulti port in use here, sending might be postponed. This was leading to a problem with the game entering waitforeverybody before showing the stats. In particular, it initially attempted to send a PACKET_TYPE_PLAYER_READY message, which could get postponed in the manner described above. In case it received PACKET_TYPE_PLAYER_READY messages from all other peers before the time arrived for sending pending packets, though, waitforeverybody would return, eventually leading to a call to StatScreen/BonusScreen, without sending the pending message until the user in question continued. Other peers would have to wait for the given player to confirm level change before they could see their own stat screens.

including 3+ players sessions.

Thanks to LittleTijn for testing and inspecting.

the functions' signatures (often due to being used as callbacks/hooks)

with (possible) side-effects is written to an unused var.

used if previously commented out code was uncommented (including a few instances of uninitialized var reads).