## About The Pull Request
Using these search regexes:
Ending in 0:
`addtimer\((.*),\s?(\d{1,3})0\b\)`
replacement:
`addtimer($1, $2 SECONDS)`
Two digit ending in odd:
`addtimer\((.*), (\d)([1-9])\)$`
replacement:
`addtimer($1, $2.$3 SECONDS)`
Single digit ending odd:
`addtimer\((.*), ([1-9])\)$`
replacement:
`addtimer($1, 0.$2 SECONDS)`
## Why It's Good For The Game
Code readability
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
While on the floor, you can:
- Use the UIs of Atmos machinery (except thermomachine and bluespace gas
vendor), Holopads, Crayons (spray cans too), radios, and Disposal bins
- Close extinguisher cabinets with Right-Click
- Click and drag yourself onto a photocopier to climb onto it.
I also changed all instances of ``ui_status`` to have all the args it's
being passed, I was messing with it a bit but it's gonna be for a later
PR.
## Why It's Good For The Game
It's an extra layer of harmless realism, also nice QoL for people who do
not have functional legs and do not have a wheelchair.
## Changelog
🆑
qol: You can use atmos machines, holopads, crayons, spray cans, and
disposal bins while floored.
fix: You can close extinguisher cabinets while floored.
fix: You can climb onto a photocopier from the floor.
/🆑
## About The Pull Request
Situation: areas have a list of all turfs in their area.
Problem: `/area/space` is an area and has a 6 to 7 digit count of turfs
that has to be traversed for every turf we need to remove from it. This
can take multiple byond ticks just to preform this action for a single
space rune
Solution: split the list by zlevel, and only search the right zlevel
list when removing turfs from areas.
replaces `area.get_contained_turfs()` with a few new procs:
* `get_highest_zlevel()` - returns the highest zlevel the area contains
turfs in. useful for use with `get_turfs_by_zlevel`
* `get_turfs_by_zlevel(zlevel)` - returns a list of turfs in the area in
a given zlevel. Useful for code that only cares about a specific zlevel
or changes behavior based on zlevel like lighting init.
* `get_turfs_from_all_zlevels()` - the replacement for
`get_contained_turfs()`, renamed as such so anybody copying/cargo
culting code gets a hint that a zlevel specific version might exist.
Still used in for loops that type checked so byond would do that all at
once
* `get_zlevel_turf_lists()` - returns the area's zlevel lists of lists
but only for non-empty zlevels. very useful for for loops.
The area contents unit test has been rewritten to ensure any improper
data triggers failures or runtimes by not having it use the helpers
above (some of which ensure a list is always returned) and access the
lists directly.
This ports a whole bunch of various PRs and commits from
https://github.com/effigy-se/effigy-se , with heavy refactoring to keep
it fresh for /tg/'s code standards.
## About The Pull Request
The whole slew of announcement touchups lately (as in #78995
(37db1ecbf8) / #79052
(12308dbd3d)) have made me realize how
much this stuff sucks. The author of these new spans was advertising
these in coding general, so I sat down and coded it. Look at the spans,
they're much nicer than what we had going on:
(ignore the capitalized alert status names, this was removed)
<details>
<summary>Dark Mode</summary>


</details>
<details>
<summary>Light Mode</summary>


