Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
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.
Additional InformationDownload links for the DnD files can be found here.
Attached Filesdiff file icon states.diff [^] (5,431 bytes) 2016-09-26 20:54 [Show Content]

- Relationships
related to 0003107closed Issues with weapon switching and state jumps 
child of 0002776closedDusk FindStateLabelAndOffset flaws 

-  Notes
User avatar (0015608)
Torr Samaho (administrator)
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.
User avatar (0015609)
Dusk (developer)
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.

User avatar (0015610)
Torr Samaho (administrator)
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.
User avatar (0015612)
Dusk (developer)
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.
User avatar (0015617)
Torr Samaho (administrator)
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.
User avatar (0015619)
Ivan (reporter)
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.
User avatar (0015623)
Dusk (developer)
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.

User avatar (0015624)
EnsaladaDeTomate (reporter)
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.
User avatar (0015639)
Torr Samaho (administrator)
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.
User avatar (0015652)
Torr Samaho (administrator)
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.
User avatar (0015704)
Torr Samaho (administrator)
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.
User avatar (0015708)
Dusk (developer)
2016-09-26 20:56
edited on: 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.

User avatar (0015714)
Torr Samaho (administrator)
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.
User avatar (0015717)
Edward-san (developer)
2016-09-28 06:33

What happens if the 'Offset' parameter in 'Command SetThingFrame' part of spec.things.txt changed from Short to Long?
User avatar (0015718)
Torr Samaho (administrator)
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.
User avatar (0015759)
ZzZombo (reporter)
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.

User avatar (0016551)
WaTaKiD (updater)
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 [^]'
User avatar (0017584)
Torr Samaho (administrator)
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?
User avatar (0017749)
Ru5tK1ng (updater)
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.
User avatar (0017823)
Ivan (reporter)
2017-06-12 23:19

No errors seem to be happening so far.
User avatar (0017951)
Ru5tK1ng (updater)
2017-06-29 22:29

I just confirmed with Ivan that the issue is no longer present.

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

- Issue History
Date Modified Username Field Change
2016-09-08 19:17 Ivan New Issue
2016-09-10 15:24 Torr Samaho Note Added: 0015608
2016-09-10 15:24 Torr Samaho Assigned To => Dusk
2016-09-10 15:24 Torr Samaho Status new => assigned
2016-09-10 15:25 Torr Samaho Target Version => 3.0
2016-09-10 21:44 Dusk Note Added: 0015609
2016-09-10 21:46 Dusk Note Edited: 0015609 View Revisions
2016-09-10 21:48 Dusk Note Edited: 0015609 View Revisions
2016-09-11 08:12 Torr Samaho Note Added: 0015610
2016-09-11 15:39 Dusk Note Added: 0015612
2016-09-11 16:10 Torr Samaho Note Added: 0015617
2016-09-11 19:53 Ivan Note Added: 0015619
2016-09-12 21:44 Dusk Note Added: 0015623
2016-09-12 22:45 Dusk Note Edited: 0015623 View Revisions
2016-09-12 23:13 EnsaladaDeTomate Note Added: 0015624
2016-09-14 06:02 Torr Samaho Note Added: 0015639
2016-09-18 06:15 Torr Samaho Note Added: 0015652
2016-09-25 20:36 Torr Samaho Note Added: 0015704
2016-09-26 20:54 Dusk File Added: states.diff
2016-09-26 20:56 Dusk Note Added: 0015708
2016-09-26 20:56 Dusk Note Edited: 0015708 View Revisions
2016-09-27 18:52 Torr Samaho Note Added: 0015714
2016-09-28 06:33 Edward-san Note Added: 0015717
2016-09-29 18:42 Torr Samaho Note Added: 0015718
2016-10-04 23:05 ZzZombo Note Added: 0015759
2016-10-04 23:06 ZzZombo Note Edited: 0015759 View Revisions
2016-11-21 07:06 Torr Samaho Relationship added child of 0002776
2016-11-27 20:19 Torr Samaho Additional Information Updated View Revisions
2016-12-25 22:20 WaTaKiD Note Added: 0016551
2017-05-07 14:52 Torr Samaho Relationship added related to 0003107
2017-05-07 14:56 Torr Samaho Note Added: 0017584
2017-05-07 14:56 Torr Samaho Status assigned => needs testing
2017-05-23 02:43 Ru5tK1ng Note Added: 0017749
2017-06-12 23:19 Ivan Note Added: 0017823
2017-06-29 22:29 Ru5tK1ng Note Added: 0017951
2017-06-29 22:29 Ru5tK1ng Status needs testing => resolved
2017-06-29 22:29 Ru5tK1ng Resolution open => fixed
2017-06-29 22:29 Ru5tK1ng Fixed in Version => 3.0
2018-09-30 21:43 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker