|
Notes |
|
|
|
|
Do you have an example wad which would cause the issue? |
|
|
|
(0013768)
|
|
Borg
|
|
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
|
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
|
|
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 :) |
|
|
|
|
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. |
|
|
|
|
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? |
|
|
|
|
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
|
|
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
|
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
|
|
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 -2**15 < x < 2**15 - 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
|
|
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.. |
|
|
|
|
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. |
|