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
0000713Zandronum[All Projects] Bugpublic2012-03-25 17:332012-05-01 01:49
ReporterTIHan 
Assigned ToTIHan 
PriorityurgentSeverityminorReproducibilitysometimes
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version98d 
Target VersionFixed in Version 
Summary0000713: Lost Souls desync online
DescriptionMore info here:'http://www.skulltag.com/forum/viewtopic.php?f=33&t=26770 [^]'

"
Lost Souls will desync a lot when infighting, and probably when fighting in general. But it's reproducible by watching them infight. It seems that their positions aren't displayed correctly, so when they attack, their attack starts at a position behind their actual one.

Sometimes both of the Lost Souls will "lock-up" together for a few seconds and then suddenly teleport to their true positions. Also in the demo, you'll see that when one of the Lost Souls "charge backwards", the other Lost Soul won't attack the position of the sprite, but a position behind it instead.

This means that there's a desync between what you see client-side and what's going on server-side, I think. It's a bit difficult to explain.
"
Attached Files? file icon 2012.04.24_10.03.34_doom2.cld [^] (63,995 bytes) 2012-04-24 08:06
? file icon 2012.04.30_13.39.31_doom2.cld [^] (185,481 bytes) 2012-04-30 12:07
? file icon monster_teleport_01.wad [^] (4,866 bytes) 2012-04-30 16:37
png file icon Screenshot_Doom_20120430_175327.png [^] (45,458 bytes) 2012-04-30 16:39

- Relationships

-  Notes
User avatar (0002932)
unknownna (updater)
2012-03-27 21:35

 > If you run into a Lost Soul that is charging backwards, it'll lock up at that position until it's true position hits a wall (or another actor). That's why a Lost Soul was attacking a spot behind the sprite of another Lost Soul, because it knew the true location of the other Lost Soul.

> Cacodemons' z-axis movement tend to desynchronize badly when you shoot them with a rocket from below and make them thrust up and towards a wall. There's a great desynchronization between the client and the server in terms of thrusting the Cacodemons when they're shot.
User avatar (0003273)
TIHan (reporter)
2012-04-15 04:45

 If someone can provide a WAD that can, for the most part, easily reproduce the issues stated, we can probably work out this bug.
User avatar (0003413)
TIHan (reporter)
2012-04-24 03:09

 Can someone try this?
'http://www.mediafire.com/download.php?65p1njbkb6py3yx [^]'

I've attempted to address the issues stated above. Please tell me if they are gone. Also in the build, I've included the monster bandwidth reduction patch.
User avatar (0003415)
unknownna (updater)
2012-04-24 08:06

 Nice, it seems that you considerably improved the LS behavior. I recorded a demo of the Cacodemon issue with your test build since it's not fixed yet.
User avatar (0003417)
TIHan (reporter)
2012-04-24 13:17
edited on: 2012-04-24 13:29

 > I recorded a demo of the Cacodemon issue with your test build since it's not fixed yet.

Then it must not be in P_ZMovement. I'll have to look at this later. Probably late tonight or tomorrow.

FYI, to fix the lost soul issue I applied a custom THRUACTORs flag for monsters. Looks like the client doesn't handle stuff properly when actor monsters hit other actors.
User avatar (0003418)
unknownna (updater)
2012-04-24 13:50

 > FYI, to fix the lost soul issue I applied a custom THRUACTORs flag for monsters

I noticed a side effect: Monsters that are moving on bridge things will glitch around. It looks like their positions are updated only when they change their direction or attack.
User avatar (0003419)
TIHan (reporter)
2012-04-24 14:57

 > It looks like their positions are updated only when they change their direction or attack.

This is the new system Carn wrote of how monsters are handled, they are only updated under those conditions, everything else is client-side.

The problem we have, is that monsters do not update when they hit things - which we are seeing is a problem in certain cases. If I allow updates when monsters hit actors/walls/ceilings - bandwidth would skyrocket 150%.

Since I believe bridge things are also actors, the custom THRUACTORs flag applies to those bridges. When I get a chance, I'll modify the flag and make something like THRUMONSTERS. But, even with this I fear problems, because what if monsters are piled up on top of each other? The client-side will just make them go through each other.

Perhaps we need an entirely new approach to the problem.
User avatar (0003421)
Torr Samaho (administrator)
2012-04-25 01:52

 Since actor-actor hits are important for monster movement I don't see why turning off client side actor-actor hits while still not letting the server inform the client about the hit should improve the situation (unless there was no actor-actor hit on the server and the client mispredicted this). Perhaps there is more to the issue.