</details>
This PR also features
* Major announcement code handling cleanup and refactor! There was a lot
of copypasta so let's distill it all down into one proc
* Better cacheing! We were doing a shit load of new string generation
needlessly! That's fixed now.
* Better string concatenation! Lists are better for string tree reasons.
It still works just as well, as you can see from the screenshots above.
Best of all, no fucking `<br>` dogshit everywhere!
* We don't use string equivalency in order to figure out the "type" of
an announcement. It's all defines now. This was a bonus that I just
coded in since it irritated me.
* Minor spellcheck of "announcement".
* All of our HTML string mangling stuff is now all span macros! I love
macros.
## Why It's Good For The Game
In the same vein of adding examine blocks (#67937
(b864589522)) because old examinations
tended to blend in with the chat and everything chat-wise used to suck
really hard- I think this is a really nice way to draw attention to
announcements in the chat box without needing a shit load of line breaks
that just really look ugly and have no real consistency. You can look at
the PRs/commits I linked above for an idea of just how ugly it could be
getting.
I haven't audited every announcement in this PR, we can tweak this down
the line.
## Changelog
🆑 LT3, san7890
add: Announcements have gotten a fresh coat of paint! They should be
popping with splendid new colors and should have a lot less ugly
linebreaks, while still managing to keep your attention at the screen.
/🆑
I know we didn't need to port all the CSS themes but I added them
anyways in case admins wanna have some fun.
There can probably be more code improvements, just figured I'd crack it
out while I had time.
The colors also seem fine, let me know if we need more redness or
something. It's okay for stuff to be toned down a bit imo, but that
should be done after a hot second.
---------
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
## About The Pull Request
Places "setting up being able to use hands" into an element so it can be
easily applied to non-carbon mobs.
## Why It's Good For The Game
This is one of the last roadblocks for basic mob implementation and
people were intimidated by it but it turns out this shit is easy, 90% of
this code is already just on `living` and I put a little bit more there.
The element _really_ only handles stuff like dropping items on death,
picking things up rather than biting them, and adding examine text.
This also removes some copy/pasted code between `simple_animal` and
`carbon` and unifies some behaviours which were implemented for some
dextrous simple animals but not others.
Changes to give Ian a single hand representing his mouth will come at a
later date.
## Changelog
🆑
qol: You can now see what drones and gorillas are holding by examining
them.
admin: It's now easier to give handless mobs hands by applying the
"dextrous" element.
balance: Spiders and Bears can now climb railings (you know if... they'd
rather do that than destroy them).
/🆑
## 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
**Simplified version of #72179**
### SOUNDS
Changes next sound files:
- airraid.ogg
- bloblarm.ogg
- alert.ogg
Adds next sound files:
- notice3.ogg
- announce_syndi.ogg
Now `announce.ogg` plays when a Captain joins round, and
`announce_dig.ogg` for Requests Console announcements.
The `announce_syndi.ogg` plays when an announcement is made through an
emagged communications console. It also plays when the evacuation
shuttle is fully hijacked or Cultists fully corrupt the evacuation
shuttle.
You can listen to them all here:
https://github.com/tgstation/tgstation/assets/42353186/10c5e597-6db7-464a-b693-f5a2672dc3d0
_All of the sound files are either made by me from existing sounds in
the game or taken from freesound.org and properly credited._
### STATUS DISPLAYS
Status displays are fully replaced with the addition of a few new ones.
<details>
<summary>Status display monitor</summary>


</details>
<details>
<summary>Misc displays</summary>



</details>
<details>
<summary>Alert displays</summary>




</details>
Now the communications console Status Display menu replaced the "Red
Alert" display option with the "Current Alert" which showcases the
current alert display.
Also, the Status Display menu has an additional "Radiation" display
option.
## Why It's Good For The Game
I believe this Pull Request is a good game for a couple of reasons:
1. It better conveys the gravity of emergency situations, such as Code
Red, by utilizing a more intimidating and recognizable sound. This gives
more weight to these situations, making them feel more urgent and
important in the game. Players always tend to not notice that it's in
action.
2. The replacement of the old and outdated Status Display sprites with
newer, more eye-catching ones is a great improvement. This helps to
emphasize the importance of emergency situations even further by making
them more noticeable. Status Displays was one of the last wall-mounts
using ancient sprites.
3. The Captain's arrival using another sound effect from other
announcements gives more status to the Captain as the ultimate head of
the station.
4. Heads announcement using `announce_dig.ogg` makes the sound itself
more used outside of SM cascade, and also makes Head announcements more
noticeable.
5. Emagged console using `announce_syndi.ogg` making Traitor
announcements more noticeable. Also, it is played after evac shuttle is
fully hijacked or corrupted by Cultists giving a more ominous effect
## Changelog
🆑
sound: Adds/modifies next sound files: airraid.ogg, bloblarm.ogg,
alert.ogg, notice3.ogg, announce_syndi.ogg
sound: Code Red, Delta, and other extreme emergencies now possess more
unique alarm sound effect
sound: Captain's arrival now is announced by Captain's announcement
sound, but not for Acting Captain's
sound: Making Captain announcement through emagged console; hijacking or
fully corrupting evacuation shuttle now plays more ominous sound
sound: Making announcements through Requests Console now plays a more
noticeable sound
image: Status Displays sprites have been fully changed. Now they include
displays for every Security Level
qol: The "Red Alert" button in the Communications console status display
menu has been replaced with a "Current Alert" button showing the current
station Security Level display on Status Displays
qol: Communications console status display menu got a new "Radiation"
button which shows radiation symbol on Status Displays
/🆑
## About The Pull Request
You shouldn't ever qdel a callback. If you don't want to own it free
your ref (remove it from a list/set it to null). When all refs are
cleared it'll get cleaned up by byond itself
## About The Pull Request
Further continous organizing and cleaning the Icons folder. There are
still some minior nitpicks left to do, but I reached my daily sanity
expenses limit again, and the faster these get in the less issues for
both me and others later. Also cleans some mess I caused by my blindness
last PR.
## Why It's Good For The Game
Saner spriters = better sprites
## About The Pull Request
HackMD for this can be found here:
https://hackmd.io/VEbjO1kaQJarao4KqGfzgw?view
Basically, this gives the first Janitor an access key that they can use
to enter departments. This requires a Head of Staff to approve it
through the keycard authenticator, and only holds one department at a
time, and will clear itself out after 10 minutes.
This gives departmental AA, including the head of staff's office, adding
a tradeoff.
The Janitor is alerted when access is given to their key (as their
keyring will say such) and everyone can see janitors trying to open a
door when they use it (with a cool sound, too).
You can't bump open airlocks with it, I limited it to directly using it
on the door, because I thought it made it feel more realistic to a
keyring.
I had an earlier version of this that gave the key it's own access,
which allowed bumping open, but it also allowed things like locking RD
consoles, and I dunno how strong I want this key to be.
I also wanted to limit how easy this is to greytide/steal, currently
only the first Janitor spawns with the key. I thought it would be too
easy to exploit otherwise, or essentially stolen roundstart if there
were no Janitors. Maybe this can also fit as a Traitor objective after
melon's new objective PR is done?
### Minor detail
While adding icons, I realized inhands don't actually set its icon state
to the default if it's null, so I removed that LYING comment.
## Why It's Good For The Game


Alternatively, https://youtu.be/dlkSbQ-IkRM?t=182 (timestamp)
## Changelog
🆑 JohnFulpWillard, sprites by BalkyGoat
add: The Janitor Access key: Janitors can now be given departmental AA
(one at a time) using the Keycard authentication device in Command
offices. Use it if you need cleaning!
fix: HoP's trim is no longer set to edit Supply access.
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## 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>
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
replaces a ton of log_game with user.log_message so the log is added to individual and global logs.
adds a few logs for individual LOG_VICTIM, LOG_ATTACK etc logging.
adds logging for bluespace launchpad's tele coords being changed.
took the word "has" out of log_combat, as it's extra and just lengthens the log.
Why It's Good For The Admins
It's extremely laggy to open game.txt so an alternative is individual game logs
Changelog
cl
admin: A lot of game logs will now also be in individual game logs, for convenience in log diving.
admin: Added logging for bluespace launchpad x and y offset changes, which go to individual game logs.
admin: Attack logs will now be slightly shorter, one useless word was removed.
/cl
* Fixes security level sounds not playing.
- The sound var was never set, turns out it used the default announcement sounds for alert or no alert.
* Documentation tweak
* Thank you san
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: san7890 <the@san7890.com>
Areas.dmi right now houses all of our mapped turfs icons (which is roughly 400 icons). Not an issue, but it's incredibly large and clunky to navigate right now. This isn't an issue for the average coder and/or player code diving, but it is for mappers wanting to add new turfs. Currently, the file has some organization, but its still an overall mess. This PR aims to slice the behemoth with multiple .dmi files corresponding to specific areas.
I also plan to repath /area/* -> /area/station/* for station turf only. This is to clean it up, as most other turfs follow this format (that being /area/turf_zone/*).
I'm also writing an update paths file as I go along.
This removes code/__DEFINES/misc.dm and moves all the defines to either:
another existing define file
new define file
local .dm file if the define was only used in one file
I also deleted defines that were not being used and added documentation to all of the ones that were moved out of misc.dm
Why was this needed? People were basically using the misc.dm file as a dumpster to toss all their defines into that was creating one giant mess. The defines have been organized into their proper groups and files now.
About The Pull Request
Wall items mostly use the direction from the floor to the wall in the named mapping helper. Wall items mostly use the direction from the wall to the floor for the internal dir variable.
This leads to a headache when it comes to working out what conflicts with what, and what needs placing where.
Wall frames provided a member, inverse, which specified whether or not to invert the direction of the item when looking for conflicts. It was also used to specify whether to look for conflicts outside of the wall (cameras and lights appear external to the wall) or inside the wall (most wall items). This flag was set for Intercoms, APCs, and Lights. Since APCs and Lights expect a floor-to-wall direction, and Intercoms expect a wall-to-floor direction, this means that APCs and Lights were getting the correct direction, and Intercoms were getting the wrong direction.
Some implications of this setup were:
You could build an APC on top of another wall item, provided there was nothing external attached to the wall and the area didn't have an APC.
You could stack Intercoms indefinitely on top of the same wall, provided you weren't in a one-tile wide corridor with something on the opposite wall.
Or both! Here's twenty Intercoms placed on the wall, and a freshly placed APC frame after placing all Intercoms and deconstructing the old APC:
endless-stack-of-intercoms
Not everything used this inverse variable to adjust to the correct direction. For example, /obj/machinery/defibrillator_mount just used a negative pixel_offset to be visually placed in the correct direction, even though the internal direction was wrong, and never set! This also let you stack an indefinite number of defib mounts on the same wall, provided it wasn't a northern wall... except you could do this to northern walls too, since defibs weren't considered a wall item for the purposes of checking collisions at all!
Ultimately, every constructable interior wall item either used this inverse variable to adjust to the correct placement, set a negative pixel_offset variable to have its offset adjusted to the correct placement, or overrode New or Initialize to run its own checks and assignment to pixel_x and pixel_y!
Inventory: Table of various paths, related paths, and the adjustments they used
Unfortunately, untangling /obj/structure/sign is going to be another major headache, and this has already exploded in scope enough already, so we can't get rid of the get_turf_pixel call just yet. This also doesn't fix problems with the special 2x1 /obj/structure/sign/barsign.
Some non-wall items have been made to use the new MAPPING_DIRECTIONAL_HELPERS as part of the directional cleanup.
tl;dr: All wall mounted items and some directional objects now use the same direction that they were labelled as. More consistent directional types everywhere.
Why It's Good For The Game
fml
Changelog
cl
refactor: Wall mounted and directional objects have undergone major internal simplification. Please report anything unusual!
fix: You can no longer stack an indefinite amount of Intercoms on the same wall.
fix: Defibrillator Mounts, Bluespace Gas Vendors, Turret Controlers, and Ticket Machines are now considered wall items.
fix: Wall mounted items on top of the wall now consistently check against other items on top of the wall, and items coming out of the wall now consistently check against other items coming out of the wall.
fix: The various directional pixel offsets within an APC, Fire Extinguisher Cabinet, Intercom, or Newscaster have been made consistent with each other.
fix: The pixel offsets of Intercoms, Fire Alarms, Fire Extinguisher Cabinets, Flashers, and Newscasters have been made consistent between roundstart and constructed instances.
fix: Constructed Turret Controls will no longer oddly overhang the wall they were placed on.
qol: Defibrillator mounts now better indicate which side of the wall they are on.
fix: Some instances where there were multiple identical lights on the same tile have been fixed to only have one.
/cl
## 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`
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)
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
All ui_act procs should call parent by default. All procs should preserve the value of the parent proc when it's TRUTHY and pass it down the call stack. No UI should be interactible when its flags or state indicate it should not be, except when explicity overriden by child procs intentionally disregarding parent return values to achieve a specific goal.
This PR improves options for admin controlled shuttles - all shuttle controls can be admin-locked, and players must request authorization so the shuttle can move or for controls to unlock. Before this PR, authorization request always redirected admin staff to control the CentCom ferry, even if request came from a shuttle elsewhere, which was a little odd.
Authorization request will now properly prompt the staff to control that specific shuttle, and now they also have quick option to unlock/lock the shuttle. Could come handy in events to restrict player movement.
Last change, escape pods no longer start as admin controlled, as they cannot be launched without atleast code red anyway. They instead properly state they are just locked.
Replaces like 70-80% of 0 and such, as a side effect cleaned up a bunch of returns
Edit: Most left out ones are in mecha which should be done in mecha refactor already
Oh my look how clean it is
Co-authored-by: TiviPlus <TiviPlus>
Co-authored-by: Couls <coul422@gmail.com>
About The Pull Request
/area/proc/usage() attempts to give list-like access to a bunch of vars. Why not make it a list instead and avoid all the proc calls? Might be room for followup here, to do something to powered(), use_power() etc.
Some legacy machinery was ignoring the default machinery use_power pulling from the machine's power channel by default
Total power usage was unused, APCs ignored it in favor of calculating it themselves :)
I also renamed the defines because they were in the danger zone of being very common words.
Changelog
cl Naksu
code: optimized area power usage calculations.
/cl
* De-linkifies names in deadchat_broadcast(), makes deadsay css class default too
* Makes the source argument come after message, since it is optional
* Removes excess </span>
More deadchat messages now follow the following format.
> George Mellons has done a thing at AreaName.
- Shuttle calling
- Shuttle recalling
- Security level changing
- Maintenance accessing
- Swiping for red,emergency maint, bsa
- Messenging centcom, syndicate
Fixes#34230.
Fixes#34231.
* wip
* wip2
* makes code actually compile on 511 + fixes
* versioning
* s
* adds python conversion script, schema change and removes 'force ' from item_used_for_combat
* fix to compile
* forgot to actually commit this
* Configuration datum refactor
* More WIP
* New easier on the eyes format
* More WIP
* Finished config.txt
* Fucktons more WIP
* The end of conversion draws near...
* Add all this shit
* Done converting entries finally
* Hunting down compile errors
* More WIP
* MORE CONVERSIONS
* More WIP
* More WIP
* Oh shit only 90 errors this time!
* IT COMPILES!!!
* Fixes world start runtimes
* Makes Station Z Levels a global list
* Things didnt get committed
* Define
* Removes files
* Fix mind.dm
* Wrong list name
* (
* Fixes rev checks and signpost
* Makes it actually compile
* Signpost fix
* I hate these sign posts
* Never use the web editor