Anonymous | Login | Signup for a new account | 2024-04-19 20:00 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0002832 | Zandronum | [All Projects] Bug | public | 2016-09-08 19:17 | 2018-09-30 21:43 | ||||
Reporter | Ivan | ||||||||
Assigned To | Dusk | ||||||||
Priority | high | Severity | minor | Reproducibility | random | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 3.0-beta | ||||||||
Target Version | 3.0 | Fixed in Version | 3.0 | ||||||
Summary | 0002832: Incorrect Jump Frame Errors | ||||||||
Description | I 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 Information | Download links for the DnD files can be found here. | ||||||||
Attached Files | states.diff [^] (5,431 bytes) 2016-09-26 20:54 [Show Content] | ||||||||
Relationships | |||||||||||
|
Notes | |
(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. |
(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):
So this is a symptom of an underlying problem, which causes significant bandwidth waste. |
(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:
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 (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. |
(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. |
(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. |
(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. |
(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. |
(0015639) Torr Samaho (administrator) 2016-09-14 06:02 |
Quote from Dusk 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 (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. |
(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. |
(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. |
(0015714) Torr Samaho (administrator) 2016-09-27 18:52 |
Thanks for the diff! I just tested this very briefly locally and got
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 (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? |
(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. |
(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. |
(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 [^]' |
(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? |
(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. |
(0017823) Ivan (reporter) 2017-06-12 23:19 |
No errors seem to be happening so far. |
(0017951) Ru5tK1ng (updater) 2017-06-29 22:29 |
I just confirmed with Ivan that the issue is no longer present. |
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 |
Copyright © 2000 - 2024 MantisBT Team |