MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001162Zandronum[All Projects] Bugpublic2012-11-03 16:022019-06-04 21:54
Reporterunknownna 
Assigned ToDusk 
PriorityhighSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version1.0 
Target Version2.2Fixed in Version 
Summary0001162: A_Jump causes nasty desyncs to occur in Futur War online
DescriptionDue to the way the clients handle A_Jump, actor flags/properties can desync between the client and server. Many of the monsters in Futur War use A_Jump to go to their death states. The death states call A_NoBlocking, but it isn't called on the client-end. If you then move through the corpses, it'll lag a lot. It feels terrible. And it's even worse if cl_ticsperupdate is set to 3.

Now, you can apparently work around this by adding a 1 tic frame before the one that calls A_NoBlocking, but I don't know if anyone is going to go through every affected monster in Futur War and do that anytime soon.
Steps To Reproduce1. zandronum -file thing_jumpdesync_01.wad -host
2. Connect a client to the server and join the game.
3. Aim at the zombiemen and press +attack.
4. Move to the zombiemen corpses.
Additional Information
Actor ZombieMan_02 Replaces ZombieMan
{
    Monster
    Health 5
    Radius 256
    Height 256
    States
    {
    Spawn:
        POSS A 10
        Loop
    See:
        POSS AABBCCDD 4
        Loop
    Missile:
        Stop
    Pain:
        Goto See
    Death:
        TNT1 A 0
        POSS A 10 A_NoBlocking
        POSS L -1
        Stop
    Death.DamageType_01:
        TNT1 A 0
        TNT1 A 1 A_Jump (256, "Death")
        Stop
    }
}
TagsNo tags attached.
Relationships
related to 0001200closed Torr Samaho "randomguy" causes clients to freeze in online games 
related to 0002381confirmed  Thing desync after map changes in hubs: Clients think that dead actors are SOLID and/or they don't know of DeathHeight 
Attached Files? thing_jumpdesync_01.wad (968) 2012-11-03 16:02
https://zandronum.com/tracker/file_download.php?file_id=866&type=bug
Issue History
Date ModifiedUsernameFieldChange
2012-11-03 16:02unknownnaNew Issue
2012-11-03 16:02unknownnaFile Added: thing_jumpdesync_01.wad
2012-11-03 16:02unknownnaStatusnew => confirmed
2013-08-02 00:08ArcoNote Added: 0006890
2013-08-02 10:41DuskNote Added: 0006894
2013-08-02 10:41DuskRelationship addedrelated to 0001200
2015-06-14 20:44DuskAssigned To => Dusk
2015-06-14 20:44DuskStatusconfirmed => assigned
2015-07-21 12:10unknownnaNote Added: 0012983
2015-07-21 12:10unknownnaStatusassigned => needs review
2015-07-21 12:13unknownnaNote Added: 0012984
2015-07-21 12:13unknownnaTarget Version => 2.2
2015-08-09 10:24unknownnaRelationship addedrelated to 0002381
2015-08-19 19:23Torr SamahoNote Added: 0013239
2015-08-19 19:23Torr SamahoStatusneeds review => needs testing
2015-08-19 19:29cobaltNote Added: 0013240
2015-09-15 03:56Ru5tK1ngNote Added: 0013518
2016-05-17 21:45WaTaKiDNote Added: 0014950
2016-05-17 21:45WaTaKiDStatusneeds testing => assigned
2016-05-17 21:46WaTaKiDNote Edited: 0014950bug_revision_view_page.php?bugnote_id=14950#r9024
2017-02-12 20:16StrikerMan780Note Added: 0016850
2017-02-12 20:40Torr SamahoNote Added: 0016851
2019-06-04 21:54DuskStatusassigned => new

Notes
(0006890)
Arco   
2013-08-02 00:08   
Persists in v1.1.1. This issue affects monsters as well.
(0006894)
Dusk   
2013-08-02 10:41   
Quote from "Blzut3"
Edit: While on the topic of knowns in A_Jump. A_Jump(256, "SomeState") is sometimes used instead of 'goto SomeState' since it is resolved at runtime instead of "compile time." This would be another fairly simple condition to check if(maxchance >= 256 && count == 1) and the client would accurately predict this case.
(0012983)
unknownna   
2015-07-21 12:10   
'https://bitbucket.org/Torr_Samaho/zandronum/pull-request/85/clients-now-predict-the-a_jump-256-target/diff [^]'
(0012984)
unknownna   
2015-07-21 12:13   
I think I noticed this issue in Complex Doom a few times as well. Well worth having fixed as quickly as possible.
(0013239)
Torr Samaho   
2015-08-19 19:23   
I added your patch.
(0013240)
cobalt   
2015-08-19 19:29   
Issue addressed by commit cef36570caa4: Clients now predict the A_Jump(256, "target") special case (addresses 1162)
Committed by Teemu Piippo [Dusk] on Monday 15 June 2015 03:47:25

Changes in files:

 docs/zandronum-history.txt | 1 +
 src/thingdef/thingdef_codeptr.cpp | 13 +++++++------
 2 files changed, 8 insertions(+), 6 deletions(-)
(0013518)
Ru5tK1ng   
2015-09-15 03:56   
I tried out the testwad with 3.0 and while I didn't experience any lag like I did with 2.1.2, I did notice some weird desyncs with the custom zombiemen. Namely playing though Doom2 map02 I saw corpses falling into the ground, floating in air for a time, changing to different dead/gib sprites.
(0014950)
WaTaKiD   
2016-05-17 21:45   
(edited on: 2016-05-17 21:46)
the above commit has been backed out ('https://bitbucket.org/Torr_Samaho/zandronum/commits/43f301ded97ab7bc8e7581b0211d91f3da6414ce [^]' ) due to causing a regression mentioned in'http://zandronum.com/tracker/view.php?id=2338 [^]'
(0016850)
StrikerMan780   
2017-02-12 20:16   
21:29 <Striker> I know that state jumping and such is really spotty and has been discussed to death... but, I wonder, would piggybacking off of the gametic system (seeding random jumps off of the current gametic, which is synced between client and server) to make sure jump outcomes are the same on client and server work?
21:32 <Striker> Or seeding based on the current gametic + how many times A_Jump has been called in the current tic so far, so multiple calls in the same frame don't produce the same outcome for every actor.
21:33 <Striker> I just want to see A_Jump not be absolute shit online.
21:51 <Hypnotoad> sounds like a good idea
(0016851)
Torr Samaho   
2017-02-12 20:40   
I have thought about the jumping for a while and think a much better way to handle this would be to have the client simply force the client to keep the actor in the jump state till it gets a message from the server with the outcome of the jump.