Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000829Zandronum[All Projects] Bugpublic2012-05-01 19:482018-10-01 00:03
Reporterunknownna 
Assigned ToDusk 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version98d 
Target Version1.4Fixed in Version1.4 
Summary0000829: Players automatically pick up items upon spawn after changemap map changes in Coop/Survival
Description
Quote from unknownna
It seems that players are hard coded to automatically pick up items upon spawn in (Team)Possession/Terminator.

This also happens in Coop/Survival after changemap map changes. But you don't actually pick up the items, they simply disappear.
Steps To Reproduce1. skulltag.exe -file changemap_pickup_01.wad +map map01
2. "changemap map01" in the console.
3. Exit the intermission screen.
Attached Files? file icon changemap_pickup_01.wad [^] (2,330 bytes) 2012-05-01 19:48
png file icon Screenshot_Doom_20120501_213945.png [^] (31,997 bytes) 2012-05-01 19:49

- Relationships
related to 0000411closedTorr Samaho Players automatically pick up items upon spawn in (Team)Possession/Terminator 
has duplicate 0001574closedDusk Spawning on items after map change results in no said items 
has duplicate 0001917closed Upon changemap, player attempts to pick up any colliding Inventory items 
related to 0001983closed weapon missing after teleporting within a hub, due to player destinations placed on top of items. 

-  Notes
User avatar (0003547)
Dusk (developer)
2012-05-01 20:20

I can reproduce this... but only offline. Does this happen in GZDoom r323?
User avatar (0003549)
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 unknownna
Quote from Edward-san
Does it occurr in gzdoom 323? If yes, does it also in latest zdoom svn?

No. In GZDoom 323, the player only picks up the megasphere when s/he starts to move, or crouches.

> 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.

User avatar (0003550)
Dusk (developer)
2012-05-01 20:36

Ah, I had alwaysapplydmflags set to false, I can reproduce this now online.
User avatar (0011218)
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 ..

User avatar (0011257)
Dusk (developer)
2015-01-04 01:43

'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/125 [^]'
User avatar (0011261)
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

bool G_CheckSpotNoPickup (int playernum, FMapThing *mthing)
{
  const bool hadPickup = ( players[playernum].mo && players[playernum].mo->flags & MF_PICKUP );
  // [TP/BB] Prevent the current player body from picking up anything with the G_CheckSpot call.
  if ( hadPickup )
    players[playernum].mo->flags &= ~MF_PICKUP;
  const bool ret = G_CheckSpot (playernum, mthing);
  // [BB] Restore the flag if necessary.
  if ( hadPickup )
    players[playernum].mo->flags |= MF_PICKUP;
  return ret;
}

(warning not tested, not even compiled) and call that one instead of G_CheckSpot.
User avatar (0011263)
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.

User avatar (0011265)
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.
User avatar (0011266)
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(-)
User avatar (0011279)
WaTaKiD (updater)
2015-01-04 23:29

after testing with 2.0-r150104-1712, issue seems fixed

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: WaTaKiD
Opponents: No one explicitly opposes this issue yet.

- Issue History
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






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker