MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003167Zandronum[All Projects] Bugpublic2017-06-23 00:022018-09-30 21:42
ReporterCombinebobnt 
Assigned ToTorr Samaho 
PriorityhighSeveritymajorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version3.0-beta 
Target Version3.0Fixed in Version3.0 
Summary0003167: Players spawning without weapons in cooperative gametypes
DescriptionI've been playing survival lately and notice throughout several wads that players have been spawning occasionally with no weapons. They either have to pick up a weapon from the map or like in samsara extra classes, must spectate and rejoin (maybe a mod conflict with 3.0 there).
Steps To Reproduce1. Start sever in survival gamemode, plain ass doom2.wad no wads needed (didn't bother checking survival invasion)
2. Have two people join
3. Player 1 dies (loses all lives)
4. Player 2 beats the map
5. First player spawns in next map with no guns
Additional Informationwads:

valiant
'http://allfearthesentinel.net/download?file=valiant.wad [^]'

woc:
'http://nuclearempire.net/wads/wrathofcronosr1_9.pk3 [^]'
'http://nuclearempire.net/wads/wrathofcronosdoompatch1_9.pk3 [^]'

samsara exheros
'http://allfearthesentinel.net/download?file=samsara-v0.31-beta.pk3 [^]'
'http://allfearthesentinel.net/download?file=samsara_ex-hb3.pk3 [^]'
'http://allfearthesentinel.net/download?file=sm-exfix21.pk3 [^]'
'http://allfearthesentinel.net/download?file=exmixer-v0.72.pk3 [^]'
TagsNo tags attached.
Relationships
has duplicate 0003182closed  Dying in coop game -> next round you start with no guns (even can't use fists) 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2017-06-23 00:02CombinebobntNew Issue
2017-06-23 00:03CombinebobntNote Added: 0017879
2017-06-23 00:22Ru5tK1ngDescription Updatedbug_revision_view_page.php?rev_id=10723#r10723
2017-06-23 00:22Ru5tK1ngSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=10725#r10725
2017-06-23 00:22CombinebobntNote Added: 0017880
2017-06-23 00:23CombinebobntNote Edited: 0017880bug_revision_view_page.php?bugnote_id=17880#r10727
2017-06-23 00:26ArgentumNote Added: 0017881
2017-06-23 00:26CombinebobntNote Edited: 0017880bug_revision_view_page.php?bugnote_id=17880#r10728
2017-06-23 01:17Ru5tK1ngNote Added: 0017882
2017-06-25 02:05Ru5tK1ngNote Added: 0017902
2017-06-25 02:05Ru5tK1ngStatusnew => needs review
2017-06-25 02:05Ru5tK1ngTarget Version => 3.0
2017-06-25 13:28Torr SamahoNote Added: 0017905
2017-06-25 16:31Ru5tK1ngNote Added: 0017918
2017-06-25 19:52Torr SamahoNote Added: 0017927
2017-06-25 20:10Ru5tK1ngNote Added: 0017929
2017-06-26 00:34ArgentumNote Added: 0017930
2017-06-26 01:09jdagenetNote Added: 0017931
2017-06-26 01:15jdagenetNote Edited: 0017931bug_revision_view_page.php?bugnote_id=17931#r10737
2017-06-26 05:31Ru5tK1ngNote Added: 0017932
2017-06-26 06:04Torr SamahoNote Added: 0017933
2017-06-26 06:05Torr SamahoAssigned To => Torr Samaho
2017-06-26 06:05Torr SamahoStatusneeds review => feedback
2017-06-26 06:15EnsaladaDeTomateNote Added: 0017934
2017-06-26 06:17EnsaladaDeTomateNote Edited: 0017934bug_revision_view_page.php?bugnote_id=17934#r10739
2017-06-26 18:47Torr SamahoNote Added: 0017936
2017-06-26 19:49jdagenetNote Added: 0017938
2017-06-27 01:28CombinebobntNote Added: 0017943
2017-06-27 01:28CombinebobntStatusfeedback => assigned
2017-06-27 01:28Ru5tK1ngNote Added: 0017944
2017-06-27 01:29Ru5tK1ngNote Edited: 0017944bug_revision_view_page.php?bugnote_id=17944#r10743
2017-06-29 18:35Ru5tK1ngNote Added: 0017950
2017-06-30 03:37Ru5tK1ngNote Edited: 0017950bug_revision_view_page.php?bugnote_id=17950#r10745
2017-06-30 04:28Ru5tK1ngNote Added: 0017952
2017-06-30 04:28Ru5tK1ngStatusassigned => needs review
2017-06-30 19:43Edward-sanNote Added: 0017953
2017-06-30 21:08Ru5tK1ngNote Added: 0017954
2017-07-01 22:30Ru5tK1ngStatusneeds review => needs testing
2017-07-07 22:26Ru5tK1ngRelationship addedhas duplicate 0003182
2017-07-11 22:44CombinebobntNote Added: 0018006
2017-07-11 23:50Ru5tK1ngStatusneeds testing => resolved
2017-07-11 23:50Ru5tK1ngResolutionopen => fixed
2017-07-11 23:50Ru5tK1ngFixed in Version => 3.0
2018-09-30 21:42Blzut3Statusresolved => closed

Notes
(0017879)
Combinebobnt   
2017-06-23 00:03   
arg said it happened often in chex quest plain gameplay. ok i need to test
(0017880)
Combinebobnt   
2017-06-23 00:22   
(edited on: 2017-06-23 00:26)
ok I tested and its really easy to reproduce. good rustking will put the info in there

sv_deadplayerscankeepinventory is false btw

I have a random guess that the 'new survival flag behavior' causes this. Maybe it takes the whole player inventory but forgets to regive basic items defined in the playerclass (player.startswith), which is stuff like the fist and the pistol
(0017881)
Argentum   
2017-06-23 00:26   
Proofs from testing:
'http://i.imgur.com/YYLNHAB.png [^]' - Chex.wad
'http://i.imgur.com/AZ5zURO.png [^]' - Doom2.wad
(0017882)
Ru5tK1ng   
2017-06-23 01:17   
As Ivan and I determined, this:'https://bitbucket.org/Torr_Samaho/zandronum/commits/c2b0b3675a1b05a12bc77c7225931766658bc4c9#Lsrc/p_interaction.cppT2574 [^]'

line causes players who are dead spectators to have their inventory wiped because the condition !ZADF_DEAD_PLAYERS_CAN_KEEP_INVENTORY is being met.

Additionally I'm not sure if this:'https://bitbucket.org/Torr_Samaho/zandronum/commits/c2b0b3675a1b05a12bc77c7225931766658bc4c9#Lsrc/p_user.cppT1506 [^]'

could also cause issues.
(0017902)
Ru5tK1ng   
2017-06-25 02:05   
I was able to fix the bug and seemingly keep Zalewa's behavior intact.

'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/208/dead-players-were-incorrectly-losing-all/diff [^]'
(0017905)
Torr Samaho   
2017-06-25 13:28   
Thanks! Looks good except for some style issue, see my comments on bitbucket.
(0017918)
Ru5tK1ng   
2017-06-25 16:31   
Updated based off your comments.
(0017927)
Torr Samaho   
2017-06-25 19:52   
Thanks, but when looking closer at the patch in the dev meeting, we realized that it shouldn't change the behavior at all. So I tried to reproduce the problem locally to check whether the patch fixes this on my end. It turned out that I can't reproduce the problem. Can somebody reproduce the problem with the official binaries or does it only happen on servers with custom code modifications like TSPG?
(0017929)
Ru5tK1ng   
2017-06-25 20:10   
I also couldn't reproduce the problem with the last official 3.0 beta release. So as stated, it's most likely an issue on TSPG's end.
(0017930)
Argentum   
2017-06-26 00:34   
It is not limited to TSPG; My own servers had this issue when Combinebobnt and I were testing this on Chex.wad (since it wasn't supported by TSPG). It also had already occurred on a previous server of mine using the same build.
(0017931)
jdagenet   
2017-06-26 01:09   
(edited on: 2017-06-26 01:15)
I'm able to reproduce this on 170625-1906 every single time with a local server and a bot.

All I'm doing is hosting a normal survival server, no DMFlags or server settings are applied. I'm adding a bot into the game and killing myself until I have no lives left and then I just "ChangeMap MAPXX" and boom I get the bug when the next map loads.

Arg and myself are able to trigger the bug, but strangely Rust is unable to. We ruled out the possibility of client settings by testing with a fresh ini and the bug is still reproducible for me, but not for Rust.

EDIT: The bug can be reproduced offline using the same setup.
(0017932)
Ru5tK1ng   
2017-06-26 05:31   
Even though I wasn't able to test it, I did get those 2 to try out older builds and it lead us all the way back to the same commit:'https://bitbucket.org/Torr_Samaho/zandronum/commits/c2b0b3675a1b05a12bc77c7225931766658bc4c9 [^]'

I'm trying to see what could possibly have changed here to cause this bug that some how only affects certain users. Perhaps something is being over looked?
(0017933)
Torr Samaho   
2017-06-26 06:04   
It's definitely possible that the problem only happens under circumstances we are not aware of yet. Did anybody get the bug with a Windows server yet?
(0017934)
EnsaladaDeTomate   
2017-06-26 06:15   
(edited on: 2017-06-26 06:17)
Just tested in a custom server with bots, using Windows 7, and i got the same issue, i respawned without weapons, and other bots did aswell.

Proof:'http://i.imgur.com/eMMu8Nu.png [^]'

(in the image, me and the bot Chubbs have no weapons, even the coop info points out that he has nothing, you can only see his health and armor counts)
(0017936)
Torr Samaho   
2017-06-26 18:47   
Can you post the full server log, the server ini and the full command that was used to start the server under Windows 7? In addition, a client side demo could be helpful. Preferably, all with doom2 as IWAD and no mods or map packs loaded.
(0017938)
jdagenet   
2017-06-26 19:49   
For the record, this issue can be reproduced using 2.1.2 offline but not online. At some point something changed in 3.0 for the bug to leak out on a server.
(0017943)
Combinebobnt   
2017-06-27 01:28   
happens when alwaysapplydmflags is 1. tested in lastest blahblahblah v 625
(0017944)
Ru5tK1ng   
2017-06-27 01:28   
(edited on: 2017-06-27 01:29)
I figured out the reason why the devs and I couldn't recreate it is because we didn't use doom explorer, we used the command line. Their servers were being launched with alwaysapplydmflags 1.

I already tested way before you Bob. :)
(0017950)
Ru5tK1ng   
2017-06-29 18:35   
(edited on: 2017-06-30 03:37)
So this is the difference between alwaysapplydmflags 1 or 2: 'https://bitbucket.org/Torr_Samaho/zandronum/src/f767211c5f2c9cf01e1d7b886d8306caac64fd8b/src/p_mobj.cpp?at=default&fileviewer=file-view-default#p_mobj.cpp-5681 [^]'

And it turns out this is the part of the code that doesn't like the invul powerup effect on level loadup that you are given when alwaysapplydmflags is true.
(0017952)
Ru5tK1ng   
2017-06-30 04:28   
Adding the following check solved the issue of no inventory when revived on map change, map exit or map reset. sv_deadplayerscankeepinventory also worked properly when moving between levels. Applydmflags nor sv_maxlives caused any issue when being revived on a new map.

'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/210/revived-dead-spectators-had-no-inventory/diff [^]'
(0017953)
Edward-san   
2017-06-30 19:43   
Certainly that flag is cumbersome :)

I can confirm both the bug and the fix, though maybe some more tests on various situations would help.
(0017954)
Ru5tK1ng   
2017-06-30 21:08   
I'll see if I can get the fix up on TSPG so that it could be tested on Saturday during SNS.
(0018006)
Combinebobnt   
2017-07-11 22:44   
tested in 170709 and looks like it works