MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001253Zandronum[All Projects] Bugpublic2013-01-19 21:442018-09-30 21:39
ReporterWatermelon 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.0 
Target Version2.2Fixed in Version2.2 
Summary0001253: Team telefrag issue: G_CheckSpot always returns true if the spawn spot is > player height for the sector it's in
DescriptionI went through and did some debugging, and G_CheckSpot returns true if the team spawn spot is > the player height.

In IDL map04, the team spawn spots are 64 units off the ground (as with everything else in the map), and they proceed to drop to the ground due to gravity. For some reason, G_CheckSpot uses the Z height of the spawn spot in determining if players will telefrag, but when it thinks it's clear (because nothing is in the way at that height level), it returns true and tells the spawning function that it's clear to go.

I am unclear if the spawn spot is actually forced to the ground by gravity, or if it just spawns the player on the ground, but one of them is done and this results in telefragging of the player.


Therefore, there needs to be a tweak to either
- Check the actual location of the spawn spot and see if it's using the Z height of where the map thing starts, rather than where it may be due to gravity
- Check and see if the spawning occurs at the ground level regardless of the Z height



This has come up because it's a major inconvenience when you frag a team-mate because the author of the map made all his things spawn 64 units off the ground.
G_CheckSpot works fine in other maps where everything is ground level.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0001032closed Torr Samaho Z-Height support for player starts 
related to 0001634closed Edward-san Weird spawn telefragging behavior on Duel32 + Transfer Heights 
related to 0001499closed  Slight chance that players will spawn on each other (same spawnpoint) 
related to 0002791confirmed  Moving slightly off a spawn makes you vunerable to join/defect telefrag in team games 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-01-19 21:44WatermelonNew Issue
2013-01-20 09:25Torr SamahoNote Added: 0005802
2013-01-20 09:25Torr SamahoStatusnew => feedback
2013-01-20 16:53WatermelonNote Added: 0005803
2013-01-20 16:53WatermelonStatusfeedback => new
2013-01-21 06:26Torr SamahoNote Added: 0005805
2013-02-06 23:57WatermelonNote Added: 0005952
2013-02-07 01:07WatermelonNote Edited: 0005952bug_revision_view_page.php?bugnote_id=5952#r3276
2013-02-07 04:36ZzZomboNote Added: 0005960
2013-02-07 12:06DuskStatusnew => acknowledged
2013-02-07 12:06DuskResolutionopen => waiting for zdoom
2013-02-07 12:16Edward-sanNote Added: 0005962
2013-02-07 22:59DuskNote Added: 0005965
2013-02-07 22:59DuskStatusacknowledged => feedback
2013-02-08 12:05DuskNote Edited: 0005965bug_revision_view_page.php?bugnote_id=5965#r3291
2013-03-14 02:26WatermelonNote Added: 0006118
2013-03-14 02:26WatermelonStatusfeedback => new
2013-08-01 14:14WatermelonNote Added: 0006878
2013-08-01 23:49DuskResolutionwaiting for zdoom => open
2013-08-13 22:56QentNote Added: 0007017
2013-09-13 13:49DuskRelationship addedrelated to 0001499
2014-06-11 15:46WatermelonRelationship addedrelated to 0001032
2014-06-11 15:47WatermelonRelationship addedrelated to 0001634
2014-06-11 15:49WatermelonStatusnew => confirmed
2014-06-24 19:25WatermelonNote Added: 0009731
2014-06-24 19:25WatermelonStatusconfirmed => needs review
2014-06-24 19:32Torr SamahoNote Added: 0009733
2014-06-24 19:32Torr SamahoNote Edited: 0009733bug_revision_view_page.php?bugnote_id=9733#r5196
2014-06-24 19:33Torr SamahoNote Revision Dropped: 9733: 0005195
2014-06-24 19:33Torr SamahoStatusneeds review => feedback
2014-06-26 07:54JKist3Note Added: 0009750
2014-10-09 16:34WatermelonNote Added: 0010430
2014-10-09 16:34WatermelonStatusfeedback => new
2014-10-09 19:38Torr SamahoNote Added: 0010433
2014-10-15 23:05WatermelonNote Added: 0010603
2014-10-15 23:05WatermelonAssigned To => Watermelon
2014-10-15 23:05WatermelonStatusnew => needs review
2014-10-16 01:35WatermelonNote Edited: 0010603bug_revision_view_page.php?bugnote_id=10603#r5776
2014-10-25 12:13Torr SamahoNote Added: 0010681
2014-10-25 12:13Torr SamahoStatusneeds review => needs testing
2014-10-25 12:19cobaltTarget Version => 1.4
2014-10-25 12:19cobaltDescription Updatedbug_revision_view_page.php?rev_id=5862#r5862
2014-10-25 12:19cobaltNote Added: 0010682
2015-01-18 02:06WatermelonNote Added: 0011414
2015-01-18 02:06WatermelonStatusneeds testing => assigned
2015-01-18 03:59WaTaKiDNote Added: 0011423
2015-03-08 20:51DuskTarget Version1.4 => 2.1
2015-03-08 20:51DuskDescription Updatedbug_revision_view_page.php?rev_id=6732#r6732
2015-04-01 02:36WatermelonNote Added: 0011958
2015-04-01 09:10Edward-sanNote Added: 0011966
2015-06-24 22:44DuskTarget Version2.1 => 2.2
2016-04-10 19:25DuskStatusassigned => new
2016-04-10 19:27DuskAssigned ToWatermelon =>
2016-07-02 11:14Torr SamahoNote Added: 0015164
2016-07-02 11:15Torr SamahoStatusnew => feedback
2016-07-19 02:57Ru5tK1ngNote Added: 0015384
2016-07-19 07:46WaTaKiDNote Added: 0015386
2016-07-19 11:12Edward-sanNote Added: 0015389
2016-07-19 14:11Ru5tK1ngNote Added: 0015393
2016-07-19 17:08Edward-sanNote Added: 0015397
2016-07-19 17:19Ru5tK1ngRelationship addedrelated to 0002791
2016-08-17 20:14Edward-sanNote Added: 0015456
2016-08-17 20:15Edward-sanNote Edited: 0015456bug_revision_view_page.php?bugnote_id=15456#r9402
2016-08-18 00:41Ru5tK1ngNote Added: 0015463
2016-08-18 08:55Edward-sanNote Added: 0015473
2016-08-27 20:08Ru5tK1ngNote Added: 0015531
2016-08-27 20:08Ru5tK1ngNote Deleted: 0015531
2016-08-27 20:21Ru5tK1ngNote Added: 0015532
2017-06-10 22:35Ru5tK1ngNote Added: 0017816
2017-06-10 22:35Ru5tK1ngStatusfeedback => resolved
2017-06-10 22:35Ru5tK1ngResolutionopen => fixed
2017-06-10 22:35Ru5tK1ngFixed in Version => 2.2
2018-09-30 21:39Blzut3Statusresolved => closed

