* Initial pipecrawl work
Ok so pipecrawl images were updating EVERY TIME YOU MOVED
This was not good mojo
What I've done here is twofold
First, I ensured pipecrawl updates only when the net changes. This
breaks the current implementation, but I intend on fixing that
Second, I moved our method of getting pipes to the spatial grid
This isn't that great at the moment, but I intend on adding support for
tracking entered/exited cells, which should make this much better
* Much faster pipecrawling processing, niceties
Adds a concept called a cell tracker datum.
It manages a list of cells a passed in bound is "inside", and when
queried will return a list of new cells, and old cells.
Because we only really care about maintaining an absolute window of
"CELLS WE ARE IN" and less about always removing cells we're not in, we
can manage a second window to prevent moving up and down on a cell line
causing a ton of updates.
Uses this concept to optimize pipecrawling significantly, from 3ms per
call before to roughly 0.03ms per call.
Also moves pipecrawl images to their own plane, so they don't overlap ui
elements
* Pipecrawling effects niceties, direction help
You can now move in more then one direction when pipecrawling
This works as expected, if you hold up and left, move up for a while,
and come to a fork, you'll go left
Added some effects to pipecrawling. It'll darken the lighting plane
slightly, so you get a nice effect instead of just fullbright.
Also added a color matrix and drop shadow to the pipe images, this way
they stand out a bit more.
You now glide between pipe moves, rather then moving instantly. This
doesn't effect your actual move rate, but it no longer feels jittery
with say, 60fps
* Bounds
* Fixes runtimes, cache something somethign sonic speed
* Reworks how being interested in the spatial grid is tracked
Rather then checking multiple variables on the atom to consider, we
instead check for the existence of a string key.
This key is used by a list on the spatial grid subsystem to retrive a
cached list of all of the atoms "types"
Doing this requires doing a bit of extra work in
important_recursive_contents code, but it allows us to separate being a
part of the spatial grid from using important recursive contents, which
is very nice.
As a consequence, I've had to unroll some lazylist macros in important
recursive contents logic. It's not ""that"" bad but it's not great
either.
Oh and this adds a slight cost to enter/exit cell, but it's minimal.
Basically, rather then checking for different features of a grid member,
we just iterate the list their string key points to. Very handy
So there's an added cost of a list copy and all, but we save the
headache of more types technically increasing the cost of
addition/removal.
I also made adding/removing from the grid into one "pulbic" proc rather then two
different ones for each operation, because it was starting to get silly
* waaa waa it doesn't compile
* chord -> coord
* Ensures important_recursive_contents is actually emptied on removal
* Removes soul
* Kyler's review
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Kyler's review 2
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Kyler's review 3
Moves some procs around, improves some documentation, catches a few
small issues
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Removes all supurfolus uses of QDEL_HINT_LETMELIVE
This define exists to allow abstract, sturucturally important things to
opt out of being qdeleted.
It does not exist to be a "Immune to everything" get out of jail free
card.
We have systems for this, and it's not appropriate here.
This change is inherently breaking, because things might be improperly
qdeling these things. Those issues will need to be resolved in future,
as they pop up
* Changes all needless uses of COMSIG_PARENT_PREQDELETED
It exists for things that want to block the qdel. If that's not you,
don't use it
* Adds force and hard del verbs, for chip and break glass cases
respectively
The harddel verb comes with two options before it's run, to let you
tailor it to your level of fucked
* Damn you nova
Adds proper parent returns instead of . = ..()
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* Ensures immortality talismans cannot delete their human if something goes fuckey. Thanks ath/oro for pointing this out
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* makes hud images only apply by z level
* makes some of the atom_hud procs have better names
* fixes warning with the hud_user list and adds better documentation
* better docs for hud_images
* removes TODOs
* docs for hud_list
* adds support for linked z levels so mobs can see lower ones
* fixes merge conflict and shittily makes only shocked airlocks get added
* adds support for setting images in the hud as active and inactive
* gets rid of unatomic spatial grid change
* maybe i should actually try COMPILING my changes
* fixes merge skew and makes it compile again
* fixes huds refusing to remove from users who changed z level
* improves z level and registration logic
* fixes antag huds not appearing
* Fixes antag huds not properly setting. We now use hud_list in init, so it needs to be set before the new call, not after. Not sure why the use of appearance key was split like this, but none else knows either so none can stop me
* Ensures that hiding a basic appearance also hides the atom's active list too
* Fixes antag huds going poof
Ensures that remove_atom_from_hud will return false if the passed atom
isn't managed by it
This fixes antag huds disappearing randomly, since they assumed that if
the parent call of remove_atom_from_hud returned true, we should delete
ourselves. This is a safe assumption for them to make, since they should
only ever have one atom.
Does kinda bork if we call remove_atom_from_hud in a way that is unsure
if the passed atom is actually in that list. We were forced into doing
this by how atom huds use the qdeleting signal.
* makes basic alternate_appearance's only update themselves when setting their hud image to active and makes them not add themselves to the global huds_by_category list
* fixes mistake with hud_users list being set non associatively (bad)
* as anything in bot path loops
* Fixes merge skew problems
* Makes bot paths non global
This way they can show themselves to only the bot that "owns" them, ya
feel me?
* Fixes huds not showing up sometimes, cleans up some code
Post Kapu's limb refactor, we were calling prepare_huds twice in a human
init call chain. What was happening was this:
call prepare_huds() // Human
I gained a new hud image
I set active hud icons to mirror it
call prepare_huds() // Living
I overwrote the new hud image
I attempted to set active hud icons, which failed because it assumes
this can never happen
*cries*
* Renames add_hud_to_atom to show_to
My hope is this will make understanding hud code a bit easier, by tying
the behavior to a "verb" more closely. Also renamed a few vars
* remove_hud_from_mob -> hide_from
* Nitpicks a few comments
* Whoops/fuck/shit/damn it all/hhhhhhhhhhhh
* Moves check down, improves stack trace a bit
Co-authored-by: KylerAce <kylerlumpkin1@gmail.com>
* Adds MC initialization stages. Earlier stages can fire while later ones init.
Removes TICK_LIMIT_MC_INIT config for barely doing anything to speed up init and being inconvenient to work with if fires and inits can happen at the same time.
things being held inside the spatial grid while they should be deleted causes a rareish unit test failure for create_and_destroy. hopefully this fixes it by checking for if the entering movable is being qdeleted as well as early returning in enter_cell if the spatial grid isnt initialized.
Im not sure what exactly causes the hanging refs, but i suspect its something to do with not properly catching qdeleting objects if they for whatever reason enter another part of the spatial grid instead of nullspacing.
This will give us a better idea of what kind of failure we're dealing with -Lemon
* Atoms (mostly new players caused by logout) can get deleted before spatial grid initializes.
* Fixes images when viewing your notes before SSassets initializes.
* Fixes abandoned crate runtime.
* Fixes armor runtimes on eating clothes (this really needs alternative solution)
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.
