0002516: Powerups expire much earllier on client side

Notes
(0013766) Edward-san (developer) 2015-11-08 21:56	Do you have an example wad which would cause the issue?

(0013768) Borg (reporter) 2015-11-09 18:57	Sure. Worst written mod ever created ;)) Complex Doom + LCA. Here is code: Actor LegRuneDoubleDamage : PowerDamage { +INVENTORY.HUBPOWER +INVENTORY.PERSISTENTPOWER DamageFactor "Normal", 2 Powerup.Duration 0x7FFFFFFF } Actor LegDoubleFiringSpeed : PowerDoubleFiringSpeed { +INVENTORY.HUBPOWER +INVENTORY.PERSISTENTPOWER Powerup.Duration 0x7FFFFFFF } Actor LegProtection : PowerProtection { +INVENTORY.PERSISTENTPOWER +INVENTORY.HUBPOWER +NORADIUSDMG Powerup.Duration 0x7FFFFFFF DamageFactor "Normal", 0.85 ActiveSound "Pickups/LegProtectionActive" }

(0013796) Torr Samaho (administrator) 2015-11-15 10:12 edited on: 2015-11-15 10:13	An unsigned short is sufficient to transfer numbers up to 65535. Converting tics to minutes, i.e. 65535 / ( 35 * 60 ), that's a duration of more than 31 minutes. Instead of using more net traffic for all powerups, I wonder whether we should just have the server instruct the client that the duration of such powerups is infinite and have the server tell the client to remove the powerup when it's run out.

(0013825) Borg (reporter) 2015-11-16 17:18	Only 31 minutes :) Remember we are speaking about +PERSISTENTPOWER Second.. How often Powerup are syned over network? It should be once per pickup and once per map enter.. Other place is on expire.. once only. No big deal. Do NOT do premature optimization in place where this is insignificant. Of course I could be mistaken, I didnt read who source code... But if I am... You can close it :)

(0013827) Torr Samaho (administrator) 2015-11-16 18:45	Quote from Borg How often Powerup are syned over network? Currently, the client is informed on pickup and when entering a map. Since the client is supposed to know the duration, the server doesn't notify the client when a powerup expires, but the client removes the powerup on its own when it is supposed to expire.

(0013852) Edward-san (developer) 2015-11-19 00:53	Quote from Torr Samaho Instead of using more net traffic for all powerups, I wonder whether we should just have the server instruct the client that the duration of such powerups is infinite and have the server tell the client to remove the powerup when it's run out. Is the more net traffic really an issue? The powerups are not activated very often, AFAIR. Also, if the clients were to be informed about powerups with 'falsely infinite' duration, wouldn't this break clientside scripts relying on the current number of tics left from a powerup?

(0013854) Torr Samaho (administrator) 2015-11-19 07:07	Quote from Edward-san Is the more net traffic really an issue? The powerups are not activated very often, AFAIR. You never know what mods will do in the future. Using more bandwidth on all powerups while only a tiny fraction of the existing powerups actually need the additional bandwidth doesn't sound like a good deal. Quote from Edward-san Also, if the clients were to be informed about powerups with 'falsely infinite' duration, wouldn't this break clientside scripts relying on the current number of tics left from a powerup? Yes, that's right. Since this is not the first time such a thing is happening, we should think about more flexible ways to send data where we don't know the necessary amount of bytes in advance.

(0013857) Borg (reporter) 2015-11-19 18:42	Hmm. Isnt that a bit overcomplicated? Just gather and group all the stuff you send to client. Sort them how frequently you send info to client and you know where you should optimize for size and where you can have more freedom..

(0013858) Torr Samaho (administrator) 2015-11-19 19:56 edited on: 2015-11-19 19:57	Quote from Borg Hmm. Isnt that a bit overcomplicated? Not if it's a generic solution that can be easily applied to all network commands that use integer values that are usually small, but sometimes may be very big. Quote from Borg Just gather and group all the stuff you send to client. Sort them how frequently you send info to client and you know where you should optimize for size and where you can have more freedom.. Unfortunately, the frequency of the network commands heavily depends on the gamemode and the mod. So it's not that simple. I think the best solution would be to use a proper automatic compression on the network streams like lz4, but that requires some fundamental changes to how we handle the network streams.

(0013859) Dusk (developer) 2015-11-19 21:06	The ideal case would be if we had some form of compression going on that was not huffman, then increasing length of commands wouldn't be as much of an issue. Alas that doesn't seem to be happening. I made SVC_ACSSCRIPTEXECUTE use variable length arguments. A control byte describes how long the parameter is. Applying that universally for one integer x, we get the following lengths for sending it: - 2 bytes, when -128 < x < 127 - 3 bytes, when -215 < x < 215 - 1 - 5 bytes otherwise. So, if the expected value of x is enough to be sent as a short and otherwise is rare, we get, on average, a 1-2 bytes saving with this method in compared to sending a long. In compared to sending a short (2 bytes), it, on average, still eats up bandwidth at least 3 bytes if the expected value of x is not suitable for being sent as a byte. So it should be an useful approach when x is usually in short range but can be long as well.

(0013860) Borg (reporter) 2015-11-19 22:27	Hmm.. Not sure what hardware you guys have.. But in my case, I usualy start to run out of CPU resources instead of bandwidth.. I run server on small 20Mbit uplink.. If you add all those calculations into net data stream, it looks quite an overhead to me..

(0013862) Torr Samaho (administrator) 2015-11-20 07:10	Quote from Dusk I made SVC_ACSSCRIPTEXECUTE use variable length arguments. Yeah, this goes into the direction I was thinking of, but the average overhead can still be further reduced (6 out of the 8 bits of the control bytes are unused). For instance, we could do something like MSB encoding. Quote from Borg Hmm.. Not sure what hardware you guys have.. But in my case, I usualy start to run out of CPU resources instead of bandwidth.. I'm pretty sure that the CPU time needed to encode / decode variable length integers in a net command is negligible in comparison to the CPU time needed to have the engine process the net command.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2015-11-08 09:35	Borg	New Issue
2015-11-08 21:56	Edward-san	Note Added: 0013766
2015-11-08 21:56	Edward-san	Status	new => feedback
2015-11-09 18:57	Borg	Note Added: 0013768
2015-11-09 18:57	Borg	Status	feedback => new
2015-11-15 10:12	Torr Samaho	Note Added: 0013796
2015-11-15 10:13	Torr Samaho	Note Edited: 0013796	View Revisions
2015-11-15 10:15	Torr Samaho	Note Revision Dropped: 13796: 0008221
2015-11-16 17:18	Borg	Note Added: 0013825
2015-11-16 18:45	Torr Samaho	Note Added: 0013827
2015-11-16 20:37	Borg	Note Added: 0013830
2015-11-17 22:10	Borg	Note Deleted: 0013830
2015-11-19 00:53	Edward-san	Note Added: 0013852
2015-11-19 07:07	Torr Samaho	Note Added: 0013854
2015-11-19 18:42	Borg	Note Added: 0013857
2015-11-19 19:56	Torr Samaho	Note Added: 0013858
2015-11-19 19:57	Torr Samaho	Note Edited: 0013858	View Revisions
2015-11-19 19:58	Torr Samaho	Note Revision Dropped: 13858: 0008255
2015-11-19 21:06	Dusk	Note Added: 0013859
2015-11-19 22:27	Borg	Note Added: 0013860
2015-11-20 07:10	Torr Samaho	Note Added: 0013862

Relationships