Anonymous | Login | Signup for a new account | 2025-07-27 18:07 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 | ||||
0000829 | Zandronum | [All Projects] Bug | public | 2012-05-01 19:48 | 2018-10-01 00:03 | ||||
Reporter | unknownna | ||||||||
Assigned To | Dusk | ||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 98d | ||||||||
Target Version | 1.4 | Fixed in Version | 1.4 | ||||||
Summary | 0000829: Players automatically pick up items upon spawn after changemap map changes in Coop/Survival | ||||||||
Description | Quote from unknownna This also happens in Coop/Survival after changemap map changes. But you don't actually pick up the items, they simply disappear. | ||||||||
Steps To Reproduce | 1. skulltag.exe -file changemap_pickup_01.wad +map map01 2. "changemap map01" in the console. 3. Exit the intermission screen. | ||||||||
Attached Files | ![]() ![]() | ||||||||
![]() |
|||||||||||||||||||||
|
![]() |
|
Dusk (developer) 2012-05-01 20:20 |
I can reproduce this... but only offline. Does this happen in GZDoom r323? |
unknownna (updater) 2012-05-01 20:29 edited on: 2012-05-01 20:32 |
> Does this happen in GZDoom r323? 'http://www.skulltag.com/forum/viewtopic.php?f=33&t=28053 [^]' Quote from unknownnaQuote from Edward-san > I can reproduce this... but only offline. Strange. I'm able to reproduce it online. There's a difference between alwaysapplydmflags 1 and alwaysapplydmflags 0. The SSG isn't supposed to stay if sv_weaponstay is set to 0. |
Dusk (developer) 2012-05-01 20:36 |
Ah, I had alwaysapplydmflags set to false, I can reproduce this now online. |
Edward-san (developer) 2015-01-02 15:42 edited on: 2015-01-02 15:57 |
G_CheckSpot is called in G_CooperativeSpawnPlayer (which is called in G_FinishTravel), I suppose as an attempt to avoid telefrags, in g_game.cpp line 2561, but this will call PIT_CheckThing, which finds something (the supershotgun), then it calls P_TouchSpecialThing (which makes the pickup sound and disappear the supershotgun). There's no such thing in gzdoom 323 (well, there's no G_CooperativeSpawnPlayer, to begin with). In other words, calling G_CheckSpot in that place seems to be a bad idea .. |
Dusk (developer) 2015-01-04 01:43 |
'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/125 [^]' |
Torr Samaho (administrator) 2015-01-04 09:17 |
According to 0000829:0011218, calling G_CheckSpot in G_CooperativeSpawnPlayer is wrong in general (I vaguely remember that there also is a problem where players directly pickup weapons they spawn on instead of only picking them up after moving). If this is true, wouldn't it be much better to fix this call instead of doing a band aid that covers one instance of the problem? For instance, we could introduce
(warning not tested, not even compiled) and call that one instead of G_CheckSpot. |
Dusk (developer) 2015-01-04 09:26 edited on: 2015-01-04 09:26 |
Thinking about this again, I think pickups may be just one symptom caused by this problem. G_CooperativeSpawnPlayer uses G_CheckSpot to ensure the spot is available but this causes the player to interact with the spot. Perhaps G_CoperativeSpawnPlayer should instead be put to use something else. edward-san suggested something like this and P_TestMobjLocation for the purpose. For the patch I though figured that doing something like this would probably cause strange side effects so I figured a simple band-aid would retain status quo better. After all, that's what we appear to generally do anyway. |
Torr Samaho (administrator) 2015-01-04 10:02 |
I also thought about this a bit more. ZDoom itself is also using G_CheckSpot when respawning players, so it can't be wrong in general to use it for respawning players (actually, I bet Carn used ZDoom's SelectRandomDeathmatchSpot/G_DeathMatchSpawnPlayer as base for G_CooperativeSpawnPlayer). Thus, it looks like the only problem is that we are using G_CheckSpot also for the dummy player. Since your patch takes care of exactly this issue, I'll pull it. |
cobalt (updater) 2015-01-04 10:09 |
Issue addressed by commit d54d7116047c: - fixed: items at player starts would be inadvertently removed after a map change as G_FinishTravel uses G_CooperativeSpawnPlayer on Zandronum which, due to a series of function calls, caused the player body to pick up items. (fixes 829) Committed by Teemu Piippo [Dusk] on Sunday 04 January 2015 01:57:11 Changes in files: docs/zandronum-history.txt | 1 + src/g_level.cpp | 4 ++++ 2 files changed, 5 insertions(+), 0 deletions(-) |
WaTaKiD (updater) 2015-01-04 23:29 |
after testing with 2.0-r150104-1712, issue seems fixed |
This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why. |
|
Supporters: | WaTaKiD |
Opponents: | No one explicitly opposes this issue yet. |
![]() |
|||
Date Modified | Username | Field | Change |
2012-05-01 19:48 | unknownna | New Issue | |
2012-05-01 19:48 | unknownna | File Added: changemap_pickup_01.wad | |
2012-05-01 19:49 | unknownna | File Added: Screenshot_Doom_20120501_213945.png | |
2012-05-01 19:50 | unknownna | Status | new => confirmed |
2012-05-01 19:50 | unknownna | Description Updated | View Revisions |
2012-05-01 19:51 | unknownna | Relationship added | related to 0000411 |
2012-05-01 20:05 | Dusk | Assigned To | => Dusk |
2012-05-01 20:05 | Dusk | Status | confirmed => assigned |
2012-05-01 20:20 | Dusk | Note Added: 0003547 | |
2012-05-01 20:20 | Dusk | Status | assigned => feedback |
2012-05-01 20:29 | unknownna | Note Added: 0003549 | |
2012-05-01 20:29 | unknownna | Status | feedback => assigned |
2012-05-01 20:32 | unknownna | Note Edited: 0003549 | View Revisions |
2012-05-01 20:36 | Dusk | Note Added: 0003550 | |
2012-06-09 13:22 | Torr Samaho | Category | General => Bug |
2013-09-27 10:39 | Dusk | Status | assigned => confirmed |
2013-11-10 12:03 | Dusk | Relationship added | has duplicate 0001574 |
2014-10-07 02:46 | Watermelon | Relationship added | related to 0001917 |
2015-01-02 15:42 | Edward-san | Note Added: 0011218 | |
2015-01-02 15:43 | Edward-san | Note Edited: 0011218 | View Revisions |
2015-01-02 15:45 | Edward-san | Note Edited: 0011218 | View Revisions |
2015-01-02 15:46 | Edward-san | Note Edited: 0011218 | View Revisions |
2015-01-02 15:46 | Edward-san | Note Edited: 0011218 | View Revisions |
2015-01-02 15:57 | Edward-san | Note Edited: 0011218 | View Revisions |
2015-01-03 21:20 | Dusk | Relationship added | related to 0001983 |
2015-01-04 00:01 | Dusk | Note Added: 0011256 | |
2015-01-04 00:02 | Dusk | Note Edited: 0011256 | View Revisions |
2015-01-04 01:42 | Dusk | Note Deleted: 0011256 | |
2015-01-04 01:43 | Dusk | Note Added: 0011257 | |
2015-01-04 01:43 | Dusk | Status | confirmed => needs review |
2015-01-04 09:17 | Torr Samaho | Note Added: 0011261 | |
2015-01-04 09:18 | Torr Samaho | Status | needs review => feedback |
2015-01-04 09:26 | Dusk | Note Added: 0011263 | |
2015-01-04 09:26 | Dusk | Note Edited: 0011263 | View Revisions |
2015-01-04 10:02 | Torr Samaho | Note Added: 0011265 | |
2015-01-04 10:08 | cobalt | Status | feedback => needs testing |
2015-01-04 10:08 | cobalt | Target Version | => 1.4 |
2015-01-04 10:08 | cobalt | Description Updated | View Revisions |
2015-01-04 10:08 | cobalt | Steps to Reproduce Updated | View Revisions |
2015-01-04 10:09 | cobalt | Note Added: 0011266 | |
2015-01-04 23:29 | WaTaKiD | Note Added: 0011279 | |
2015-01-05 12:09 | Dusk | Relationship replaced | has duplicate 0001917 |
2015-01-08 14:38 | Arco | Status | needs testing => resolved |
2015-01-08 14:38 | Arco | Resolution | open => fixed |
2015-01-08 14:38 | Arco | Fixed in Version | => 1.4 |
2015-01-08 14:38 | Arco | Description Updated | View Revisions |
2015-01-08 14:38 | Arco | Steps to Reproduce Updated | View Revisions |
2018-10-01 00:03 | Blzut3 | Status | resolved => closed |
Copyright © 2000 - 2025 MantisBT Team |