User avatar (0003423)
TIHan (reporter)
2012-04-25 02:22

 > I don't see why turning off client side actor-actor hits while still not letting the server inform the client about the hit should improve the situation (unless there was no actor-actor hit on the server and the client mispredicted this). Perhaps there is more to the issue.

My first thought was that the server would take care of some of it, so it gave me the idea that the client won't do any hit detection. Looks like I didn't think properly.

So, let's stay away from THRU* stuff. I think it's fine for the client-side to predict the hit-detection and obviously, that is not being handled properly.
User avatar (0003436)
TIHan (reporter)
2012-04-26 02:06
edited on: 2012-04-26 04:05

 Here is a screenshot of where I see desync issues between client and server hit dection regarding the lost soul.
'http://imgur.com/9WJ3t [^]'

Edit:
I believe I have pinpointed exactly what is causing the lost soul desync. Stay tuned.
User avatar (0003438)
TIHan (reporter)
2012-04-26 05:47
edited on: 2012-04-26 06:07

 THIS should solve at least the lost soul issue. I haven't tried the cacodemon one, but someone please test that.

I have a theory of these desyncs, as I can somewhat reproduce them on ground monsters now by comparing large crowds of monsters online vs offline. It's very subtle - since nothing is ever perfectly timed between client and server, even if its close, there is chance an actor will force itself through another actor on the client-side even though it's impossible as the game mechanics forbid it. It can be caused by lack of precision and/or timing.

In our case, our lost soul had a desync with its position when it got shot. The player could run into the lost soul and it would stop. What happened here was that the player actually went into the lost soul, breaking game mechanic rules and causing bad results. Setting the lost soul's precise 32-bit position when it got shot, fixed the desync issues. Oh but wait, there's more! Due to latency and non-absolute perfect timing, there is a chance I could still move through our lost soul even at perfect precision, causing our charging backwards desync issue. To fix this, I have to find a way to manage what happens when actors go through actors without breaking game mechanics, but with the lost soul this was pretty easy.
User avatar (0003439)
unknownna (updater)
2012-04-26 07:30

 > THIS should solve at least the lost soul issue.

It seems to have fixed the charging backwards issue, but the lost souls will still "lock-up" and desync when attacking one another.

Quote from unknownna
Sometimes both of the Lost Souls will "lock-up" together for a few seconds and then suddenly teleport to their true positions

It looks like the lost souls sometimes aren't thrusted backwards by the damage they receive from another charging lost soul, so they suddenly start to attack from a position far away from their position on the client-end.

> I haven't tried the cacodemon one, but someone please test that.

The cacodemon issue is still there.
User avatar (0003440)
Torr Samaho (administrator)
2012-04-26 11:32
edited on: 2012-04-26 11:34

 > there is chance an actor will force itself through another actor on the client-side even though it's impossible as the game mechanics forbid it. It can be caused by lack of precision and/or timing.

To me this does doesn't sound as if it is caused by lack of precision or timing. The only exception I can think of right now is if the server instructs the client to move an actor into another actor with SERVERCOMMANDS_MoveThing. Did you check whether the client properly checks the position it is told in SERVERCOMMANDS_MoveThing?
User avatar (0003444)
TIHan (reporter)
2012-04-26 13:33
edited on: 2012-04-26 13:39

 > To me this does doesn't sound as if it is caused by lack of precision or timing.
The lost soul charging backwards was most certainly a precision issue. However, I didn't test very rigorously to see if it was.

> Did you check whether the client properly checks the position it is told in SERVERCOMMANDS_MoveThing?
No I have not. I'll look at that later tonight.
User avatar (0003460)
TIHan (reporter)
2012-04-27 05:23

 Try this to see what affect this has on collision detection.

I started a branch.'https://bitbucket.org/TIHan/tst/changeset/cd0cfc4318af [^]'
User avatar (0003465)
unknownna (updater)
2012-04-27 08:17

 > Try this to see what affect this has on collision detection.

The charging backwards lost soul issue and the monster on bridge thing issue is gone, but I still noticed the other lost soul and cacodemon issues. Did you check out the demo yet? It's very easy to reproduce the cacodemon issue.
User avatar (0003466)
Torr Samaho (administrator)
2012-04-27 11:27

 >> To me this does doesn't sound as if it is caused by lack of precision or timing.
> The lost soul charging backwards was most certainly a precision issue.

As I said above: "To me this does doesn't sound as if it is caused by lack of precision or timing. The only exception I can think of right now is if the server instructs the client to move an actor into another actor with SERVERCOMMANDS_MoveThing." The second sentence of my statement is very important and from what we discussed yesterday it seems as this my conjecture has to do with what's causing the problems.
User avatar (0003474)
TIHan (reporter)
2012-04-27 22:17

 > but I still noticed the other lost soul and cacodemon issues.

I have a feeling these may not be related to the actors moving into other actors problem.

A lot of this is very new to me, as I'm having to understand at least a big chunk of the physics and collision handling behind ZDoom.
User avatar (0003481)
TIHan (reporter)
2012-04-28 17:26

 This should fix the cacodemon desyncs. Changeset

The other lost soul issues are still there though. Trying to figure out what is happening.
User avatar (0003482)
TIHan (reporter)
2012-04-28 19:59
edited on: 2012-04-28 20:00

 I think I've got it!

Please test this to see what desyncs you can reproduce.

My testing confirms that it fixes the lost soul desyncs when they fight each other. I think there was maybe 1 out of the 20 lost souls that were fighting that got desynced but it was very difficult to tell when lost souls flying all over the place, in any case this definitely helps!

'https://bitbucket.org/TIHan/tst/changeset/ec321880dc7a [^]'
User avatar (0003510)
unknownna (updater)
2012-04-30 12:08

 > This should fix the cacodemon desyncs.

It seems that it took care of the cacodemon issues.

> Please test this to see what desyncs you can reproduce.

It seems to have improved the behavior, but I still noticed the same desyncs every now and then. The lost souls seem to desync near ledges and above things before/after attacking and hitting each other. I recorded a demo of it with your test build. Ignore the first 2 lost souls since they didn't bug up.
User avatar (0003511)
unknownna (updater)
2012-04-30 16:37

 I noticed some side effects with your cacodemon fix:

* The client-side prediction of the player movement gets screwed up when you bump into monsters while having a high ping (300). It's most noticeable when you hold +forward while killing a monster, e.g., when you kill a zombieman with the SSG. It looks like your view is shifted to the opposite end of the sector before bouncing back again.

* The cyberdemon in MAP20 teleports, but is displayed on the wrong teleport destination on the client-end. I created an example WAD. It's MAP01 in the example WAD.
User avatar (0003513)
TIHan (reporter)
2012-04-30 20:10
edited on: 2012-04-30 20:34

 > The client-side prediction of the player movement gets screwed up when you bump into monsters while having a high ping (300). It's most noticeable when you hold +forward while killing a monster, e.g., when you kill a zombieman with the SSG. It looks like your view is shifted to the opposite end of the sector before bouncing back again.

I do not think the cacodemon fix has anything to do with this issue, and this issue seems like normal behavior. There is not a proper way to fix this as you cannot predict monster movement.

> The cyberdemon in MAP20 teleports, but is displayed on the wrong teleport destination on the client-end. I created an example WAD. It's MAP01 in the example WAD.

Are you sure is it just the cacodemon fix that causes this? You cannot reproduce it before the cacodemon fix? All the cacodemon fix does is inform clients of the momentum z, which the value of it is 0. At the moment I can't see a reason why it would cause this. I'll look at it more tonight.

Please be specific which fix you are testing against. If you are using the latest one that helped the lost souls fighting each other, I can see that causing some interesting issues such as this.

I would also check the very latest build in Torr's repository as it includes just the cacodemon fix. The builds I have posted here have some extra stuff that may be causing more problems for you. At least by tomorrow I'll have a new build for you that doesn't have a lot of junk code that is causing this cyberdemon issue.

Edit:
I believe I know, just now thinking about it, this cyberdemon issue is caused by the check position/p_movething in my builds. Essentially, if the client sees the new moveposition on an actor is not allowed to move to a new location, it just revert back its previous better know location, so that explains the cyberdemon being where its at on the client, but not on the server. Torr suggested we have a method that tries to put the actor in the closest possible spot; looks like we are going to have to do that.
User avatar (0003514)
unknownna (updater)
2012-04-30 20:34
edited on: 2012-04-30 20:37

 > Are you sure is it just the cacodemon fix that causes this? You cannot reproduce it before the cacodemon fix?

My mistake, it seems that both issues were introduced in 120427-0517.

BTW: Your test builds give me an error in the server console after changemap map changes: "SERVERCONSOLE_SetupColumns: Couldn't get column!".
User avatar (0003517)
Torr Samaho (administrator)
2012-05-01 01:49
edited on: 2012-05-01 02:04

 > Essentially, if the client sees the new moveposition on an actor is not allowed to move to a new location, it just revert back its previous better know location, so that explains the cyberdemon being where its at on the client, but not on the server.

