0001099: Certain actors aren't synced properly between the client and server

Notes
(0007323) Ivan (reporter) 2013-10-06 13:01	Was this ever solved?

(0007336) Torr Samaho (administrator) 2013-10-06 19:41 edited on: 2013-10-06 20:06	No, it's still broken. I suspect it has to do with RANDOMIZE, but isn't this flag only meant to be used on projectiles? EDIT: RANDOMIZE doesn't seem to have any effect here since the spikes are no projectiles.

(0007338) Blzut3 (administrator) 2013-10-06 20:26	Actor's spawned by the level are randomized: void AActor::LevelSpawned () { if (tics > 0 && !(flags4 & MF4_SYNCHRONIZED)) tics = 1 + (pr_spawnmapthing() % tics); angle_t incs = AngleIncrements (); angle -= angle % incs; flags &= ~MF_DROPPED; // [RH] clear MF_DROPPED flag HandleSpawnFlags (); // [BC] Mark this item as having been spawned on the map. ulSTFlags \|= STFL_LEVELSPAWNED; }

(0007339) Ivan (reporter) 2013-10-06 23:11	But that doesn't explain the screenshots. They weren't spawned by the game on both occassions, were they?

(0007340) Blzut3 (administrator) 2013-10-06 23:41	I assume the level has the actors placed on the map right? That means the initial state will have a random duration between 1-30 causing the behavior seen offline. I haven't traced through the net code since Torr's question was merely where the randomization is coming from. If I were to guess, it looks like this information isn't transferred to the clients on a net game so they use the full duration of the state causing them to appear to move in sync while they are not on the server.

(0007341) Torr Samaho (administrator) 2013-10-07 06:06	Thanks, Blzut3! That was exactly what I was looking for and should be enough information for me to fix this. It also seems to show a workaround for his bug you can use till it's fixed in Zandronum: Giving the actors the SYNCHRONIZED flag should get them in sync on client and server.

(0007343) Ivan (reporter) 2013-10-07 11:42	I didn't even know such a flag existed! Thanks!

(0007458) Arco (updater) 2013-10-23 19:00	Quote [14:33] <@IvanDobrovski> they seem to deal the damage on the right frames now even with RANDOMIZE on them, tested on a project [14:33] <@IvanDobrovski> so I guess it works, since in the old one it would deal damage without even showing the damaging frames :p [14:33] <+Arco> Online? [14:55] <@IvanDobrovski> yeah [14:55] <@IvanDobrovski> tested online [14:55] <@IvanDobrovski> well [14:55] <@IvanDobrovski> local server [14:55] <@IvanDobrovski> if that counts, since in the old case it wouldnt work even on a local one

**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 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
2012-10-04 17:06	unknownna	New Issue
2012-10-04 17:06	unknownna	File Added: upspikes_01.wad
2012-10-04 17:07	unknownna	File Added: Screenshot_Doom_20121004_184954.png
2012-10-04 17:07	unknownna	Status	new => confirmed
2012-10-04 17:07	unknownna	Relationship added	related to 0001090
2012-10-04 17:35	unknownna	Reporter	unknownna => NotIvan
2013-10-06 13:01	Ivan	Note Added: 0007323
2013-10-06 19:41	Torr Samaho	Note Added: 0007336
2013-10-06 20:06	Torr Samaho	Note Edited: 0007336	View Revisions
2013-10-06 20:26	Blzut3	Note Added: 0007338
2013-10-06 23:11	Ivan	Note Added: 0007339
2013-10-06 23:41	Blzut3	Note Added: 0007340
2013-10-07 06:06	Torr Samaho	Note Added: 0007341
2013-10-07 11:42	Ivan	Note Added: 0007343
2013-10-23 19:00	Arco	Note Added: 0007458
2013-10-23 19:01	Arco	Status	confirmed => resolved
2013-10-23 19:01	Arco	Resolution	open => no change required
2018-09-30 22:44	Blzut3	Status	resolved => closed