MantisBT - Zandronum
View Issue Details
0000166Zandronum[All Projects] Bugpublic2010-11-03 07:082018-09-30 20:08
unknownna 
Torr Samaho 
highmajoralways
closedfixed 
98d 
1.0 
0000166: [98d] MAPINFO "aircontrol" value causes extreme misprediction of player movement in air online
I noticed this in a "Megaman 8-Bit Deathmatch" server. The "gravity" and "aircontrol" values set in the MAPINFO lump is not reflected on the server/clients. The gravity is synced though, but the aircontrol is not.

In the worst case, the maps become unplayable online when you have a high ping.
Test the example WAD on a local server with an emulated ping of approximately 300ms+.
Seems to work properly in 98c.
No tags attached.
? mapinfo_aircontrol_desync_test.wad (2,795) 2010-11-03 07:08
/tracker/file_download.php?file_id=79&type=bug
? aircontrol_gravity_test.wad (6,886) 2010-11-07 09:15
/tracker/file_download.php?file_id=85&type=bug
Issue History
2010-11-03 07:08unknownnaNew Issue
2010-11-03 07:08unknownnaFile Added: mapinfo_aircontrol_desync_test.wad
2010-11-06 20:59Torr SamahoNote Added: 0000560
2010-11-06 20:59Torr SamahoAssigned To => Torr Samaho
2010-11-06 20:59Torr SamahoStatusnew => feedback
2010-11-07 02:54unknownnaNote Added: 0000566
2010-11-07 02:54unknownnaStatusfeedback => assigned
2010-11-07 07:42Torr SamahoNote Added: 0000569
2010-11-07 07:42Torr SamahoStatusassigned => feedback
2010-11-07 09:15unknownnaFile Added: aircontrol_gravity_test.wad
2010-11-07 09:19unknownnaNote Added: 0000570
2010-11-07 09:19unknownnaStatusfeedback => assigned
2011-02-06 20:47Torr SamahoNote Added: 0000989
2011-02-06 20:47Torr SamahoStatusassigned => feedback
2011-02-07 07:12unknownnaNote Added: 0001003
2011-02-07 07:12unknownnaStatusfeedback => assigned
2011-02-07 07:54unknownnaNote Edited: 0001003bug_revision_view_page.php?bugnote_id=1003#r477
2011-02-07 08:22unknownnaNote Edited: 0001003bug_revision_view_page.php?bugnote_id=1003#r478
2011-02-07 08:25unknownnaNote Edited: 0001003bug_revision_view_page.php?bugnote_id=1003#r479
2011-02-07 08:27unknownnaNote Edited: 0001003bug_revision_view_page.php?bugnote_id=1003#r480
2011-03-27 15:51Torr SamahoNote Added: 0001197
2011-03-27 15:56Torr SamahoStatusassigned => feedback
2011-03-27 16:34unknownnaNote Added: 0001199
2011-03-27 16:34unknownnaStatusfeedback => assigned
2011-03-27 16:54Torr SamahoNote Added: 0001201
2011-03-27 16:56Torr SamahoStatusassigned => feedback
2011-03-27 17:08unknownnaNote Added: 0001202
2011-03-27 17:08unknownnaStatusfeedback => assigned
2011-03-27 17:16Torr SamahoStatusassigned => resolved
2011-03-27 17:16Torr SamahoFixed in Version => 1.0
2011-03-27 17:16Torr SamahoResolutionopen => fixed
2011-03-27 17:27Torr SamahoProduct Version => 98d
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug
2018-09-30 20:08Blzut3Statusresolved => closed

Notes
(0000560)
Torr Samaho   
2010-11-06 20:59   
Please test if this fixes the issue.
(0000566)
unknownna   
2010-11-07 02:54   
Well, it definitely took care of the misprediction of the player movement. However, The air control and gravity values set in the MAPINFO lump are reflected on the client, but not in the server console.

And if you through the server console change the "sv_aircontrol" value to; e.g., 0.3, it'll be reflected as 0.299988 on the client. It's not like this in 98d-3016.

Another issue is; changes in the gravity factor locally through ACS, i.e., "SetActorProperty APROP_Gravity". The prediction becomes incorrect and shaky. I noticed this in a MM8BDM map called "MM1ICE". If I am correct, the gravity factor is altered whenever you fall into, or leave a "deep water" sector.
(0000569)
Torr Samaho   
2010-11-07 07:42   
> However, The air control and gravity values set in the MAPINFO lump are reflected on the client, but not in the server console.

That's a side effect of the way I use to synchronize the values. In ZDoom, the sv_aircontrol/sv_gravity value is only used if it has been altered since the level was started. Before the values are altered, the corresponding values from mapinfo are used. In order to synchronize the behavior the server doesn't send the value of sv_aircontrol/sv_gravity but the actual value that is currently used.

> And if you through the server console change the "sv_aircontrol" value to; e.g., 0.3, it'll be reflected as 0.299988 on the client. It's not like this in 98d-3016.

That's a small rounding issue because sv_aircontrol is a float while level.aircontrol is an integer.

> changes in the gravity factor locally through ACS, i.e., "SetActorProperty APROP_Gravity". The prediction becomes incorrect and shaky.

From a quick look at the code I'd say that the ACS functions SETACTORPROPERTY (Gravity), SETGRAVITY, SETGRAVITYDIRECT, SETAIRCONTROL and SETAIRCONTROLDIRECT are not adapted to the c/s architecture yet and never worked properly online before. Can you make an example wad that uses these function so that I can test the necessary fixes?
(0000570)
unknownna   
2010-11-07 09:19   
Made the example WAD. Doom Builder wouldn't let me compile the ACS scripts with SETGRAVITYDIRECT and SETAIRCONTROLDIRECT. And I couldn't find any information about them in the ZDoom wiki either.
(0000989)
Torr Samaho   
2011-02-06 20:47   
This should fix the ACS commands.
(0001003)
unknownna   
2011-02-07 07:12   
(edited on: 2011-02-07 08:27)
Yes, it fixed the issues. But would it be possible to clear the effects from players turning into spectators?

Some functions that aren't cleared (might be more):

SetGravity
SetAirControl
SetActorProperty APROP_Speed

SetGravity and SetAirControl probably affects all players, so I suppose it's not an issue, but the APROP_* (only tested APROP_Speed) properties are still in effect when you turn into a spectator.

EDIT:

There's still a lot of misprediction going on in the "MM1ICE" map when playing with a ping of around 300ms. It happens when you hold jump. But I think this is due to the combination of the DECORATE and ACS code working together. When you fall into a sector, a script gives you an inventory item, which then calls another script that alters the APROP_Gravity setting. This seems to be a natural consequence of the delay between the client / server.

(0001197)
Torr Samaho   
2011-03-27 15:51   
This should reset all relevant spectator properties you can set with SetActorProperty (this are only Speed and Gravity, the others shouldn't have any effect an spectators anyway).

> SetGravity and SetAirControl probably affects all players, so I suppose it's not an issue

I think so too.

> This seems to be a natural consequence of the delay between the client / server.

Yeah, sounds natural.

So all bugs reported in this ticket should be fixed by now, right?
(0001199)
unknownna   
2011-03-27 16:34   
> This should reset all relevant spectator properties you can set with SetActorProperty (this are only Speed and Gravity, the others shouldn't have any effect an spectators anyway).

Alright, it seems to be working as intended.

> SetGravity and SetAirControl probably affects all players, so I suppose it's not an issue

> I think so too.

Well, I do think that spectators should be unaffected by global map-effects if possible. From testing, it doesn't seem like they're noticeably affected by the global aircontrol/gravity, but I'm not completely sure about this.

> So all bugs reported in this ticket should be fixed by now, right?

Other than the possible SetGravity/SetAirControl issue, yes, I think so.
(0001201)
Torr Samaho   
2011-03-27 16:54   
> Well, I do think that spectators should be unaffected by global map-effects if possible. From testing, it doesn't seem like they're noticeably affected by the global aircontrol/gravity, but I'm not completely sure about this.

I'm relatively sure that spectators are unaffected by gravity (most likely resetting their gravity property was not necessary but it also didn't hurt) and also think that they are unaffected by the aircontrol value. If you don't observe noticeably different spectator behavior when SetGravity and/or SetAirControl are used, we should just assume that they are unaffected.
(0001202)
unknownna   
2011-03-27 17:08   
Indeed, you may mark this as resolved.