Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001609Zandronum[All Projects] Suggestionpublic2013-12-09 23:132017-04-17 18:36
ReporterIjon Tichy 
Assigned ToTorr Samaho 
PrioritynormalSeveritytweakReproducibilityN/A
StatusassignedResolutionfixed 
PlatformOSOS Version
Product Version1.2 
Target VersionFixed in Version2.0 
Summary0001609: Don't report inventory/actor property changes if they haven't actually changed
DescriptionAs 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.
Attached Files? file icon tooptimize.pk3 [^] (1,186 bytes) 2013-12-20 02:18

- Relationships
parent of 0001628closedTorr Samaho Give_Inventory doesn't work right online on zandronum 2.0 

-  Notes
User avatar (0007699)
Torr Samaho (administrator)
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.
User avatar (0007716)
Ijon Tichy (reporter)
2013-12-20 02:19

Done. See tooptimize.pk3. It's all in one ACS script, but it demonstrates the issue nonetheless.
User avatar (0007718)
Torr Samaho (administrator)
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.
User avatar (0007719)
Ijon Tichy (reporter)
2013-12-23 03:25

Seems to work here.
User avatar (0007768)
Torr Samaho (administrator)
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.
User avatar (0017174)
Korshun (reporter)
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

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

- Issue History
Date Modified Username Field Change
2013-12-09 23:13 Ijon Tichy New Issue
2013-12-15 17:38 Torr Samaho Note Added: 0007699
2013-12-15 18:09 Torr Samaho Assigned To => Torr Samaho
2013-12-15 18:09 Torr Samaho Status new => assigned
2013-12-16 07:02 Torr Samaho Status assigned => feedback
2013-12-20 02:18 Ijon Tichy File Added: tooptimize.pk3
2013-12-20 02:19 Ijon Tichy Note Added: 0007716
2013-12-20 02:19 Ijon Tichy Status feedback => assigned
2013-12-22 21:35 Torr Samaho Note Added: 0007718
2013-12-22 21:35 Torr Samaho Status assigned => needs testing
2013-12-23 03:25 Ijon Tichy Note Added: 0007719
2013-12-23 04:33 Qent Status needs testing => resolved
2013-12-23 04:33 Qent Fixed in Version => 2.0-beta
2013-12-23 04:33 Qent Resolution open => fixed
2013-12-30 18:25 Torr Samaho Relationship added parent of 0001628
2013-12-30 18:31 Torr Samaho Note Added: 0007768
2013-12-30 18:31 Torr Samaho Status resolved => assigned
2015-01-23 04:56 Blzut3 Fixed in Version 2.0-beta => 2.0
2017-04-17 18:36 Korshun Note Added: 0017174






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker