Zandronum Chat @
Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003167Zandronum[All Projects] Bugpublic2017-06-23 00:022017-07-12 22:13
Assigned ToTorr Samaho 
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 [^]

woc: [^] [^]

samsara exheros [^] [^] [^] [^]
Attached Files

- Relationships
has duplicate 0003182closed Dying in coop game -> next round you start with no guns (even can't use fists) 

-  Notes
User avatar (0017879)
Combinebobnt (reporter)
2017-06-23 00:03

arg said it happened often in chex quest plain gameplay. ok i need to test
User avatar (0017880)
Combinebobnt (reporter)
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

User avatar (0017881)
Argentum (reporter)
2017-06-23 00:26

Proofs from testing: [^] - Chex.wad [^] - Doom2.wad
User avatar (0017882)
Ru5tK1ng (updater)
2017-06-23 01:17

As Ivan and I determined, this: [^]

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: [^]

could also cause issues.
User avatar (0017902)
Ru5tK1ng (updater)
2017-06-25 02:05

I was able to fix the bug and seemingly keep Zalewa's behavior intact. [^]
User avatar (0017905)
Torr Samaho (administrator)
2017-06-25 13:28

Thanks! Looks good except for some style issue, see my comments on bitbucket.
User avatar (0017918)
Ru5tK1ng (updater)
2017-06-25 16:31

Updated based off your comments.
User avatar (0017927)
Torr Samaho (administrator)
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?
User avatar (0017929)
Ru5tK1ng (updater)
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.
User avatar (0017930)
Argentum (reporter)
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.
User avatar (0017931)
jdagenet (reporter)
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.

User avatar (0017932)
Ru5tK1ng (updater)
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: [^]

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?
User avatar (0017933)
Torr Samaho (administrator)
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?
User avatar (0017934)
EnsaladaDeTomate (reporter)
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: [^]

(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)

User avatar (0017936)
Torr Samaho (administrator)
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.
User avatar (0017938)
jdagenet (reporter)
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.
User avatar (0017943)
Combinebobnt (reporter)
2017-06-27 01:28

happens when alwaysapplydmflags is 1. tested in lastest blahblahblah v 625
User avatar (0017944)
Ru5tK1ng (updater)
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. :)

User avatar (0017950)
Ru5tK1ng (updater)
2017-06-29 18:35
edited on: 2017-06-30 03:37

So this is the difference between alwaysapplydmflags 1 or 2: [^]

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.

User avatar (0017952)
Ru5tK1ng (updater)
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. [^]
User avatar (0017953)
Edward-san (developer)
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.
User avatar (0017954)
Ru5tK1ng (updater)
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.
User avatar (0018006)
Combinebobnt (reporter)
2017-07-11 22:44

tested in 170709 and looks like it works

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: Combinebobnt EnsaladaDeTomate jdagenet Korshun Argentum
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2017-06-23 00:02 Combinebobnt New Issue
2017-06-23 00:03 Combinebobnt Note Added: 0017879
2017-06-23 00:22 Ru5tK1ng Description Updated View Revisions
2017-06-23 00:22 Ru5tK1ng Steps to Reproduce Updated View Revisions
2017-06-23 00:22 Combinebobnt Note Added: 0017880
2017-06-23 00:23 Combinebobnt Note Edited: 0017880 View Revisions
2017-06-23 00:26 Argentum Note Added: 0017881
2017-06-23 00:26 Combinebobnt Note Edited: 0017880 View Revisions
2017-06-23 01:17 Ru5tK1ng Note Added: 0017882
2017-06-25 02:05 Ru5tK1ng Note Added: 0017902
2017-06-25 02:05 Ru5tK1ng Status new => needs review
2017-06-25 02:05 Ru5tK1ng Target Version => 3.0
2017-06-25 13:28 Torr Samaho Note Added: 0017905
2017-06-25 16:31 Ru5tK1ng Note Added: 0017918
2017-06-25 19:52 Torr Samaho Note Added: 0017927
2017-06-25 20:10 Ru5tK1ng Note Added: 0017929
2017-06-26 00:34 Argentum Note Added: 0017930
2017-06-26 01:09 jdagenet Note Added: 0017931
2017-06-26 01:15 jdagenet Note Edited: 0017931 View Revisions
2017-06-26 05:31 Ru5tK1ng Note Added: 0017932
2017-06-26 06:04 Torr Samaho Note Added: 0017933
2017-06-26 06:05 Torr Samaho Assigned To => Torr Samaho
2017-06-26 06:05 Torr Samaho Status needs review => feedback
2017-06-26 06:15 EnsaladaDeTomate Note Added: 0017934
2017-06-26 06:17 EnsaladaDeTomate Note Edited: 0017934 View Revisions
2017-06-26 18:47 Torr Samaho Note Added: 0017936
2017-06-26 19:49 jdagenet Note Added: 0017938
2017-06-27 01:28 Combinebobnt Note Added: 0017943
2017-06-27 01:28 Combinebobnt Status feedback => assigned
2017-06-27 01:28 Ru5tK1ng Note Added: 0017944
2017-06-27 01:29 Ru5tK1ng Note Edited: 0017944 View Revisions
2017-06-29 18:35 Ru5tK1ng Note Added: 0017950
2017-06-30 03:37 Ru5tK1ng Note Edited: 0017950 View Revisions
2017-06-30 04:28 Ru5tK1ng Note Added: 0017952
2017-06-30 04:28 Ru5tK1ng Status assigned => needs review
2017-06-30 19:43 Edward-san Note Added: 0017953
2017-06-30 21:08 Ru5tK1ng Note Added: 0017954
2017-07-01 22:30 Ru5tK1ng Status needs review => needs testing
2017-07-07 22:26 Ru5tK1ng Relationship added has duplicate 0003182
2017-07-11 22:44 Combinebobnt Note Added: 0018006
2017-07-11 23:50 Ru5tK1ng Status needs testing => resolved
2017-07-11 23:50 Ru5tK1ng Resolution open => fixed
2017-07-11 23:50 Ru5tK1ng Fixed in Version => 3.0

Questions or other issues? Contact Us.


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker