.configure delay 0

ID:980354
 
Sep 17 2012, 2:30 am
(See the best response by DarkCampainger.)
The .configure delay 0 instruction. How do I make this into a proc instead of having to access the client in-game?
Sep 17 2012, 3:41 am
Best response
You can use a special form of winset() to call certain client-side commands:
winset(src, null, "command=\".configure delay 0\"")
Sep 17 2012, 3:48 am
Thanks DarkCampainger, appreciate it. Also, I was just wondering. Are there any drawbacks or side-effects from using this as a lag control?
Sep 17 2012, 5:06 am
In response to Zerok Kaiba
Dream Seeker uses it automatically because the client's connection is significantly behind the server. It's its own lag control; tampering with it probably doesn't help as much as you think. There's obviously no way to lessen lag other than getting a better internet service provider.
Sep 17 2012, 6:53 pm
In response to Zerok Kaiba
Zerok Kaiba wrote:
Are there any drawbacks or side-effects from using this as a lag control?

.configure delay 65000 in MLaaS and exploit the doc drop bug
Sep 21 2012, 6:58 am
My ISP is good but a game gets harder to control the bigger it gets. Right now it's at over 14MB and still got a ways to go. Eventually I fear I'll be at a point where tick_lag and fps won't be able to save the game anymore.
Sep 21 2012, 11:34 am
The size (in KB/MB) of the game has very little impact on the amount of lag. I could easily make a very small game that is extremely overtaxed and laggy, as well as a large game that could run very smoothly. It all comes down to your ability as a programming to code the game efficiently (ie. not having NPC's running when there are no players in the immediate vicinity.)
Sep 21 2012, 11:42 am
I have a lot of proc loops such as regeneration and other effectcs being called every few seconds per player. Would this cause a lot of lag?
Sep 21 2012, 11:53 am
Things called per second should be too hard on the server, even with dozens of people. When you start getting into loops that are running on 1 tick delays, that's when things start adding up real fast.
Sep 21 2012, 12:07 pm
In response to Gunbuddy13
Nowadays, people have started to use one global loop for when things have constant tick-by-tick events.
//  e.g.
var tickers[0]
datum/proc/tick()
proc/global_loop()
    spawn while(1)
        for(var/datum/d in tickers)
            d.tick()
        sleep(world.tick_lag)

mob
    tick()
        world << "I'm ticking!"

    verb/start_ticking()
        if(src in tickers) return
        tickers += src

    verb/stop_ticking()
        tickers -= src

It's been found to be better to handle loops like that instead of spawning infinite tick-loops on each individual ticker.
Sep 21 2012, 12:21 pm
At risk of pimping my library too much:

http://www.byond.com/developer/Stephen001/EventScheduling

I've kind of encompassed the whole "global loop" concept into a library that lets you do as Kaiochao does above, but also cancel events, schedule them in the future (and cancel them while pending etc) allowing for a kind of ... better controlled spawn(), in a way.

Performance improvements of course depend on your use-cases, and programming style. It has been used in Phoenix: Sundered Earth though to push their maximum okay player count on a server from 50 or so, to 120. (Little caveat, a lot of that saving will be having to re-write and clean up existing code to allow it to be used in this library, and improving the logic of existing code by adopting an event model)
Sep 21 2012, 11:54 pm
The pixel movement is called every tick. Though every other loop is called every 3 seconds. However, they aren't connected, they just call themselves to continue the loop. Is that tedious and messy? Should I combine them all into a same loop? Or would that not change anything?