MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000042Zandronum[All Projects] Bugpublic2010-09-20 21:332011-08-11 17:54
Reporterunknownna 
Assigned ToTorr Samaho 
PriorityurgentSeveritymajorReproducibilitysometimes
StatusassignedResolutionopen 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version98c 
Target VersionFixed in Version 
Summary0000042: player death sequence starts at a much higher floor height
DescriptionIf you manage to frag a player who is standing next to a wall, the corpse will sometimes begin it's death sequence at a higher floor height, even though the higher floor is much taller in map units compared to the floor the player was standing on. The player dies at a floor height of 40, but the death sequence starts at a floor height of 168.

Please watch the demo that I've included in this report. The second frag showcases the glitch. Also, Wartorn told me that if you set 'cl_capfps' to 0, the corpse will be seen as flickering between the higher and lower floor.

Done in a local server with an emulated ping of 235ms.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? 2010.09.20_22.41.59_dwango5.cld (45,093) 2010-09-20 21:33
https://zandronum.com/tracker/file_download.php?file_id=9&type=bug
? 2010.09.21_00.11.53_dwango5.cld (169,258) 2010-09-20 22:20
https://zandronum.com/tracker/file_download.php?file_id=10&type=bug
? playerposition_desync_test.wad (1,050) 2010-10-04 11:58
https://zandronum.com/tracker/file_download.php?file_id=23&type=bug
? 2010.10.04_13.54.58_playerposition_desync_test.cld (55,265) 2010-10-04 11:59
https://zandronum.com/tracker/file_download.php?file_id=24&type=bug
? playerposition_desync_test2.wad (1,866) 2010-11-02 02:56
https://zandronum.com/tracker/file_download.php?file_id=66&type=bug
? 2010.11.02_03.47.08_playerposition_desync_test2.cld (82,797) 2010-11-02 02:56
https://zandronum.com/tracker/file_download.php?file_id=67&type=bug
png Screenshot_Doom_20110426_030352.png (36,833) 2011-04-26 01:04
https://zandronum.com/tracker/file_download.php?file_id=270&type=bug
png

? playerposition_desync_test_03.wad (1,881) 2011-04-26 01:05
https://zandronum.com/tracker/file_download.php?file_id=271&type=bug
png Screenshot_Doom_20110426_034442.png (40,225) 2011-04-26 01:46
https://zandronum.com/tracker/file_download.php?file_id=272&type=bug
png

png Screenshot_Doom_20110811_194709.png (129,733) 2011-08-11 17:53
https://zandronum.com/tracker/file_download.php?file_id=415&type=bug
png

? playerposition_desync_test_04.wad (1,881) 2011-08-11 17:54
https://zandronum.com/tracker/file_download.php?file_id=416&type=bug
Issue History
Date ModifiedUsernameFieldChange
2010-09-20 21:33unknownnaNew Issue
2010-09-20 21:33unknownnaFile Added: 2010.09.20_22.41.59_dwango5.cld
2010-09-20 22:20unknownnaFile Added: 2010.09.21_00.11.53_dwango5.cld
2010-09-20 22:27WartornNote Added: 0000115
2010-09-20 22:37unknownnaNote Added: 0000116
2010-09-20 22:54WartornNote Added: 0000117
2010-09-21 03:50unknownnaNote Edited: 0000116bug_revision_view_page.php?bugnote_id=116#r60
2010-10-04 11:58unknownnaFile Added: playerposition_desync_test.wad
2010-10-04 11:59unknownnaFile Added: 2010.10.04_13.54.58_playerposition_desync_test.cld
2010-10-04 12:06unknownnaNote Added: 0000261
2010-10-04 12:06unknownnaNote Edited: 0000261bug_revision_view_page.php?bugnote_id=261#r107
2010-11-02 02:54unknownnaNote Edited: 0000261bug_revision_view_page.php?bugnote_id=261#r256
2010-11-02 02:56unknownnaFile Added: playerposition_desync_test2.wad
2010-11-02 02:56unknownnaFile Added: 2010.11.02_03.47.08_playerposition_desync_test2.cld
2011-04-26 01:04unknownnaFile Added: Screenshot_Doom_20110426_030352.png
2011-04-26 01:05unknownnaFile Added: playerposition_desync_test_03.wad
2011-04-26 01:06unknownnaNote Added: 0001471
2011-04-26 01:06unknownnaStatusnew => confirmed
2011-04-26 01:06unknownnaPrioritylow => high
2011-04-26 01:06unknownnaSeverityminor => major
2011-04-26 01:16unknownnaNote Edited: 0001471bug_revision_view_page.php?bugnote_id=1471#r762
2011-04-26 01:19unknownnaNote Edited: 0001471bug_revision_view_page.php?bugnote_id=1471#r763
2011-04-26 01:23unknownnaPriorityhigh => urgent
2011-04-26 01:37Torr SamahoNote Added: 0001472
2011-04-26 01:46unknownnaNote Added: 0001473
2011-04-26 01:46unknownnaFile Added: Screenshot_Doom_20110426_034442.png
2011-04-26 01:48unknownnaNote Edited: 0001473bug_revision_view_page.php?bugnote_id=1473#r765
2011-04-26 04:38unknownnaNote Added: 0001476
2011-05-21 22:28Torr SamahoNote Added: 0001721
2011-05-21 22:53Torr SamahoAssigned To => Torr Samaho
2011-05-21 22:53Torr SamahoStatusconfirmed => feedback
2011-05-21 23:14unknownnaNote Added: 0001725
2011-05-21 23:14unknownnaStatusfeedback => assigned
2011-05-21 23:17unknownnaNote Edited: 0001725bug_revision_view_page.php?bugnote_id=1725#r880
2011-05-21 23:37Torr SamahoNote Added: 0001727
2011-05-22 00:14unknownnaNote Added: 0001728
2011-05-22 00:28Torr SamahoNote Added: 0001729
2011-07-24 07:17unknownnaNote Added: 0001941
2011-07-24 07:20unknownnaNote Edited: 0001941bug_revision_view_page.php?bugnote_id=1941#r979
2011-07-24 12:01Torr SamahoNote Added: 0001942
2011-08-11 17:52unknownnaNote Added: 0002117
2011-08-11 17:53unknownnaFile Added: Screenshot_Doom_20110811_194709.png
2011-08-11 17:54unknownnaFile Added: playerposition_desync_test_04.wad
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug

Notes
(0000115)
Wartorn   
2010-09-20 22:27   
Verified in 98d-2937. I don't think this is an easy fix, though.
(0000116)
unknownna   
2010-09-20 22:37   
(edited on: 2010-09-21 03:50)
Added a second demo. The client shooting the other client has an emulated ping of 335ms. It seemed very probable to happen with that setup; where the shooter had a higher ping than the one being shot.

The desynchronization is that the client of the shooter sees the other client as being on a higher floor, but the other client doesn't see itself as being on the higher floor. The demo is recorded from the shooter's POV, so coop-spying the other client won't allow you to see the desynchronization as it truly is.
(0000117)
Wartorn   
2010-09-20 22:54   
Some additional insight: It seems to be really angle and position dependent, I could easily reproduce the problems based on the locations given in the demos, but not anywhere else.
(0000261)
unknownna   
2010-10-04 12:06   
(edited on: 2010-11-02 02:54)
Made an example WAD and a demo to it. It has nothing to do with the death sequence.

EDIT:

Made another example WAD with a demo to it. Demo uses 98c. Had no ping emulation. A simple pistol shot makes the other player flicker up to the higher floor.
(0001471)
unknownna   
2011-04-26 01:06   
(edited on: 2011-04-26 01:19)
Thanks to EmZee712 and Fluffles, we can now easily reproduce this issue.

Steps to reproduce:

1. Start a standard server with the example WAD loaded.
2. Connect two clients to the server.
3. Join the game with client A.
4. Bump into the diagonal wall with client A.

Edit:

Hmm, it seems that this only happens in 98e. It started to occur in build 3122M (software 3D floors).
(0001472)
Torr Samaho   
2011-04-26 01:37   
> Hmm, it seems that this only happens in 98e. It started to occur in build 3122M (software 3D floors).

But it only happens online?
(0001473)
unknownna   
2011-04-26 01:46   
(edited on: 2011-04-26 01:48)
Yes. Another strange thing is that your bullet puffs are affected by it as well. This does not happen offline. But the bullet puff issue is also present in 98d.
(0001476)
unknownna   
2011-04-26 04:38   
IIRC, you fixed this issue in that build.
(0001721)
Torr Samaho   
2011-05-21 22:28   
If this fixes the issue then I know what's causing it. In this case the fix will increase net traffic.
(0001725)
unknownna   
2011-05-21 23:14   
(edited on: 2011-05-21 23:17)
Very nice. It fixed the issue. But the issue is still present for your own puffs though.

> In this case the fix will increase net traffic.

No need to worry about this.
(0001727)
Torr Samaho   
2011-05-21 23:37   
> But the issue is still present for your own puffs though.

I'm sure that this has the same reason: To save bandwidth the server only sent the player's position at 16 bit accuracy. When at a sector boundary, this could cause a player to be rounded to the neighboring sector and since a player can't be inside the floor, it was then raised to the floor height. I made the server sent the x/y position at full precision, fixing the problems for players. I really don't want to send the puffs at full precision though, since there are potentially a lot of puffs, this would eat a lot of bandwidth.

> No need to worry about this.

Well, at latest if a broadband connection is not enough anymore for simple deathmatch, we need to worry about these things.
(0001728)
unknownna   
2011-05-22 00:14   
> Well, at latest if a broadband connection is not enough anymore for simple deathmatch, we need to worry about these things.

It was only directed towards this particular case.

> I'm sure that this has the same reason: To save bandwidth the server only sent the player's position at 16 bit accuracy. When at a sector boundary, this could cause a player to be rounded to the neighboring sector and since a player can't be inside the floor, it was then raised to the floor height. I made the server sent the x/y position at full precision, fixing the problems for players. I really don't want to send the puffs at full precision though, since there are potentially a lot of puffs, this would eat a lot of bandwidth.

I see. I wonder where Spleen went. If ST had client-side puff prediction, this wouldn't be an issue, right? So the visual error has no effect on the gameplay? In that case, it's not so important to have it fixed.
(0001729)
Torr Samaho   
2011-05-22 00:28   
> I wonder where Spleen went.

AFAIK he is too busy with RL issues.

> If ST had client-side puff prediction, this wouldn't be an issue, right?

Yes, puff prediction is a very difficult issue though. Unless it is 100% accurate (which likely is impossible to achieve), IMHO it's better not to do any puff prediction.

> So the visual error has no effect on the gameplay?

Other than the displayed puff position being off, it shouldn't have any effect.
(0001941)
unknownna   
2011-07-24 07:17   
(edited on: 2011-07-24 07:20)
> Yes, puff prediction is a very difficult issue though. Unless it is 100% accurate (which likely is impossible to achieve), IMHO it's better not to do any puff prediction.

It seems that ZDaemon's puff prediction works in a certain way. Clients only predict all the puffs that don't hit anything. But the puffs that hit something are delayed. So no blood puffs are predicted locally. Would it be possible to have a similar setup in ST?
(0001942)
Torr Samaho   
2011-07-24 12:01   
> Clients only predict all the puffs that don't hit anything. But the puffs that hit something are delayed. So no blood puffs are predicted locally. Would it be possible to have a similar setup in ST?

This would be possible but still has the same problem: Unless you find a way to make the prediction perfectly accurate the client doesn't know exactly how many of the puffs hit and how many miss. So if you do it like this, it's very possible that you see too few or too many puffs.
(0002117)
unknownna   
2011-08-11 17:52   
The player z position still desyncs if the other player jumps near the ledges when "sv_aircontrol" is set to 0 and "compat_limited_airmovement" is set to 1 (oldschool). It looks pretty stupid since the player is seen as skipping from the higher floor to the lower floor rather than jumping.