* Rocking The Boat, er, Map Vote (#69561)
* Rocking The Boat, er, Map Vote
Hey there,
A while ago, I spooke (typo intentional) to some other people. One frustration I heard was the fact that people would sometimes sneak through map votes during the very start of a shift, during a high-paced portion, or just as a meme. People in OOC would then flood the vote, putting in any given station. However, if a vote happens 10 minutes in- and the round goes for 70 minutes and not many of the original players are around, then it's not particularly fair to those who have to play next shift on a map they bemoan.
So, we can rock the vote! If a player isn't particularly chuffed with the hand they are given, they can poll the players to see if they want to change the map as well. If rocking the vote goes through, huzzah, you get the ability to vote for the map again. If it doesn't go through: tough luck. You can rock the vote one time per shift by default, and server operators can change the amount of times you can call to rock the map vote at their discretion. Calling to rock the vote either successfully or non-successfully counts as a "call", and when that limit is exceeded: no more calls.
Does this mean that we will only rotate between two maps because pissants will keep rocking the vote until they get what they like? Maybe? I still see people bemoan getting Tram or shit the bed over IceBox, but I think enough people get sick of bread-on-butter to take the server where it need to go. If operators don't really like seeing only two maps play, they can always adjust the config to ensure it doesn't happen.
* makes the grammar grammar
it would be "Rock the Vote vote" otherwise
* Rocking The Boat, er, Map Vote
Co-authored-by: san7890 <the@san7890.com>
* I shaved 2 seconds off atom init times and it's boring (#69742)
* I shaved 2 seconds off init times by moving some sleep tests to only run during unit testing and using ``as anything``
* I shaved 2 seconds off atom init times and it's boring
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Cleans up a mistake in SSair init (#69831)
Ok so in linda turfs use current_cycle to tell if they've been visited
by process_cell yet.
In a recent pr of mine, I expanded its use to init, so I could make sure
we don't double visit tiles.
However, I did this in such a way that it could in theory overrun into a
number that you might find in ssair. So I've changed the logic to make
it decrement, so it's safe in the worst case
* Cleans up a mistake in SSair init
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Revert "Fixes some access issues in the Lavaland base" (#69760)
* Revert "Fixes some access issues in the Lavaland base (#69738)"
This reverts commit a2682d1089.
* renames mining and mining eva
Mining is now Mining Dock
Mining EVA is now Mining Outpost
* Revert "Fixes some access issues in the Lavaland base"
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
* Cadaver spawner fixes (#69544)
fix: Fixed a runtime preventing nonhuman cadavers from spawning properly.
config: Cadaver spawners will no longer yell at you when morgue_cadaver_other_species_probability is blank.
config: morgue_cadaver_disable_nonhumans will now properly disable nonhuman races! (It was reversed, woops.)
* Cadaver spawner fixes
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
Fixes role banned players not being banned from roles that they are banned from (Option Two) (#69703)
I feex
Co-authored-by: Timberpoes <silent_insomnia_pp@hotmail.co.uk>
* Supermatter cascade subsystems fire when it needs to (#69686)
Supermatter cascade by default is offline, and will fire when a supermatter cascade occurs.
* Supermatter cascade subsystems fire when it needs to
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Atmos init speedup, saves 4 seconds (#69697)
* Micro optimizes ssair's turf init, saving 2 seconds
Most of this is making existing operations do more legwork, or cheaper.
I did add cycle checking to ONLY init turf linking, which required
creating a new proc.
Did some horrible horrible things in said proc to save like 0.8 seconds.
I think it was worth it.
* Atmos init speedup, saves 4 seconds
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Micro-optimize GetIdFromArguments to be 48% faster, gaining 0.48s of init time on local (likely more in prod) (#69659)
About The Pull Request
Avoids stringifying key unless its necessary. This was done redundantly twice, but I locked it to just the isnum path, as REF will always return a string, and the other path passes istext.
Use sortTim directly instead of sort_list. sort_list is just sortTim but it copies the list, so it's just wasted cost.
I still would like the bespoke element key option, as that's the only way to drastically cut down costs on things like item descriptions and decals, but this is good for the general use case, and makes it marginally less pressing.
I also want to test if we'd be better off inserting into the list in sorted order rather than sorting it all in the end, but I suspect not.
* Micro-optimize GetIdFromArguments to be 48% faster, gaining 0.48s of init time on local (likely more in prod)
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Fix client timers having invalid <1ds waits (#69356)
About The Pull Request
Timers clamped their waits to >world.tick_lag and rounded it to multiples of the same, but this is invalid for clienttime timers. Clienttime timers have a resolution of one decisecond instead, so we now clamp and round it to that instead. (The stacktrace for negative waits is technically invalid but I didn't care enough to touch it.)
Thanks to LemonInTheDark and MrStonedOne for their help in tracking this issue down.
Why It's Good For The Game
These are effectively zero-wait timers, which can mess up the iteration of the clienttime timer queue by being inserted into the past or current tick's list and causing the head/index to desync, potentially leaving spent timers in the queue or firing them again.
* Fix client timers having invalid <1ds waits
Co-authored-by: Penelope Haze <110272328+out-of-phaze@users.noreply.github.com>
* Adds lazyloading to the asset subsystems (#69454)
* Adds lazyloading to the asset subsystems
This currently applies only to spritesheets because of how monumentally
expensive they are.
If an asset is requested it will immediately be fully loaded, but
otherwise we slowly load them in with a separate subsystem.
This allows us to not hold up initialize with hair stuff. Saves roughly
33% (16 seconds with LOW_MEMORY_MODE) of initialize on my machine
My target is something closer to the 9 second init that had back in
2019, this is a good first step. Lets see how much more we can do yeah
lads?
Co-authored-by: san7890 <the@ san7890.com>
* Adds lazyloading to the asset subsystems
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* Converts SSblackbox feedback to an associative list (#69399)
About The Pull Request
I DID NOT TEST THIS. I DO NOT KNOW DATABASE STUFF. I JUST NOTICED IT WHILE WORKING ON AN UNRELATED PR.
Title.
Why It's Good For The Game
Speeds up a hot proc substantially
* Converts SSblackbox feedback to an associative list
Co-authored-by: Kapu1178 <75460809+Kapu1178@users.noreply.github.com>
* Resolves is_banned_from headaches and lag (Speeds up roundstart significantly) (#69376)
About The Pull Request
Just to be clear, when I refer to time here, I am not talking about cpu time. I'm talking about real time.
This doesn't significantly reduce the amount of work we do, it just removes a lot of the waiting around we need to do for db calls to finish.
Adds queuing support to sql bans, so if an ongoing ban retrieval query is active any successive ban retrieval attempts will wait for the active query to finish
This uses the number/blocking_query_timeout config option, I hope it's still valid
This system will allow us to precache ban info, in parallel (or in batches)
With this, we can avoid needing to setup all uses of is_banned_from to support parallelization or eat the cost of in-series database requests
Clients who join after initialize will now build a ban cache automatically
Those who join before init is done will be gathered by a batch query sent by a new subsystem, SSban_cache.
This means that any post initalize uses of is_banned_from are worst case by NATURE parallel (since the request is already sent, and we're just waiting for the response)
This saves a lot of headache for implementers (users) of the proc, and saves ~0.9 second from roundstart setup for each client (on /tg/station)
There's a lot of in series is_banned_from calls in there, and this nukes them. This should bring down roundstart join times significantly.
It's hard to say exactly how much, since some cases generate the ban cache at other times.
At base tho, we save about 0.9 seconds of real time per client off doing this stuff in parallel.
Why It's Good For The Game
When I use percentages I'm speaking about cost per player
I don't like how slow roundstart feels, this kills about 66% of that. the rest is a lot of misc things. About 11% (it's actually 16%) is general mob placing which is hard to optimize. 22% is manifest generation, most of which is GetFlatIcons which REALLY do not need to be holding up the main thread of execution.
An additional 1 second is constant cost from a db query we make to tell the server we exist, which can be made async to avoid holding the proc chain.
That's it. I'm bullying someone into working on the manifest issue, so that should just leave 16% of mob placing, which is really not that bad compared to what we have now.
Changelog
cl
code: The time between the round starting and the game like, actually starting has been reduced by 66%
refactor: I've slightly changed how ban caches are generated, admins please let me know if anything goes fuckey
server: I'm using the blocking_query_timeout config. Make sure it's up to date and all.
/cl
* Resolves is_banned_from headaches and lag (Speeds up roundstart significantly)
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* fixes qdeling atoms being thrown by explosions (#69604)
fixes the Qdeleted thing being thrown around. runtimes spamming the shit out of the logs
* fixes qdeling atoms being thrown by explosions
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Minor QuerySelect code improvements, QuerySelect documented. (#69383)
* Minor QuerySelect improvements coded from the porcelain throne.
We don't handle bad values being given in the query list well enough. This normally won't matter, runtimes are runtimes, but if mixed with real queries, it can lead to inconsistent state where we have query datums that have been ran, and query datums that have not been ran.
pre-checking is also an option, so that it can just refuse to run any of them if one is bad by checking before, but my main goal was to prevent runtimes from bad inputs leading to undeleted queries spam while being more clear about where the bug is, not try to perfectly handle the side effects of bad code.
(To be clear, i started intending to just add codedoc but now it uses as anything and typechecks because that was just eating at me while typing up the codedoc.)
* Update code/controllers/subsystem/dbcore.dm
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Minor QuerySelect code improvements, QuerySelect documented.
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Refactors z level trait checking to be less shit (#69334)
* Puts level traits and their associated z into a list and then uses it to make the z level trait procs less shit. They no longer need to loop through every z level to do what they aim to do.
* Also removes get_level from level_trait because it just does the same checks as already done above in the proc.
* Refactors z level trait checking to be less shit
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* Allows non-human bodies to spawn in the morgue at roundstart (#68867)
Adds a configurable probability for the cadavers in the morgue to spawn as nonhuman species.
* Allows non-human bodies to spawn in the morgue at roundstart
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* fixes verbs not actually queuing. (#68990)
thanks to Vallat for pointing this out
whoops turns out most verbs havent been queued since may 11th because I made /datum/controller/subsystem/verb_manager have the SS_NO_INIT flag, without also removing a check in verb_manager/proc/can_queue_verb() that stops the verb callback from being queued if the subsystem isnt initialized yet. since subsystems with SS_NO_INIT obviously never have initialized set to TRUE, this always failed for every verb manager subsystem except for SSinput (because it doesnt have SS_NO_INIT).
also adds a debug var to force a subsystem to always queue incoming verbs if possible.
now the default verb management subsystem, and speech_controller will successfully queue verbs again. SSinput always queued verbs so that shouldnt change.
* fixes verbs not actually queuing.
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Radiation pulses will yield to MC for every turf they iterate through. (#68525)
* Be less scary.
Changes radiation pulses so that they store the turfs they need to irradiate, iterate through them and remove them from the list of turfs to irradiate, then yield to MC if MC got angry, and put the radiation pulse with the remaining turfs to irradiate to the back of the radiation processing list.
Radiation pulses pulse information will no longer popleft the processing list. It will delete itself once there are no turfs to process, or if the source is null.
Caches the turfs to process to loop through, adds a counter for how many turfs it iterated through, and cuts the turfs to process by the turfs that got iterated.
* Radiation pulses will yield to MC for every turf they iterate through.
Co-authored-by: Pickle-Coding <58013024+Pickle-Coding@users.noreply.github.com>
* Makes epicenters not explode mobs twice (#68860)
About The Pull Request
Ports yogstation13/Yogstation#13983
This pr effectively halves the damage of explosion epicenters by making them only affect mobs once. Specifically, it removes them from the list of things to explode created by the get_all_contents proc, originally meant to ensure stuff in bags and boxes will set off other bombs in the same bag or box. This had the un(?)intended side-effect of making any objects in the epicenter of the blast take damage a second time, resulting in heavy blasts instakilling and very small explosions doing way too much damage. This is half a balance change and half a bug fix.
Why It's Good For The Game
This allows for more explosion-based weaponry as they now won't all be complete one-shot-win weapons. It also stops things like X4 bolas or explosive holoparasite bolas (you guys have those right?) instantly killing people with no counterplay. Also fireball is now probably a little less meta as a spell since it ONLY PROBABLY immediately wins fights and won't two-shot-crit people, usually. If yall want stuff to still do the same amount of damage just add an extra single-tile explosion to things you want to be more powerful.
Changelog
cl Mqiib, ToasterBiome
balance: Explosion epicenters no longer explode mobs twice; Fireballs and other explosive projectiles are significantly less-damaging
/cl
* Makes epicenters not explode mobs twice
Co-authored-by: Mqiib <43766432+Mqiib@users.noreply.github.com>
* [MDB Ignore][Bounty][Complete Refactor] Papercode Redux: Too Many Damn Files <Map Conflict Edition>
* Fixes merge conflicts and compilation errors, alongside fixing the joker card to make it fully functional again
* Fixed a bunch of info variables in map files
* Alright this is why I wanted this merged yesterday
Co-authored-by: Timberpoes <silent_insomnia_pp@hotmail.co.uk>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Word Filter Fix Round Two: JSON Decoding Debauchery (#68975)
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Yeah, you need to json_decode the results again, again, again. This is three JSON decodes, I believe? I could be wrong. Anyways, we add another json_decode here as well to not runtime on initialization (as well as have the word filter work most likely).
Tested on local, did not see the runtime that @ ShizCalev brought up in https://github.com/tgstation/tgstation/pull/68905#issuecomment-1204557463 (after verifying where it would be seen on master). Should be good now. Again.
* Word Filter Fix Round Two: JSON Decoding Debauchery
Co-authored-by: san7890 <the@san7890.com>
* Adds a new config entry for SQL game log bundle query size
Also adds documentation to existing config entries that don't currently appear in any default entry files on the repo.
* Adds a new config file for database-related configs for Skyrat
* Adds a `add_log_to_mass_insert_queue` proc to handle bundling insert queries into bigger, less frequent queries
* Modifies log_message() to utilise the new add_log_to_mass_insert_queue() proc
* Actually makes the MassInsert() call asynchronous, to completely remove the freezes
* Adds code to handle sending all unsent logs to the database before the subsystem is shutdown, to reduce the loss of logs at the end of a round
* Take Two: The word filter now verbosely describes config failure (Rust-g 1.0.2 Edition) (#68690)
A resuscitation of #67474 since Arm is not presently able to do it.
rustg_read_toml_file has backwards dependency to support older cases that checked for lack of list (the old sign the rust fn went wrong).
Fixes#67446
The configuration for the word filter now verbosely describes the error from the bad toml to the logs, allowing problems with it to be identified quicker and resolved.
Why It's Good For The Game
BLAZING
Ferris warning
Changelog
cl Armhulen/Armhulenn/Bazelart/Tralezab, san7890
admin: Word filters incorrectly set up will now have their errors actually described. Please, tell your server ops when you see it so they may fix the configuration.
server: Rust-g on this codebase is now on the 1.0.2 version, prepare accordingly.
/cl
I also bump rust-g's DLL to 1.0.2 in this PR as well.
* Take Two: The word filter now verbosely describes config failure (Rust-g 1.0.2 Edition)
Co-authored-by: san7890 <the@san7890.com>
* fixes chameleon card reset issues and makes nuke op trim have a hud icon (#68879)
* partial fix
* outfits now update ids
* fixes chameleon card reset issues and makes nuke op trim have a hud icon
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Biddle Verbs: Queues the Most Expensive Verbs for the Next Tick if the Server Is Overloaded (#65589)
This pr goes through: /client/Click(), /client/Topic(), /mob/living/verb/resist(), /mob/verb/quick_equip(), /mob/verb/examinate(), and /mob/verb/mode() and makes them queue their functionality to a subsystem to execute in the next tick if the server is overloaded. To do this a new subsystem is made to handle most verbs called SSverb_manager, if the server is overloaded the verb queues itself in the subsystem and returns, then near the start of the next tick that verb is resumed with the provided callback. The verbs are called directly after SSinput, and the subsystem does not yield until its queue is completely finished.
The exception are clicks from player input since they are extremely important for the feeling of responsiveness. I considered not queuing them but theyre too expensive not to, suffering from a death of a thousand cuts performance wise from many many things in the process adding up. Instead clicks are executed at the very start of the next tick, as the first action that SSinput completes, before player movement is processed even.
A few months ago, before I died I was trying to figure out why games at midpop (40-50 people) had non zero and consistent time dilation without maptick being consistently above 28% (which is when the MC stops yielding for maptick if its overloaded). I found it out, started working on this pr, then promptly died. luckily im a bit less dead now
the current MC has a problem: the cost of verbs is completely and totally invisible to it, it cannot account for them. Why is this bad? because verbs are the last thing to execute in the tick, after the MC and SendMaps have finished executing.
tick diagram2
If the MC is overloaded and uses 100% of the time it allots itself this means that if SendMaps uses the amount its expected to take, verbs have at most 2% of the tick to execute in before they are overtiming and thus delaying the start of the next tick. This is bad, and im 99% sure this is the majority of our overtime.
Take Click() for example. Click isnt listed as a verb but since its called as a result of client commands its executed at the end of the tick like other verbs. in this random 80 pop sybil round profile i had saved on my computer sybil 80 pop (2).txt /client/Click() has an overtime of only 1.8 seconds, which isnt that bad. however it has a self cpu of 2.5 seconds meaning 1.8/2.5 = 72% of its time is overtiming, and it also is calling 80.2 seconds worth of total cpu, which means that more than 57.7 seconds of overtime is attributed to just /client/Click() executing at the very end of a tick. the reason why this isnt obvious is just because the verbs themselves typically dont have high enough self cpu to get high enough on the rankings of overtiming procs to be noticed, all of their overtime is distributed among a ton of procs they call in the chain.
Since i cant guarantee the MC resumes at the very start of the next tick due to other sleeping procs almost always resuming first: I time the duration between clicks being queued up for the next tick and when theyre actually executed. if it exceeds 20 milliseconds of added latency (less than one tenth the average human reaction time) clicks will execute immediately instead of queuing, this should make instances where a player can notice the added latency a vanishingly small minority of cases. still, this should be tm'd
* Biddle Verbs: Queues the Most Expensive Verbs for the Next Tick if the Server Is Overloaded
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Fixes a lua state null return related to the print wrapper, improves the lua editor ui formatting, and implements a stopgap lua lag fix (#68816)
This PR fixes this issue by making sure every proc called in the stack of /proc/wrap_lua_print which could sleep is called using INVOKE_ASYNC, and to prevent such problems in the future, marks all the wrappers as SHOULD_NOT_SLEEP(TRUE). I also figured out how to fix the dumb overflowing problem of the lua editor ui.
Due to lag concerns regarding lua states with a large number of global variables (including fields within global tables), I have made it so the global table and state log are hidden by default - they can be shown using a toggle button in the editor ui.
* Fixes a lua state null return related to the print wrapper, improves the lua editor ui formatting, and implements a stopgap lua lag fix
Co-authored-by: Y0SH1M4S73R <legoboyo@earthlink.net>
* Fixes security level alerts playing the incorrect sounds
* Fixes the merge conflict
* Slightly improves the code on our end, adds the documentation that we were now missing
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