Notes
(0005802)
Torr Samaho   
2013-01-20 09:25   
Is it any different in GZDoom 323 or the most recent ZDoom version?
(0005803)
Watermelon   
2013-01-20 16:53   
How would I test team fragging in GZDoom/ZDoom?

Do I have to get TCP going with a test map?
(0005805)
Torr Samaho   
2013-01-21 06:26   
I think you don't need to test this with teams. Just create a DM map with two DM starts that are placed above the ground like the problematic team starts. Then start a two player (G)ZDoom deathmatch. You don't even need two real players, just start (G)ZDoom twice on the same machine (with its usual peer-to-peer network syntax) and see if these players ever telefrag each other.
(0005952)
Watermelon   
2013-02-06 23:57   
(edited on: 2013-02-07 01:07)
Confirmed bug on ZDoom, sent in a tracker request. We'll see where it goes.

If nothing comes of it, could there possibly be a patch made for Zan 1.1?



EDIT: Response:'http://forum.zdoom.org/viewtopic.php?f=2&t=35431 [^]'
Do we have that flag for mapinfo?
(0005960)
ZzZombo   
2013-02-07 04:36   
Nope.
(0005962)
Edward-san   
2013-02-07 12:16   
The revision which introduced the MAPINFO flag is 3746, btw.
(0005965)
Dusk   
2013-02-07 22:59   
(edited on: 2013-02-08 12:05)
ZDoom fixed this:'http://zdoom.org/Changelog/4070/files [^]'
Unfortunately the fix references the rather recent useplayerstartz mapinfo flag that Zandronum does not have.
(0006118)
Watermelon   
2013-03-14 02:26   
What are thoughts on a temporary fix? Would it be a new dmflag3? Or is checking for not being in the bounding box of a player good enough?
(0006878)
Watermelon   
2013-08-01 14:14   
I would be interested in adding a temporary fix which could be swapped out later for Zdoom's implementation when we get there.

Though if we're going to wait for zdoom this can be closed.
(0007017)
Qent   
2013-08-13 22:56   
Useplayerstartz would be a great feature to have with 3D floors. What are the chances of backporting that and then this?
(0009731)
Watermelon   
2014-06-24 19:25   
Do we mind having a temporary fix in while we wait for zdoom?

If no, close. If so, I'll code it.
(0009733)
Torr Samaho   
2014-06-24 19:32   
Depends on how big the fix is. According to 0001253:0005965 the fix is just

if (!(level.flags & LEVEL_USEPLAYERSTARTZ))
{
    z = 0;
}

Since Zandronum doesn't have LEVEL_USEPLAYERSTARTZ, the fix should just be

    z = 0;