Yeah, this is exactly why I insisted that the client may not simply reject the move.

EDIT: Here is a binary of the latest repository revision (containing TIHan's Caco fix).

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: WaTaKiD
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2012-03-25 17:33 TIHan New Issue
2012-03-27 21:35 unknownna Note Added: 0002932
2012-03-27 21:35 unknownna Status new => confirmed
2012-04-15 04:45 TIHan Note Added: 0003273
2012-04-24 01:37 TIHan Assigned To => TIHan
2012-04-24 01:37 TIHan Status confirmed => assigned
2012-04-24 03:09 TIHan Note Added: 0003413
2012-04-24 03:09 TIHan Status assigned => feedback
2012-04-24 08:06 unknownna Note Added: 0003415
2012-04-24 08:06 unknownna File Added: 2012.04.24_10.03.34_doom2.cld
2012-04-24 13:17 TIHan Note Added: 0003417
2012-04-24 13:17 TIHan Status feedback => assigned
2012-04-24 13:29 TIHan Note Edited: 0003417 View Revisions
2012-04-24 13:50 unknownna Note Added: 0003418
2012-04-24 14:57 TIHan Note Added: 0003419
2012-04-25 01:52 Torr Samaho Note Added: 0003421
2012-04-25 02:22 TIHan Note Added: 0003423
2012-04-26 02:06 TIHan Note Added: 0003436
2012-04-26 03:31 TIHan Note Edited: 0003436 View Revisions
2012-04-26 03:37 TIHan Note Edited: 0003436 View Revisions
2012-04-26 04:05 TIHan Note Edited: 0003436 View Revisions
2012-04-26 05:47 TIHan Note Added: 0003438
2012-04-26 06:07 TIHan Note Edited: 0003438 View Revisions
2012-04-26 06:18 TIHan Status assigned => feedback
2012-04-26 07:30 unknownna Note Added: 0003439
2012-04-26 11:32 Torr Samaho Note Added: 0003440
2012-04-26 11:34 Torr Samaho Note Edited: 0003440 View Revisions
2012-04-26 13:33 TIHan Note Added: 0003444
2012-04-26 13:33 TIHan Status feedback => assigned
2012-04-26 13:39 TIHan Note Edited: 0003444 View Revisions
2012-04-27 05:23 TIHan Note Added: 0003460
2012-04-27 05:23 TIHan Status assigned => feedback
2012-04-27 08:17 unknownna Note Added: 0003465
2012-04-27 11:27 Torr Samaho Note Added: 0003466
2012-04-27 22:17 TIHan Note Added: 0003474
2012-04-27 22:17 TIHan Status feedback => assigned
2012-04-28 17:26 TIHan Note Added: 0003481
2012-04-28 17:26 TIHan Status assigned => feedback
2012-04-28 19:59 TIHan Note Added: 0003482
2012-04-28 19:59 TIHan Status feedback => assigned
2012-04-28 19:59 TIHan Status assigned => feedback
2012-04-28 19:59 TIHan Priority normal => urgent
2012-04-28 20:00 TIHan Note Edited: 0003482 View Revisions
2012-04-30 12:07 unknownna File Added: 2012.04.30_13.39.31_doom2.cld
2012-04-30 12:08 unknownna Note Added: 0003510
2012-04-30 16:37 unknownna Note Added: 0003511
2012-04-30 16:37 unknownna File Added: monster_teleport_01.wad
2012-04-30 16:39 unknownna File Added: Screenshot_Doom_20120430_175327.png
2012-04-30 20:10 TIHan Note Added: 0003513
2012-04-30 20:10 TIHan Status feedback => assigned
2012-04-30 20:10 TIHan Status assigned => feedback
2012-04-30 20:18 TIHan Note Edited: 0003513 View Revisions
2012-04-30 20:19 TIHan Note Edited: 0003513 View Revisions
2012-04-30 20:25 TIHan Note Edited: 0003513 View Revisions
2012-04-30 20:28 TIHan Note Edited: 0003513 View Revisions
2012-04-30 20:34 unknownna Note Added: 0003514
2012-04-30 20:34 TIHan Note Edited: 0003513 View Revisions
2012-04-30 20:37 unknownna Note Edited: 0003514 View Revisions
2012-05-01 01:49 Torr Samaho Note Added: 0003517
2012-05-01 02:04 Torr Samaho Note Edited: 0003517 View Revisions
2012-06-09 13:22 Torr Samaho Category General => Bug




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker