Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>

…ped, it cannot be slowed, it cannot be reasoned with. YOU HAVE NO IDEA HOW READY YOU ARE (tgstation#66657)

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 tgstation#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

…on#67931)

* Adds coffins to crates' exclude_types.

Adds coffins to crates' exclude_types.

* Updates comment

Updates a years old comment with the current economy prices.

…licate files that never were (tgstation#67887)

All files must now be included in the .dme, removes some old files

Renames all occurrences of "delimber", "delimber_anomaly", "delimbering", etc. to "bioscrambler", "bioscrambler_anomaly", and "bioscrambling", etc.

Re-adds the code that went missing when tgstation#65755 was merged.

…#67775)

* remove trait_holy, add antimagic

* readds trait_holy and changes desc

Noticed some error sprites so went on with this PR. For all the soap sprites I just moved the inhand soap sprites to the suit storage position, the soap sprites were made by: epochayur and SweptWasTaken.

… already exploded (tgstation#67665)

Adds a check so that if there are no var/obj/machinery/power/supermatter_crystal/engine on the station. Testing was a bit hard because I didn't know how to test any of it with admin tools, so it involved a lot of running around doing objectives on local until I got a final objective. I'm pretty sure this PR works correctly.

* Fixes the bug

* Updates comment

Adds an inhand sprite for the Bluespace RPED

* Bells can now be attached to wheelchairs.

Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>

…tgstation#67906)

* Removes a misleading ballmer define, as drunken science points were removed in experisci.

tgstation#67915)

Re-adds the freeform boards to an open table in all the AI uploads, re-adds the purge boards to the harmful table in all uploads, and removes them from their associated spawners so that all stations have them as roundstart guaranteed spawns.

Small QoL thing for mappers. Mapping Helpers automatically go on the highest plane possible, POINT_LAYER. This would result in broken/burnt flooring having the following appearance in map editors:

This is just weird clutter that doesn't particularly look good. So, I just switched both of those subtypes to the same layer that we use for cleanable decal effects, just for nice visual clarify. Here's what that looks like:

…orrectly in Multi-Z debug by adding the blobstart that it should have anyway (tgstation#67948)

Fixes tgstation#67789 

This was spontaneous because stationloving uses find_safe_turf, which has an iteration limit of 1,000.

In several cases, the Nightwatcher has been called Nightwater. This PR fixes that.

See title, the non-radiation shutters and non-maintenance airlocks in the new Icebox atmos were made transparent
(Note: Not tested in game, but viewed in Dream Maker and looks fine)

Adds the Active Sonar Module to the game, a module which lets you see the locations of living creatures within a 9 tile radius.
It can be attained by researching Security Modules, and then printed like any other module.
It takes 3 complexity to house, has a 25 second cooldown, and takes a good amount of energy to use.

…n#67966)

Co-authored-by: tattle <article.disaster@gmail.com>

Removes the Exclamation Point from Server Hop

Hey there,

Recently, I haven't been able to directly connect to Sybil. However, I am able to easily get onto Campbell, and use the Server Hop command to readily get over there. However, one small snag I've ran into is that the `Server Hop!` verb means that you have to type it in as `server-hop!` in the chat bar. This was really confusing to me the first few times because no other verb requires you input in the correct punctuation. So, I decided to prune out the exclamation point to get weird of this oddity.

So why this was happening was because in DM, - has a higher precedence than **, so instead of a nice Gaussian function, this was made, where the y-coordinate represents the amount of freon that's made as a percentage of the total possible amount, which meant that unless your temperature was basically right at 800K, the freon, even thousands of moles of it, would be made instantly (or nearly instantly).

Allows Icebox's atmospherics APC to be accessible roundstart by moving a console.

Patches Rad_Area Directional Sign

Hey there,

I was trying to do something much more ambitious, but that completely fell through. I did catch this little mistake that caused this to occur though:

This PR just makes it the correct pathing for the directional helpers.

    Renames low_pop_minimum_threat to low_pop_maximum_threat. Untested but it'll fail CI if it doesn't work
    Increases threat_per_midround_roll from 6.5 to 7, to slightly shift number of midrounds.
    Lowered the number of roundstart traitors. I intend to do more in the larger part 2 PR, but the crux of it is that Dynamic 2022 part 1 creates a lot of midround traitors, which is great, but now that means we can lower the amount of total roundstart traitors. This changes it from 1 traitor every 24 people to 38. Eventually I want to make traitor not scale so hard, but it'll be tough to do that and make sure it doesn't just roll extremely chaotic rulesets in its place.

…67984)

drink your processable component copy-paste

gives dirs to all shutters on metastation

Fix invisible monkey equipment

Original fix by SabreML
Ported from github.com/pariahstation/Pariah-Station/pull/768

)

Gorilla speed change

…, rather than varedits (tgstation#68006)

I'll have to do the others at some point

I don't want to, but it'll happen

…tion#68004)

* [MDB Ignore] Shifts all (sane) varedited signs to directionals

Hey there,

So we have these cool new sign directionals now, but we still have all of the old pixel-shifted pre-fabrications lying around. So, I added an UpdatePaths (as well as Updated the Paths) to be a bit better at using directionals, because directionals are pretty neato.

This should update every single var_edit that used the proper 32 pixelshift (some of them used 28, and I'm unable to account for that automatically with current tooling) into a proper subtype. Mappers tend to learn by looking at well established maps, so it's always important to ensure that the well-established maps use the most recent tooling (i.e.: bring them up to the surface) and avoid needless excess lines in maps.

* The Commit With All The Maps

OH GOD OH FUCK

* Renames the UpdatePaths

Hey there,

There was this really picky thing with Holopads being in `FLOOR_PLANE`, so you would get stuff like this since wires+pipes are in the `GAME_PLANE`:

Looks ugly, right? So, let's set the holopad to `GAME_PLANE` for mapping purposes (since it'll help you visualize what you're looking at in game), and have it set to `FLOOR_PLANE` on Initialize. If we didn't set it on mapload, you'd get this really jarring shadow effect that doesn't really feel "in-place".

Hey there,

Landmarks were in the `TURF_LAYER`... layer, so that means you would see bizarre stuff like this in mapping:

Really obtuse to have everything, and I do mean everything, just be on the same layer of the turf just due to how often stuff gets covered up and left behind. So, I decided to make every single landmark (except for the jobstart ones, which were already on `MOB_LAYER`) to the `OBJ_LAYER` layer. This looks a lot better to my eyes, and the results speak for themselves:

Hey there,

I was enjoying a nice round of ss13 a few days ago, when I noticed this:

That's very odd! The caution line was painted in game, but the decals overlapping in such a manner was definitely in the map. So I decided to hunt down and standardize the decalling for the brig to ensure that you wouldn't have to do this. While in the area, I found a lot of weird stuff like:

* Unconnected shocked windows

* Atmospherics/Wires running under tables

* More Decalling Weirdness

So, I just straighted that all out to the point where it hopefully looks better now.

Hey there,

Apparently when balloons were split out of `items_and_weapons.dmi`, this was left behind causing stuff like this to happen:

Pretty goofy, right? Let's update the DMI pathing to ensure we don't see the silly purple/white cube when we really want to see an effect that nearly no one knows of (it's the thing that helps you crash the shuttle into a station, I think?).

Update emergency_meteor.dmm

…ion#67987)

* Initial commit

* input is colored according to the theme

* removed unused setting

…on#67985)

Scrubber thing.

Scrubbers will now turn off on atmos machinery disconnect() proc call.

* Repaths regen_core

* updates var names

* updates var name

…roperly (tgstation#67957)

* Renames plasma floor damage states

* Fixes bug, updates to overlays

…ral (tgstation#67955)

Fixes an ert bounty hunter's outfit, and the bounty hunter ID

Fixes IceBox Disposals

My bad, I broke it in tgstation#67706 (9ee1228).

)

Did you know that the base type of the beach turf has different atmos to literally every other tile in that gateway?

)

Fix display formatting issue with operating computer ui

About The Pull Request

The up and down directions of the greyscale knight armor's worn sprites were two pixels too high. I moved them down by that much.
Why It's Good For The Game

Fixes tgstation#67861
Changelog

cl
fix: The runic knight helmet's worn sprites have had their alignment fixed.
/cl