If that's true, we can add this with a comment that it will be generalized by ZDoom changes later.
(0009750)
JKist3   
2014-06-26 07:54   
fyi this was a bug in odamex as well. It would commonly happen in judas23_: A player would drop down to get the bfg and his opponent would respawn. the player dropping to the bfg would be above the spawn point and the spawn check would return that the spawn point was available. The opponent would then spawn in the bfg, telefragging the player dropping down. Alexmax fixed this issue on odamex for what it's worth.
(0010430)
Watermelon   
2014-10-09 16:34   
Torr can we please do that? If that's all that needs to be done, I can test it with a few people and make sure it works.
(0010433)
Torr Samaho   
2014-10-09 19:38   
Sure, if the fix I posted in 0001253:0009733 really fixes the issue, we can add it. If you have time to test this, please go ahead.
(0010603)
Watermelon   
2014-10-15 23:05   
(edited on: 2014-10-16 01:35)
Pull request sent.

Tests are successful, no more telefragging occurs and it behaves expectedly.
(0010681)
Torr Samaho   
2014-10-25 12:13   
Added your patch.
(0010682)
cobalt   
2014-10-25 12:19   
Issue addressed by commit 519d3421dcb2: Player spawn height now is on the ground so any player starts in the air will not result in team telefragging unless all spawns are full (fixes 1253).
Committed by WChrisK on Wednesday 15 October 2014 19:04:55

Changes in files:
 docs/zandronum-history.txt | 1 +
 src/g_game.cpp | 5 +++++
 2 files changed, 6 insertions(+), 0 deletions(-)
(0011414)
Watermelon   
2015-01-18 02:06   
Watakid went out of his way to hunt me down, found out this isn't working in 2.0's branch when its supposedly in. I will figure out why on returning from my RL business.
(0011423)
WaTaKiD   
2015-01-18 03:59   
<WaTaKiD> it seems while i was tested earlier, some of the other testers were running around and my multiple clients happened to get shot off the spawns slightly
<WaTaKiD> but
<WaTaKiD> i just tested again, and as long as i do not move at all upon spawning, it seems to work just fine
<WaTaKiD> striker mentioned something like it should check for the player's whole collision box, instead of only the middle of the actor or something
(sorry for the misleading info at first)
(0011958)
Watermelon   
2015-04-01 02:36   
Are we okay with doing a bounding box check to see if the actor is in the way?
(0011966)
Edward-san   
2015-04-01 09:10   
Can someone check if 0001253:0011423 happens in ZDoom 2.7.0 (which contains the fix revision 4070)?
(0015164)
Torr Samaho   
2016-07-02 11:14   
Is this still a problem in 3.0?
(0015384)
Ru5tK1ng   
2016-07-19 02:57   
Quote
<WaTaKiD> i just tested again, and as long as i do not move at all upon spawning, it seems to work just fine


Is there an ideal wad to use for testing purposes?
(0015386)
WaTaKiD   
2016-07-19 07:46   
idl201x_b.pk3 map01 has 4 starts per team which is wut i used, but i can make a minimal example wad if requested

host a ctf server using idl201x_b.pk3 on map01
connect and join 4 clients to the same team but do not move them at all
there should be no telefragging ever
now move one of those clients just a tiny bit and spectate/rejoin with another client and eventually a telefrag will occur

i did notice that if u do rcon map/changemap map01 and start joining with the clients, theres a chance a telefrag could occur despite nobody moving

but if u spectate/rejoin, disconnect/reconnect, or exit/reconnect, no telefrag, as long as nobody moved
(0015389)
Edward-san   
2016-07-19 11:12   
Does it still happen with the build in 0001634 ?
(0015393)
Ru5tK1ng   
2016-07-19 14:11   
Everything that WataKid described still happens with that build. Just for the record, map01 in the IDL201x wad has 4 team starts for each team. I'm not sure if team spawns are handled differently from regular DM spawns.
(0015397)
Edward-san   
2016-07-19 17:08   
I checked the code and noticed fundamentally different issue from this ticket and causes the 'telefrags by moving a bit' problem. Can you please make a new ticket? I'll explain what's going on there.
(0015456)
Edward-san   
2016-08-17 20:14   
(edited on: 2016-08-17 20:15)
Apart from the 'moving a bit' issue, is it there any other bug which is directly connected to this ticket and happens in 3.0? If not, then this should be considered fixed because of the 3.0 code upgrade.
(0015463)
Ru5tK1ng   
2016-08-18 00:41   
I retried the CTF test case mentioned above with 3.0-160814.

After a change map vote, I telefragged one of my teammates even though there was still 1 spot available to spawn on.
(0015473)
Edward-san   
2016-08-18 08:55   
Are you sure this happens only in this kind of map and not in normal CTF maps?
(0015532)
Ru5tK1ng   
2016-08-27 20:21   
I tried using map04 of the idlwad which has 7 teamspawns per base and I tested both the build from 1634 and 160814-2010.

After joined 6 players on 1 team, the 7th player eventually telefragged a teammate despite there being 1 free spawn. It took a few tries of spectating and joining repeatedly, but eventually it happened and a map reset wasn't needed for it to occur. No one moved or defected or anything.
(0017816)
Ru5tK1ng   
2017-06-10 22:35   
After looking through the ticket again, I think the original issue of G_Checkspot and Z height spawns have long been resolved considering Zandronum now has USEPLAYERSTARTZ.

All issues regarding telefragging teammates with free spawns and what not is continued in 2791