It still works because... luck? The only thing that uses this is the
Crew Monitor which sends a Z-level as the argument... Which happens to
work because the Z-level is usually 1.
* Update NanoUI to the latest version, ported from Baystation12
* Update the Air Alarm UI
* Make changes to subsystems and some machines to make the new NanoUI
work
When the MC is making up missed subsystem fires from lag, it will now only fire that subsystem at most, half of that subsystem's normal fire rate until missed fires are made up, rather than firing as quick as possible making lag worst.
When a subsystem causes byond to miss a byond tick, it will stop processing subsystems and sleep for two extra byond ticks on top of its normal sleep rate.
When the cpu is above 80%, the MC will also sleep for twice as long between ticks (stacks with the change above)
The processing interval of the MC is now capped to a lower bound of two byond ticks or 1ds, whatever is lower.
Dwait now scales with the cpu usage var. 10% cpu adds 10% extra to dwait, 50% cpu adds 50% extra to dwait, etc.
Adds crew monitor to the asset cache system
Adds paper to the asset cache system
Added a way to send files to the client slowly without clogging up the queue. (This isn't technically "safe", but the client would only have issues if they didn't have that file already (rare), and only if they used a window that needed that asset (currently only nanoui windows) within the first 15 to 90 seconds of connecting (depending on ping))
Makes NanoUI use this slow send system to blindly send it's asset files. (Once bay's nanoui is ported, i'll improve this so that nanoui fully implements asset cache checking)
Makes asset cache use this system to send all registered asset files, so that ui windows don't have to wait for them if the client's been connected a while.
Replaces typesof(path) - path with subtypesof(path) in obvious places. I was a bit conservative, there's probably a few more places that could use this.
Byond will queue all browse(), browse_rsc(), and winset() calls to the client, to ensure they load in order, and ensure any resources from a browse_rsc call (css/html/js) are already at the client by the time any html windows loads.
How ever, each file is processed separately, and byond will wait for the reply from the client before it will send the next file.
Our current system sends all of these html resource files to the client at once when they connect, this is the sole cause of the lag when a client connects. Byond will not send the client a file it already has, but it has to ask the client first, and it does so one file at a time, waiting for a reply from the client before sending the next one down the pipe.
This system fixes that.
Basically it works like this:
Client connects: nothing happens, no massive queuing of browse_rsc() calls, so no interface delay
Client opens a asset_cache controlled html based interface
Asset cache gets notified by the html based interface what assets the client needs to have.
Asset cache checks to see if it's sent that client those files.
Asset cache sends the missing ones, adding them to the list of assets the client has.
This basically spreads out the delay to when you first open a window that uses resources, where it is much more manageable.
I've kinda done a halfass port without too much thought, I see some room for improvement to better fit /tg/'s coding style and make the system more flexible. I'm PRing this because if I don't, it will never get finished.
PDAs and html_interface has been imported in to the new system lazily to test. at 100ms connection start interface lag went from 35 seconds to 16 seconds. Nanoui hasn't been imported, and once it is, that should drop down to almost nothing.
I'll work on this some more after some sleep.
If the list is missing, it will default to which races are defined as roundstart in the species datums. Plasmamen have been removed from this list pending bugfixes.
If JOIN_WITH_MUTANT_RACE isn't set in config, humans only will still be enforced regardless.
Why use replacetext with no arguments? I have no idea.
This wasn't runtiming because of the bygex stuff I guess.
Thanks octareroon91 for reporting this to me ingame.
For finding a spawn point, it will now use this logic to find a spawn point, stopping at the first one it finds
Empty job spawn point
Filled up job spawn point (spawning them on top of eachother if it can't find enough spawn points)
Late join spawn point
Random tile in the arrivals shuttle area.
If it hits either of those two final points it will pop a message in the runtime log.
