|
Notes |
|
|
(0003547)
|
|
Dusk
|
|
2012-05-01 20:20
|
|
|
I can reproduce this... but only offline. Does this happen in GZDoom r323? |
|
|
|
(0003549)
|
|
unknownna
|
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.
|
|
|
|
(0003550)
|
|
Dusk
|
|
2012-05-01 20:36
|
|
|
Ah, I had alwaysapplydmflags set to false, I can reproduce this now online. |
|
|
|
(0011218)
|
|
Edward-san
|
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 ..
|
|
|
|
(0011257)
|
|
Dusk
|
|
2015-01-04 01:43
|
|
|
|
|
|
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. |
|
|
|
(0011263)
|
|
Dusk
|
|
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.
|
|
|
|
|
|
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. |
|
|
|
(0011266)
|
|
cobalt
|
|
2015-01-04 10:09
|
|
|
|
|
|
|
after testing with 2.0-r150104-1712, issue seems fixed |
|
changemap_pickup_01.wad (2,330) 2012-05-01 19:48
Screenshot_Doom_20120501_213945.png (31,997) 2012-05-01 19:49