* Fixed maps constantly being metastation (fixes recent maps being included in mapvote) (#70006)
About The Pull Request
See title. The vote subsystem needs to load after the persistence subsystem so that the blocked_maps list can be properly populated with data from the RecentMaps.json in the data folder.
This fixes the maps constantly being metastation
Why It's Good For The Game
Same map over and over again = bad
Different maps each time = good
Changelog
cl
fix: Fixed map vote including maps that have already been played twice in the last 3 rounds.
/cl
* Fixed maps constantly being metastation (fixes recent maps being included in mapvote)
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
* Register shuttles immediately after loading instead of waiting for them to dock first (no more double shuttle!) (#69901)
* Moves register() call in action_load() to before docking instead of after, preventing 2 shuttles from being loaded in certain edge cases.
* Register shuttles immediately after loading instead of waiting for them to dock first (no more double shuttle!)
Co-authored-by: VexingRaven <msgerbs@users.noreply.github.com>
* Object Window Niceties (#69825)
* Object Window Niceties
Alright. I got bored and polished up the object/alt click window.
It had a few issues:
First, we generated all our images in bulk, as soon as requested
Second, the caching was global, despite only working on a client to
client basis
Third, we only generated up to 10 images. This could be fine, but the
javascript code will continuiously rerender assuming unrendered images
will come eventually, and they well, weren't. This caused MASSIVE
clientside lag
Fourth and finally, I did not like how moving away from the viewed turf
lagged behind, in sync with the stat tab update. Looked bad.
I've resolved all these.
I solved the first three issues by reworking how obj images were
generatated and managed.
Rather then storing a basic cache on the subsystem, and doing all the
image generation at once, we queue up image generation as we like, and
generate images inside a new processing subsystem fire.
This isn't the best solution, since it still eats cpu somewhat, but it's
a whole lot better then the other options, outside either removing the
need to getflat, or somehow predicting what items a client will want to
see
I've started storing three bits of info. First, a list of all the
objects we currently want to display.
Second, a list of atom -> image html
Third, a list of atoms to imageify.
This information is stored on a datum on /client, since I want this to
have a lifetime linked to well, clients.
I've used this datum to solve that fourth bit, using a component I made
for parallax a bit back. This lets me react to our client's mob, and
update the tab linked to that, rather then on a subsystem call by call
basis.
That's about it.
Co-authored-by: san7890 <the@ san7890.com>
* Object Window Niceties
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* Excited groups will care about gas reactions before dismantling. Turfs will not sleep when there are gas reactions. Fixes water vapour not consuming water vapour when freezing turfs. (#69479)
* Excited groups care about reactions.
Adds reacting var for open turfs. Reacting gets set to the return of react() inside the open turf's process_cell() proc.
Adds turf_reactions var for excited groups. turf_reactions gets set to the result of has_reactions OR reacting. Excited group processing will check if the excited group's has_reactions is REACTING or STOP_REACTIONS before dismantling the excited group. Excited group processing will set the excited group's has_reactions to NONE at the end before MC_TICK_CHECK.
Fixes water vapour not consuming water vapour when temperature is below WATER_VAPOR_DEPOSITION_POINT.
Changes water vapour reaction to have a consumed var, it gets set to MOLES_GAS_VISIBLE when it freezes a turf or makes it slippery. If consumed, then water vapour moles decrease by consumed, set reaction results and set return value to REACTING.
Fixes water_vapour reaction by making its mole count decrease by consumed instead of attempting to do arithmetic on the water vapour list, which somehow didn't runtime.
* Excited groups will care about gas reactions before dismantling. Turfs will not sleep when there are gas reactions. Fixes water vapour not consuming water vapour when freezing turfs.
Co-authored-by: Pickle-Coding <58013024+Pickle-Coding@users.noreply.github.com>
* Fixes a runtime with map voting (#69908)
* Adds a sanity check in voting, in case no one actually voted.
* Fixes a runtime with map voting
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* Verbose Vote Initiation Feedback Tooltippery (#69763)
* Verbose Vote Initiation Feedback Tooltippery
Hey there,
So basically, the old implementation had it such that when a vote was disabled and you tried to trigger it, you could get a very nice message in your chat explaining why you could not trigger that vote in that moment. HOWEVER, there's a current fatal flaw in this logic:
You can't ever get that to_chat reason as to _why_ this vote is disabled since you can't click the button. I don't know if this ever worked, which is sad, because we had a lot of these nice messages that one would never see. So, let's leverage the power of TGUI and add messages.
The messages are applied per-datum singleton, and are a generic explanation of what the vote does when there is no specific reason assigned to it when the can_be_initiated() proc runs. If it can not be initiated, we change the message to reflect exactly why the player can not initiate the vote. It ends up looking something like this:
In order for this to work well for the restart vote and to lessen the amount of copy-pasting I might have to do, I created a new proc that checks to see if a valid admin is online, and uses that for both updating the message and restarting the server if the vote clears.
* fixes messages not resetting
* removes misleading section
the admin can always restart the server if they wish
* Verbose Vote Initiation Feedback Tooltippery
Co-authored-by: san7890 <the@san7890.com>
* 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>
