MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002338Zandronum[All Projects] Bugpublic2015-07-09 12:552018-09-30 22:01
Reporterfr-blood 
Assigned ToEdward-san 
PrioritynormalSeverityminorReproducibilityrandom
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version2.1 
Target Version3.0Fixed in Version3.0 
Summary0002338: Monster desync by dead monsters unblocked by A_NoBlocking in item pickup
DescriptionIn my project AfterDoom_v0.1b.wad using monster inheritance make sometimes their images go randomly at another position than the actor itself, witch make them teleport in clientside.
Steps To ReproduceDownload: AfterDoom_v0.1b.wad(you can get it in best ever), just launch a random map(normal doom2 monsters are replaced), and then just fight them and you will see that sometimes their image won't be at the position where the zombies are for a short delay and then it will comeback that will looks like a teleportation.
Additional InformationThis bug happens only when I use inheritance between monsters.
TagsNo tags attached.
Relationships
related to 0002382feedback Edward-san Special MinotaurFriend desync in Hexen causes it to stand still on client-end: Target issue 
child of 0000099confirmed  monsters move east online if 'A_Chase' is called when idling 
Attached Files? inheritancedesync.wad (12,289) 2015-11-16 17:55
https://zandronum.com/tracker/file_download.php?file_id=1688&type=bug
txt decorate.txt (529) 2016-05-11 20:53
https://zandronum.com/tracker/file_download.php?file_id=1807&type=bug
Issue History
Date ModifiedUsernameFieldChange
2015-07-09 12:55fr-bloodNew Issue
2015-07-09 13:09DuskNote Added: 0012847
2015-07-09 13:09DuskAssigned To => Dusk
2015-07-09 13:09DuskStatusnew => feedback
2015-07-09 19:23fr-bloodNote Added: 0012848
2015-07-09 19:23fr-bloodStatusfeedback => assigned
2015-07-09 19:25fr-bloodNote Edited: 0012848bug_revision_view_page.php?bugnote_id=12848#r7571
2015-07-09 19:25fr-bloodNote Edited: 0012848bug_revision_view_page.php?bugnote_id=12848#r7572
2015-07-20 10:01fr-bloodNote Added: 0012976
2015-07-20 10:01fr-bloodNote Edited: 0012976bug_revision_view_page.php?bugnote_id=12976#r7746
2015-08-09 12:57unknownnaNote Added: 0013150
2015-08-09 12:58unknownnaRelationship addedrelated to 0002382
2015-08-09 12:58unknownnaRelationship addedchild of 0000099
2015-08-09 13:01unknownnaNote Edited: 0013150bug_revision_view_page.php?bugnote_id=13150#r7846
2015-11-15 11:53Torr SamahoNote Added: 0013799
2015-11-15 11:54Torr SamahoStatusassigned => feedback
2015-11-16 12:33fr-bloodNote Added: 0013822
2015-11-16 12:33fr-bloodStatusfeedback => assigned
2015-11-16 17:55WaTaKiDFile Added: inheritancedesync.wad
2016-05-10 21:09Torr SamahoProduct Version2.1 => 3.0-beta
2016-05-10 22:33Edward-sanNote Added: 0014851
2016-05-10 22:34Edward-sanNote Edited: 0014851bug_revision_view_page.php?bugnote_id=14851#r8987
2016-05-11 08:22WaTaKiDNote Added: 0014854
2016-05-11 08:56Edward-sanNote Added: 0014855
2016-05-11 09:55WaTaKiDNote Added: 0014856
2016-05-11 10:57fr-bloodNote Added: 0014857
2016-05-11 10:58fr-bloodNote Edited: 0014857bug_revision_view_page.php?bugnote_id=14857#r8989
2016-05-11 13:18Edward-sanNote Added: 0014858
2016-05-11 13:19Edward-sanNote Edited: 0014858bug_revision_view_page.php?bugnote_id=14858#r8991
2016-05-11 16:18Edward-sanProduct Version3.0-beta => 2.1
2016-05-11 17:08WaTaKiDNote Added: 0014859
2016-05-11 18:11WaTaKiDNote Added: 0014860
2016-05-11 18:21WaTaKiDNote Edited: 0014860bug_revision_view_page.php?bugnote_id=14860#r8993
2016-05-11 18:54Torr SamahoNote Added: 0014861
2016-05-11 19:15fr-bloodNote Added: 0014862
2016-05-11 19:24Edward-sanNote Added: 0014863
2016-05-11 19:25WaTaKiDNote Added: 0014864
2016-05-11 19:31WaTaKiDNote Edited: 0014864bug_revision_view_page.php?bugnote_id=14864#r8995
2016-05-11 20:26fr-bloodNote Added: 0014867
2016-05-11 20:41Edward-sanFile Added: decorate.txt
2016-05-11 20:41Edward-sanFile Deleted: decorate.txt
2016-05-11 20:43Edward-sanFile Added: decorate.txt
2016-05-11 20:43Edward-sanNote Added: 0014868
2016-05-11 20:53Edward-sanFile Deleted: decorate.txt
2016-05-11 20:53Edward-sanFile Added: decorate.txt
2016-05-11 20:58DuskAssigned ToDusk =>
2016-05-11 20:58DuskStatusassigned => new
2016-05-11 21:55Edward-sanNote Added: 0014869
2016-05-11 21:56Edward-sanNote Edited: 0014869bug_revision_view_page.php?bugnote_id=14869#r8997
2016-05-12 06:02Torr SamahoNote Added: 0014876
2016-05-12 10:14Edward-sanNote Added: 0014878
2016-05-12 10:15Edward-sanNote Edited: 0014878bug_revision_view_page.php?bugnote_id=14878#r8999
2016-05-12 10:15Edward-sanAssigned To => Edward-san
2016-05-12 10:15Edward-sanStatusnew => feedback
2016-05-12 10:15Edward-sanStatusfeedback => assigned
2016-05-12 18:45Torr SamahoNote Added: 0014879
2016-05-12 19:09Edward-sanNote Added: 0014880
2016-05-12 19:15Torr SamahoNote Added: 0014881
2016-05-12 19:46Edward-sanNote Added: 0014882
2016-05-12 19:53Torr SamahoNote Added: 0014883
2016-05-17 05:55Torr SamahoTarget Version => 3.0
2016-05-17 19:53Torr SamahoNote Added: 0014947
2016-05-17 21:04Edward-sanNote Added: 0014948
2016-05-17 21:05Edward-sanStatusassigned => needs review
2016-05-21 16:04Edward-sanNote Added: 0014962
2016-05-21 16:04Edward-sanStatusneeds review => needs testing
2016-05-21 16:04Edward-sanSummaryUse inheritance causes monster desync on clientside => Monster desync by dead monsters unblocked by A_NoBlocking in item pickup
2016-07-02 16:23WaTaKiDNote Added: 0015182
2016-07-02 16:36WaTaKiDStatusneeds testing => resolved
2016-07-02 16:36WaTaKiDResolutionopen => fixed
2016-07-02 16:36WaTaKiDFixed in Version => 3.0
2018-09-30 22:01Blzut3Statusresolved => closed

Notes
(0012847)
Dusk   
2015-07-09 13:09   
What?
(0012848)
fr-blood   
2015-07-09 19:23   
(edited on: 2015-07-09 19:25)
Excuse me for the lack of precision my english bad.

The link of the mode:'http://www.best-ever.org/download?file=afterdoom_v0.1b.wad [^]'

In decorate here is how works inheritance:'http://zdoom.org/wiki/Using_inheritance [^]'
I'm sure that you guys already used that stuff.

In my mod all the zombies got the same parent and by using that connection, it cause somehow desync between their position on clientside and serverside(I see the zombie at a certain position when the server see him somewhere else), the desync is short and when it stop the position of the zombie in clientside join the other one in serverside which looks like a teleportation(without the teleportfog).

Why I say that the problem is from the inheritance ?
Because it happens only if the zombies use special states from their parent.
(0012976)
fr-blood   
2015-07-20 10:01   
I found a way to reproduce with that wad:

'http://download1512.mediafire.com/j96hcq5ml4hg/khyaw77qkl31x1i/testv1.wad [^]'

You have to open a server and join it, find a zombieman and when he will see you use noclip cheat and go through a wall and you will see how the zombieman is jittering and after you get out of the wall he will go back at his old position.

That what I was locking for, a lot of things like that are happining in my mode.
(0013150)
unknownna   
2015-08-09 12:57   
(edited on: 2015-08-09 13:01)
This seems to be another target issue (caused by A_ClearTarget). For some reason monsters move east when they don't have any targets online.
(0013799)
Torr Samaho   
2015-11-15 11:53   
Can somebody re-upload the example wad? The link doesn't seem to work anymore.
(0013822)
fr-blood   
2015-11-16 12:33   
I copy pasted one of the actor that I use on my project in this wad:

'http://www.mediafire.com/download/a10lg30cpi5n6ac/inheritancedesync.wad [^]'

There are a lot of missing stuff but the desync happens even if I add them.

Here are the steps:
- Launch Zandronum 3.0 on a server with the wad
- Join MAP01
- Set up noclip and go inside a wall
- Shoot one time and you will see the zombiemen teleporting until you get in front of them.
(0014851)
Edward-san   
2016-05-10 22:33   
(edited on: 2016-05-10 22:34)
Can the decorate code in the example wad reduced as more as possible? It's hard to investigate with the tons of states and jumps..
(0014854)
WaTaKiD   
2016-05-11 08:22   
the provided example wad works fine in 2.1.2 but not in 3.0

ive found this commit to be the culprit:'https://bitbucket.org/Torr_Samaho/zandronum/commits/cef36570caa48d2f18a1d4afaee7e6458c6c121a [^]'

which addresses this ticket:'http://zandronum.com/tracker/view.php?id=1162 [^]'
(0014855)
Edward-san   
2016-05-11 08:56   
That commit was done before 2.1 came out, so it should've been possible to reproduce also in 2.1.x and not in 2.0.
(0014856)
WaTaKiD   
2016-05-11 09:55   
i just tested 2.1.1, 2.1, and 2.0 and i was unable to reproduce the zombiemen's jittery movement, same as 2.1.2

also i just searched thru the zandronum-stable repo and was unable to find the commit in there
(0014857)
fr-blood   
2016-05-11 10:57   
(edited on: 2016-05-11 10:58)
Sorry Edward, since I don't know what state/jump is the source of that problem I could delete the one causing it by making this code more easily.

I don't remember how I coded that example .wad but what I can tell you is that the problem is present on Zandronum 2.1.2, check the current thread of the last 3.0 beta for a video.

Here is the wad:'http://www.mediafire.com/download/11hwiq7zjss8xz8/AfterDoom_v0.1b.wad [^]' an old version for 2.x before the code upgrate.

You will find the code of the zombies in the first decorate entry under ZOMBIE marker with Slade 3
(0014858)
Edward-san   
2016-05-11 13:18   
(edited on: 2016-05-11 13:19)
Urgh, I see why you can't reproduce the issue in 2.x, WaTaKiD ... actually the A_Jump(256) prediction history was added at the wrong place (in 2.1 instead of 3.0).
(0014859)
WaTaKiD   
2016-05-11 17:08   
fr-blood: im going to need more information on how u were able to reproduce the jittery zombieman movement in zan 2.1.2

is it a server u hosted off of ur computer, or is it for example a best ever server? what dmflags/dmflags2 etc do u have set? do u have any other settings/flags set, such as sv_defaultdmflags etc? are there any other wads besides AfterDoom_v0.1b.wad loaded?
(0014860)
WaTaKiD   
2016-05-11 18:11   
(edited on: 2016-05-11 18:21)
with edward-san's help, i backed out changeset cef3657 and the zombiemen's movement was no longer jittery in zan 3.0

edit: this is the build i used:'https://www.dropbox.com/s/7ynx98vxfs2jbfo/ZandroDev3.0-A_JumpJitteryFixTest.zip?dl=0 [^]'
(0014861)
Torr Samaho   
2016-05-11 18:54   
Sounds like there are two issues then: The 3.0 regression caused by the A_Jump change and an inheritance related issue that is already present in 2.1.2.
(0014862)
fr-blood   
2016-05-11 19:15   
I launched the server myself with Doom Explorer:
 .DMFLAGS: 1610891524
 .DMFLAGS2: 2097920
 .ZADMFLAGS: 1104
 .COMPATFLAGS: 67108868
 .ZACOMPATFLAGS: 2
 alwaysapplydmflags 1
 sv_randommaprotation 0
 sv_notimelimitvote 1
 sv_nopointlimitvote 1
 sv_nodrop 1
 sv_maxplayers 32
 sv_maxclients 32
 I launched the wad with the mappack doomcoop2-bd-ok.wad
(0014863)
Edward-san   
2016-05-11 19:24   
fr-blood, can you try with the custom binary posted by WaTaKiD?
(0014864)
WaTaKiD   
2016-05-11 19:25   
(edited on: 2016-05-11 19:31)
ah i see now, i was finally able to reproduce the zombiemen's jittery movement in 2.1.2, the extra zombiemen found in doomcoop2-bd-ok.wad helped

