Anonymous | Login | Signup for a new account | 2024-04-25 14:40 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0003167 | Zandronum | [All Projects] Bug | public | 2017-06-23 00:02 | 2018-09-30 21:42 | ||||
Reporter | Combinebobnt | ||||||||
Assigned To | Torr Samaho | ||||||||
Priority | high | Severity | major | Reproducibility | sometimes | ||||
Status | closed | Resolution | fixed | ||||||
Platform | Microsoft | OS | Windows | OS Version | XP/Vista/7 | ||||
Product Version | 3.0-beta | ||||||||
Target Version | 3.0 | Fixed in Version | 3.0 | ||||||
Summary | 0003167: Players spawning without weapons in cooperative gametypes | ||||||||
Description | I'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 Reproduce | 1. 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 Information | wads: 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 [^]' | ||||||||
Attached Files | |||||||||
Relationships | ||||||
|
Notes | |
(0017879) Combinebobnt (reporter) 2017-06-23 00:03 |
arg said it happened often in chex quest plain gameplay. ok i need to test |
(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 |
(0017881) Argentum (reporter) 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 (updater) 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 (updater) 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 (administrator) 2017-06-25 13:28 |
Thanks! Looks good except for some style issue, see my comments on bitbucket. |
(0017918) Ru5tK1ng (updater) 2017-06-25 16:31 |
Updated based off your comments. |
(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? |
(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. |
(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. |
(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. |
(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:'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 (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? |
(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:'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 (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. |
(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. |
(0017943) Combinebobnt (reporter) 2017-06-27 01:28 |
happens when alwaysapplydmflags is 1. tested in lastest blahblahblah v 625 |
(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. :) |
(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: '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 (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. 'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/210/revived-dead-spectators-had-no-inventory/diff [^]' |
(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. |
(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. |
(0018006) Combinebobnt (reporter) 2017-07-11 22:44 |
tested in 170709 and looks like it works |
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 |
2018-09-30 21:42 | Blzut3 | Status | resolved => closed |
Copyright © 2000 - 2024 MantisBT Team |