Skip to content

Player spawn regression fixes

Adam Kaminski requested to merge topic/default/player-spawn-fixes into branch/default

A couple of fixes to unforeseen regressions related to player spawning that got caught in the new beta:

  1. In cooperative game modes, if a player was supposed to spawn at a random cooperative spot, they'd sometimes spawn in the void, or just at random spots in the map. This issue only seems to happen in Linux builds, but not in Windows builds.

  2. If sv_spawnfarthest was enabled in deathmatch-based game modes, and all player starts were taken (e.g. there's more players spawning than spots available), a fatal error would get thrown with the message: Could not find a valid deathmatch spot! (this should not happen). Since I already restored some of the code from GZDoom 1.8.6 in ea8604d448e9, I decided to restore the remaining code so that the behaviour is now identical to GZDoom.

This technically means that Zandronum will now try picking a random cooperative start for the player to spawn at in deathmatch, if any exist on the map when there's no free deathmatch starts available. However, this is probably better than immediately trying to pick a random deathmatch start that's already full and increase the occurrence of spawn telefrags. Not to mention, this also further reduces delta from GZDoom.

EDIT: after further testing, the GZDoom behaviour doesn't always work perfectly. Particularly, G_PickPlayerStart doesn't check if AllPlayerStarts is empty in 1.8.6, which can cause a crash (i.e. return &AllPlayerStarts[pr_pspawn(AllPlayerStarts.Size())];). Also, the necessary commit(s) from later versions of GZDoom that would need to be transplanted to fix this issue unfortunately don't merge into our codebase cleanly. Instead, just use SelectRandomDeathmatchSpot to pick a valid spot, as it was done before.

Edited by Adam Kaminski

Merge request reports

Loading