Zandronum Chat on our Discord Server Get the latest version: 3.2
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
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?
Attached Files? file icon ZBug.pk3 [^] (15,200 bytes) 2013-07-29 13:31

- Relationships

-  Notes
User avatar (0006831)
Watermelon (developer)
2013-07-29 14:58

 I'll look into this
User avatar (0006833)
Ivan (reporter)
2013-07-29 16:29

 Here's a video showing it in action:'https://www.dropbox.com/s/yja1x9vgk94wf4p/ZbugVid.zip [^]'
User avatar (0006835)
Torr Samaho (administrator)
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?
User avatar (0006840)
Ivan (reporter)
2013-07-29 21:43

 Oh sorry, it IS a typo.
User avatar (0006841)
Dusk (developer)
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?
User avatar (0006842)
Ivan (reporter)
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...
User avatar (0006861)
Watermelon (developer)
2013-07-31 15:27

 Only happens online, going to try to find the revision it occurs at
User avatar (0006863)
Watermelon (developer)
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.
User avatar (0006866)
Torr Samaho (administrator)
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.
User avatar (0006867)
Watermelon (developer)
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
User avatar (0006868)
Watermelon (developer)
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.
User avatar (0006869)
Watermelon (developer)
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 [^]'

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
2013-07-29 13:31 Ivan New Issue
2013-07-29 13:31 Ivan File Added: ZBug.pk3
2013-07-29 14:57 Watermelon Assigned To => Watermelon
2013-07-29 14:57 Watermelon Status new => assigned
2013-07-29 14:58 Watermelon Note Added: 0006831
2013-07-29 16:29 Ivan Note Added: 0006833
2013-07-29 19:37 Torr Samaho Note Added: 0006835
2013-07-29 21:43 Ivan Note Added: 0006840
2013-07-29 21:50 Dusk Description Updated View Revisions
2013-07-29 23:32 Dusk Note Added: 0006841
2013-07-30 08:04 Ivan Note Added: 0006842
2013-07-31 15:27 Watermelon Note Added: 0006861
2013-07-31 17:25 Watermelon Note Added: 0006863
2013-07-31 17:25 Watermelon Assigned To Watermelon =>
2013-07-31 17:25 Watermelon Assigned To => Watermelon
2013-07-31 17:25 Watermelon Status assigned => new
2013-07-31 17:26 Watermelon Note Edited: 0006863 View Revisions
2013-07-31 17:27 Watermelon Assigned To Watermelon =>
2013-07-31 17:28 Watermelon Note Edited: 0006863 View Revisions
2013-07-31 17:32 Watermelon Note Edited: 0006863 View Revisions
2013-07-31 17:39 Watermelon Note Edited: 0006863 View Revisions
2013-07-31 19:11 Torr Samaho Note Added: 0006866
2013-07-31 23:36 Watermelon Note Added: 0006867
2013-08-01 00:29 Watermelon Note Added: 0006868
2013-08-01 03:02 Watermelon Assigned To => Watermelon
2013-08-01 03:02 Watermelon Status new => assigned
2013-08-01 03:21 Watermelon Note Added: 0006869
2013-08-01 03:21 Watermelon Status assigned => needs review
2013-08-09 17:09 Watermelon Status needs review => needs testing
2013-09-18 18:17 Watermelon Status needs testing => resolved
2013-09-18 18:17 Watermelon Resolution open => fixed
2018-09-30 22:44 Blzut3 Status resolved => closed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker