Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
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.
Attached Files

- Relationships
related to 0001032closedTorr Samaho Z-Height support for player starts 
related to 0001634closedEdward-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 

-  Notes
User avatar (0005802)
Torr Samaho (administrator)
2013-01-20 09:25

 Is it any different in GZDoom 323 or the most recent ZDoom version?
User avatar (0005803)
Watermelon (developer)
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?
User avatar (0005805)
Torr Samaho (administrator)
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.
User avatar (0005952)
Watermelon (developer)
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?
User avatar (0005960)
ZzZombo (reporter)
2013-02-07 04:36

 Nope.
User avatar (0005962)
Edward-san (developer)
2013-02-07 12:16

 The revision which introduced the MAPINFO flag is 3746, btw.
User avatar (0005965)
Dusk (developer)
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.
User avatar (0006118)
Watermelon (developer)
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?
User avatar (0006878)
Watermelon (developer)
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.
User avatar (0007017)
Qent (updater)
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?
User avatar (0009731)
Watermelon (developer)
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.
User avatar (0009733)
Torr Samaho (administrator)
2014-06-24 19:32
edited on: 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.
User avatar (0009750)
JKist3 (reporter)
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.
User avatar (0010430)
Watermelon (developer)
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.
User avatar (0010433)
Torr Samaho (administrator)
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.
User avatar (0010603)
Watermelon (developer)
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.
User avatar (0010681)
Torr Samaho (administrator)
2014-10-25 12:13

 Added your patch.
User avatar (0010682)
cobalt (updater)
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(-)
User avatar (0011414)
Watermelon (developer)
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.
User avatar (0011423)
WaTaKiD (updater)
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)
User avatar (0011958)
Watermelon (developer)
2015-04-01 02:36

 Are we okay with doing a bounding box check to see if the actor is in the way?
User avatar (0011966)
Edward-san (developer)
2015-04-01 09:10

 Can someone check if 0001253:0011423 happens in ZDoom 2.7.0 (which contains the fix revision 4070)?
User avatar (0015164)
Torr Samaho (administrator)
2016-07-02 11:14

 Is this still a problem in 3.0?
User avatar (0015384)
Ru5tK1ng (updater)
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?
User avatar (0015386)
WaTaKiD (updater)
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
User avatar (0015389)
Edward-san (developer)
2016-07-19 11:12

 Does it still happen with the build in 0001634 ?
User avatar (0015393)
Ru5tK1ng (updater)
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.
User avatar (0015397)
Edward-san (developer)
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.
User avatar (0015456)
Edward-san (developer)
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.
User avatar (0015463)
Ru5tK1ng (updater)
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.
User avatar (0015473)
Edward-san (developer)
2016-08-18 08:55

 Are you sure this happens only in this kind of map and not in normal CTF maps?
User avatar (0015532)
Ru5tK1ng (updater)
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.
User avatar (0017816)
Ru5tK1ng (updater)
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

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

- Issue History
Date Modified Username Field Change
2013-01-19 21:44 Watermelon New Issue
2013-01-20 09:25 Torr Samaho Note Added: 0005802
2013-01-20 09:25 Torr Samaho Status new => feedback
2013-01-20 16:53 Watermelon Note Added: 0005803
2013-01-20 16:53 Watermelon Status feedback => new
2013-01-21 06:26 Torr Samaho Note Added: 0005805
2013-02-06 23:57 Watermelon Note Added: 0005952
2013-02-07 01:07 Watermelon Note Edited: 0005952 View Revisions
2013-02-07 04:36 ZzZombo Note Added: 0005960
2013-02-07 12:06 Dusk Status new => acknowledged
2013-02-07 12:06 Dusk Resolution open => waiting for zdoom
2013-02-07 12:16 Edward-san Note Added: 0005962
2013-02-07 22:59 Dusk Note Added: 0005965
2013-02-07 22:59 Dusk Status acknowledged => feedback
2013-02-08 12:05 Dusk Note Edited: 0005965 View Revisions
2013-03-14 02:26 Watermelon Note Added: 0006118
2013-03-14 02:26 Watermelon Status feedback => new
2013-08-01 14:14 Watermelon Note Added: 0006878
2013-08-01 23:49 Dusk Resolution waiting for zdoom => open
2013-08-13 22:56 Qent Note Added: 0007017
2013-09-13 13:49 Dusk Relationship added related to 0001499
2014-06-11 15:46 Watermelon Relationship added related to 0001032
2014-06-11 15:47 Watermelon Relationship added related to 0001634
2014-06-11 15:49 Watermelon Status new => confirmed
2014-06-24 19:25 Watermelon Note Added: 0009731
2014-06-24 19:25 Watermelon Status confirmed => needs review
2014-06-24 19:32 Torr Samaho Note Added: 0009733
2014-06-24 19:32 Torr Samaho Note Edited: 0009733 View Revisions
2014-06-24 19:33 Torr Samaho Note Revision Dropped: 9733: 0005195
2014-06-24 19:33 Torr Samaho Status needs review => feedback
2014-06-26 07:54 JKist3 Note Added: 0009750
2014-10-09 16:34 Watermelon Note Added: 0010430
2014-10-09 16:34 Watermelon Status feedback => new
2014-10-09 19:38 Torr Samaho Note Added: 0010433
2014-10-15 23:05 Watermelon Note Added: 0010603
2014-10-15 23:05 Watermelon Assigned To => Watermelon
2014-10-15 23:05 Watermelon Status new => needs review
2014-10-16 01:35 Watermelon Note Edited: 0010603 View Revisions
2014-10-25 12:13 Torr Samaho Note Added: 0010681
2014-10-25 12:13 Torr Samaho Status needs review => needs testing
2014-10-25 12:19 cobalt Target Version => 1.4
2014-10-25 12:19 cobalt Description Updated View Revisions
2014-10-25 12:19 cobalt Note Added: 0010682
2015-01-18 02:06 Watermelon Note Added: 0011414
2015-01-18 02:06 Watermelon Status needs testing => assigned
2015-01-18 03:59 WaTaKiD Note Added: 0011423
2015-03-08 20:51 Dusk Target Version 1.4 => 2.1
2015-03-08 20:51 Dusk Description Updated View Revisions
2015-04-01 02:36 Watermelon Note Added: 0011958
2015-04-01 09:10 Edward-san Note Added: 0011966
2015-06-24 22:44 Dusk Target Version 2.1 => 2.2
2016-04-10 19:25 Dusk Status assigned => new
2016-04-10 19:27 Dusk Assigned To Watermelon =>
2016-07-02 11:14 Torr Samaho Note Added: 0015164
2016-07-02 11:15 Torr Samaho Status new => feedback
2016-07-19 02:57 Ru5tK1ng Note Added: 0015384
2016-07-19 07:46 WaTaKiD Note Added: 0015386
2016-07-19 11:12 Edward-san Note Added: 0015389
2016-07-19 14:11 Ru5tK1ng Note Added: 0015393
2016-07-19 17:08 Edward-san Note Added: 0015397
2016-07-19 17:19 Ru5tK1ng Relationship added related to 0002791
2016-08-17 20:14 Edward-san Note Added: 0015456
2016-08-17 20:15 Edward-san Note Edited: 0015456 View Revisions
2016-08-18 00:41 Ru5tK1ng Note Added: 0015463
2016-08-18 08:55 Edward-san Note Added: 0015473
2016-08-27 20:08 Ru5tK1ng Note Added: 0015531
2016-08-27 20:08 Ru5tK1ng Note Deleted: 0015531
2016-08-27 20:21 Ru5tK1ng Note Added: 0015532
2017-06-10 22:35 Ru5tK1ng Note Added: 0017816
2017-06-10 22:35 Ru5tK1ng Status feedback => resolved
2017-06-10 22:35 Ru5tK1ng Resolution open => fixed
2017-06-10 22:35 Ru5tK1ng Fixed in Version => 2.2
2018-09-30 21:39 Blzut3 Status resolved => closed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker