Fixes#56292
Why It's Good For The Game
Increases chances of smooth experience
Changelog
cl Semoro
fix: timers not removing from second queue on init
/cl
Previously it was possible for events to enter the short queue when the timer is offset by more than BUCKET_LEN
Now it is forced to schedule events into the second queue if the timer is processing slower then world time goes allowing the timer to keep up
This PR provides a better definition of TIMER_MAX to avoid scheduling timed events that are more than one window of buckets away in terms of timeToRun into buckets queue and properly passing them into the second queue.
Ports ss220-space/Paradise#578
Should be merged with/after #64138
Detailed explanation
The timer subsystem mainly uses two concepts, buckets, and second queue
Buckets is a fixed-length list of linked lists, where each "bucket" contains timers scheduled to run on the same tick
The second queue is a simple list containing sorted timers that scheduled too far in future
To process buckets, the timer uses two variables named head_offset and practical_offset
head_offset determines the offset of the first bucket in time
while practical_offset determines offset from bucket list beginning
There are two equations responsible for determining where timed event would end up scheduled
TIMER_MAX and BUCKET_POS
TIMER_MAX determines the maximum value of timeToRun for timed event to schedule into buckets and not the second queue
While BUCKET_POS determines where to put timed event relative to current head_offset
Let's look at BUCKET_POS first
BUCKET_POS(timer) = (((round((timer.timeToRun - SStimer.head_offset) / world.tick_lag)+1) % BUCKET_LEN)||BUCKET_LEN)
Let's imagine we have our tick_lag set to 0.5, due to that we will have BUCKET_LEN = (10 / 0.5) * 60 = 1200
And head_offset of 100, that would make any timed event with timeToRun = 100 + 600N to get bucket_pos of 1
Now let's look at the current implementation of TIMER_MAX
TIMER_MAX = (world.time + TICKS2DS(min(BUCKET_LEN-(SStimer.practical_offset-DS2TICKS(world.time - SStimer.head_offset))-1, BUCKET_LEN-1)))
Let's say our world.time = 100 and practical_offset = 1 for now
So TIMER_MAX = 100 + min(1200 - (1 - (100 - 100)/0.5) - 1, 1200 - 1) * 0.5 = 100 + 1198 * 0.5 = 699
As you might see, in that example we're fine and no events can be scheduled in buckets past boundary
But let's now imagine a situation: some high priority subsystem lagged and caused the timer not to fire for a bit
Now our world.time = 200 and practical_offset = 1 still
So now our TIMER_MAX would be calculated as follow
TIMER_MAX = 200 + min(Q, 1199) * 0.5
Where Q = 1200 - 1 - (1 - (200 - 100) / 0.5) = 1200 - 1 - 1 + (200 - 100) / 0.5 = 1398
Which is bigger then 1199, so we will choose 1199 instead
TIMER_MAX = 200 + 599.5 = 799.5
Let's now schedule repetitive timed event with timeToRun = world.time + 500
It will be scheduled into buckets since, 700 < TIMER_MAX
BUCKET_POS will be ((700 - 100) / 0.5 + 1) % 1200 = 1
Let's run the timer subsystem
During the execution of that timer, we will try to reschedule it for the next fire at timeToRun = world.time + 500
Which would end up adding it in the same bucket we are currently processing, locking subsystem in a loop till suspending
On next tick we will try to continue and will reschedule at timeToRun = world.time + 0.5 + 500
Which would end up in bucket 2, constantly blocking the timer from processing normally
Why It's Good For The Game
Increases chances of smooth experience
Changelog
cl Semoro
fix: Avoid timer scheduling too far events into short queue
/cl
When I made my move loop changes (815bb8a) 62567, I converted a few walk() procs to
the new system
What I didn't know when I did that conversion is that walk() operates on ticks, when move loops operate on
deciseconds
So when I converted say, mob movement over, I accidentially halved the attack movespeed of all of our mobs
This resolves that, alongside a few other misteps
Of note: There are old comments implying that walk()'s delay is not actually linear, or simply as the reference says "in ticks"
I don't have a good idea of how fast things actually should be though, which makes this tricky
In light of this, I've decreased the move speed of legion slightly, in hopes that it will feel more "normal"
I've also fixed a bug with move_to and move_away, they were treating their distance parameters as move to this and one more, rather then move to this. This lead to mobs attempting to overlap with your sprite. s cringe, and also fixed
Fixes misc moveloop runtimes souced by mid move deletes and disposal loop traps, this was caused by a misunderstood bit of logic. current_pipe needs to be set to the actual return value of transfer() rather then our current location
Space drifting "listened" for moves outside of its expected range, and if it saw them it would self delete
The problem is it registered for this behavior in drifting_start(), which was intended to be called by the MOVELOOP_START signal
But because that signal was fired as a consequence of move() being called, we never registered the signal
So if you took an item out of your pack, when it hit the ground it would get the drifting component
Next tick it would be drift moved to its intended location, the move would "fail", and then it would stop
This lead to items being visually in your inventory, but not functionally
Which leads to a lot of really weird behavior
Oh and I added a var to moveloops that's just "are we running" to make solving this class of issue easier
As it is right now, we never actually clear the temporary list processing_queries
So if the subsystem is for some reason unable to complete a run, we will just whip right back around to it again
If it's been long enough, this could even cause horrific log spam. There was just now a manuel round with roughly 30k undeleted query errors. not good.
But what was actually not deleting you may ask?
Well
When you create a db request, a 5 minute timer starts. after those 5 minutes are up, the request is qdeleted by the db subsystem
This is to prevent the creation of unused requests, and to handle requests that are never cleaned up
Telemetry code was creating all of its db requests inside a for loop that could check tick, and then later
attempting to call them in series
Since requests by default sleep, this almost always lead to undeleted queries, which harddel'd given long enough periods
I've fixed this by moving the data gathering away from the query creation
Why is it good for the game
I was working on atmos code, happy, safe in my delusion, when suddenly I got a ping from tattle freaking out over 200 undeleted queries a second
This resolves that issue, so I can once again live in peace
Changelog
cl
admin: Telemetry code will spam you with undeleted query logs much less often now!
server: Improved how the db subsystem handles undeleted queries, should never have an incident like that again
/cl
* Adds a subsystem to handle automated directional movement, replaces all instances of walk_towards with it. Makes meteors and immovable rods not drift in space, and makes immovable rods more destructive. Note, I've opted not to use byond's method of moving towards something, which is effectively Move(src, get_step(src, get_dir(src, target))) as it's cringe and doesn't make a smooth line. I've replaced it with a autoupdating rise over run setup, read the code for more details
* woop forgot the subsystem
* Documentation, contributing.md entry, and some cleanup
* Makes the moveloop datum more oop friendly, sets us up for a lot of conversions
* Converts the curseblob and walk_away() to the subsystem
* Changes the default for override from FALSE to TRUE
* converts walk() over, still need to add a replacement proc for it, but we didn't actually have anything that used the raw proc
* converts the rest of walk_to() over, nearing the end now
* cleans up some errors
* Fully documents everything, fills in some missing movement types, uses the power of oop to make things cleaner, and typepaths longer
* Finishes the contributing.md stuff
* Done
* Fefaults -> Defaults, can you tell I wrote this at 1AM?
* resolves bubblegum issues
* Roh's suggestions
Co-authored-by: Rohesie <rohesie@gmail.com>
* Cleanup
* Hey lemon, did you know that Destroy() lives on datums? ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
* Converts over the discrepencies created in my absense
* HAHA FUCK YOU I PAY MY DUES
* Whoops lost some stuff in the merge
* Converts the system from seconds to deciseconds to make dealing with the api more sane
* Some stuff I missed
* Makes movement an inheritable subsystem type, splits the moveloop file into two, one for the subsystem, and one for the datums
* Makes a subsystem that handles directing movers out to other subsystems. It's a bit bad right now, but it's a
good first step. I think I'll move the move loop datum to a lazy var on mobs instead of an assoc list, don't
like lists.
Also makes the movement procs global, I'll move em to the /movement subsystem at some point or something like
that
* Converts the existing uses of the procs over to the new format
* Adds support for subsystem precedence, so a type of A can override type B.
General cleanup, still kinda in debug mode but it's getting better
* I'll admit I'm not too familiar with this, but I think it will work
* Adds starting logic so movement types "pausing" makes any sense
Redoes how waiting is handled to make it based on world.time directly. I don't remember why. I think it's better
this way.
Adds a drifting movement type, moves space drift over to it.
Needs severe work before it's ready, too much info stored and modified on the moving object, see comment
Starts work on making drifting smooth
* Moves almost all space drifting vars over to signals on the movement datum
Properly implements glide size stuff for both the subsystem and the loops. Space drift will be smoother now.
It's not perfect, but it'll work just fine for now
Adds a way to override a client'd mob's glide size mid move, uses it to make entering a spacedrift look right
Adds a way to delay a client move outside of just move_delay, meant to be used for long periods, and setup such
that it doesn't make inputs persist
Adds flags to movement loops, alongside MOVELOOP_OVERRIDE_CLIENT_CONTROL, which blocks client movements while
the loop is firing, and for it's visual delay after
This means you can't exit a space drift until you hit the actual wall. This feels a lot better
Some general logic stuff, move() will return true/false if it succeeded or failed
Adds a stop_loop() proc that's called when a move loop is no longer active
Suck my nuts
* Moves precedence to the loop instead of the subsystem
* Moves drifting into a component, this lets me explictly block input after the move loop ends, so people can't
move the moment they functionally move onto a new tile
This is a bit underdeveloped currently, but that's a problem for another day
Cleans up some uses of move procs, fixes runtimes in metoer and curseblob code
Adds signals for stopping/starting a move loop, sending one for destroy is redundant.
Moves existing event signals from the movable being acted on to the loop itself, makes more sense this way
Makes the move handler return the created loop up the chain so we can register to it
Fixes a logic error in loop contesting code that lead to loops never actually being removed from subsystems
because they didn't know they should be.
Properly changes lifetime from a time to stop, to functionally an amount of moves to complete before stopping
Adds some new signals for pre/post loop process. This is to better tie into components.
I decided I didn't like the idea of tying all functionality to the loops themselves
The loop decides functionally how to move, components or just tied in signals can decide when/when not to move
and can modify properties of the loop
Making a new loop for things like atmos drift, something I'm interested in tackling in the future, seemed silly
* Moves movement procs directly to the subsystem for better namespacing or whatever
* Moves movement packets onto /atom/movable, no longer need the debugging
I've decided to not just put their contents fully onto atom movable, since it makes debugging on live much
harder, can't sdql for them anymore.
Fixes a runtime in meteor code, properly this time
Fixes a logic error in stop_looping
Makes move manager NO_INIT, because well, it doesn't init
* Commits human sin, makes Recover() work properly for movement subsystems
* Fixes immovable rod orbits not always working, they were returning too early in moved and fucking up the var we use to track move count, and thus not sending a signal properly
* Reworks the curseblob to use signals more, and to not use override
* Missed this in the movement ss commit
* Removes override, makes having a higher or equal precedence take its place
* Updates documentation
* Cleans up some unused defines
* Nukes the unused flags option
* Whoops forgot to qdel check
* Removes an unused var I had for client move prevention before I started using a component
* Let's do this properly
* Modernizes meteor code to better match how explosions actually work currently
* Some more cleanup
* Cleans up effect code a little bit
Nukes the effect system's sleep loop, we use movement loops instead
As a part of that, instead of 1 timer per effect spawned, we react to loop failure and make it 1 timer per
effect system
This should reduce the amoumt of slowdown we see after mass lighting break
It's not everything, we're still making a timer per spark effect, but it cuts things down significantly
* Updates explosions to not sleep
* Adds support for modifying a loops delay post process, makes extinguisher code suck less then it does currently, nukes some more sleeps and timer loops
* Converts water tank resin over to move loops rather then sleeps, minor behavior change mind, the cooldown starts on fire rather then on land, but I think that makes more sense anyway
* compile and runtime fix
* Fixes some runtimes, cleans up some code, ensures feature parity when it comes to logging
* Prevents resin foam from space drifting
* Adds support for flags back into the system, I need it for reasons
* Updates move_towards to fix some bugs and resolve some inconsistent behavior, implements a flag that makes a loop's first move start instantly
* Fixes extinguishers not actually transfering any reagents
* Converts sprays to the new system. This does actually minorly change behavior, in that I've changed the order of spray actions from step -> sleep -> wash to step -> wash -> sleep, but I'm not terribly torn up about it because frankly I think it feels better
* Converts grav catapults over to the new system
* Converts trays over to moveloops
* Converts robot streaking to move loops, the other two coming soon
* Compile you won't. Also fixes a behavior issue with oil streaks
* Does directional step_to properly, cleans up the other two streaking types
* Converts step_trigger over, not that it's actually used anywhere. Changes how stoping a move works, you need to explicitly qdel, other the step is just considered to be ignored. This will make life easier later
* Adds a jps movement loop. It's a bit bloaty, id is stupid, but it'll work just fine
* Makes the system support passing in a datum that's just used as extra context for the move. The hope is this makes signalizing things less of an absolute headache
* Begins the conversion of ai movement datums to movement loops
* These two are reasonably simple, only weird thing I'm doing is A: Not allowing target hotswapping, which I hope none is doing, and B: passing the controller into the move loop as extra context so things work properly
* JPS is a bit more complex, partially because the old implementation was a bit weird. 2 major things. 1: I'm dropping what I think was a redundant behavior minimum distance check from the premove bit of logic, since I'm pretty sure it didn't do anything. 2, instead of just stoping the step in an error state like being pulled, we count it against our max move total
* Audit
* Moves most forced movement to the framework, adds some components to make things nicer
* Implements a flag that makes the loop always operate, regardless of precedence and without impacting any other loops
* Moves movement subsystems into the right folder
* Hey potato what if you had two procs that did the same thing and one called the other? Wow it's useless
* Merges slipping and force movement
* Converys conveyors over to the system. It's a bit fragile, but I think it's totally worth it to save the sleep loop
* Precedence -> Priority, cleans up some logic errors, makes priority highest to lowest instead of lowest to highest, straight cleans some code up
* Makes poly and bubbles ignore spacedrift, now that precedence actually functions properly. I'm likely missing cases of this, will deal with it later
* Depression, thy name is linter
* Fixes linter, and hopefully fixes the runtimes in ci too
* Wew
* Sets sprays and extinguishers back to legacy, since people do actually seem to have noticed
* Spelling errors my beloved
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* More detail, moves return descriptions
* Converts transit tubes to the system?
* Adds the glide size modifier. Not honestly sure that this should be default, considering how crummy it makes things look for normal walking, but it's useful as hell here
* Adds a force move in dir template, actual support for fast initial steps (wtf old me) and a helper proc for setting delay
* Cleans up displosal code a bit, I thought about adding it to the system but it would functionally be just 'disposal loops'. Maybe I'll make a template subtype? not sure how I want to handle stuff like this
* Cleans up mob movement a bit
* Let's use the controller's visual delay
* Makes the resin thrower nicer, cries
* Cleans up some comments, replaces an implicit world.icon_size with an explicit one, fixes up a typecheck
* typecache instead of double istype. Can't do much about the !atom/movable, list would be too big I feel
* hhh
* bro wtf
* Documents the why of SS_TICKER
* Puts SSmovement on SS_TICKER. Lets us support tick steps
* Cleans up the charge action. Makes it use moveloops
* Fixes CI? kinda worried that this just got dropped
* Converts disposal pipes to move loops. They stutter a bit more then usual as of now, hoping that's a me thing, if it's not I'ma look at uping the priority of the base subsystem
* Moves the move subsystems off background, puts some on ssticker
* Prevents some things that shouldn't move in space from moving in space
* Documents the general form and usage of the system
* Virgin one vs chad once
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Removes unneeded check
* Moves appropriate movement subsystems into SS_BACKGROUND. Removes redundant SS_KEEP_TIMINGs
I do want the behavior of SS_TICKER, which at this point is tick based waits, and ignoring overtime when
calculating next fire.
Since honestly, these subsystems should ignore overtime in regards to next fire, the cost of moving A may be
nothing compared to the cost of moving B.
* Makes the MODULUS macro use floor. I knew our coders would never let me down, glad this exists, thanks ninja
Fixes teleporting caused by shitty round() behavior, adds a "you hit your target" case to homing loops
* Converts blood splatters to move loops, that'll do it
Co-authored-by: Rohesie <rohesie@gmail.com>
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
Creates a wrapper macro for ex_act() and moves the signal and contents explosion calls to there. This way we can ensure the signal is always fired. Also desnowflakes reagents responding to explosions.
Ensures that a signal is always called when the attendant proc is called.
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)
