MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001436Zandronum[All Projects] Bugpublic2013-07-29 13:312018-09-30 22:44
ReporterIvan 
Assigned ToWatermelon 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version1.1.1 
Target VersionFixed in Version 
Summary0001436: Client Z prediction issue
DescriptionHere's a sample from an actor in GvH, the ghostbuster trap. It's basically a projectile spawned through A_SpawnItemEx to give it a speed on the X axis. The problem arises when it lands on the ground, where a script executes to stop it. (A_Stop causes a desync at where the script is, already tried that) This was working perfectly in Zandronum 1.0, but now it started to bug. What happens is, as soon as it lands, it starts floating in the air.
Steps To Reproduce* Open the ZBug.pk3 with Zandronum.
* Type "Give GhostbusterTraps" and "Give Trapammo 10" on your console.
* Press alt fire as you jump, you'll notice the traps are hanging on the air.
* An interesting thing I noticed is that, this will NEVER happen on the first map you happen to try it on, so change the map to say, map32 instead of the default map01. It works properly on the first execution.
Additional InformationA_Stop also causes a weird desync. Try to replace the ACS_executeAlways(503, 0) lines with A_Stop and you'll notice that the traps move on their own, however when you press the fire key they will be moved to their ACTUAL position. Might as well fix two bugs at once, right?
TagsNo tags attached.
Relationships
Attached Files? ZBug.pk3 (15,200) 2013-07-29 13:31
/tracker/file_download.php?file_id=1033&type=bug
Issue History
Date ModifiedUsernameFieldChange
2013-07-29 13:31IvanNew Issue
2013-07-29 13:31IvanFile Added: ZBug.pk3
2013-07-29 14:57WatermelonAssigned To => Watermelon
2013-07-29 14:57WatermelonStatusnew => assigned
2013-07-29 14:58WatermelonNote Added: 0006831
2013-07-29 16:29IvanNote Added: 0006833
2013-07-29 19:37Torr SamahoNote Added: 0006835
2013-07-29 21:43IvanNote Added: 0006840
2013-07-29 21:50DuskDescription Updatedbug_revision_view_page.php?rev_id=3819#r3819
2013-07-29 23:32DuskNote Added: 0006841
2013-07-30 08:04IvanNote Added: 0006842
2013-07-31 15:27WatermelonNote Added: 0006861
2013-07-31 17:25WatermelonNote Added: 0006863
2013-07-31 17:25WatermelonAssigned ToWatermelon =>
2013-07-31 17:25WatermelonAssigned To => Watermelon
2013-07-31 17:25WatermelonStatusassigned => new
2013-07-31 17:26WatermelonNote Edited: 0006863bug_revision_view_page.php?bugnote_id=6863#r3835
2013-07-31 17:27WatermelonAssigned ToWatermelon =>
2013-07-31 17:28WatermelonNote Edited: 0006863bug_revision_view_page.php?bugnote_id=6863#r3836
2013-07-31 17:32WatermelonNote Edited: 0006863bug_revision_view_page.php?bugnote_id=6863#r3837
2013-07-31 17:39WatermelonNote Edited: 0006863bug_revision_view_page.php?bugnote_id=6863#r3838
2013-07-31 19:11Torr SamahoNote Added: 0006866
2013-07-31 23:36WatermelonNote Added: 0006867
2013-08-01 00:29WatermelonNote Added: 0006868
2013-08-01 03:02WatermelonAssigned To => Watermelon
2013-08-01 03:02WatermelonStatusnew => assigned
2013-08-01 03:21WatermelonNote Added: 0006869
2013-08-01 03:21WatermelonStatusassigned => needs review
2013-08-09 17:09WatermelonStatusneeds review => needs testing
2013-09-18 18:17WatermelonStatusneeds testing => resolved
2013-09-18 18:17WatermelonResolutionopen => fixed
2018-09-30 22:44Blzut3Statusresolved => closed

Notes
(0006831)
Watermelon   
2013-07-29 14:58   
I'll look into this
(0006833)
Ivan   
2013-07-29 16:29   
Here's a video showing it in action:'https://www.dropbox.com/s/yja1x9vgk94wf4p/ZbugVid.zip [^]'
(0006835)
Torr Samaho   
2013-07-29 19:37   
Quote from Ivan
This was working perfectly in Zandronum 1.1

Is this a typo and you meant 1.0?
(0006840)
Ivan   
2013-07-29 21:43   
Oh sorry, it IS a typo.
(0006841)
Dusk   
2013-07-29 23:32   
Quote
A_Stop also causes a weird desync. Try to replace the ACS_executeAlways(503, 0) lines with A_Stop and you'll notice that the traps move on their own, however when you press the fire key they will be moved to their ACTUAL position. Might as well fix two bugs at once, right?

This sounds like a different issue, thus should go into a separate ticket, right?
(0006842)
Ivan   
2013-07-30 08:04   
I don't know, I thought this could be viewed as a desync issue then again, I seem to have derped as I wrote this because that one doesn't have to do with the Z predictions...
(0006861)
Watermelon   
2013-07-31 15:27   
Only happens online, going to try to find the revision it occurs at
(0006863)
Watermelon   
2013-07-31 17:25   
(edited on: 2013-07-31 17:39)
Appears to have started here:
'https://bitbucket.org/Torr_Samaho/zandronum/commits/704bc808f81cf49ee35d81bc7dada8d9c8b5ad5d [^]'


Interestingly on the first map (map01) it does not happen, but if you change map to something else it begins happening.



Since this is not something I've added, I'm going to set it available to be assigned to again. I will attempt a fix but there is an option here for Torr if he wants to take it over



EDIT:
It appears that when the object hits the ground and spawns the new actor, it spawns it at the "->lastX/Y/Z" of the previous actor on non-map01 maps.

What happens is in the Death state, it is sent back to the Spawn state, and therefore I guess it is being set back to where it 'spawned' which in this case is the center of the player. I don't know if Death -> Spawn states is intended behavior, but it appears to work in 1.0.
(0006866)
Torr Samaho   
2013-07-31 19:11   
Quote from Watermelon

Since this is not something I've added, I'm going to set it available to be assigned to again. I will attempt a fix but there is an option here for Torr if he wants to take it over

If you'd like to work on this, feel free to. Could be a good opportunity to get more familiar with the monster movement system and bandwidth saving mechanism introduced in 1.0. If you'd like me to take care of this instead, just let me know.
(0006867)
Watermelon   
2013-07-31 23:36   
I'm going to be attempting to solve this. If I can't get it done in a few days then I'll let you know



So far it's a desync between the client and server. The client traps upon hitting the ground and entering the Death state (or entering the Spawn state, one of the two) are being set to lastX/Y/Z, when on the server end it's at the proper spot (on the ground). Lets see if I can solve this
(0006868)
Watermelon   
2013-08-01 00:29   
After a crap ton of debugging, it seems:
[20:17:58] Ghosttrap: 29622272 105906176 2097152 / 0 0 0 <CLIENT GETS THIS>

[20:17:58] Ghosttrap: 29622272 106299392 2097152 / 0 0 0
[20:17:58] Ghosttrap: 29622272 106692608 2031616 / 0 0 0
[20:17:58] Ghosttrap: 29622272 107085824 1900544 / 0 0 0
[20:17:58] Ghosttrap: 29622272 107479040 1703936 / 0 0 0
[20:17:58] Ghosttrap: 29622272 107872256 1441792 / 0 0 0
[20:17:58] Ghosttrap: 29622272 108265472 1114112 / 0 0 0
[20:17:58] Ghosttrap: 29622272 108658688 720896 / 0 0 0
[20:17:58] Ghosttrap: 29622272 109051904 262144 / 0 0 0
[20:17:58] Ghosttrap: 29622272 109445120 0 / 0 0 0
[20:17:58] Ghosttrap: 29622272 109445120 0 / 29622272 109445120 0
[20:17:58] Ghosttrap: 29622272 109445120 0 / 29622272 109445120 0
[20:17:58] Ghosttrap: 29622272 109445120 0 / 29622272 109445120 0
[20:17:58] Ghosttrap: 29622272 109445120 0 / 29622272 109445120 0
... etc

Seems the server does not set the last known position properly, upon fixing this if I can find where to put it, that should be good. I don't know why it's setting it later on and not earlier though.
(0006869)
Watermelon   
2013-08-01 03:21   
I think I got it! So many hours spent on this bug for so little lines of code... I hope this really solves it

Can you see anything wrong with this? It may need to go in more than one area. If you know a better place or method to do this feel free to do so.



'https://bitbucket.org/Water_Melon/wbuild/commits/8aebf400b13a99eb20e6372058c06c4413721848 [^]'