Fixes asset cache locking up the MC initialization at world start.
Fixes asset cache not pre-loading resources to clients that connect from a world reboot.
Fixes a null reference runtime relating to the client disconnecting at the wrong time (I still conciser this to be a byond bug)
Fixes crew monitor registering assets because they exist
Fixes crew monitor trying to send zlevel assets for zlevels it hasn't processed.
Fixes nano ui sometimes not sending the template asset to the client on open.
Clients now cache their jobbans to save on DB queries.
Legacy jobbans and "new" (savefile) jobbans have been removed.
These are old cruft that has been unused for years, and since we require
a DB for notes anyway we might as well just get rid of the legacy stuff.
I considered removing legacy bans as well, but I was unsure if that
would go way beyond the scope of this PR (my main goal here is making
jobban_isbanned not awful).
Also note that this was basically untested, as I do not have a test
database. Any help testing this would be much appreciated.
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.
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.
Also removed a few preferences_toggles verbs that are no longer needed.
Haven't tested this too much yet, but from what I can tell, no ill effects of doing this have been observed.
You can disable byond member features in preferences, something the other method checked, but this could lead to somebody not being able to get in to re-enable them.
be_special and antag defines are no longer limited to 16 values (1 - 32768) by being changed from a bitfield to a list, an appropriate block of code exists to automatically update bitfield versions to the new list format. the list format allows us to have (functionally) infinite antag types.
isbanned() cleaned up, it logs sticky ban matches, and better handles admins being exempt from bans
Adminbans now still work once the admin is demoted.
Admins bypassing a ban because they are an admin is logged and announced to all admins including the one who walked past it.
Admins are now exempt from host bans. (this only applies to host bans for ss13, global host bans (where the 'apply to this game only' checkbox is not checked (defaults to not checked)) do not trigger isbanned() and thus, admins can not bypass them, no matter what we do.)
Added a system to queue a message for a client, to be shown next time they connect, this was needed because isbanned() is called before the client is created, so if you want to send a message to an admin, letting them know they just walked pass a matching ban, you have to do it this way.
The final solution of bad taste in midis question
Added special client verb that kills all sounds currently playing for
this client
This is better because toggle midis only pauses them, not actually stops
them