it seems that it only happens as they move across one of the zombiemen's corpses, whereas i was unable to reproduce this before because i wasnt sticking around long enuff for them to kill eachother

edit: i just tested the binary i linked with that backed out changeset, the zombiemen's movement jitters if they walk over the corpses
(0014867)
fr-blood   
2016-05-11 20:26   
I tested it with ZandroDev3.0-A_JumpJitteryFixTest.zip, there were no jitters at the begining and as Watakid said it started when they walked over the corpses.
(0014868)
Edward-san   
2016-05-11 20:43   
Managed to reduce quite a bit. The decorate file is enough for the desync.
(0014869)
Edward-san   
2016-05-11 21:55   
(edited on: 2016-05-11 21:56)
The bug in question has nothing to do with inheritance, but only with monsters getting unblocked by picked items.

Clients are prevented to execute pickup actions, hence to unblock the monster, and the server is prevented to do anything with non-player inventories.

Furthermore, if we change the server to send also non-player inventories, bandwidth would suffer too much.
(0014876)
Torr Samaho   
2016-05-12 06:02   
Sounds like we should have the server notify the client about the flag change in A_Unblock (called by A_NoBlocking) like we do for A_ChangeFlag.
(0014878)
Edward-san   
2016-05-12 10:14   
(edited on: 2016-05-12 10:15)
This changeset should fix the issue, but I'd like to restrict the server notification to ACTION_CALL_FROM_INVENTORY() (the problem is restricted to monster inventories), but A_Unblock doesn't contain the PARAMINFO parameters, so this is impossible. I could change the function to include also the paraminfo ( DECLARE_PARAMINFO in definition, PUSH_PARAMINFO in every call ), but this requires more delta to ZDoom. What do you think?
(0014879)
Torr Samaho   
2016-05-12 18:45   
Why do you think that A_Unblock and A_ChangeFlag should be handled completely differently?
(0014880)
Edward-san   
2016-05-12 19:09   
A_Unblock, differently from A_ChangeFlag, can be executed by the client and it's called also in cl_main.cpp (well, not directly ... see all the calls to A_NoBlocking). This means that clients would change the actor flag by themselves in case the actor calls any action involving A_Unblock not by inventories (for example in the Death state, as it happens with stock monster actors) and then they would receive the ChangeFlag command from the server uselessly.
(0014881)
Torr Samaho   
2016-05-12 19:15   
Why can't the client execute A_ChangeFlag? The example wad in 2195 that led to the A_ChangeFlag net handling is quite similar to the example here. There we have an item that calls A_ChangeFlag(THRUSPECIES, 0).
(0014882)
Edward-san   
2016-05-12 19:46   
Yes but A_ChangeFlag is not called in any way by clients via CALL_ACTION, so the network handling can reject clients without side effects. We can't do the same with A_Unblock because it's called via CALL_ACTIONs in the client code.
(0014883)
Torr Samaho   
2016-05-12 19:53   
We can replace the CALL_ACTION-A_NoBlocking calls with direct A_Unblock calls and add an additional, optional bool argument to A_Unblock to enforce the clients to do the flag change when necessary. I think these CALL_ACTION calls date back to a time when A_Unblock didn't exist, they were simply never updated to use A_Unblock.
(0014947)
Torr Samaho   
2016-05-17 19:53   
Quote from WaTaKiD
with edward-san's help, i backed out changeset cef3657 and the zombiemen's movement was no longer jittery in zan 3.0

I backed out the changeset in the main repo. So the regression should be gone now.
(0014948)
Edward-san   
2016-05-17 21:04   
Sorry, I forgot to make the pull request with the fix + feedback adjustment:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/02b781f9e3e74d0b2450881d9cf8f286bcd80b5c [^]'
(0014962)
Edward-san   
2016-05-21 16:04   
Added in 3.0 changeset:'https://bitbucket.org/Torr_Samaho/zandronum/commits/368000cfe861 [^]' . Also changed the title of the bug into the real issue.
(0015182)
WaTaKiD   
2016-07-02 16:23   
using'https://www.dropbox.com/s/47tfog9di3lorlg/zandronum-3.0-r160702-1232-b244a48-windows.zip?dl=0 [^]' and the various wads/decorate linked here, it seems like the desyncs have been fixed