* Wait for db queries to finish during db shutdown (#77311)
* Try waiting for db queries to finish during db shutdown
---------
Co-authored-by: oranges <email@oranges.net.nz>
* Adds a system for logging metadata about hard deletes (#76956)
## About The Pull Request
I'm sick of the progress bar harddel, and I've ran into this problem in
the past, so I'm just gonna do something about it
If you want to provide an individual logged bit of info about a harddel,
you can override `/datum/proc/dump_harddel_info()` and return a string
containing "whatever"
Use of this should be limited, this could potentially clutter del logs,
especially if it's used on something that fails often, like pipes
I do think it's still useful tho. It's output ingame, in the logs, and
in unit test failures. Hopefully all nicely tho I'm only really 100%
sure about in game.
* Adds a system for logging metadata about hard deletes
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Add "Hall of Fame" emergency shuttle (#77074)
## About The Pull Request
This adds a new emergency shuttle called the **Hall of Fame**.
It's designed around persistence. The goal is to have the shuttle store
memories, photos, and trophies for the crew to see!
## Why It's Good For The Game
Cool way for the crew to store and share memories.
## Changelog
🆑
add: Add a new 'Hall of Fame' emergency shuttle. It even comes with it's
own nifty photo album.
/🆑
* Add "Hall of Fame" emergency shuttle
---------
Co-authored-by: Tim <timothymtorres@gmail.com>
* [no gbp] Fixes runtime in SSstation (#77231)
No excuse, just dumb. Random layer is the randomly generated parallax
layer, which is null 30% of the time, so this would runtime in SSstation
setup in 30% of rounds
Also another thing where I added extra params and didn't add them to the
proc, fucking parallax for some roundstart clients and latejoins
🆑
fix: fixes a runtime in SSstation setup
fix: fixes parallax not rendering correctly for latejoins
/🆑
* [no gbp] Fixes runtime in SSstation
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
* Improves the RPG loot wizard event. (#77218)
## About The Pull Request
As the title says. Adds a bunch more stat changes to various different
items and a somewhat simple way of modifying them whilst minimizing
side-effects as much as possible.
Added a new negative curse of polymorph suffix that can randomly
polymorph you once you pick up the item.
Curse of hunger items won't start on items that are not on a turf.
Curse of polymorph will only activate when equipped.
Bodyparts, two-handed melees, bags, guns and grenades, to name a few,
have a bunch of type-specific stat changes depending on their quality.
Some items won't gain fantasy suffixes during the RPG loot event, like
stacks, chairs and paper, to make gamifying the stats a bit harder.
I'm sure there'll still be other ways to game the event, but it's not
that big of a deal since these are the easiest ways to game it.
High level items also have a cool unusual effect aura
## Why It's Good For The Game
Makes the RPG item event cooler. Right now, it's a bit lame since
everything only gains force value and wound bonus on attack. This makes
the statistic increases more type-based and make it interesting to use
It's okay for some items to be powerful since this is a wizard event and
a very impactful one too. By making the curse of hunger items not spawn
on people, it'll also make it a less painful event too.
## Changelog
🆑
add: Expanded the RPG loot wizard event by giving various different
items their own statistic boost.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Improves the RPG loot wizard event.
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Doubles the time you can get the "Long shift" achievement, makes it not grant on admin restarts (#77195)
## About The Pull Request
- "Long shift" can now be earned from sub 10 minute rounds rather than
sub 5 minute rounds
- Admin restarts no longer give out "Long shift"
## Why It's Good For The Game
I do not think this achievement can *possibly* be earned right now. Like
at all.
Nuke Ops and cult are the only antags that can possibly do it and it's
incredibly infeasible (requiring that they nuke the station or summon
Nar'sie in just 3 minutes!)
So I bumped up the timer to 10 minutes. This means that ops can get it
if they nuke the station in 8 minutes, cult can get it if they REALLY
speedrun, and revs can get it if they beeline the heads.
I checked the DB for stats on this achievement and it's only been earned
in 3 rounds across the last year - `208780` (admin restart due to a bug)
`192892` (admin restart due to a bug?) `186192` (admin restart).
So I also prevented admin forcing the round to end. (I don't know if it
catches admin reboots directly I'll have to check that.)
## Changelog
🆑 Melbert
balance: The "Long Shift" achievement is now feasibly obtainable, and
admins can no longer trigger it unknowingly
/🆑
* Doubles the time you can get the "Long shift" achievement, makes it not grant on admin restarts
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Adds a unit test to stop elements from using identical lists for their arguments. (#76322)
## About The Pull Request
Ok, so a few days ago I made an issue report about multiple instances of
identical elements being generated because of uncached lists.
ninjanomnom (the mind being the element datums) cleared it up and said
an implementation of GetIdFromArguments() that also checks the list
contents wouldn't be worth the performance cost, while adding that a
unit test should be written to check that it doesn't happen at least
during init, which should catch a good chunk of cases.
Also, i'm stopping RemoveElement() from initializing new elements
whenever a cached element is not found. Ideally, there should be a focus
only unit test for that too, but that's something we should tackle on a
different PR.
Some of the code comments may be a tad inaccurate, as much as I'd like
to blame drowsiness for it. Regardless, the unit test takes less than
0.2 seconds to complete on my potato so it's fairly lite.
## Why It's Good For The Game
This will close#76279.
## Changelog
No player-facing change to be logged.
* Adds a unit test to stop elements from using identical lists for their arguments.
* Fixes unit test
* seeing double
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Converting crabs to basic mobs (#77109)
## About The Pull Request
Exactly what it reads on the tin. As a bonus, they will flee from
attacking targets, hunt tiny critters (crabs are now small-sized) and
actually move sideways (it's an element that covers both client and
basic movement)
## Why It's Good For The Game
Another simple to basic mob refactor.
## Changelog
🆑
refactor: Crabs refactored into basic mobs. They now hunt tiny critters
and flee from attackers.
fix: Fixed crabs not crab-walking.
/🆑
* Converting crabs to basic mobs
* UpdatePaths
* More path changes
* Update simple_animal_freeze.dm
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* flame_range and flash_range autoset fix (#77118)
## About The Pull Request
From #27184 flame_range and flash_range should automatically default to
light_impact_range and devastation_range
4abf35e4a7/code/controllers/subsystem/explosions.dm (L285-L288)
But it was broken, probably after moving to subsystem, because now
functions set arguments to 0.
Please note I don't play tg and haven't tested this change. Fix changes
default behavior and may cause unwanted effects.
* flame_range and flash_range autoset fix
---------
Co-authored-by: Alexander V <volas@ya.ru>
* Sets a saner length limit to ID assignments and paintings' titles. (#76723)
* Sets a saner length limit to ID assignments and paintings' titles.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Adds a runtime protection check to play_tts (#77106)
## About The Pull Request
I see this stack trace on occasion
```
[2023-07-25 19:04:56.970] RUNTIME: runtime error: get_language_holder() called on a QDELing atom, this will try to re-instantiate the language holder that's about to be deleted, which is bad.
- proc name: get language holder (/atom/movable/proc/get_language_holder)
- source file: code/game/atoms_movable.dm,1458
- usr: null
- src: AdipemDragon (/mob/dead/new_player)
- src.loc: null
- call stack:
- AdipemDragon (/mob/dead/new_player): get language holder()
- Text To Speech (/datum/controller/subsystem/tts): play tts(L.E.M.O.N. (/mob/living/silicon/robot), /list (/list), /sound (/sound), /sound (/sound), /datum/language/common (/datum/language/common), 7, 0)
- Text To Speech (/datum/controller/subsystem/tts): fire(0)
- Text To Speech (/datum/controller/subsystem/tts): ignite(0)
- Master (/datum/controller/master): RunQueue()
- Master (/datum/controller/master): Loop(2)
- Master (/datum/controller/master): StartProcessing(0)
```
Evidently, the list of listeners is *somehow* getting new players or
observers that are being qdeleted (maybe hard deleting?)
That might be a little hard to track down so until then I figure it's
fine to throw in a stack trace and continue so it doesn't brick the
message for everyone else
## Why It's Good For The Game
Prevents the proc from runtiming and cancelling execution, ergo not
playing to everyone else
## Changelog
🆑 Melbert
fix: Fixes some occasions which result in TTS messages not playing
/🆑
* Adds a runtime protection check to play_tts
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Makes TTS blips/enabled into one pref (#76558)
## About The Pull Request
I actually do not know how to test this locally as I don't know how to
set TTS up, hope it works.
## Why It's Good For The Game
It's 2 buttons, one only works depending on the other, I don't think it
makes sense.
## Changelog
🆑
qol: The TTS and TTS Blips option is now one choiced preference.
/🆑
* Makes TTS blips/enabled into one pref
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Rename digital clock subsystem (#77028)
Renames digital clock subsystem to be better alongside other player
facing names
* Rename digital clock subsystem
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Fix APC related issues (#77005)
## About The Pull Request
Fixes a bunch of stuff broken by #76822, including APC control console,
malf blackout ability, shunted malf pinpointing, Admin APC recharge and
others.
## Why It's Good For The Game
Yes.
## Changelog
:cl:Thebleh
fix: Fixed several APC related issues.
/🆑
* Fix APC related issues
---------
Co-authored-by: thebleh <43266738+rdragan@users.noreply.github.com>
* [MDB IGNORE] Angled Lights & Lighting Prototyping Tool (#74365)
## About The Pull Request
Hello friends, I've been on a bit of a lighting kick recently, and I
decided I clearly do not have enough things to work on as it is.
This pr adds angle support to static lights, and a concepting/debug tool
for playing with lights on a map.
Let's start from first principles yeah?
### Why Angled Lights?
Mappers, since they can't actually see a light's effect in editor, tend
to go off gut.
That gut is based more off what "makes sense" then how things actually
work
This means they'll overplace light sources, and also they tend to treat
lights, particularly light "bars" (the bigger ones) as directional.
So you'll have two lights on either sides of a pillar, lights inside a
room with lights outside pointing out, etc.
This has annoying side effects. A lot of our map is overlit, to the
point that knocking out a light does.... pretty much nothing.
I find this sad, and would like to work to prevent it. I think dark and
dim, while it does not suit the normal game, is amazing for vibes, and I
want it to be easier to see that.
Angled lights bring how lights work more in line with how mappers expect
lights work, and avoids bleedover into rooms that shouldn't be bled
into, working towards that goal of mine.
### How Angled Lights?
This is more complex then you'd first think so we'll go step by step
Oh before we start, some catchup from the last time I touched lighting
code.
Instead of doing a lighting falloff calculation for each lighting corner
(a block that represents the resolution of our lights) in view we
instead generate cached lightsheets. These precalculate and store all
possible falloffs for x and y distances from a source.
This is very useful for angle work, since it makes it almost totally
free.
Atoms get 2 new values. light_angle and light_dir
Light angle is the angle the light uses, and light_dir is a cardinal
direction it displays in
We take these values, and inside sheetbuilding do some optional angle
work. getting the center angle, the angle of a pair of coords, and then
the delta between them.
This is then multiplied against the standard falloff formula, and job
done.
We do need some extra fenangling to make this all work nicely tho.
We currently use a pixel turf var stored on the light source to do
distance calculations.
This is the turf we pretend the light source is on for visuals, most
often used to make wall lights work nice.
The trouble is it's not very granular, and doesn't always have the
effect you might want.
So, instead of generating and storing a pixel turf to do our distance
calculations against, we store x and y offset variables.
We use them to expand our working range and sheet size to ensure things
visually make sense, and then offset any positions by them.
I've added a way for sources to have opinions on their offsets too, and
am using them for wall lights.
This ensures the angle calculations don't make the wall behind a light
fulldark, which would be silly.
### Debug Tool?
In the interest of helping with that core problem, lights being complex
to display, I've added a prototyping tool to the game.
It's locked behind mapping verbs, and works about like this.
Once the verb is activated, it iterates over all the sources in the
world (except turfs because those are kinda silly), outlining and
"freezing" them, preventing any future changes.
Then, it adds 3 buttons to the owners of a light source.
The first button toggles the light on and off, as desired.
The third allows you to move the source around, with a little targeting
icon replacing your mouse
The second tho, that's more interesting.
The second button opens a debug menu for that light
There's a lot here, let's go through it.
Bit on the left is a list of templates, which allow you to sample
existing light types (No I have no idea why the background is fullwhite,
need to work on that pre merge)
You can choose one by clicking it, and hitting the upload button.
This replaces your existing lighting values with the template's,
alongside replacing its icon and icon state so it looks right.
There are three types as of now, mostly for categorization. Bar, which
are the larger typically stronger lights, Bulb, which are well, bulbs,
and Misc which could be expanded, but currently just contains floor
lights.
Alongside that you can manually edit the power, range, color and angle
of the focused light.
I also have support for changing the direction of the light source,
since anything that uses directional lighting would also tie light dir
to it.
This isn't *always* done tho, so I should maybe find a way to edit light
dir too.
My hope is this tool will allow for better concepting of a room's
lights, and easier changing of individual object's light values to suit
the right visuals.
### Lemon No Why What
Ok so I applied angle lights to bars and bulbs, which means I am
changing the lighting of pretty much every map in the codebase.
I'm gonna uh, go check my work.
Alongside this I intend to give lighting some depth. So if there's room
to make a space warmer, or highlight light colors from other sources, I
will do that.
(Images as examples)
I also want to work on that other goal of mine, making breaking lights
matter. So I'll be doing what I can to ensure you only need to break one
light to make a meaningful change in the scene.
This is semi complicated by one light source not ever actually reaching
fullbright on its own, but we do what we must because we can.
I'm as I hope you know biased towards darker spaces, I think contrast
has vibes.
In particular I do not think strong lights really suit maintenance.
Most of what is used there are bulbs, so I'm planning on replacing most
uses with low power bulbs, to keep light impacts to rooms, alongside
reducing the amount of lights placed in the main tunnels
**If you take issue with this methodology please do so NOW**, I don't
want to have to do another pass over things.
Oh also I'm saving station maps for last since ruins are less likely to
get touched in mapping march and all.
### Misc + Finishing Thoughts
Light templates support mirroring vars off typepaths using a subtype,
which means all the templates added here do not require updating if the
source type changes somehow. I'd like to expand the template list at
some point, perhaps in future.
I've opened this as a draft to make my intentions to make my changes to
lights known, and to serve as motivation for all the map changes I need
to do.
### Farish Future
I'm unhappy with how we currently configure lights. I would like a
system that more directly matches the idea of drawing falloff curves,
along with allowing for different falloffs for different colors,
alongside extending the idea to angle falloff.
This would make out of engine lighting easier, allow for nicer looking
lights (red to pink, blue to purple, etc), and improve accessibility by
artists.
This is slightly far off, because I have other obligations and it's
kinda complicated, but I'd like to mention it cause it's one of my many
pipedreams.
## Changelog
🆑
add: Added angle lighting, applies it to most wall lights!
add: Adds a lighting prototyping tool, mappers go try it out (it's
locked behind the mapping verb)
/🆑
---------
Co-authored-by: MMMiracles <lolaccount1@ hotmail.com>
* [MDB IGNORE] Angled Lights & Lighting Prototyping Tool
* Update north_star.dmm
* Revert "Update north_star.dmm"
This reverts commit bb5b8b5a549f7edc3e23a369a147ed96bab41991.
* Updatepaths
* Update nukie_base.dmm
* Newer version of northstar with the penguins
* Update northstar_cryo.dmm
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: MMMiracles <lolaccount1@ hotmail.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Stabilizes code that flicks overlays to view/all clients (#76937)
## About The Pull Request
Rather then using images and displaying them with client.images, we can
instead simply make an object, give it the passed in image/MA's
appearance, and then vis_contents it where we want.
If you want to animate things, you can just use the atom we return from
the proc call.
This ends up costing about 25% of the best case scenario (one guy
online)
It will save more time with more users, but it also allows us to avoid
the hypersuffering that is passing GLOB.clients into the flick proc. So
I think I'm happy enough with this.
For context, here's average per call cost for flick_overlay_view() right
now.
It winds between 5e-5 and 1e-4. With these changes we should pretty
consistently hit the low end of this, because none of our work really
varies all that much.
(I was using sswardrobe for this, but it ends up being a lot slower so
like, why yaknow)
```
/atom/movable/flick_visual
New: 3.65625ms
Provide: 7.4375ms
Qdel: 9.4375ms
Stash: 9.46875ms
```
## Why It's Good For The Game
Using our tools should not make your code eat cpu time for no reason.
Hearers is expensive, iterating clients is expensive, let's not be
expensive.
* Stabilizes code that flicks overlays to view/all clients
* Not every client needs to see this
* and these could be using SECONDS
* grr DM
* Convert these modular files to seconds too
* Update dance_machine.dm
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Optimization pass focused on foam code (saves about 30% of cpu usage I think) (#76104)
## About The Pull Request
Foam is crummy at high load rn, both because it runs on a low priority
background subsystem, and because it wastes a bit of time.
Let's reduce usage (while speeding up a bunch of other stuff too), and
give it more cpu generally.
[Optimizes reagent processing
somewhat](d409bd4afc)
Turns out most of the cost of foam is the reagents it carries, and the
varying effects they have
I'm doing my best here to optimize them without touching "user space"
too much
That means doing things like prechecking if we're gonna spawn on top of
an existing decal (from glitter, flour, etc), and using that same proc
to also avoid spawning on unacceptable turfs (I had to convert
inheritance to a bitflag system to make this work, but I think that's ok
since we want it imparative anyhow)
It's actually nice for code quality too, since it lets me clean up code
that was using raw locates and weird var pong.
god I wish I had implied types man
[Optimizes foam spreading in its most accursed aspect, reagent
copying](5cc56a64ad)
Holy shit reagent code is a lot.
I'm doing a bunch of small things here. istype in init -> typecache,
removing procs that are called once and loop over a list we JUST looped
over (ph and the caching for reactions in particular)
I am mainly trying to optimize copy_to here, since that's what foam
spams
As a part of this, I removed a pair of update_total and handle_reactions
calls that were done on the reagents we are copying FROM
I have no god damn idea why you would want to do that, but if anything
is relying on the copy proc modifying the source, then that code
deserves to break
Speaking of, I cleaned up handle_reaction's main filter loop a lot,
removed a lot of redundant vars and changed it from a full loop w
tracker vars to an early exit pattern
This meant using a loop label, which is unfortunate, but this is the
fastest method, and it does end up cleaning up the code significantly,
Which is nice
Oh also I made the required_other var function even if there is no atom
attached to the reaction, since I don't see why it wouldn't
This last bit is gonna get a bit esoteric so bear with me
Failing calls (which are most of them) to handle_reactions are going to
be fastest if they need to check as few reactions as possible
One reagent in a reaction's required list is marked as the "primary",
and thus gets to trigger checking it.
We need all the reagents to react anyhow, so we might as well only check
if we have one particular one to avoid double checking
Anyhow, in order to make most calls the fastest, we want these reactions
distributed as evenly as possible across all our reagents.
The current way of doing this is just taking the first reagent in the
requirements list and using it, which is not ideal
Instead of that, lets figure out how many reactions each reagent is in,
then divy reactions up based off that and the currently divvied
reactions
This doubles the reagent index count, and takes the most common reagent,
water, from 67 reactions to I think like 22
Does some other general cleaning in reagent code too, etc etc etc
[Fixes runtimes from the forced gravity element being applied more then
once](941d067611)
I feel like this element should take a trait source or something to make
them potentially unique, it's too easy to accidentally override one with
another
[Removes connect_loc usage in atmos_sensitive, replaces it with direct
reg/unreg](de1c76029d)
I only really used it because I liked the componentization, but it costs
like 0.2 seconds off init alone which is really stupid, so let's just do
this the very slightly harder way
[Micros foam code slightly by inlining a LinkBlockedWithAccess
call](744da3694c)
This is in the space of like 0.05 seconds kinda save so I can put it
back if you'd like, the double loop just felt silly
[Changes how foam processes
slightly](ee5e633e32)
Rather then treating spreading and processing as separate actions, we do
both in sync.
This makes foam fade faster when spreading, which is good cause the
whole spread but unclearing foam thing looks silly.
It also avoids the potential bad ending of foam spreading into itself,
backwards and forwards. This is better I promise.
[Bumps fluid priority closer to heavy eaters, moves it off
background](811797f09d)
Also fixes a bug where foam would travel under public access airlocks.
## Why It's Good For The Game
Saves a lot of cpu just in general, from both init and live.
In theory makes foam faster, tho I'd have to test that on live at
highpop to see if I've actually succeeded or not. Guess we'll see.
* Optimization pass focused on foam code (saves about 30% of cpu usage I think)
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Bloop <vinylspiders@gmail.com>
Replaces lava and chasm's "safeties" and ignoring turf slowdown on catwalks with traits and a new element. (#76376)
This adds a new element for movables that grants turfs they're in
traits, changes lava and the chasm component to check for traits
instead, ditto for turf slowdown. It also implements another trait that
prevents wet floor from slipping people, as well as some other changes
(feel free to opine on them really):
- Tables and conveyor belts now stop turf slowdown, much like catwalks,
as I imagine people walking on them are not really touching the floor.
(I'd include protection against lava too... until they melt, but that'd
mean finding a way to have these objects burn in the first place, and
lava code is still stupid despite a years old refactor I did)
- Tables also stop slippery turfs from slipping (bananas, soaps etc.
still apply). I wish there were a way to make some objects slippery by
coating them in water vapor or splashing water/lube, but that's outside
the scope of this PR.
- Fixed an edge case in which a mob standing on a lava turf would be
left permanently visually on fire if the lava is changed to another kind
of turf.
- Removed unused code from stone tiles.
I'm going to include these traits in that global list for admin-added
traits... tomorrow perhaps. 💤
Replacing some hard-coded mechanics with easier to use traits and an
element, which I also need for the submerge element PR.
🆑
refactor: Replaced hardcoded "safeties" for lava, chasms and ignoring
turf slowdowns on catwalks with traits.
balance: much like catwalks, tables and conveyors also disable turf
slowdowns.
balance: slippery turfs won't slip you when walking on a table.
fix: Fixed an edge case in which a mob standing on a lava turf would be
left visually but permanently on fire if the lava is changed to another
kind of turf.
/🆑
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Macros multi-z code, removes the false premise of manual offsets (#76248)
## About The Pull Request
[Removes the pretense of relative multiz
levels](0293fdc2bd)
Our multiz system does not support having a z level that is only
connected one way, or which goes down backwards or anything like that.
That's a fiction of the trait system, the actual backend has never
really supported this.
This pr removes the assumptions we were making backend around this, and
uses that to save cpu time.
I am also converting multiz_levels from an assoc list to a pure one,
which saves significantly on access times and cleans up the code
somewhat.
Also I'm making the get_below/get_above procs into macros, for the sake
of cpu time.
[Converts the starlight disease to use BYOND's directional defines
instead of our
own](7d698f02d9)
To some extent spurred on by
https://github.com/DaedalusDock/daedalusdock/pull/298, tho it was known
before
## Why It's Good For The Game
Faster multiz code, faster init, etc etc etc
* modular files how very dare you
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Machine list is now stored in SSmachines | Remove excessive use of global lists for specific machine types
* Resolve merge conflicts
* Modular adjustments
* destroy this double return on destroy
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Refactors mind language holders into non-existent, fixes new languages being deleted on species swap + tests
* Fixing merge conflicts
* don't forget to ctrl+s!
* Another forgotten file
* urgh
* gets rid of vestiges of update_atom_languages()
and mind language holders
* No longer needed
* Fixes some modular grant_language calls
* Deprecated code
* This was up here before..
* Fixes failing unit tests, refactors silverscale lizards language a bit removing the need for skyrat edits
Removes some no longer needed code
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Bilingual can now choose their language
* Fix a merge error, removes a skyrat edit in favor of modular override
* uh what
* Moves the setup of GLOB.all_languages back into the subsystem + makes it load before SSAssets
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Random Station Smuggler Satchel Rebalance (#76621)
## About The Pull Request
Rebalances the smuggler satchels that were randomly replaced around the
station.
Now only two are spawned, down from 10
## Why It's Good For The Game
Though I think these are cool, currently with 10 spawning roundstart
they feel like they are everywhere, especially if you are walking around
with t-ray vision. The smugglers satchel is powerful item, powerful
enough to be in the traitor uplink. It makes inventory management a lot
easier, as you essentially have another backpack in your backpack. I
feel like this is a fine reward for being lucky or actively looking for
them, but with how they are currently, you can pretty much guarantee
your chances of getting 5 with a t-ray scanner and a couple minutes of
walking around, invalidating the inventory system. Now if you want this
reward, you have to make a choice to look for one, with the knowledge
that you still may not find it.
## Changelog
🆑 Seven
balance: Only 2 smugglers satchels will spawn on the station at
roundstart, down from 10
/🆑
* Random Station Smuggler Satchel Rebalance
---------
Co-authored-by: Lufferly <40921881+Lufferly@users.noreply.github.com>
Co-authored-by: Bloop <vinylspiders@gmail.com>
* Stop stack tracing if ezdb daemon is already running (#76555)
## About The Pull Request
This is an annoyance for me because I often kill the game but not the
EZDB daemon (leaving the cmd window open), and it just triggers this
stack trace while I have a debugger running. It's still able to connect
to the daemon in-game and functions perfectly fine, just hate dealing
with a completely needless stack_trace() every single time.
## Why It's Good For The Game
LET ME WORK!!! PLEASE!!!
## Changelog
Nothing that players should care about.
* Stop stack tracing if ezdb daemon is already running
---------
Co-authored-by: san7890 <the@san7890.com>
* Datumizes out jobconfig.toml (extensibility edition) (#76102)
## About The Pull Request
Hey there,
#75992 (fc54fd6a60) made me realize just
how wacky the job config system is to people trying to add more new
stuff to it, so I finally got the motivation to fix it up.
The gist is that it does all of the same stuff on the front-end as you
would expect, but instead of having to modify core generation code to
create/recreate the files, it instead uses a robust series of getters
and setters. It's much better to use these getters and setters because
we can apply needed game logic (like ensuring that the age that the
server operator puts in is actually sane, and not completely out of
bounds (if you want to permanently price people out of a position, just
set it to 0)). The getters are also nifty too, because they let me atone
for an early mistake I made with how assistants are meant to work with
"unlimited" nonsense.
All a new coder who wants to add stuff to the config needs to do now is
create the define, create the datum, add the procs for the datums, and
that's it! They don't have to do any of the wacky stuff or account for
weird stuff or do any weird copypasta, it's all handled by the system.
One datum is all you need, quite neat.
This also fixes some issues in #75992 that probably weren't discovered
in testing, but the only good way to fix it was a retune+refactor, which
is included in this PR.
## Why It's Good For The Game
Much more extensible, ensuring this system actually works as fully
intended, etc.
I fixed up the documentation (they didn't regenerate the job config
after they updated the code-side documentation) and some weird spacing
stuff that I missed in my review of that aforementioned PR. Everything
should work as expected, it's been tested quite a bit. It's also in its
own folder now, which is neat because we can share the local defines and
split all this stuff out of the already-quite-large SSjob file.
## Changelog
🆑
server: job_config.toml should now comply with reload-configuration
verb, meaning you can hot-reload the configuration from disk and have it
apply ingame automatically.
config: The documentation for setting Minimum Character Age on a per-Job
basis has been altered to be more explicit.
fix: The Minimum Character Age configuration entry is now sanitized to
ensure that it's within the codebase-defined ages, since there's no
(legitimate) way to get a character outside of those ages anyways.
Invalid values will log to the config log.
/🆑
---------
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* Datumizes out jobconfig.toml (extensibility edition)
---------
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Jacquerel <hnevard@ gmail.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Sends AI VOX messages over announcement instead of radio (#76327)
## About The Pull Request
Fixes#76310
`sound_override = TRUE` makes it so that no sound is played for the
announcement since "TRUE" isn't a sound file, but that might be bad code
let me know
## Why It's Good For The Game
Sending the message over the radio makes the AI "speak" it, so TTS plays
from AI at the same time as the VOX sounds, which makes the announcement
sound bad for the AI and anyone around them. This turns it from being
sent over the radio to an announcement so that TTS doesn't apply. It
also just makes more sense having the VOX announcement sent as an
announcement rather than just a normal radio message.
## Changelog
🆑
qol: AI VOX messages are sent over announcement instead of radio
fix: AI VOX messages work properly on multi-Z stations
/🆑
* Sends AI VOX messages over announcement instead of radio
---------
Co-authored-by: BlueMemesauce <47338680+BlueMemesauce@users.noreply.github.com>
* Removes per z level station relays, allows tcomms to reach across interconnected zs (#76360)
## About The Pull Request
The second layer of tram does not need its own relay, it is like 10 feet
max above the first.
Feels wrong in game, mappers tend to just sneak these off in corners, it
sucks.
Shouldn't need to do it.
Instead, tcomms z levels will be filled based off the z stack, rather
then just the layer itself.
Adds a list/helper to make this more efficient/more easily duplicable
## Why It's Good For The Game
Matches what people expect better, removes redundant map bits, better
vibes.
## Changelog
🆑
balance: Tcomms now works across connected (vertically) zlevels. No more
hunting in maint for the relay.
/🆑
* Removes per z level station relays, allows tcomms to reach across interconnected zs
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: Jolly-66 <70232195+Jolly-66@users.noreply.github.com>
* Moves ui references from the tgui subsystem to datums themselves (#76215)
## About The Pull Request
Unused vars have 0 memory cost, and the ref and list lookup here is
REALLY expensive, for both init and foam spreading.
## Why It's Good For The Game
Saves 0.2s off a station flood on meta, and 0.17s off init. More time in
other qdel heavy areas
Pulled off #76104 for the sake of cleanliness
* Moves ui references from the tgui subsystem to datums themselves
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Optimizes timer insertion by 80% (W QDEL_IN micro) (#76214)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
[Reduces timer insertion cost by
80%](c9e5b285ed)
Timer name generation involved a LOT of string shit, some in ways where
the string only existed for a moment.
This costs a good bit of time, and can be reduced with only minimal
impacts on the end product, so let's do that. Includes a compile flag to
flip it back if we ever have trouble in future.
This is about 0.1s off init, since we do a lot of timer stuff then too
[Removes STOPPABLE flag from QDEL_IN, moves it to a bespoke
macro](e7a5d7f2a7)
Its a waste most of the time, tho I would LOVE to analyze at compile
time to work out if we care
## Why It's Good For The Game
I like it when we don't spend all of our cpu time just setting the name
var on timers. that's good and not bad.
This saves time fucking everywhere. 15% off explosions, 0.1 seconds off
init, bunch of time off foam. it's just good.
Cherry picked out of #76104 since that was too cluttered (sannnnnn)
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
* Optimizes timer insertion by 80% (W QDEL_IN micro)
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Fully fixes atom init desyncs (#76179)
## About The Pull Request
The old system was... ok, but the stack trace was unfortuante, and the
potential to double remove was silly.
Let's use a list of source, value instead, to block overremovals and
properly support different load states
## Why It's Good For The Game
Prevents a bug a goodhearted bagilmin showed me where shuttles would
randomly just fail to load.
Calling clear twice should not be a failure
## Changelog
🆑
fix: Maps loaded post init will no longer randomly enter a failed state.
Hopefully.
/🆑
* Fully fixes atom init desyncs
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Fixes runtimes when tts is not enabled (#76178)
## About The Pull Request
I'm surprised none else got this already, constant null var reads
because the stack datum isn't created unless the subsystem is active.
Annoying
* Fixes runtimes when tts is not enabled
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
