* Cleans up the fallout from plane cube
Alright.
Makes cleaning bubbles respect planes
Adds support for updating overlays on move, fixing an issue with pointing at items
Adds better error messages for failing to provide args for mutable_appearance()
Fixes a bug where string overlays were not respecting insertion order
* Adds documentation for offset spokesman and offset_const
* Better stack trace
* Removes some redundant uses of cached MAs
At this scale, attempting to cache MAs like this has 0 impact on anything
And just makes things more messy then they need to be
* ensures fullscreen objects START offset, so things are always proper
* ensures chatmessages always have the right offset
* fixes compile
* whoops, the above lighting plane should actually be ABOVE the lighting plane
* fixes compile, also cleans up the fire overlay a tad
* Adds a unit test for plane masters that are shrunk by multiz being double shrunk
This is slightly hacky because of how I'm handing the plane master
group, but it's not THAT bad, and gives me some real good coverage
* Properly targets the seethrough plane at the game world plate. This fixes unit tests, and also just makes more sense
* whoops
* oh
* adds datum support for allocate(), cleans up a harddel from testing
* Makes camera chunks index at 1, and also makes them support non powers of two sizes, since that was unneeded
* fixes runtime in allocate
* Makes only station areas part of Statioj
* Makes only subtypes of /area/station be part of the station
* Removes Icemoon and Shuttles as a check for Anomaly placers as they aren't needed anymore, not being part of shuttles.
* Removes a ton of uses of NO_ALERTS where it is no longer needed.
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
* 'optimizes' space transitions by like 0.06 seconds, makes them easier to read tho, so that's an upside
* ''''optimizes'''' parsed map loading
I'm honestly not sure how big a difference this makes, looked like small
percentage points if anything
It's a bit more internally concistent at least, which is nice. Also I
understand the system now.
I'd like to think it helped but I think this is kinda a "do you think
it's easier to read" sort of situation. if it did help it was by the
skin of its teeth
* Saves 0.6 seconds off loading meta and lavaland's map files
This is just a lot of micro stuff.
1: Bound checks don't need to be inside for loops, we can instead bound the iteration counts
2: TGM and DMM are parsed differently. in dmm a grid_set is one z level,
in tgm it's one collumn. Realizing this allows you to skip copytexts and
other such silly in the tgm implemenentation, saving a good bit of time
3: Min/max bounds do not need to be checked inside for loops, and can
instead be handled outside of them, because we know the order of x
and y iteration. This saves 0.2 seconds
I may or may not have made the code harder to read, if so let me know
and I'll check it over.
* Micro ops key caching significantly. Fixes macros bug
inserting \ into a dmm with no valid target would just less then loop
the string. Dumb
Anyway, optimizations. I save a LOT of time by not needing to call
find_next_delimiter_position for every entry and var set. (like maybe 0.5
seconds, not totally sure)
I save this by using splittext, which is significantly faster. this
would cause parsing issues if you could embed \n into dmms, but you
can't, so I'm safe.
Lemme see uh, lots of little things, stuff that's suboptimal or could be
done cheaper. Some "hey you and I both know a \" is 2 chars long sort of
stuff
I removed trim_text because the quote trimming was never actually used,
and the space trimming was slower then using the code in trim. I also
micro'd trim to save a bit of time. this saves another maybe 0.5.
Few other things, I think that's the main of it. Gives me the fuzzy
feelings
* Saves 50% of build_coordinate's time
Micro optimizing go brrrrr
I made turf_blacklist an assoc list rather then just a normal one, so
lookups are O(log n) instead of O(n). Also it's faster for the base case
of loading mostly space.
Instead of toggling the map loader right before and right after New()
calls, we toggle at the start of mapload, and disable then reenable if
we check tick. This saves like 0.3 seconds
Rather then tracking an area cache ourselves, and needing to pass it
around, we use a locally static list to reference the global list of
area -> type. This is much faster, if slightly fragile.
Rather then checking for a null turf at every line, we do it at the
start of the proc and not after. Faster this way, tho it can in theory
drop area vvs.
Avoids calling world.preloader_setup unless we actually have a unique
set of attributes. We use another static list to make this comparison
cheap. This saves another 0.3
Rather then checking for area paths in the turf logic, or vis versa, we
assume we are creating the type implied by the index we're reading off.
So only the last type entry will be loaded like a turf, etc.
This is slightly unsafe but saves a good bit of time, and will properly
error on fucked maps.
Also, rather then using a datum to hold preloader vars, we use 2 global
variables. This is faster.
This marks the end of my optimizations for direct maploading. I've
reduced the cost of loading a map by more then 50% now. Get owned.
* Adds a define for maploading tick check
* makes shuttles load again, removes some of the hard limits I had on the reader for profiling
* Macro ops cave generation
Cave generation was insanely more expensive then it had any right to be.
Maybe 0.5 seconds was saved off not doing a range(12) for EVERY SPAWNED
MOB.
0.14 was saved off using expanded weighted lists (A new idea of mine)
This is useful because I can take a weighted list, and condense it into
weight * path count. This is more memory heavy, and costs more to
create, but is so much faster then the proc.
I also added a naive implementation of gcd to make this a bit less bad.
It's not great, but it'll do for this usecase.
Oh and I changed some ChangeTurfs into New()s. I'm still not entirely
sure what the core difference between the two is, but it seems to work
fine.
I believe it's safe because the turf below us hasn't init'd yet, there's
nothing to take from them. It's like 3 seconds faster too so I'll be sad
when it turns out I'm being dumb
* Micros river spawning
This uses the same sort of concepts as the last change, mostly New being
preferable to ChangeTurf at this level of code.
This bit isn't nearly as detailed as the last few, I honestly got a bit
tired. It's still like 0.4 seconds saved tho
* Micros ruin loading
Turns out it saves time if you don't check area type for every tile on a
ruin. Not a whole ton faster, like 0.03, but faster.
Saves even more time (0.1) to not iterate all your ruin's turfs 3 times
to clear away lavaland mobs, when you're IN SPACE who wrote this.
Oh it also saves time to only pull your turf list once, rather then 3
times
* 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
About The Pull Request
Closets now initialize their contents once in dump_contents(). This saves more than 1.6 seconds of init time (all /obj/structure/closet now initialize in 84ms).
Not sure what assumptions this will break, there's a lot of closets, so separate PR.
cl
del: You can no longer see maint spawners before the round starts (but your rounds start faster now :) )
/cl
* 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.
ever see the tram take 10 milliseconds per movement to move 2100 objects? now you have
https://user-images.githubusercontent.com/15794172/166198184-8bab93bd-f584-4269-9ed1-6aee746f8f3c.mp4
About The Pull Request
fixes#66887
done for the code bounty posted by @MMMiracles to optimize the tram so that it can be sped up. the tram is now twice as fast, firing every tick instead of every 2 ticks. and is now around 10x cheaper to move. also adds support for multiz trams, as in trams that span multiple z levels.
the tram on master takes around 10-15 milliseconds per movement with nothing on it other than its starting contents. why is this? because the tram is the canary in the coal mines when it comes to movement code, which is normally expensive as fuck. the tram does way more work than it needs to, and even finds new ways to slow the game down. I'll walk you through a few of the dumber things the tram currently does and how i fixed them.
the tram, at absolute minimum, has to move 55 separate industrial_lift platforms once per movement. this means that the tram has to unregister its entered/exited signals 55 times when "the tram" as a singular object is only entering 5 new turfs and exiting 5 old turfs every movement, this means that each of the 55 platforms calculates their own destination turfs and checks their contents every movement. The biggest single optimization in this pr was that I made the tram into a single 5x11 multitile object and made it only do entering/exiting checks on the 5 new and 5 old turfs in each movement.
way too many of the default tram contents are expensive to move for something that has to move a lot. fun fact, did you know that the walls on the tram have opacity? do you know what opacity does for movables? it makes them recalculate static lighting every time they move. did you know that the tram, this entire time, was taking JUST as much time spamming SSlighting updates as it was spending time in SStramprocess? well it is! now it doesnt do that, the walls are transparent. also, every window and every grille on the tram had the atmos_sensitive element applied to them which then added connect_loc to them, causing them to update signals every movement. that is also dumb and i got rid of that with snowflake overrides. Now we must take care to not add things that sneakily register to Moved() or the moved signal to the roundstart tram, because that is dumb, and the relative utility of simulating objects that should normally shatter due to heat and conduct heat from the atmosphere is far less than the cost of moving them, for this one object.
all tram contents physically Entered() and Exited() their destination and old turfs every movement, even though because they are on a tram they literally do not interact with the turf, the tram does. also, any objects that use connect_loc or connect_loc behalf that are on the same point on the tram also interact with each other because of this. now all contents of the tram act as if theyre being abstract_move()'d to their destination so that (almost) nothing thats in the destination turf or the exit turf can react to the event of "something laying on the tram is moving over you". the rare things that DO need to know what is physically entering or exiting their turf regardless of whether theyre interacting with the ground can register to the abstract entered and exited signals which are now always sent.
many of the things hooked into Moved(), whether it be overrides of Moved() itself, or handlers for the moved signal, add up to a LOT of processing time. especially for humans. now ive gotten rid of a lot of it, mostly for the tram but also for normal movement. i made footsteps (a significant portion of human movement cost) not do any work if the human themselves didnt do the movement. i optimized has_gravity() a fair amount, and then realized that since everything on the tram isnt changing momentum, i didnt actually need to check gravity for the purposes of drifting (newtonian_move() was taking a significant portion of the cost of movement at some points along the development process). so now it simply doesnt call newtonian_move() for movements that dont represent a change in momentum (by default all movements do).
also i put effort into 1. better organizing tram/lift code so that most of it is inside of a dedicated modules folder instead of scattered around 5 generic folders and 2. moved a lot of behavior from lift platforms themselves into their lift_master_datum since ideally the platforms would just handle moving themselves, while any behavior involving the entire lift such as "move to destination" and "blow up" would be handled by the lift_master_datum.
also
https://user-images.githubusercontent.com/15794172/166220129-ff2ea344-442f-4e3e-94f0-ec58ab438563.mp4
multiz tram (this just adds the capability to map it like this, no tram does this)
Actual Performance Differences
to benchmark this, i added a world.Profile(PROFILER_START) and world.Profile(PROFILER_START) to the tram moving, so that it generates a profiler output of all tram movement without any unrelated procs being recorded (except for world.Profile() overhead). this made it a lot easier to quantify what was slowing down both the tram and movement in general. and i did 3 types of tests on both master and my branch.
also i should note that i sped up the "master" tram test to move once per tick as well, simply because the normal movement speed seems unbearably slow now. so all recorded videos are done at twice the speed of the real tram on master. this doesnt affect the main thing i was trying to measure: cost for each movement.
the first test was the base tram, containing only my player mob and the movables starting on the tram roundstart. on master, this takes around 13 milliseconds or so on my computer (which is pretty close to what it takes on the servers), on this branch, it takes between 0.9-1.3 milliseconds.
ALSO in these benchmarks youll see that tram/proc/travel() will vary significantly between the master and optimized branches. this is 100% because there are 55 times more platforms moving on master compared to the master branch, and thus 55x more calls to this proc. every test was recorded with the exact same amount of distance moved
here are the master and optimized benchmark text files:
master
master base tram.txt
https://user-images.githubusercontent.com/15794172/166210149-f118683d-6f6d-4dfb-b9e4-14f17b26aad8.mp4
also this shows the increased SSlighting usage resulting from the tram on master spamming updates, which doesnt happen on the optimized branch
optimized
optimization base tram.txt
https://user-images.githubusercontent.com/15794172/166206280-cd849aaa-ed3b-4e2f-b741-b8a5726091a9.mp4
the second test is meant to benchmark the best case scaling cost of moving objects, where nothing extra is registered to movement besides the bare minimum stuff on the /atom/movable level. Each of the open tiles of the tram had 1 bluespace rped filled with parts dumped onto it, to the point that the tram in total was moving 2100 objects. the vast majority of these objects did nothing special in movement so they serve as a good base case. only slightly off due to the rped's registering to movement.
on master, this test takes over 100 milliseconds per movement
master 2000 obj's.txt
https://user-images.githubusercontent.com/15794172/166210560-f4de620d-7dc6-4dbd-8b61-4a48149af707.mp4
when optimized, about 10 milliseconds per movement
https://user-images.githubusercontent.com/15794172/166208654-bc10086b-bbfc-49fa-9987-d7558109cc1d.mp4
optimization 2000 obj's.txt
the third test is 300 humans spawned onto the tram, meant to test all the shit added on to movement cost for humans/carbons. in retrospect this test is actually way too biased in favor of my optimizations since the humans are all in only 3 tiles, so all 100 humans on a tile are reacting to the other 99 humans movements, which wouldnt be as bad if they were distributed across 20 tiles like in the second test. so dont read into this one too hard.
on master, this test takes 200 milliseconds
master 300 catgirls.txt
when optimized, this takes about 13-14 milliseconds.
optimization 300 catgirls on ram ranch.txt
Why It's Good For The Game
the tram is literally 10x cheaper to move. and the code is better organized.
currently on master the tram is as fast as running speed, meaning it has no real relative utility compared to just running the tracks (except for the added safety of not having to risk being ran over by the tram). now the tram of which we have an entire map based around can be used to its full potential.
also, has some fixes to things on the tram reacting to movement. for example on master if you are standing on a tram tile that contains a banana and the TRAM moves, you will slip if the banana was in that spot before you (not if you were there first however). this is because the banana has no concept of relative movement, you and it are in the same reference frame but the banana, which failed highschool physics, believes you to have moved onto it and thus subjected you to the humiliation of an unjust slipping. now since tram contents that dont register to abstract entered/exited cannot know about other tram contents on the same tile during a movement, this cannot happen.
also, you no longer make footstep sounds when the tram moves you over a floor
TODO
mainly opened it now so i can create a stopping point and attend to my other now staling prs, we're at a state of functionality far enough to start testmerging it anyways.
add a better way for admins to be notified of the tram overloading the server if someone purposefully stuffs it with as much shit as they can, and for admins to clear said shit.
automatically slow down the tram if SStramprocess takes over like, 10 milliseconds complete. the tram still cant really check tick and yield without introducing logic holes, so making sure it doesnt take half of the tick every tick is important
go over my code to catch dumb shit i forgot about, there always is for these kinds of refactors because im very messy
remove the area based forced_gravity optimization its not worth figuring out why it doesnt work
fix the inevitable merge conflict with master lol
create an icon for the tram_tunnel area type i made so that objects on the tram dont have to enter and exit areas twice in a cross-station traversal
add an easy way to vv tram lethality for mobs/things being hit by it. its an easy target in another thing i already wanted to do: a reinforced concept of shared variables from any particular tram platform and the entire tram itself. admins should be able to slow down the tram by vv'ing one platform and have it apply to the entire tram for example.
Changelog
cl
balance: the tram is now twice as fast, pray it doesnt get any faster (it cant without raising world fps)
performance: the tram is now about 10 times cheaper to move for the server
add: mappers can now create trams with multiple z levels
code: industrial_lift's now have more of their behavior pertaining to "the entire lift" being handled by their lift_master_datum as opposed to belonging to a random platform on the lift.
/cl
* 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>
Essentially SSmapping had a list for each theme of ruin (space, lava,
ice, ice underground). These were all filled with an if statement
checking the ruin templates type. Now, i've given ruins a ruin_type var, which is then used to dynamically add to a single list of ruins, which separates lists of ruins by ruin type.
Good for downstreams who may have more ruin types
Changelog
cl
refactor: Dehardcoded SSmapping ruin types.
/cl
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
Bring _HELPERS/_lists.dm to latest standards by:
-Adding proper documentation and fixing existing one
-Giving vars proper names
-Procs now use snake case as per standard (many files that use those procs will be affected)
Maint loot spawners hang around and never get qdeleted after spawning their loot.
This does a little bit of simple code logic to limit copypasta and ensure that loot spawners never qdel late and that they qdel precisely when they intend to. Or when SSmapping intends for them to.
First off, I am aware of the Feature Freeze for this month. This PR was initially started in #60401 about a month ago to break the changes into smaller PRs. The end result for this PR is a poor man's attempt at roguelike procedural generation. Enjoy!
Link to the README for how the new spawner system works.
Added the following new random mapping spawners:
pen, crayon, stamp, paper, pamphlet, briefcase, folder, wardrobe closet, wardrobe closet colored, backpack, narcotics, permabrig_weapon, permabrig_gear, prison, material, carpet, ornament, generic decoration, statue, showcase, paint, tool, tool_advanced, tool_rare, material_cheap, material, material_rare, toolbox, flashlight, canister, tank, vending_restock, atmospherics_portable, tracking_beacon, musical_instrument, gambling, coin, money_small, money, money_large, drugs, dice, cigarette_pack, cigarette, cigar, wallet_lighter, lighter, wallet_storage, deck, toy, toy_figure, booze, snack, condiment, cups, minor_healing, injector, surgery_tool, surgery_tool_advanced, surgery_tool_rare, firstaid_rare, firstaid, patient_stretcher, medical supplies, crate, crate_abandoned, girder, grille, lattice, spare_parts, table_or_rack, table, table_fancy, tank_holder, crate_empty, crate_loot, closet_private, closet_hallway, closet_empty, closet_maintencne, chair, chair_maintence, chair_flipped, chair_comfy, barricade, data_disk, graffiti, mopbucket, caution_sign, bucket, soap, box, bin, janitor_supplies, soup, salad, dinner
Removed deprecated wizard trap, vault, and armory spawners.
About The Pull Request
Rewrites the entire preferences menu in tgui. Rewrites the entire backend to be built upon datumized preferences, rather than constant additions to the preferences base datum.
Splits game preferences into its own window.
Antagonists are now split into their individual rulesets. You can now be a roundstart heretic without signing up for latejoin heretic, as an example.
This iteration matches parity, and provides very little new functionality, but adding anything new will be much easier.
Fixes#60823Fixes#28907Fixes#44887Fixes#59912Fixes#58458Fixes#59181
Major TODOs
Quirk icons, from @Fikou (with some slight adjustments from me)
Lore text, from @EOBGames (4/6, need moths and then ethereal lore from @AMonkeyThatCodes)
Heavy documentation on how one would add new preferences, species, jobs, etc
A lot of specialized testing so that people's real data don't get corrupted
Changelog
cl Mothblocks, Floyd on lots of the design
refactor: The preferences menu has been completely rewritten in tgui.
refactor: The "Stop Sounds" verb has been moved to OOC.
/cl
* The Failsafe can now recover from an deleted MC
Its also more reliable and can handle a situation where its main Loop runtimes and the MC is stuck
* Reset defcon level correctly
Oops left that in from debugging the levels
* Correctly recover SSasset
* Only decrease defcon if MC creation failed
Also add some sort sleep between emergency loops
* Makes the last two emergency actions manual procs
Since they are kinda unstantable its probalby best
if only admins call these manually
Its also more reliable and can handle a situation where its main Loop runtimes and the MC is stuck
You can also now debug Master/New()
While there will most likely never be any situation where the MC is just gone its still good to know that the game can recover from such a situation
For example maybe someone messed up a SDQL query or maybe someone wanted to delete the MC to create a new one hoping the Failsafe would do so for him
Maintenance loot spawners now fire at roundstart, rather than during the initialization of the Atoms subsystem.
Maintenance loot spawners do not qdel themselves during the spawning process, but persist, and merely hide themselves from living players.
As a cute side effect, this lets preround observers look at the colourful maintenance loot dice icons before the round starts. Observers can continue to see the loot dice post-round, but they are deliberately
very faint.
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs.
Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines.
Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing.
Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc.
(Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)
As described in issue #56733, there is a possibility of a race condition in SSmapping.add_new_zlevel - either during Z level incrementing, or the proc itself, as it only expands the amount of registered z-levels after being finished.
While the first hopefully shouldn't happen, it can still manifest because of the CHECK_TICK within. A practical result is that two concurrent calls to this proc will both create a new Z-level, but actually report having made the same first one.
This is problematic for map_templates that will then load blindly to the reported Z-level when using load_new_z, overwriting each other. We sometimes encounter that end result on CM13 codebase because of a map load that can be triggered by an user topic - if two people click at the same time, it's not unlikely for the first call to sleep in CHECK_TICK and let the second run, causing double-loading.
Creates update_name and update_desc
Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together
Less non-icon handling code in update_icon and friends
Signal hooks for things that want to change names and descriptions
99%+ of the changes in this are just from switching everything over to update_appearance from update_icon
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
Refactors the holodeck to use map templates instead of copy_contents_to, which every maintainer seems to have complaints about.
Fixes#41485 because the matches become part of the spawned list created by ssatoms
Fixes#54789 because the holodeck area no longer has the NO_TELEPORT flag
Fixes#55676 because the map templates cant be changed midround unlike the program copies in the centcom z level
Fixes#49318 because the holodeck no longer creates new areas like the original did
This pr also changes initTemplateBounds to be a /datum/map_template proc instead of a parsed_map proc. This was mainly so I wouldn't have to duplicate vars between map_template and parsed_map. It's also nice because there's no longer a parsed_map proc inside the map_template file, especially when it didn't need to be a parsed_map proc.
The holodeck sims wont take up space in the centcom z level any more (which allows for more possible programs in the future), and map templates are more heavily tested. This is also a chance to future proof the holodeck against bugs. Holodeck also seems more responsive. This should allow for a second custom holodeck in some future ruin as well, although that of course will not be in play for the near future because of the offstation content ban. Also I documented the fuck out of the holodeck
This replaces lavaland's old diagonal tunnel gen which was really
horrendously jammed into asteroid floor code (?????) with Cellular
Automata which runs in rust (PR for that here:
https://github.com/tgstation/rust-g/pull/57 ). The new code is a bit
cleaner, but also looks better.
VID: https://streamable.com/a45ke2
Things to do:
- Make an icemoon version
- Fix the roundstart atmos adjacency issues
I asked AnturK if this was an acceptable PR for this month; he said it
was okay as long as I didn't add new areas, which I don't plan to do.
But if anyone thinks this PR breaks the spirit of the month I'll open
it again in december.
I re-styled the CSS for the stat panel in hopes to make it look nice, and I also added the ability to use sub-categories (currently a single level) of verbs using a . (period), an example being Admin.Fun instead of the previous Admin - Fun. This now results in a sub-category being automagically generated in the stat panel.
-bitfielded a bunch of bools on /area, I left some untouched cus they get called a lot
-Unused vars
-Fixed a var pretending to be a fake bool
-Probably more
