Preference asset creation, which while consistently created in early assets, can be requested at any time before then and often is, currently takes about 15 to 25 seconds to produce. Because of extremely hard to reproduce BYOND icon bugs, most of this is done on the same tick.
Lowering the cost of initialization itself is very tricky. Some of it we can theoretically optimize, such as creating humans for antagonists, others we can't, such as the raw cost of icon blending.
Furthermore, adding new icons later down the line would just increase this initialization time even more.
Instead of optimizing the asset creation, which is an uphill battle, this instead chooses to amortize the cost by caching preference assets created per git revision. This means that preference assets will be created, with their long delay, only once whenever the code changes.
This is done on a config, defaulting to on so that production needs no changes, as the whole point of these being made at runtime at all is that it keeps assets/art styles consistent, and PRs making subtle bugs that break preference generation in some way is not uncommon. On development, your git revision will stay the same until you commit, no matter what code changes you make.
bout The Pull Request
MouseEntered currently fires multiple (multiple) times per frame, presumably over every atom that was hovered in some timeframe (though it appears to be much worse than that).
This makes MouseEntered only add to a queue, while a per-tick subsystem ensures only the most recent MouseEntered gets the screentip work done on it, through a generic on_mouse_enter proc call.
Contextual screen tips are coming and are going to make the screen tip code more computationally expensive, so slimming it down is going to be a must.
Would like to hear from @LemonInTheDark if this makes any obvious difference in time dilation, since it of course won't be as easy as just checking MouseEntered overtime anymore.
makes say_verb() not execute immediately and instead put itself in the queue of the subsystem meant to process it: SSspeech_controller so that it executes at the start of the next tick during the MC's run instead of outside of it.
i considered making this part of #61422 (d005d76f0b) but this is good regardless of how that one pans out and i already overstuffed that one.
tldr the REAL cause of get_hearers_in_view() overtime is an effect of how byond schedules verbs within the tick.
when the server is overloaded there isnt much time between when SendMaps finishes and when the next tick was supposed to start, but verbs still need to be executed. So verbs will eat into the time the next tick should have started and the MC cant compensate for it at all since it uses byonds internal tick scheduler instead of our external tick scheduler.
Atomizes a much larger PR for another time...
There are typos in span and other html messages that causes them to not render correctly or at all.
Bug fixes
Converts those instances of span to use the macro
I'm refactoring proximity monitors and fields, removing lots of bloat from both that's hardly even used. Proximity monitors no longer generate effect objects to track the surrounding area, should be less cpu expensive and easier to maintain (or phase out), read and use.
This PR also adds a couple components which may be needed for future stuff (for starters, the mirror reflection PR #62638 could use the connect_range comp)
Improving old old, ugly old code and adding some useful backend components. Tested and working.
About The Pull Request
On the tin. Hopefully the comedic timing isn't TOO gadzonked from this, but I think it feels OK.
Why It's Good For The Game
It just doesn't make sense to have the gender-neutral "he" for this game when you could have someone playing a female character (or anything else). I shrug my shoulders and ride off into the sunset.
Changelog
cl
fix: The Nanotrasen News Network has updated their news tickers for when a station horrifically blows up to be more accommodating towards the person directly responsible for making sure it didn't horrifically blow up.
/cl
Ports Semoro's fix (ss220-space/Paradise#511) related to potential SStimer bucket corruption which caused infinite loop.
The essence of the fix is that earlier timers with a built linkedlist could get into the second queue, which could cause an incorrect state. It works super stupidly, resets the state to the original correct one
BUT THERE IS STILL A BUG IN THE CODE RELATED TO THE INFINITE LOOP!
For some reason the SStimer on our server started to break recently at the beginning of the round. Found that code for waterfall drip effect was causing the issue. Found that setting frequensy to 0 (and calling reset_bucket sometimes) can be used to reproduce the bug. Tried to fix it with this PR
there is an oustanding bug with airlocks causing SStimer to brake sometimes.
cl
fix: fixed potential bucket corruption in timer reset_buckets
/cl
a month or two ago i realized that on master the reason why get_hearers_in_view() overtimes so much (ie one of our highest overtiming procs at highpop) is because when you transmit a radio signal over the common channel, it can take ~20 MILLISECONDS, which isnt good when 1. player verbs and commands usually execute after SendMaps processes for that tick, meaning they can execute AFTER the tick was supposed to start if master is overloaded and theres a lot of maptick 2. each of our server ticks are only 50 ms, so i started on optimizing this.
the main optimization was SSspatial_grid which allows searching through 15x15 spatial_grid_cell datums (one set for each z level) far faster than iterating over movables in view() to look for what you want. now all hearing sensitive movables in the 5x5 areas associated with each spatial_grid_cell datum are stored in the datum (so are client mobs). when you search for one of the stored "types" (hearable or client mob) in a radius around a center, it just needs to
iterate over the cell datums in range
add the content type you want from the datums to a list
subtract contents that arent in range, then contents not in line of sight
return the list
from benchmarks, this makes short range searches like what is used with radio code (it goes over every radio connected to a radio channel that can hear the signal then calls get_hearers_in_view() to search in the radios canhear_range which is at most 3) about 3-10 times faster depending on workload. the line of sight algorithm scales well with range but not very well if it has to check LOS to > 100 objects, which seems incredibly rare for this workload, the largest range any radio in the game searches through is only 3 tiles
the second optimization is to enforce complex setter vars for radios that removes them from the global radio list if they couldnt actually receive any radio transmissions from a given frequency in the first place.
the third optimization i did was massively reduce the number of hearables on the station by making hologram projectors not hear if dont have an active call/anything that would make them need hearing. so one of hte most common non player hearables that require view iteration to find is crossed out.
also implements a variation of an idea oranges had on how to speed up get_hearers_in_view() now that ive realized that view() cant be replicated by a raycasting algorithm. it distributes pregenerated abstract /mob/oranges_ear instances to all hearables in range such that theres at max one per turf and then iterates through only those mobs to take advantage of type-specific view() optimizations and just adds up the references in each one to create the list of hearing atoms, then puts the oranges_ear mobs back into nullspace. this is about 2x as fast as the get_hearers_in_view() on master
holy FUCK its fast. like really fucking fast. the only costly part of the radio transmission pipeline i dont touch is mob/living/Hear() which takes ~100 microseconds on live but searching through every radio in the world with get_hearers_in_radio_ranges() -> get_hearers_in_view() is much faster, as well as the filtering radios step
the spatial grid searching proc is about 36 microseconds/call at 10 range and 16 microseconds at 3 range in the captains office (relatively many hearables in view), the new get_hearers_in_view() was 4.16 times faster than get_hearers_in_view_old() at 10 range and 4.59 times faster at 3 range
SSspatial_grid could be used for a lot more things other than just radio and say code, i just didnt implement it. for example since the cells are datums you could get all cells in a radius then register for new objects entering them then activate when a player enters your radius. this is something that would require either very expensive view() calls or iterating over every player in the global list and calling get_dist() on them which isnt that expensive but is still worse than it needs to be
on normal get_hearers_in_view cost the new version that uses /mob/oranges_ear instances is about 2x faster than the old version, especially since the number of hearing sensitive movables has been brought down dramatically.
with get_hearers_in_view_oranges_ear() being the benchmark proc that implements this system and get_hearers_in_view() being a slightly optimized version of the version we have on master, get_hearers_in_view_as() being a more optimized version of the one we have on master, and get_hearers_in_LOS() being the raycasting version currently only used for radios because it cant replicate view()'s behavior perfectly.
About The Pull Request
I have received exemption from the freeze by Oranges.
This PR was originally done for Skyrat-tg, as a bounty. Oranges took interest and Skyrat people approved taking it upstream so I did. (original PR Skyrat-SS13/Skyrat-tg#9912 )
Features:
This PR adds "field of view" mechanics, which by default don't do anything.
Once you pick up and wear a gas mask you'll notice a cone behind you.
That cone will hide all mobs, projectiles and projectile effects.
HOWEVER... hidden things in the cone (or for people who are blind or nearsighted) will play a visual effect.
The fov cone shadow density can be adjusted
Technicalities:
Originally a component, but by Watermelon's advice I have made this a datumized behaviour instead. (semi-component) This way it is faster, less memory use etc. Once again a component
People have native fov, which can be enabled by a config, by default it's off. (or by an admin verb)
People have fov traits, which add the fov impairings to you, gas masks do that now. All clothes have a support for possibly applying them.
Moves all things that should be hidden onto a new plane which is just above GAME_PLANE, that was we can efficiently filter them out of clients views.
Being dead or extending your eye view (xenobio console) will disable the FOV mask.
This PR was brought to you by Skyrat paying me aswell as rotational mathematics
Why It's Good For The Game
Oranges approves so it's good.
Changelog
cl
add: Gas Masks now limit your field of view
add: Added field of view mechanics. It's darkness can be tweaked by a pref
add: Blind, nearsighted and fov-limited people will now see sounds as visual effects.
/cl
About The Pull Request
Paintings can now do stroke painting.
Added painting management panel for admins.
Paintings now display author's character name, year of painting, medium and patron when hung on wall.
You can become new patron by paying more than the previous one.
Added painter's palettes to library vendor. (Sprites by @Mickyan )
Backend changes:
Images are now stored in /data/paintings/images/*.png instead of /data/paintings/[category]/*.png
Old categories are now just tags
Screens & Video
Changelog
cl
add: You can now become patron of your favorite painting by buying sponsorship from Nanotrasen Trust Foundation.
add: Painter's palettes are now available at library vendor.
qol: Can use strokes in paintings now
/cl
* Removes like 50% of the cost of using the ui, it turns out that the storage component is fucking moronic. Likely significantly reduces the overtime of typecacheof
* Reduces the cost of reloading the dummy by ~50%
Turns out just initializing and deleting organs was like half the cost of reloading a default dummy.
It occured to me (Mothblocks) that we don't actually care about any organs we can't see or that don't effect visuals. So almost all of our organ loading can just be skipped.
This saves a significant chunk of cpu time, items next!
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
Just fixes some spelling for gangs. I also fixed misspellings for "posession" to "possession". Fixed "seperate " to "Separate" Fixed "Cemetary" to "Cemetery"
Adds a new ui state so that players can access the paicard tgui while it's slotted in their PDA (inside the pda wasn't technically in the user's close inventory).
Adds some documentation for the pAI candidate file
Users now get notifications if they can't save files (guest keys).
pAIs previously had NO on screen indicator of hack progress, so I've given them a progressbar over the door
More visual output for pAIs
More output for edge cases
More documentation
Fixes#63161
About The Pull Request
A circuit and shell components have been added to Synthesizers (headphones and spacepods included, though with a reduced capacity because of their size), so they can now be used for wiremod. Just like for instant cameras, no shell design here. They are meant to be found in dorms or maybe ordered from cargo.
Why It's Good For The Game
The station outside the sci department has plenty of USB ports stuff but is lacking when it comes to circuits shell. This is another small step toward a better and more applicable wiremod.
Changelog
cl
expansion: Synthesizers and headphones can now have circuits installed.
/cl
About The Pull Request
Does what it says! pAI interfaces, including pAI card interfaces, have all been reworked.
I spent a bit of time working with pAIs doing this, so I've changed and fixed other things in the process.
Door jacking had little to no UI feedback
Many of the pAI actions had little feedback
Some of the logic was poor or not working (pAI request, for instance)
Why It's Good For The Game
One of the worst UIs in the game is redone
Three interfaces are now two: pAI cards and recruit window -> 1 tgui window, pAI software interface -> tgui
Door jacking gives more feedback, including sounds and messages.
New procs inside general and security records to fetch data
Requesting a pAI now uses the notify_ghosts proc like most other ghost roles
Changelog
cl
refactor: pAI interfaces have been converted to TGUI.
refactor: Requesting a holographic pAI friend now correctly notifies ghosts of your loneliness.
add: pAI door jacks have been given a bit more UI feedback.
del: Requesting and downloading a pAI no longer uses two separate screens.
/cl
At the last Toolbox Tournament, @MrStonedOne pointed out some big performance consumers. Some are disablable through easy means, but others were not. This adds two easy ones to the mix.
Before, all items deleted would sit in a queue for 5 minutes, with all shrinks and expansions of said queue requiring byond to copy all of these items over to the new list.
Theory: 99% of items soft-delete within byond within the first second. (5 minutes is only needed because a byond quirk with items referenced by verbs)
Result:
Within the first 7 minutes of a local test launch and round start, ~35,000 things get qdeleted.
Of those 35 THOUSAND things, only 12 things failed as still referenced with a 1 second pre-queue.
Said 12 things passed as garbage collected at the 5 minute queue.
(Note: 30 thousand of these items are from world start and round init.)
I have no data on how much this speeds anything up, leaving a 30 thousand list (that has to be copyed every time qdelete processes it and cuts off the items it processed) hanging around for no reason for the first 5 minutes of the round was all i needed to justify the pr.
So, it was runtiming because it wasn't checking for the length of the list, so it was failing to display the results and failing to do anything about the results of said vote. That means map votes didn't do anything.
Renames conveyor2.dm to conveyor.dm, and removes the historical comment about "new conveyor belts". As a reminder, comments should be about what the code is now, not what it used to be. (Muh history -Lemon)
Moves conveyor belts to their own SS with an identical wait. It is very common, as an admin, for me to want to adjust conveyor belt processing, either to make it faster (for laughs) or to disable it when it is causing heavy lag. It is very difficult to do this (especially the former) because it just uses fast process.
About The Pull Request
Document: https://hackmd.io/@bazelart/HkY-SO9VF
Each department's request console is upgraded. Instead of making requests, they are only able to see crates related to their department that helps the department. They can order one for free (so not out of anyone's wallet) and it will arrive at cargo. Cargo gets the price of the ordered crate for bringing it to the department that ordered it (via an area check, of which the crate will remain locked until satisfied, emitter cracking aside).
Ordering a crate puts the console on a cooldown depending on the price of the crate ordered. The time ranges from 10 minutes at the lowest value, to capped at 20 minutes at 4x the default crate's price. the price in time follows a ease in out circular function, where the time increases slowly as the time goes up, but a lot in the middle. towards the higher end it slows down again.
Cargo will start with far less money, but this is countered by the new source of income.
Finish Mapping it
Finish tgui panel for department orders
Testmerge it for balance and feedback who cares
Maybe give multiple destination areas, just in case one area gets obliterated who cares!
Why It's Good For The Game
Cargo starts with a budget to spend on themselves, which lets them order their department rewards before doing anything. There is no inherent reward to delivering to other departments other than social expectations of filling the job, which means cargo will simply ignore deliveries and requests if there are more self-important things going on, since those deliveries both cost cargo and do not help cargo in any way
Changelog
cl
add: replaced the request consoles in each department with department order consoles, which order for free on a cooldown. cargo gets these orders and delivers the crates, which are locked until delivery. upon delivery, cargo gets paid the value of the crate, and can then sell the crate back on the shuttle.
balance: cargo doesn't start with a budget, other departments get what their budget was split up amongst them
/cl
About The Pull Request
This is for the admin combo HUD. Players shouldn't notice any difference (except at roundend).
2021-11-09T16-27-26.mp4
Removes the ability to set custom antag HUDs for custom admin teams for complexity, though if there's a large enough demand I can try to bring it back in another PR.
Fixes#59767
TM candidate only so that I can make sure antags aren't getting leaked to people who shouldn't see them.
Changelog
cl
fix: Antag HUDs will no longer clear on deconversion if the player was another antag.
qol: Antag HUDs (as seen by admins and at the round end) will now animate between all antagonists, rather than just choosing the most latest.
/cl
It kept on tripping because the RegEx expression was malformed due to an absence of words in to_join_on_whitespace_splits, which caused it to filter out spaces that were at the beginning or at the end of a message, or if there was two spaces one by the other.
Also prevents people from sending a message that's only spaces in OOC, because that's a little silly.
I find stuffing everything in game.log is a real problem when you need to actually find useful information about what happened to a specific Silicon. It's hard to tell what happened to Silicon throughout a round, even when crossreferencing attack/game logs, so having a Silicon log for all the information related to them would be really useful.
For example, a Cyborg can spawn unlinked on Robocop, go Janitor and crowbar someone to death with a Robodoctor AI. When looking through logs, an Admin can easily assume it was a rogue Engineering cyborg who disobeyed their laws to kill someone.
This also isn't adding a whole new log file, more than it is just renaming the law log file to silicon and adding more useful things into it, so it isn't logging bloat (if that's even a concern)
About The Pull Request
This is a fix for map not load anymore because of security changes
Why It's Good For The Game
Maps are good as they encourage gameplay and differentiate ss13 from a classic MUD game
Changelog
cl
add: unit test for map load
add: directory param to map load + whitelist for data and _maps
add: advertising for mojave sun in tg commit logs
/cl
This PR fixes a bunch of the code for load_map_config(), documenting it better and removing a deprecated (I hope) parameter that was also a security concern along the way, while also making another proc for just loading the default map config, which is supposed to always be functional.
About The Pull Request
In my personal, subjective opinion; trialmins should not, in fact, be able to read and delete server/box configuration files on a whim.
cl
server: Patches multiple(?) arbitrary file related vulnerabilities
/cl
* Splits init profiles into their own file, so we can better track where pain points come from.
After all there's no point in knowing that sprite sheets generate 32 seconds of overtime during init if you
only care about inround, or vis versa.
(I'm tired of people freaking out about blends that are only done during init)
* Whoops
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else.
Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter.
Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away!
While helping RaveRadbury debug some issues with enabling Halloween species early via the brute force method of enabling them in the config rather than the gentleman's solution of testmerging a PR that changes the Halloween date, we discovered something dreadful.
Cloth golems cannot be enabled! Infact, any species with a space in the ID cannot be enabled.
It uses the splitter despite VALUE_MODE_FLAG being set. So a key entry like ROUNDSTART_RACES cloth golem would get parsed as cloth = golem, then entered into the config as cloth = TRUE
NEW AND IMPROVED PART HERE
I've re-written how keyed_list config entries are parsed, splitting it into a number of procs to do some discrete block of logic.
Based on feedback from MSO, he expected that VALUE_MODE_FLAG keyed_list entries could have elements overridden. However, this functionality was not present in the code.
I have implemented it. We now support 3 methods of setting VALUE_MODE_FLAGS.
Implicitly enable the config entry: CONFIG_ENTRY config_key_goes_here
Explicitly enable the config entry: CONFIG_ENTRY config_key_goes_here 1
Explicitly disable the config entry: CONFIG_ENTRY config_key_goes_here 0
There have been functionality changes too. Previously, everything before the first splitter was the key and everything after was the value. However, in ambiguous config entries (Such as ROUNDSTART_RACES cloth golem 0) it would be unclear if the intent was (cloth, golem 0) or (cloth golem, 0) or indeed if the intent was (cloth golem 0, 1).
As a result, there is now the following paradigm in place: Everything after the LAST splitter is the value, everything before is the key and a log_config warning is now given explaining the problem and showing how it was resolved.
[2021-10-27 19:48:12.840] WARNING: Multiple splitter characters (" ") found. Using "cloth golem" as config key and "1" as config value.
This warning will trigger if multiple splitters are present for any keyed_list config entry, and will trigger on implicit VALUE_MODE_FLAGS entries that have splitters. The example above is it triggering on ROUNDSTART_RACES cloth golem - It has detected that there is potential ambiguity between (cloth, golem) or (cloth golem, 1), has picked a sensible option for the data type and has warned about it.
The intent is that no config entry should be ambiguous. It should be clear what is key and what is value when dealing with keyed_list config entries.
There's probably more work to do on other config entries to bring them up to this standard, but this is the thing I'm hitting in this PR.
Similarly, I have improved the validation aspect of keyed_list config entries with additional logging in general.
[2021-10-27 19:47:53.135] ERROR: Invalid KEY_MODE_TYPE typepath. Is not a valid typepath: /mob/living/carbon/monkey
I have added a unit test to make sure species IDs do not contain splitters from the two keyed_list subtypes relating to species.
I have added sanity checking to the race config subtypes since we have a big dick global list of all races sorted by ID, so a race not existing will fail validation and output a meaningful config log entry.
I have removed /datum/config_entry/keyed_list/probability from the code as it is unused with the removal of all game modes except Dynamic.
The config change necessitated the renaming of all golem species IDs. Doing so and renaming the clothgolem.ts file to match has fixed the broken cloth golem page too.
Turfs have a variable, intact, which conflates three meanings:
Determining whether there's something that can be pried out, such as directly with a crowbar or indirectly with a tile stack and a crowbar off-hand.
Determining whether underfloor pieces are visible.
Determining whether underfloor pieces can be interacted with - by players with tools, through interaction with effects like chemical acid, or foam.
When plating is hit with a stack of tiles, /turf/open/floor/attackby checks whether the turf is intact, and if so, ends the attack chain regardless of whether or not the attempt to hotswap a turf (with a crowbar) is successful or not. However, turfs which want the underfloor to be visible - such as catwalks and glass - set the intact variable to FALSE, and so can be repeatedly placed over one another, as if they were the first tile to be placed over the plating.
This refactors /turf/var/intact into two distinct variables:
/turf/var/overfloor_placed, for whether or not there is something over plating.
/turf/var/underfloor_visible, for whether or not the various underfloor pieces should be invisible, visible, or both visible and interactable.
All references to /turf/var/intact have been replaced with an equivalent overfloor_placed or underfloor_visible reference, depending on which check is appropriate. underfloor_accessibility can take one of UNDERFLOOR_HIDDEN, UNDERFLOOR_VISIBLE, or UNDERFLOOR_INTERACTABLE. This prevents cases such as acid foam or tools phasing through glass floors to affect the underfloor pieces underneath, and covers all kinds of unusual, not-wiring-visiblity usage such as Holodeck completeness, Revenant interaction, or station integrity checking.
human huds will no longer runtime and die when prefs aren't initalised
SSEconomy will no longer have to deal with pathed jobs inside accounts
Some of the negative/neutral quirks that use the mind have been relegated to last_mind instead for runtime purposes
Mafia saymode will no longer runtime when someone uses it with no current mafia game
Autolathe secondary_attack will no longer runtime/work only because of runtimes
MULTIPLE CHECKS FOR QDELETED STACKS BEFORE ADDING FINGERPRINTS
More player_list client checks
A lazyinitlist for proximity monitors, as they used lazyremove which nulls the list when it hits zero things in it
A check for cigarettes in case temperature exposure causes a reaction that removes all reagents
Catwalks no longer runtime every time someone walks on them
/obj/machinery/atmospherics/components/binary/crystallizer will no longer runtime on secondary_attack if someone can't interact
cyborg models will no longer assume the thing they're inside is a cyborg and runtime when it isn't (cryopods)
When a simplemob falls into nullspace, it will no longer runtime (goliaths falling into chasms and etc)
runtime fix in techweb.dm when using a card without a sanity check
runtime fix with folders when they have nothing in them
runtime fix with glowing eyes when the LAZYADD doesn't get called in regenerate_light_effets() and so doesn't initalise the list
major cleanup of modules/atmospherics folder and all related files, still many missing
-cleanup of procs name
-cleanup of vars name
-documentation of some of the procs
-minor changes to some for() logic (no in game changes just early continue or as anything checks)
No in game changes, only code and docs
