Anonymous | Login | Signup for a new account | 2024-11-10 19:49 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
0001609 | Zandronum | [All Projects] Suggestion | public | 2013-12-09 23:13 | 2017-04-17 18:36 | ||||||||
Reporter | Ijon Tichy | ||||||||||||
Assigned To | Torr Samaho | ||||||||||||
Priority | normal | Severity | tweak | Reproducibility | N/A | ||||||||
Status | assigned | Resolution | fixed | ||||||||||
Platform | OS | OS Version | |||||||||||
Product Version | 1.2 | ||||||||||||
Target Version | Fixed in Version | 2.0 | |||||||||||
Summary | 0001609: Don't report inventory/actor property changes if they haven't actually changed | ||||||||||||
Description | 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. | ||||||||||||
Attached Files | tooptimize.pk3 [^] (1,186 bytes) 2013-12-20 02:18 | ||||||||||||
Relationships | ||||||
|
Notes | |
(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. |
(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. |
(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. |
(0007719) Ijon Tichy (reporter) 2013-12-23 03:25 |
Seems to work here. |
(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. |
(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 |
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 |
Copyright © 2000 - 2024 MantisBT Team |