## About The Pull Request
I woke up today and thought 'what would be easy thing to do today so I
can say I've done something?'. Then I remembered I saw several gangtool
usages the time I split radio up, and I could remedy those. 7 hours
later, device.dmi is split in a folder of its own, and I've also given
unique sprites to door remotes and landing desginators.
## Why It's Good For The Game
The device.dmi was kind of a mess.
## Changelog
🆑
/🆑
This appears to sometimes runtime when the target stationary port is
somehow a different size to the ripple port. The code had an out of
bounds check of a sort, but it doesn't actually work because the array
accesses runtime instead of returning a null
As to why the turfs available were not the same? most likely because the
bounds overlapped the world edge due to a fuck huge shuttle.
I have a feeling even if this proc completes something would fail later
anyway.
edit: oh so it was the lance shuttle which is fuck hueg
#79961 is related but not fixed by this.
This adds a tracker for sources of invisibility and a priority system. I
needed this for another thing so I'm doing this first since it touches a
lot of code. As for the bugs fixed in the changelog, it's only what I
noticed while going through everything and there's likely a few more
things fixed with this. This should be testmerged for a while, I'll
bring this out of draft when it feels safe.
🆑
admin: Invisimin can now be used on mobs that are already invisible,
whether through temporary or permanent effects.
fix: Monkeyize/Humanize mob transformations no longer permanently reveal
invisible mobs if they had effects making them invisible otherwise.
fix: Objects with the undertile element that have been made invisible
through other means are no longer revealed by being uncovered.
/🆑
## About The Pull Request
See title.
## Why It's Good For The Game
If a lazy template is loaded AFTER roundstart it doesn't get included
into the global init procs, because that work is offloaded into a
subsystem
LINDA runtimes are bad, null.archive() runtime be gone.
## Changelog
🆑
fix: The Syndicate have fired their previous construction company after
poor results in recent outposts.
/🆑
## About The Pull Request
Adds multi-z support for lazy templates
Also fixes some improper use and placement for turf flags
## Why It's Good For The Game
Shadow needs/wants this for bit runner maps.
Turf flags are also why lava has been generating in places it shouldnt.
(inside of ruins)
## Changelog
🆑
fix: Lava can no longer occasionally generate inside of previously
loaded templates and breach and/or destroy shit
/🆑
---------
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
The emergency shuttle maintains its security level coefficient and does
the calculation instead of outside procs that aren't aware of what alert
it was when the shuttle was first called.
If the shuttle auto-call timer should be capped at the current security
level timer, that can be done in a different PR.
## Why It's Good For The Game
Fixes https://github.com/tgstation/tgstation/issues/78159
## Changelog
🆑 LT3
fix: Emergency shuttle should correctly scale timer up/down when
changing security levels
/🆑
## About The Pull Request
Hey there,
There were more than a few times (like in cinematic code) where we might
need to accurately know the source of what's adding this trait (or have
multiple sources for the whole 'we don't want this mob to do shit while
we transform this mob'), so in order to rectify this potential issue,
let's refactor it into a trait.
## Why It's Good For The Game
Some code already declared that there might be issues with this being a
boolean var (with no way of knowing _why_ we don't want this mob to not
transform (or not do anything idk). Let's remove those comments and any
future doubt in those instances with the trait macros. Also, stuff like
`TRAIT_IMMOBILIZED` which does a similar thing in many contexts was
already a trait that was regularly added in conjunction with flipping
the variable, so we're able to flatten all that stuff into
`add_traits()` and `remove_traits()` now. nice
I also cleaned up quite a bit of code as I saw it, let me know if it
should be split out but I guarantee that if I didn't do it- no one will
for the next two years.
## Changelog
🆑
refactor: If you transform into another mob and notice bugs with
interacting with the game world, please create a bug report as this
framework was recently refactored.
/🆑
Probably fucked up somewhere, lmk
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Title.
Vendor tipping code is now on /atom/movable, and any movable can fall
over like a vendor does. Things like crits have been moved to
type-specific availability tables, their effects are now held in their
own proc, are now random per crushed item, have probability weights,
etc.
In the process of making this PR I also had to fix another issue, where
a bunch of take_damage() overrides had incorrect args, so that explains
the take_damage changes I made.
Tipping now also attacks any atoms on the target, given they use
integrity.
Adds 2 new malf modules.
1. REMOTE VENDOR TIPPING: A mid-cost and mid-supply module allows malf
AIs to remotely tip a vendor in any of the 8 directions. After 0.5
seconds of delay and a visual indicator (along with other warnings), the
vendor falls over.
1.1. In the process of making this I had to expand a arrow sprite to
have orthogonal directions, which is why you may see the testing dmi
being changed.
2. CORE ROLLING: A mid-cost but low-supply ability that allows the AI to
roll around and crush anything it falls on, including mobs. This has a
5% chance to have a critical hit so it isnt THAT terrible - plus it's
guaranteed to never stunlock. It's real utility lies in the fact the AI
now has limited movement without borgs. Also, the psychological factor.
As a bonus, vendor tipping now uses animate and transforms instead of
replacing matrices.
## Why It's Good For The Game
1. Generifying vendor tipping code is just good, period. It's a very
wacky and silly little piece of code that really doesn't need to be
isolated to vendors exclusively. ANY big and heavy object can fall over
and do a ton of damage.
1.1. Also, adding weights to critical hits is really good, because it
lets things like the headgib finally be a lot less terrifying, as
they're a lot less likely to happen.
2. Remote vendor tipping is a bit of a goofy ability that isn't really
THAT practical but has a chance of catching someone unaware and doing
some serious damage to that person alone.
2.1. Atop of this, vendor tipping isn't that loud of an action as say,
blowing things up, or doing a plasma flood. Even overrides aren't this
silent or a non-giveaway. A vendor falling on someone, though, is a
mundane thing that happens a lot. This is a decent way to assassinate
people before going loud (or at least, damage people) that isn't offered
yet.
4.
3.1. For real though, AIs rolling around is just fucking hilarious. The
ability to move isn't offered right now (which isn't that much of a bad
things), but with sufficiently limited charges (or limits to how many
times you can buy the ability), this can be a funny little t hing that
lets the AI potentially hide somewhere on the sat (or just relatively
close to the sat, such as engineering [it can't go through the
teleporter with this but it can go through transit tubes]) without the
need for borgs.
3.2. Also, it lets the AI sacrifically execute people by blowing up
their brains.
## About The Pull Request
Removes all of the duplicate global lists for specific machine types
where the only thing they do is store all machines of that type.
Adds machine tracking to SSmachines in the form of a list for all
machines, and then an associative list for machines by their type.
Previously we have machines in multiple global lists, such as airlocks
being in GLOB.doors, GLOB.airlocks, GLOB.machines.
This makes that not a thing, and also means that iterating through
GLOB.machines looking for a specific type is no longer as expensive.
## About The Pull Request
https://github.com/tgstation/tgstation/assets/7501474/a2d83ce8-eba1-42d9-a1f8-9d73f7c40b21
Adds shuttle events! Stuff can now start to happen outside the shuttle,
either benign or spicy (but usually just fun to watch)!
## Why It's Good For The Game
The shuttle escape sequence is an important part of the game, uniting
about every player surviving player. Recently, #71906 has made the
escape sequence more forgiving as well as more interesting by
conditionally doubling the playing field. The area outside the shuttle
is still mostly empty though, except for the few people being spaced,
daredevils and the occasional epic space fight.
This PR adds adds some space events to spice up the outside of the
shuttle! This both gives people something too look at, making the escape
sequence feel less static and more lively, as well as give people a
reason to go outside and get the full experience of ~being decapitated
by a meteor~ swimming with the fishes!
<details>
<summary>Shuttle Events</summary>
**Friendly carp swarm**
Spawns a group of carp that flies past the shuttle, completely friendly
unless provoked.
**Friendly meteors**
Spawns a lot of strong meteors, but they all miss the shuttle.
Completely safe as long as you don't go EVA
**Maintenance debris**
Picks random stuff from the maintenance spawn pool and throws it at the
shuttle. Completely benign, unless you get hit in the head by a toolbox.
Could get you some cool stuff though!
**Dust storm**
Spawns a bunch of dust meteors. Has a rare chance to hit the shuttle,
doing minimal damage but can damage windows and might need inflight
maintenance
**Alien queen**
One in every 250 escapes. Spawns a player controlled alien queen and a
ripley mech. RIP AND TEAR!! Really not that dangerous when you realize
the entire crew is on the shuttle and the queen is fat as fuck, but can
still be fun to throw people around a bit before being torn to shreds.
**ANGRY CARP**
Once in every 500 escapes. Spawns 12 normal carp and 3 big carps, who
may just decide to go through the shuttle or try and bust through the
window if you look at them wrong. Somewhat dangerous, you could stay
away from the windows and try to hide, or more likely shoot at them and
weld the windows
**Fake TTV**
Lol
**Italian Storm**
Once in every 2000 rounds. Throws pasta, pizza and meatballs at the
shuttle. Definitely not me going off the rails with a testing event
**Player controlled carp trio**
Once in every 100 escapes. Spawns three player controlled carp to harass
the shuttle. May rarely be a magicarp, megacarp or chaos carp. I can't
honestly see them do anything other than be annoying for 3 seconds and
die
There are some other admin only ones: a group of passive carps going
directly through the shuttle and just being little shits, and a magic
carp swarm
</details>
Events are selected seperately, there isn't a crazy weighting system,
each just has a chance to run, and multiple could run at once. They also
don't immediately trigger, so people can get settled a bit, and to make
sure just waiting out the more dangerous ones is still a valid strategy.
## Changelog
🆑
add: Adds shuttle events! If shuttle escapes weren't exciting before
(doubtful), they definitely are now! I'm joking it's mostly an
atmosphere thing.
admin: Adds an admin panel to interact with shuttle events, under the
Events tab: Change Shuttle Events
fix: Objects spawned in hyperspace will properly catch hyperspace drift
/🆑
There's a few things I'd like to do later (another PR) (honestly anyone
can do them because I suck at follow-ups), because this is too big as
is:
- Hijack triggered shuttle events
- More events (got a lot of cool suggestions, but I'm putting most of
them on hold)
- Maybe stration announcements if some more dangerous ones get added
- Structures appearing next to the escape shuttle???
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Removes the /brig red plastitanium shuttle floor, replaces the checks
related to it with checking if the area is the shuttle brig
From what I checked in vscode, all the shuttles that use this floor
already also have the shuttle brig area on the same tiles so it changes
nothing (and might even fix things if shuttles don't use this floor type
for their shuttle brig)
## Why It's Good For The Game
Why the fuck are we checking for a TURF
## Changelog
Not player facing
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.
## About The Pull Request
Hey there,
This took a while to do, but here's the gist:
Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.
Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.
Scenarios this PR corrects:
* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*
(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game
If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).
Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.
I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.
(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
## About The Pull Request
Tram was missing its syndicate docking port, so while the Syndicate
Infiltrator could use their station locked advanced navigational console
to get to the station, the Starfury's Corvette and fighters could not do
such a thing, as they defaulted to gaze upon the areas around the
Starfury, and could not swap the camera view to the station z level, due
to this missing port.
In addition, I noticed that the same values have been copy pasted on all
stations, so I have decided to create some new docking port subtypes,
one generic nearby the station (though no shuttles use it as of now),
and one for northwest of the station (used by meta, kilo, and now,
Tram), and one for northeast of station (used by delta and icebox).
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
When the traitor does enough tasks to summon the battlecruiser, the
backup and extraction should arrive on every station.
Closes#72204Closes#73441
## Changelog
🆑
fix: The Starfury's Corvette and Fighters can now visit Tramstation
/🆑
## About The Pull Request
Fixes#72240
So, in the past, `onCentCom` ran a check at the end that said "if we're
on centcom z, in centcom area, or in shuttle that is endgame launched:
return TRUE"
Meanwhile its brother `onSyndieBase` did not need to run the same
checks, because it was also on the centcom z-level.
This meant that for the purposes of `considered_escaped`, `onCentCom`
pretty much entirely eclipsed `onSyndieBase`, only mattering for, well,
Nuke Ops
So the fix was simple - add the check for "in shuttle that is engame
launched" to `onSyndieBase`.
I took this opportunity to do a quick audit of associated "escaped" and
"alive" code. Did you know that hardcore random only checked that you
were on centcom to award survival points? Instead of any other checks
for escaped like stat?
Also the ancient "romerol zombies can't be used as an easy way to
greentext escape" was broken, because it checked the wrong species ID?
Bonus performance optimization: `in area` -> `in
area.get_contained_turfs()`
## Why It's Good For The Game
Hijack does not turn around to become an L
## Changelog
🆑 Melbert
fix: Hijacked shuttles now count as "escaping alive" once agian
fix: Hardcore random survival now actually checks that you've escaped
alive, and not just made it to centcom
fix: Intelligent zombies can now escape.
fix: Infectious zombies now don't count as escaped as intended.
/🆑
## About The Pull Request
Ever since dynamic shuttle dock size calculation, escape pods failed to
select the random lavaland/icemoon docking ports as a valid target, as
those ports had no shuttle attached to them, and thus, their dimensions
were stuck at 0. This PR makes permits these to be always a valid
target, similar to hyperspace transit docking ports.
Also, the various pods connected to the pod computer multiple times.
Each of them has added pod_lavaland as its valid destination lists, and
then when the escape pod port's id got updated with a counter to ensure
a unique ID, they have added pod_[counter]_lavaland to its destination.
This meant that every pod past the first had a dropdown, so they could
select which destination they could land at, instead of just the one
intended for solely them. This is also fixed.
Also autodocs two vars, and replaces some single letter vars.
## Why It's Good For The Game
fixes#72966
## Changelog
🆑
fix: emagged/delta pods properly fly to lavaland
/🆑
## About The Pull Request
Adds automatic cordoning to block reservations.
Also fixes an issue where ChangeTurf would cause SSicon_smoothing to
throw runtimes by calling QUEUE_SMOOTH regardless of initialization
completion
## Why It's Good For The Game
## Changelog
---------
Signed-off-by: GitHub <noreply@github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
It's the season of giving and so here at Nanotrasen we've partnered with
a new supplier in order to create a limited run of Luxury Escape Pods.
These larger, carpeted pods with extra windows and smoother, quieter
engines will be rolling out soon to stations who do particularly well on
their quarterly earnings reports!
<details>
<summary>Redact Before Sending</summary>
Of course, that funding had to come from somewhere. Stations with a
particularly poor performance may have to settle for the budget option
until results improve.
</details>
In order to facilitate station traits modifying escape pods, I made a
subtype of stationary shuttle dock specifically for escape pods.
There is a map update script which will replace existing pod docks with
the new one, it also cuts down on some map var edits.
I was worried that varying the pod size would cause problems but it
actually went surprisingly smoothly, only Kilo had a couple of plating
turfs in the way. This might cause problems for maps in development
though, if they are relying on escape pods being a _very_ specific size.
## Why It's Good For The Game
I just think it's neat.
But more station traits = more variance between rounds = more fun, I
guess?
Varying how large escape pods might be can create interesting dilemmas
between crew about how to fit into them, at least about how tall they
need to make the pile of prone people.
The escape pod dock subtype might help out newer mappers a little bit,
as it means fewer var edits to copy/paste from other maps.
## Changelog
🆑
add: New station traits can vary how large and comfortable the station
escape pods are.
/🆑
Adds some new procs relating to baseturfs that replaces some code that
reads and sets them directly. Moves them to their own file. **To
reviewers: Any proc in baseturfs.dm that is snake_case is mine, anything
else is just moved**.
Adds tests for the existing procs of baseturfs.
I'm going to be doing some optimizations to baseturfs that change the
actual representation of baseturfs, and so I'm prepping these to be
implementation agnostic.
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Adds the ability to calculate the information during runtime by
iterating through the shuttle areas; which essentially means that you
now have the ability to shrink/expand shuttles. A front end for doing
this has not been implemented in this PR, however this means that in the
future doing so would be as simple as adding the new area into the
shuttle_areas list on the docking port and then calling
`calculate_docking_port_information` on the docking port.
## About The Pull Request
Area contents isn't a real list, instead it involves filtering
everything in world
This is slow, and something we should have better support for.
So instead, lets manage a list of turfs inside our area. This is simple,
since we already move turfs by area contents anyway
This should speed up the uses I've found, and opens us up to using this
pattern more often, which should make dev work easier.
By nature this is a tad fragile, so I've added a unit test to double
check my work
Rather then instantly removing turfs from the contained_turfs list, we
enter them into a list of turfs to pull out, later.
Then we just use a getter for contained_turfs rather then a var read
This means we don't need to generate a lot of usage off removing turf by
turf from space, and can instead do it only when we need to
I've added a subsystem to manage this process as well, to ensure we
don't get any out of memory errors. It goes entry by entry, ensuring we
get no overtime.
This allows me to keep things like space clean, while keeping high
amounts of usage on a sepearate subsystem when convienient
As a part of this goal of keeping space's churn as low as possible, I've
setup code to ensure we do not add turfs to areas during a z level
increment adjacent mapload. this saves a LOT of time, but is a tad
messy
I've expanded where we use contained_turfs, including into some cases
that filter for objects in areas. need to see if this is sane or not.
Builds sortedAreas on demand, caching until we mark the cache as
violated
It's faster, and it also has the same behavior
I'm not posting speed changes cause frankly they're gonna be a bit
scattered and I'm scared to.
@Mothblocks if you'd like I can look into it. I think it'll pay for
itself just off `reg_in_areas_in_z` (I looked into it. it's really hard
to tell, sometimes it's a bit slower (0.7), sometimes it's 2 seconds
(0.5 if you use the old master figure) faster. life is pain.)
## Why It's Good For The Game
Less stupid, more flexible, more speed
Co-authored-by: san7890 <the@san7890.com>
* Makes engines machines instead of structures
* Updates the maps
* Fixes boards and anchoring
* Removes 2 unused engine types
Router was actually used a total of once, so I just replaced it with propulsion.
I think cutting down on these useless engine types that make no difference in-game would be a nice first step to adding more functionalities to them.
* Don't use power (since shuttles dont have)
Shuttles don't have APCs, instead they just have infinite power, so I'm removing their power usage for now. I'm hoping this can be removed when unique mechanics are added to engines, because I would like them to make use of power like other machines.
* re-organizes vars
* deletes deleted dm file
* Slightly improves cargo selling code
* Renames the updatepaths
* Removes in_wall engines
I hate this stupid engine it sucks it's useless it's used solely for the tram it provides nothing of benefit to the server
replaces them with regular engines
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
About The Pull Request
Currently there are a bunch of snowflake checks on the mining shuttle console's attack_hand proc, including a check for TRAIT_ILLITERATE which is hardcoded to specific destinations and is causing issues with the public lavaland shuttle in #69641. When I started looking at that issue I realized that this should all probably be done in ui_interact() instead, and also that checking specifically for TRAIT_ILLITERATE when there's a proc for this (can_read) makes little sense. So I moved it all to ui_interact and cleaned up the TRAIT_ILLITERATE check. I also moved some code related to getting the list of destinations of shuttle consoles into a proc which is shared between the ui_data proc and the can_read check.
Now any illiterate mob which isn't otherwise blocked from interacting (such as monkies, ash lizards, and humans with a quirk) which interact with the shuttle console will spend 10 seconds "randomly mashing buttons" before sending it to a random valid destination. This is (essentially) the current behavior for humans with illiteracy and was (per @timothymtorres ) the intended behavior for ash lizards when he added the illiteracy quirk to begin with in #66648. I'm just making it less snowflakey and I guess technically adding it to monkies too since they could also use the shuttle before that PR and it doesn't make sense to exclude them arbitrarily.
Why It's Good For The Game
Fixes#69641
Generally makes the code more standardized, attack_hand checks are legacy from before ui interact was unified into can_interact and ui_interact. Making the code apply to all shuttle consoles and randomly pick a valid destination makes the more maintainable and less prone to random issues than a hardcoded list.
Also makes the other existing checks more consistent, for example the labor shuttle will now also warn rev heads, block free golems, and let illiterates move them just like the mining and public lavaland shuttles do.
Changelog
cl VexingRaven
fix: The illiteracy quirk will no longer break the mining shuttle
refactor: Refactored some checks on the shuttle console to apply to all consoles
/cl
* Fixes emergency pods not working
* ``get_control_console()`` currently doesn't work because it's runtiming instead of properly finding the shuttle computer, which would cause pod's request() to return and call parent, but parent handles sending the pods off, so I fixed it by not calling parent if they didn't have a console, and also fixed it finding its console.
* wtf emagged shuttles can just go?
* replaces || with &&
current_engines and initial_engines were actually their thrust power, which I was unaware of because of undocumented vars.
I renamed the, documented them, and fixed them.
* A lot of shuttle code improvements
* Makes use of ``as anything`` in many places
* Adds mapload to connect_to_shuttle()
* Renames many vars, including shuttle 'id' var to 'shuttle_id' and engine 'state' to 'engine_state'.
* Engines now weakref their attached ship, and disconnect when unwrenched from it.
* Removes check for force when deleting a mobile docking port, being deleted should still clear your stuff, regardless of being forced.
Because of all the above, I was able to remove a few pointless checks scattered around, like engine's alter_engine_power()
* better comment for port_id
* Fixes Cargo, Arrivals, and Pirate ships.
* Merge branch 'master' into shuttlecode-oh-no
* last few
* fixes the CI
* fixes
* Fixes infinite engines
* Revert "Merge branch 'master' into shuttlecode-oh-no"
This reverts commit 94eba37de9fe3f4a01dc40bb064771b764f379e3.
* trammies
* whiteship tram
* Makes use of ?. instead
apparently this is what weakrefs use, so 🤷
* i hate supernovaa41
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* removes lateinit that I never implemented
* adds _ref to weakref var name
* small change to weld time define
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
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
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.
bring code up to latest standards, move many procs to named files inside _HELPERS
no idea where to put some of these procs, help is appreciated
made more files to contain some unique code, deleted unsorted.dm, we can rest now
## About The Pull Request
stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it
for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload
## Regex used:
procs without args, not even regex
`/Initialize()`
procs with args
`\/Initialize\((?!mapload)((.)*\w)?`
cleanup of things i didn't want to mapload:
`\/datum\/(.)*\/Initialize\(mapload`
fixes#60197
woke up today with a ridiculous idea of semi-automatic compile time loop unrolling, wasnt worth the complexity in the least but it made the basis of this PR which i then continued work on. makes area_sensitive_contents into a more general system of important_recursive_contents where we can define reasonable uses to replace recursive contents iteration of the type found in get_hearers_in_view() as long as everything that uses it isnt something incredibly common to the point that it noticeably increases memory usage.
Sourced from #59118 and a cursed project I'll pr later, This pr contains a lot of harddel fixes for stuff that pops up after a player interacts with something. I'm not gonna list them all here because there's something like 60 130, check the commit log if you're curious
Oh and I moved ref tracking screaming to a separate define, and made some optimizations to the thing in general. I think that's it, this pr is a bit of a frankenstine
extends the tile reskinning functionality to iron, bronze, plastitanium, carpet and pod floors
makes a bit of tile code better
moves some paths around, like elevator shafts being plating instead of floor
adds rotating as a tile reskinning function available on chapel or side floors for example
lets players customize any rooms they would want much more than it is possible now, allowing for more creativity
## About The Pull Request
Changes up some layer and plane defines for no particular reason lol
## Why It's Good For The Game
Planes actually override layers, and layers control ordering within planes. A lot of the usage of plane and layer was wholly unnecessary. This refactor helps future maintainability while also being needed staging for _future features._
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>
imo; the ss13 audio-scape is quite barren, you can only hear most things if you can see them, which in my opinion doesn't make much sense. This changes that so you can hear further away, but falloff is much higher, so in reality you will only hear things relatively quietly when they're out of sight.
This PR increases the hearing distance of most sound by 9, excluding sounds such as antag items that are meant to be used stealthily
This PR also replaces Byond's inbuilt falloff system with something I made, (And thanks to potato for helping me throw together a formula for it). This fall-off system makes sound fall off more naturally, with sounds being full volume within a certain range, and then softly falling off until they are completely quiet. This makes for a smoother transition between "This sound is full volume" and "I dont hear this sound".
Co-authored-by: ff <ff>
Fix lavaland podding
Make lavaland pod destinations hidden
Removed unused variables from connect_to_shuttle() proc
Shuttle consoles remove old custom port id from possible destinations when connects to new shuttle
Custom ports keeps clear from unwanted numbers.
Now shuttle machinery property connects to additional loaded shuttles.
Add some docking_port register logging and safety.
