MantisBT - Zandronum
View Issue Details
0001609Zandronum[All Projects] Suggestionpublic2013-12-09 23:132017-04-17 18:36
Ijon Tichy 
Torr Samaho 
normaltweakN/A
assignedfixed 
1.2 
2.0 
0001609: Don't report inventory/actor property changes if they haven't actually changed
As it stands, all TakeInventory, GiveInventory, and SetActorProperty changes (among other things, I'm sure) are broadcasted to the client(s) regardless of if anything actually changed. If you TakeInventory a Clip and you're out of bullets, that will be sent to the client regardless of anything having actually changed. This causes ACS scripts that don't do a CheckInventory/CheckActorProperty before every Take/GiveInventory/SetActorProperty call to cause unnecessary traffic, and in severe cases, needless lag.

What I suggest is to keep track of these changes for the tic they're made when in an actual netgame. When an inventory count or actor/player/etc property is changed, store its original value in an array, as well as a reference to the item or property in particular, however that may be. At the end of that tic, check the original value against the new value. If they're the same, there is no need to tell the client that anything changed, and so nothing is sent regarding that value. Otherwise, send an update as usual.

Mods like Samsara do many inventory modifications and actor property changes per tic, according to both clientside CVars (for stuff like classic Wolfenstein movement, classic weapon animations, etc), serverside CVars (jetpack banning, no custom gravity, etc), whether certain items are present (extra life for Blazko, jetpack for Duke, many powerup timers for Ranger), and whatnot. As a result, the mod poorly scales up to player count, and while wrapping code with "if (CheckInventory(things)) { stuff }" blocks is surely possible, it's cumbersome and trades off net friendliness for unnecessary code bloat, ugliness, and wasted cycles. Something like this would help drastically.
No tags attached.
parent of 0001628closed Torr Samaho Give_Inventory doesn't work right online on zandronum 2.0 
? tooptimize.pk3 (1,186) 2013-12-20 02:18
https://zandronum.com/tracker/file_download.php?file_id=1119&type=bug
Issue History
2013-12-09 23:13Ijon TichyNew Issue
2013-12-15 17:38Torr SamahoNote Added: 0007699
2013-12-15 18:09Torr SamahoAssigned To => Torr Samaho
2013-12-15 18:09Torr SamahoStatusnew => assigned
2013-12-16 07:02Torr SamahoStatusassigned => feedback
2013-12-20 02:18Ijon TichyFile Added: tooptimize.pk3
2013-12-20 02:19Ijon TichyNote Added: 0007716
2013-12-20 02:19Ijon TichyStatusfeedback => assigned
2013-12-22 21:35Torr SamahoNote Added: 0007718
2013-12-22 21:35Torr SamahoStatusassigned => needs testing
2013-12-23 03:25Ijon TichyNote Added: 0007719
2013-12-23 04:33QentStatusneeds testing => resolved
2013-12-23 04:33QentFixed in Version => 2.0-beta
2013-12-23 04:33QentResolutionopen => fixed
2013-12-30 18:25Torr SamahoRelationship addedparent of 0001628
2013-12-30 18:31Torr SamahoNote Added: 0007768
2013-12-30 18:31Torr SamahoStatusresolved => assigned
2015-01-23 04:56Blzut3Fixed in Version2.0-beta => 2.0
2017-04-17 18:36KorshunNote Added: 0017174

Notes
(0007699)
Torr Samaho   
2013-12-15 17:38   
Please provide a minimal example wad (or better one example wad for each command you'd like to be optimized in this regard) where these commands create needless traffic. I'll see what I can do about optimizing this behavior.
(0007716)
Ijon Tichy   
2013-12-20 02:19   
Done. See tooptimize.pk3. It's all in one ACS script, but it demonstrates the issue nonetheless.
(0007718)
Torr Samaho   
2013-12-22 21:35   
This should fix the useless traffic in the example wad. BTW: I noticed 2.0 has a bug with the starting ammo of a player on the clients. That has to be fixed separately.
(0007719)
Ijon Tichy   
2013-12-23 03:25   
Seems to work here.
(0007768)
Torr Samaho   
2013-12-30 18:31   
Turns out its not that simple for GiveInventory: If a player gets an additional backback for instance, the amount of backpacks in the player's inventory does not change. Thinking further about this, perhaps GiveInventory may even lead to non-inventory changes (didn't test this), making it infeasible to check whether GiveInventory changed something or not. I'll have to revert the bandwidth saving changes to GiveInventory unless somebody can think about a feasible way to check whether GiveInventory had any effect or not.
(0017174)
Korshun   
2017-04-17 18:36   
The following actor properties are not optimized in 170416-0710:
APROP_Alpha
APROP_AttackSound
APROP_DeathSound
APROP_Invulnerable
APROP_JumpZ
APROP_Health
APROP_PainSound
APROP_SpawnHealth
APROP_RenderStyle
APROP_ViewHeight