MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002832Zandronum[All Projects] Bugpublic2016-09-08 19:172018-09-30 21:43
ReporterIvan 
Assigned ToDusk 
PriorityhighSeverityminorReproducibilityrandom
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.0-beta 
Target Version3.0Fixed in Version3.0 
Summary0002832: Incorrect Jump Frame Errors
DescriptionI was PM'ing some bug reports to Torr, and he asked me to create this ticket so it's easier to discuss. Relevant changeset:'https://bitbucket.org/Torr_Samaho/zandronum/commits/be80717ad949c9eae6c091b929c4cb0d7ee06c3a [^]'

Basically what happens is actors that do not have frame X will be reported to be trying to jump to this said frame. Happens mostly clientside but it spams console and usually causes fps drops.
Steps To Reproduce
Additional InformationDownload links for the DnD files can be found here.
TagsNo tags attached.
Relationships
related to 0003107closed  Issues with weapon switching and state jumps 
child of 0002776closed Dusk FindStateLabelAndOffset flaws 
Attached Filesdiff states.diff (5,431) 2016-09-26 20:54
https://zandronum.com/tracker/file_download.php?file_id=1890&type=bug
Issue History
Date ModifiedUsernameFieldChange
2016-09-08 19:17IvanNew Issue
2016-09-10 15:24Torr SamahoNote Added: 0015608
2016-09-10 15:24Torr SamahoAssigned To => Dusk
2016-09-10 15:24Torr SamahoStatusnew => assigned
2016-09-10 15:25Torr SamahoTarget Version => 3.0
2016-09-10 21:44DuskNote Added: 0015609
2016-09-10 21:46DuskNote Edited: 0015609bug_revision_view_page.php?bugnote_id=15609#r9488
2016-09-10 21:48DuskNote Edited: 0015609bug_revision_view_page.php?bugnote_id=15609#r9489
2016-09-11 08:12Torr SamahoNote Added: 0015610
2016-09-11 15:39DuskNote Added: 0015612
2016-09-11 16:10Torr SamahoNote Added: 0015617
2016-09-11 19:53IvanNote Added: 0015619
2016-09-12 21:44DuskNote Added: 0015623
2016-09-12 22:45DuskNote Edited: 0015623bug_revision_view_page.php?bugnote_id=15623#r9495
2016-09-12 23:13EnsaladaDeTomateNote Added: 0015624
2016-09-14 06:02Torr SamahoNote Added: 0015639
2016-09-18 06:15Torr SamahoNote Added: 0015652
2016-09-25 20:36Torr SamahoNote Added: 0015704
2016-09-26 20:54DuskFile Added: states.diff
2016-09-26 20:56DuskNote Added: 0015708
2016-09-26 20:56DuskNote Edited: 0015708bug_revision_view_page.php?bugnote_id=15708#r9556
2016-09-27 18:52Torr SamahoNote Added: 0015714
2016-09-28 06:33Edward-sanNote Added: 0015717
2016-09-29 18:42Torr SamahoNote Added: 0015718
2016-10-04 23:05ZzZomboNote Added: 0015759
2016-10-04 23:06ZzZomboNote Edited: 0015759bug_revision_view_page.php?bugnote_id=15759#r9584
2016-11-21 07:06Torr SamahoRelationship addedchild of 0002776
2016-11-27 20:19Torr SamahoAdditional Information Updatedbug_revision_view_page.php?rev_id=9923#r9923
2016-12-25 22:20WaTaKiDNote Added: 0016551
2017-05-07 14:52Torr SamahoRelationship addedrelated to 0003107
2017-05-07 14:56Torr SamahoNote Added: 0017584
2017-05-07 14:56Torr SamahoStatusassigned => needs testing
2017-05-23 02:43Ru5tK1ngNote Added: 0017749
2017-06-12 23:19IvanNote Added: 0017823
2017-06-29 22:29Ru5tK1ngNote Added: 0017951
2017-06-29 22:29Ru5tK1ngStatusneeds testing => resolved
2017-06-29 22:29Ru5tK1ngResolutionopen => fixed
2017-06-29 22:29Ru5tK1ngFixed in Version => 3.0
2018-09-30 21:43Blzut3Statusresolved => closed

Notes
(0015608)
Torr Samaho   
2016-09-10 15:24   
This demo from WaTaKiD allows to reproduce the issue:'https://www.dropbox.com/s/k2qv0qzlo3tyi7o/2016.09.07_12.12.41_sunlust.dndv2.1pk3.dnd_onlyammov2.3.dnd_monstersv0.5pk3.newtextcolours_260pk3.zip?dl=0 [^]'

Dusk, can you have a look? I think this is caused by the recent change in the logic used for server commands SetPlayerPSprite and SetThingFrame. At least the errors in the demo vanish if I let the client ignore the SetThingFrame commands.
(0015609)
Dusk   
2016-09-10 21:44   
(edited on: 2016-09-10 21:48)
The linked changeset has nothing to do with these warnings. The client is unable to resolve the actor from net ID.

The reason is that the client used to just ignore them, but the code generator change makes the client print a warning (I felt this was justified because making cl_showwarnings more encompassing was part of the point):

        // Find the actor associated with the ID.
        pActor = CLIENT_FindThingByNetID( lID );
        if ( pActor == NULL )
        {
                // There should probably be the potential for a warning message here.
                return;
        }


So this is a symptom of an underlying problem, which causes significant bandwidth waste.
(0015610)
Torr Samaho   
2016-09-11 08:12   
This sounds like a very different problem, that should also be fixed of course. Let me elaborate, I just noticed that the ticket description does not contain enough information. One of the errors produced in this demo is
"Jump target 'Remove' not found in ShadowGhostB"

and the DECORATE code of the actor is as follows:

ACTOR ShadowGhostA
{
    Radius 4
    Height 8
    Speed 0
    Damage 0
    Mass 75
    RenderStyle "Translucent"
    Alpha 0.3
    PROJECTILE
    States
    {
    Spawn:
        TROX A 10
        Stop
    }
}
 
ACTOR ShadowGhostB : ShadowGhostA
{
    States
    {
    Spawn:
        TROX B 10
        Stop
    }
}

The errors are not generated by the client specific code, but by the DECORATE function pointer parser. What seems to happen is that an actor is put into a state that neither belongs to the actor nor to any of its ancestors. Then it encounters a code pointer that has a named state as argument. When trying to resolve the state from the name, DECORATE checks the calling actor for this state, but this actor doesn't have it.

If you play the demo with "cl_showwarnings 0", these warnings become apparent during the first map change.
(0015612)
Dusk   
2016-09-11 15:39   
That's weird. I'm going to need a testcase to see how the server manages to send such a strange packet to the client.
(0015617)
Torr Samaho   
2016-09-11 16:10   
Actually, what I observed may be a demo playback problem. If I use demo_skiptonextmap, I get these errors during first map change. If I use demo_skiptics, I don't get them. AFAIK, Ivan observed these errors also when no demo playback is involved, so it still looks like there is a problem.
(0015619)
Ivan   
2016-09-11 19:53   
Extra info about this problem:

- This error seems to happen randomly on actors.
- This is a clientside problem, it doesn't affect everyone in a server.
- It happens in normal playthroughs in a populated server.
- I noticed this bug happening with my mod DnD, not sure if any other mods are affected yet.
- This involves actors not having the reported states, and lots of jump offset errors.
- The demo I have given was from Watakid's POV but half the server say they saw the messages in the console whereas the others did not. It also seems to involve actors that can not possibly be doing anything besides their routine states. (Like medkit_43, which is for player number 43 but since no player 43 was even in the server it won't go past a simple a_jumpif check)

If you need any more info let me know.
(0015623)
Dusk   
2016-09-12 21:44   
(edited on: 2016-09-12 22:45)
It's looking like to be platform-specific. I wrote some code to detect mismatches in what the client and server think the target state is in state jump messages and only caught these mismatches when a Windows client connects to a Linux server.

Looks like the order of states owned by actors can vary across platforms. I'll have to think more about this.
(0015624)
EnsaladaDeTomate   
2016-09-12 23:13   
This also happens with samsara extra heroes with monster mixer, sometimes, the spam of "Jump target 'state' not found in 'ActorName'" is so heavy that slow downs the server rendering it unplayable, and the only way to fix it is by changing map or restarting the server.

(Sorry if my english is not the best, but ill try my best to explain this)

I dont know if this might help, but this issue has happened regarding a monster unique actor states tried to beign loaded by a player weapon (a custom one beign called by "Flash" state) that doesnt have such states, slowing down everyone in the server and forcing them to disconnect.

How did this happened? the monster throw a projectile in front of the player's weapon (or flash) and the spam of "jump target..." started.
(0015639)
Torr Samaho   
2016-09-14 06:02   
Quote from Dusk
Looks like the order of states owned by actors can vary across platforms. I'll have to think more about this.

Hmm, even if the order of states is different, an actor still shouldn't end up in the state of a completely unrelated actor, should it? Like ShadowGhostD being set to MetalScrap+4.
(0015652)
Torr Samaho   
2016-09-18 06:15   
Is it this possible that this only happens after a player has disconnected from the server?

Does anybody know how to reproduce the "SetThingFrameNF: couldn't find actor:" warnings shown in the demo with "cl_showwarnings 1"? To me it looked as if the server here tries to change the state of TheDoomGuy actors the clients don't know about.
(0015704)
Torr Samaho   
2016-09-25 20:36   
For the record, the "SetThingFrameNF: couldn't find actor:" warnings were caused by voodoo dolls and should be fixed now. I also fixed numerous other things that caused warnings on the client.
(0015708)
Dusk   
2016-09-26 20:56   
Attached the diff I used to figure out the platform-specific problem.

Looking at it again, perhaps we could use the logic used in "FindStateLabelAndOffset" to go through all states and build a hash table, using the type name and the offset as the key, to do fast and reliable state lookups.
(0015714)
Torr Samaho   
2016-09-27 18:52   
Thanks for the diff! I just tested this very briefly locally and got

client_SetThingFrame: mismatch detected: server wants to set thing 566 (Credit_01) state to Credit_01::GenericCrush+2034576, but it actually is Credit_01::GenericCrush+1720246.

when using Windows server and client. So there even is problem if both client and server use the same platform. The offset in this case sounds like complete nonsense (the actor certainly doesn't have more than a million states...), I'll look into this.
(0015717)
Edward-san   
2016-09-28 06:33   
What happens if the 'Offset' parameter in 'Command SetThingFrame' part of spec.things.txt changed from Short to Long?
(0015718)
Torr Samaho   
2016-09-29 18:42   
No actor I know has more then SHORT_MAX frames. If the offset exceeds SHORT_MAX, the offset computation failed.
(0015759)
ZzZombo   
2016-10-04 23:05   
(edited on: 2016-10-04 23:06)
In the light of'https://github.com/rheit/zdoom/commit/15cbf4bae66359a3ffe9eb2b20b30ca31df39768 [^]' I guess it's a ZDoom problem just fixed by this commit. Somebody should check it.
(0016551)
WaTaKiD   
2016-12-25 22:20   
this 3.0 build contains the 2 following commits, which should help figure things out: 'https://www.dropbox.com/s/0ek7zjo2zzguq7g/zandronum-3.0-r161225-2158-9d44e3c-windows.zip?dl=0 [^]'

'https://bitbucket.org/zandronum/zandronum-sandbox/commits/48bd9e33fd8fb2786ae6fcc591326369b068a3a9 [^]'

'https://bitbucket.org/zandronum/zandronum-sandbox/commits/bbcb3a10408e613bd1a8c2c60a232ed37331407e [^]'
(0017584)
Torr Samaho   
2017-05-07 14:56   
The fix for 0003107 may already have fixed this. So can somebody check whether this issues is still a problem?

While at it, Dusk brought up that the fix may interfere with Dehacked mods. Can somebody test mapsets like Lunatic and Ancient Aliens to see whether Dehacked is still working as intended in 3.0?
(0017749)
Ru5tK1ng   
2017-05-23 02:43   
I tested the latest changes with Lunatic and Ancient Aliens online and all those dehacked monsters worked correctly. Just waiting on Ivan to see if the fix for 0003107 solved the issue with his mod.
(0017823)
Ivan   
2017-06-12 23:19   
No errors seem to be happening so far.
(0017951)
Ru5tK1ng   
2017-06-29 22:29   
I just confirmed with Ivan that the issue is no longer present.