world.statfreq

ID:137451
 
Nov 18 2001, 10:56 am
Here's an idea. Setting this number to an amount in ticks would control how often each client would query the server for Stat().

Setting this to zero would make it so that the client would never automatically make a Stat() request.

If I had more control over Stat(), I could easily reduce lag to just about nil in most of my games, by only calling Stat() when variables change.
Nov 18 2001, 12:16 pm
I like the sound of this. I also like the name you gave it, I could tell what you wanted just from the title =).
Nov 18 2001, 2:03 pm
In response to Cinnom
my god that is one of the best ideas ive ever seen requested.

its not a glitzy feature, but its needed, effecient, and important all in one!

FIREking
Nov 18 2001, 5:00 pm
In response to FIREking
yeah with the lag I've experince in my own game even on updating stats, this could be useful! Hope they take note and add something like this in there! ;)

LJR
Nov 19 2001, 4:00 am
Spuzzum wrote:
Here's an idea. Setting this number to an amount in ticks would control how often each client would query the server for Stat().

Setting this to zero would make it so that the client would never automatically make a Stat() request.

If I had more control over Stat(), I could easily reduce lag to just about nil in most of my games, by only calling Stat() when variables change.

Does Stat() really have a noticeable effect on your client-side performance? The amount of data transmitted should be practically negligeable, at least when you factor in typical network overhead from map updates and the like. The only problems I've seen with Stat() have been server-side, where designers are doing long computations inside the proc (a no-no). And I believe (you can test to confirm this) that you can slow the server-side Stat() calls by simply calling sleep() inside them.
Nov 19 2001, 6:45 am
In response to Tom
And I believe (you can test to confirm this) that you can slow the server-side Stat() calls by simply calling sleep() inside them.

Yes, but one of the problems with this is you can't easily wake up from the sleep when things do change, so it is not too appealing to sleep for very long. Ideally, there would be a flag (client.stats_changed) that would cause an update when in this special non-polling mode. The designer could still sleep in Stat() to enforce a minimum time between updates if that turned out to be a concern.

Nov 19 2001, 4:01 pm
In response to Dan
Yes, but one of the problems with this [sleep] is you can't easily wake up from the sleep when things do change

This is off-subject (very) , but does anyone else agree with me that Dan must have been thinking of sleep?
Nov 19 2001, 4:02 pm
In response to StinkyCrapNapkin
wake up from the sleep means
when the sleep proc stops waiting, and lets the rest of the proc continue
Nov 21 2001, 7:26 pm
In response to Tom
Tom wrote:
Spuzzum wrote:
Here's an idea. Setting this number to an amount in ticks would control how often each client would query the server for Stat().

Setting this to zero would make it so that the client would never automatically make a Stat() request.

If I had more control over Stat(), I could easily reduce lag to just about nil in most of my games, by only calling Stat() when variables change.

Does Stat() really have a noticeable effect on your client-side performance? The amount of data transmitted should be practically negligeable, at least when you factor in typical network overhead from map updates and the like. The only problems I've seen with Stat() have been server-side, where designers are doing long computations inside the proc (a no-no). And I believe (you can test to confirm this) that you can slow the server-side Stat() calls by simply calling sleep() inside them.

In that case, if Stat() has no noticeable effect, drop it down to 1 tick! =P

My reasons were so I could manually call Stat() and ignore the built-in Stat() call altogether -- not only would statpanels be more accurate, but they wouldn't be constrained by the fixed 8-tick call. I would also be much enamoured of a rapid Stat() calling, which with my method could be applied well -- that is, updated only when necessary, even once per tick.

Strategy games, for example, would be able to set world.statfreq to 12 or even above, drastically reducing lag when hosted on 56K modems. Action games could set it down to 2 or 1. Turn-based games could easily set it to 0 and update it manually.