MantisBT - Zandronum
View Issue Details
0001971Zandronum[All Projects] Bugpublic2014-10-25 08:432024-11-27 09:18
Frits 
Torr Samaho 
normalmajoralways
confirmedopen 
MicrosoftWindowsXP/Vista/7
1.3 
 
0001971: Floors don't reset properly online for clients
After trying to play hr2 map 31 i noticed how floor desynced on the client after i died and the map restarted. Reconnecting fixed the issue.



Start a hr2final map 31, activate the lift, die on the lift, round restarts and the lift will be broken.

Or play the demo with

zandronum -playdemo Zandronum_25.10.2014_10.37.07.cld -file hr2final.wad hr2-final-fix.wad NewTextColours1_170.pk3 connectsound.wad

and jump to the relevant demo position with

demo_skiptics 2000


1. zandronum -iwad doom2.wad -file hr2_floor_test_02.wad -host
2. zandronum -iwad doom2.wad -file hr2_floor_test_02.wad -connect localhost +idmypos 1
3. Join the game.
4. Fire at the switch with the pistol. The floor will lower.
5. Press +use to reset the map.
6. Repeat step 4 and 5 until it breaks.
No tags attached.
related to 0003334assigned Kaminsky Tickrate discrepancies between clients/servers 
related to 0002401confirmed  Floor_Waggle doesn't reset floor to its proper position online 
related to 0000459confirmed  "one/five minute warning" message always displayed for newly connected clients on certain maps 
? Zandronum_25.10.2014_10.37.07.cld (719,823) 2014-10-25 08:46
https://zandronum.com/tracker/file_download.php?file_id=1313&type=bug
png Screenshot_Doom_20141025_103441.png (327,191) 2014-10-25 08:47
https://zandronum.com/tracker/file_download.php?file_id=1314&type=bug
? hr2_floor_test_02.wad (72,112) 2015-08-11 15:26
https://zandronum.com/tracker/file_download.php?file_id=1615&type=bug
png Screenshot_Doom_20150811_171302.png (88,241) 2015-08-11 15:30
https://zandronum.com/tracker/file_download.php?file_id=1616&type=bug
png

? hr2_floor_test_03.wad (89,610) 2024-11-27 09:15
https://zandronum.com/tracker/file_download.php?file_id=3179&type=bug
Issue History
2014-10-25 08:43FritsNew Issue
2014-10-25 08:45Torr SamahoNote Added: 0010677
2014-10-25 08:46FritsFile Added: Zandronum_25.10.2014_10.37.07.cld
2014-10-25 08:47FritsNote Added: 0010678
2014-10-25 08:47FritsNote Edited: 0010678bug_revision_view_page.php?bugnote_id=10678#r5855
2014-10-25 08:47FritsFile Added: Screenshot_Doom_20141025_103441.png
2014-10-25 08:49FritsNote Edited: 0010678bug_revision_view_page.php?bugnote_id=10678#r5856
2014-10-25 08:50FritsNote Edited: 0010678bug_revision_view_page.php?bugnote_id=10678#r5857
2014-10-25 09:10FritsNote Edited: 0010678bug_revision_view_page.php?bugnote_id=10678#r5858
2014-10-25 11:18Torr SamahoSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=5860#r5860
2014-10-25 11:31Torr SamahoNote Added: 0010680
2014-10-25 11:31Torr SamahoAssigned To => Torr Samaho
2014-10-25 11:31Torr SamahoStatusnew => assigned
2014-10-25 11:31Torr SamahoStatusassigned => feedback
2014-10-25 15:40FritsNote Added: 0010685
2014-10-25 15:40FritsStatusfeedback => assigned
2014-10-25 15:53FritsNote Edited: 0010685bug_revision_view_page.php?bugnote_id=10685#r5864
2014-10-25 16:07Torr SamahoNote Added: 0010686
2015-04-04 16:45FritsNote Added: 0012019
2015-04-04 16:50FritsNote Edited: 0012019bug_revision_view_page.php?bugnote_id=12019#r6905
2015-04-04 16:55FritsNote Edited: 0012019bug_revision_view_page.php?bugnote_id=12019#r6906
2015-04-04 17:02FritsNote Edited: 0012019bug_revision_view_page.php?bugnote_id=12019#r6907
2015-08-10 14:27unknownnaNote Added: 0013196
2015-08-10 14:27unknownnaStatusassigned => confirmed
2015-08-10 14:43unknownnaNote Edited: 0013196bug_revision_view_page.php?bugnote_id=13196#r7886
2015-08-10 14:44unknownnaNote Edited: 0013196bug_revision_view_page.php?bugnote_id=13196#r7887
2015-08-10 16:11Edward-sanNote Added: 0013201
2015-08-10 16:11Edward-sanStatusconfirmed => feedback
2015-08-11 11:25FritsNote Added: 0013209
2015-08-11 11:25FritsStatusfeedback => assigned
2015-08-11 13:36unknownnaNote Added: 0013210
2015-08-11 14:30unknownnaNote Edited: 0013210bug_revision_view_page.php?bugnote_id=13210#r7897
2015-08-11 14:39unknownnaNote Edited: 0013210bug_revision_view_page.php?bugnote_id=13210#r7898
2015-08-11 15:25unknownnaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=7899#r7899
2015-08-11 15:26unknownnaFile Added: hr2_floor_test_02.wad
2015-08-11 15:26unknownnaStatusassigned => confirmed
2015-08-11 15:30unknownnaFile Added: Screenshot_Doom_20150811_171302.png
2015-08-11 15:41unknownnaNote Edited: 0013210bug_revision_view_page.php?bugnote_id=13210#r7900
2015-08-11 15:45unknownnaNote Edited: 0013210bug_revision_view_page.php?bugnote_id=13210#r7901
2015-08-12 15:46unknownnaRelationship addedrelated to 0002401
2024-03-07 14:19unknownnaNote Added: 0023312
2024-04-14 23:34unknownnaRelationship addedrelated to 0000459
2024-11-27 09:15unknownnaFile Added: hr2_floor_test_03.wad
2024-11-27 09:15unknownnaRelationship addedrelated to 0003334
2024-11-27 09:18unknownnaNote Added: 0024163

Notes
(0010677)
Torr Samaho   
2014-10-25 08:45   
Is this a new problem in 1.3 or did this also happen in earlier versions? And can you record a client demo that shows this issue?
(0010678)
Frits   
2014-10-25 08:47   
(edited on: 2014-10-25 09:10)
you're faster then i can add a demo :). This didn't exist in 1.2.2

As you can see in the screenshot and demo, the floor looks like it's lowered on the client but on the server it's actually on the same level as i am standing.

EDIT: it's not happining all the time more like half of my attempts. And as far as i can tell when there are 2 players it can be possible that only player A sees it and vice versa.

(0010680)
Torr Samaho   
2014-10-25 11:31   
Thanks for the demo!
Quote from Frits
This didn't exist in 1.2.2

In that case, can you check older 1.3 builds (see here and here) to narrow down when this crept in?
(0010685)
Frits   
2014-10-25 15:40   
(edited on: 2014-10-25 15:53)
It's present in 1.3 140610-2242.

I wasn't able to run to demo in other versions of zandronum with Zcinema as this demo somehow failed to run on it.
I tried reproducing the bug in a local server but that unfortunately didn't work either.

(0010686)
Torr Samaho   
2014-10-25 16:07   
Unfortunately, playing the demo is not sufficient to check whether a certain revision is affected by the bug. It needs to be checked with client and server using the revision in question.

Quote from Frits

I tried reproducing the bug in a local server but that unfortunately didn't work either.

Does this mean the problem only happens if you use a non-local server, regardless of the binary revision? In this case, can you check if you can reproduce the problem with a ping / packet loss emulator like Gamer's Proxy?
(0012019)
Frits   
2015-04-04 16:45   
(edited on: 2015-04-04 17:02)
Sorry for the long delay in my reply Torr, as i am quite busy in real life.
I managed to reproduce this in 2.0 with HR2 MAP31 on a localhost server w/o using gamersproxy. However i cannot produce it when i'm offline or in multiplayer emulation mode.

A good way to reproduce this is to activate the lift, die while it's lowering and then jump off the edge so that when the survival countdown timer reaches 0 you're still mid-air(falling down towards the lift floor). I hope that makes sense to you ;)

(0013196)
unknownna   
2015-08-10 14:27   
(edited on: 2015-08-10 14:44)
I can confirm this. It seems to have something to do with ping spikes. It's very easy to reproduce the issue with these proxy settings when using Gamer's Proxy:

* The ping is combined at 40 ms.
* Ping spike chance is 75.00%.
* Max ping spike strength is 500.00%.

I managed to reproduce the issue in 98d and 1.0 as well.

(0013201)
Edward-san   
2015-08-10 16:11   
A reduced example wad would really help here.
(0013209)
Frits   
2015-08-11 11:25   
That's so strange, I've played this map a million and one times in 98D and never noticed it. Maybe it just occurs more now?

@edward-san but everyone has hr2.wad :P (-map map31 -nomonsters)
(0013210)
unknownna   
2015-08-11 13:36   
(edited on: 2015-08-11 15:45)
Quote from Edward-san
A reduced example wad would really help here.

It doesn't seem to happen in hr2_floor_test_01.wad. It also doesn't happen when I copy-paste an empty shell of the map. It starts to happen once I copy-paste all the things as well. I'll try to narrow this down further.

It seems to be dependent on how many things there are present in the map. The more things there are present, the more likely it is to break.

It can also happen with a direct LAN connection to the server.

On a side note, the new example WAD causes the gameplay to lag/stutter considerably more offline when resetting the map once. The lag/stutter is very reminiscent of the RichEdit control lag issue. However, unlike the RichEdit lag issue, this lag goes away after a "map/changemap" map change and starts to lag again whenever you reset the map.

(0023312)
unknownna   
2024-03-07 14:19   
I figured out what makes this break.

If there's too many actors (1760+ things) on the map that have a minimum of 2 frames in their idle animation, for instance "BKEY AB 10", it glitches. It can be any thing that has a few frames of animation in its idle state. The more actors that animate, the worse it desyncs. The same amount of things that only have 1 frame of looping animation or have a -1 frame in their idle states don't cause the glitch.

This code causes the glitch:

Spawn:
        BKEY AB 10
        Loop


This code doesn't:

Spawn:
        BKEY A 10
        Loop


Why this makes floors break at map resets, I'm not sure. But maybe this information can help you narrow it down.
(0024163)
unknownna   
2024-11-27 09:18   
This issue is curiously linked to 0003334, particularly when using "cl_usemovebuffer 1". This causes the map to break more often even with a local connection to the server. You can "fix" the issue by turning the movebuffer off, and if you use the chasecam to observe your own player, you can see how the player shifts heights depending on the "cl_usemovebuffer" setting. The player animation also breaks and won't stop animating. I also recommend using the "idmypos" cheat to see the z-height desync.

There are 2 maps (MAP01 and MAP02) in the updated example wad. They are identical other than having different dummy actors that animate differently. The 1st map that almost always glitches out uses 2 frames for its actors, whereas the 2nd map that doesn't break uses 1 frame for its actors.

Simply shoot at the switch, and press +use to reset the map. Use "changemap/nextmap" to do the same on the other map that doesn't break.

I can confirm that the offending map also breaks in Skulltag 98d, so it's an ancient issue that's made more present with the new movebuffer.

Quote from unknownna
On a side note, the new example WAD causes the gameplay to lag/stutter considerably more offline when resetting the map once. The lag/stutter is very reminiscent of the RichEdit control lag issue. However, unlike the RichEdit lag issue, this lag goes away after a "map/changemap" map change and starts to lag again whenever you reset the map.


This does not seem to be the case anymore from testing. It never lags now. It must have been changed or fixed by something else later on.