Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
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.
Attached Files? file icon inheritancedesync.wad [^] (12,289 bytes) 2015-11-16 17:55
txt file icon decorate.txt [^] (529 bytes) 2016-05-11 20:53 [Show Content]

- Relationships
related to 0002382feedbackEdward-san Special MinotaurFriend desync in Hexen causes it to stand still on client-end: Target issue 
child of 0000099new monsters move east online if 'A_Chase' is called when idling 

-  Notes
User avatar (0012847)
Dusk (developer)
2015-07-09 13:09

 What?
User avatar (0012848)
fr-blood (reporter)
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.
User avatar (0012976)
fr-blood (reporter)
2015-07-20 10:01
edited on: 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.
User avatar (0013150)
unknownna (updater)
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.
User avatar (0013799)
Torr Samaho (administrator)
2015-11-15 11:53

 Can somebody re-upload the example wad? The link doesn't seem to work anymore.
User avatar (0013822)
fr-blood (reporter)
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.
User avatar (0014851)
Edward-san (developer)
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..
User avatar (0014854)
WaTaKiD (updater)
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 [^]'
User avatar (0014855)
Edward-san (developer)
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.
User avatar (0014856)
WaTaKiD (updater)
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
User avatar (0014857)
fr-blood (reporter)
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
User avatar (0014858)
Edward-san (developer)
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).
User avatar (0014859)
WaTaKiD (updater)
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?
User avatar (0014860)
WaTaKiD (updater)
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 [^]'
User avatar (0014861)
Torr Samaho (administrator)
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.
User avatar (0014862)
fr-blood (reporter)
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
User avatar (0014863)
Edward-san (developer)
2016-05-11 19:24

 fr-blood, can you try with the custom binary posted by WaTaKiD?
User avatar (0014864)
WaTaKiD (updater)
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
User avatar (0014867)
fr-blood (reporter)
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.
User avatar (0014868)
Edward-san (developer)
2016-05-11 20:43

 Managed to reduce quite a bit. The decorate file is enough for the desync.
User avatar (0014869)
Edward-san (developer)
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.
User avatar (0014876)
Torr Samaho (administrator)
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.
User avatar (0014878)
Edward-san (developer)
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?
User avatar (0014879)
Torr Samaho (administrator)
2016-05-12 18:45

 Why do you think that A_Unblock and A_ChangeFlag should be handled completely differently?
User avatar (0014880)
Edward-san (developer)
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.
User avatar (0014881)
Torr Samaho (administrator)
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).
User avatar (0014882)
Edward-san (developer)
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.
User avatar (0014883)
Torr Samaho (administrator)
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.
User avatar (0014947)
Torr Samaho (administrator)
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.
User avatar (0014948)
Edward-san (developer)
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 [^]'
User avatar (0014962)
Edward-san (developer)
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.
User avatar (0015182)
WaTaKiD (updater)
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

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

- Issue History
Date Modified Username Field Change
2015-07-09 12:55 fr-blood New Issue
2015-07-09 13:09 Dusk Note Added: 0012847
2015-07-09 13:09 Dusk Assigned To => Dusk
2015-07-09 13:09 Dusk Status new => feedback
2015-07-09 19:23 fr-blood Note Added: 0012848
2015-07-09 19:23 fr-blood Status feedback => assigned
2015-07-09 19:25 fr-blood Note Edited: 0012848 View Revisions
2015-07-09 19:25 fr-blood Note Edited: 0012848 View Revisions
2015-07-20 10:01 fr-blood Note Added: 0012976
2015-07-20 10:01 fr-blood Note Edited: 0012976 View Revisions
2015-08-09 12:57 unknownna Note Added: 0013150
2015-08-09 12:58 unknownna Relationship added related to 0002382
2015-08-09 12:58 unknownna Relationship added child of 0000099
2015-08-09 13:01 unknownna Note Edited: 0013150 View Revisions
2015-11-15 11:53 Torr Samaho Note Added: 0013799
2015-11-15 11:54 Torr Samaho Status assigned => feedback
2015-11-16 12:33 fr-blood Note Added: 0013822
2015-11-16 12:33 fr-blood Status feedback => assigned
2015-11-16 17:55 WaTaKiD File Added: inheritancedesync.wad
2016-05-10 21:09 Torr Samaho Product Version 2.1 => 3.0-beta
2016-05-10 22:33 Edward-san Note Added: 0014851
2016-05-10 22:34 Edward-san Note Edited: 0014851 View Revisions
2016-05-11 08:22 WaTaKiD Note Added: 0014854
2016-05-11 08:56 Edward-san Note Added: 0014855
2016-05-11 09:55 WaTaKiD Note Added: 0014856
2016-05-11 10:57 fr-blood Note Added: 0014857
2016-05-11 10:58 fr-blood Note Edited: 0014857 View Revisions
2016-05-11 13:18 Edward-san Note Added: 0014858
2016-05-11 13:19 Edward-san Note Edited: 0014858 View Revisions
2016-05-11 16:18 Edward-san Product Version 3.0-beta => 2.1
2016-05-11 17:08 WaTaKiD Note Added: 0014859
2016-05-11 18:11 WaTaKiD Note Added: 0014860
2016-05-11 18:21 WaTaKiD Note Edited: 0014860 View Revisions
2016-05-11 18:54 Torr Samaho Note Added: 0014861
2016-05-11 19:15 fr-blood Note Added: 0014862
2016-05-11 19:24 Edward-san Note Added: 0014863
2016-05-11 19:25 WaTaKiD Note Added: 0014864
2016-05-11 19:31 WaTaKiD Note Edited: 0014864 View Revisions
2016-05-11 20:26 fr-blood Note Added: 0014867
2016-05-11 20:41 Edward-san File Added: decorate.txt
2016-05-11 20:41 Edward-san File Deleted: decorate.txt
2016-05-11 20:43 Edward-san File Added: decorate.txt
2016-05-11 20:43 Edward-san Note Added: 0014868
2016-05-11 20:53 Edward-san File Deleted: decorate.txt
2016-05-11 20:53 Edward-san File Added: decorate.txt
2016-05-11 20:58 Dusk Assigned To Dusk =>
2016-05-11 20:58 Dusk Status assigned => new
2016-05-11 21:55 Edward-san Note Added: 0014869
2016-05-11 21:56 Edward-san Note Edited: 0014869 View Revisions
2016-05-12 06:02 Torr Samaho Note Added: 0014876
2016-05-12 10:14 Edward-san Note Added: 0014878
2016-05-12 10:15 Edward-san Note Edited: 0014878 View Revisions
2016-05-12 10:15 Edward-san Assigned To => Edward-san
2016-05-12 10:15 Edward-san Status new => feedback
2016-05-12 10:15 Edward-san Status feedback => assigned
2016-05-12 18:45 Torr Samaho Note Added: 0014879
2016-05-12 19:09 Edward-san Note Added: 0014880
2016-05-12 19:15 Torr Samaho Note Added: 0014881
2016-05-12 19:46 Edward-san Note Added: 0014882
2016-05-12 19:53 Torr Samaho Note Added: 0014883
2016-05-17 05:55 Torr Samaho Target Version => 3.0
2016-05-17 19:53 Torr Samaho Note Added: 0014947
2016-05-17 21:04 Edward-san Note Added: 0014948
2016-05-17 21:05 Edward-san Status assigned => needs review
2016-05-21 16:04 Edward-san Note Added: 0014962
2016-05-21 16:04 Edward-san Status needs review => needs testing
2016-05-21 16:04 Edward-san Summary Use inheritance causes monster desync on clientside => Monster desync by dead monsters unblocked by A_NoBlocking in item pickup
2016-07-02 16:23 WaTaKiD Note Added: 0015182
2016-07-02 16:36 WaTaKiD Status needs testing => resolved
2016-07-02 16:36 WaTaKiD Resolution open => fixed
2016-07-02 16:36 WaTaKiD Fixed in Version => 3.0
2018-09-30 22:01 Blzut3 Status resolved => closed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker