* [NO-GBP] Optimizes rad nebula (#77014)
Switches rad nebula to only directly irradiate carbons and use radiated component
* [NO-GBP] Optimizes rad nebula
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
* Material container & related stuff ui refactors & clean-up (#76220)
## About The Pull Request
**1. Material container clean-up & refactor**
- Replaced `total_amount` var with `total_amount()` proc, this var can
be easily computed by summing up all material amounts rather than
storing it as a var which is tedious to update & keep track of when
materials are added/removed
- Removed unused procs `transer_amt_to()`, `can_insert_amount_mat()`,
and `get_categories()`. These procs are not used anywhere in the
codebase so let's remove them & make some space.
- Callbacks are replaced with signals, the callbacks don't need to be
explicitly garbage collected & having macros & procs marked with
`SIGNAL_HANDLER` makes your intentions more readable & explicit.
- Fixes#76151
All material adding, removal, checking operations are "Integer"
operations, i.e. the final value is rounded & them made 1 if the final
value is 0 using the macro `OPTIMIZE_COST`[coudn't come up with a better
name]. No more dealing with decimal value materials
The problem was after the protolathe was upgraded with better parts all
the design costs were multiplied with a decimal `efficiency_coeff`
value, this means even though in the UI the cost was displayed as 60
bluespace crystals its actual cost was `60.0001` something in the
backend causing this check for materials to fail & print the error
message.
- Replaced `GetComponent(/datum/component_material_container)` with just
a simple ref to the material container when adding the component, so we
can save some overhead from calling this proc
- Gave all procs a ton of documentation with documentation having
documentation
- Fixes#76506 RCD and other devices that uses the silo link upgrade now
have the correct material usages
- Fixes#72096. It wasn't just a problem with ancient protolathe but
with all machines that used `datum/component/remote_materials` the
problem was remote materials would add an instance of
`datum/remote/material_container` if it wanted to use local storage but
this component would get added before `datum/component/remote_materials`
could be registered i.e. it comes before remote_materials in the
component list. So when the machine is destroyed it will first destroy
`material_container` & then `remote_materials` therefore destroying the
materials before they could get ejected
- Silo link is established when parent is registered with remote
materials raher than adding an external timer which is faster
- Everything that uses a material container will auto eject their sheets
when destroyed
- Moved this & remote materials into its own folder for better
organization
**2. Material UI Changes**
- Removed the x25 & x50 print buttons from the autolathe, now they just
have x5 & x10 buttons like the protolathe, These buttons were of no use
since you could just type the exact amount you want to print in the
`[Max: <some amount>]` side bar. The code to compute these buttons was
just plain right nasty & some of it unused in the UI.
- The material eject button in the material bar does not gray out when
you can eject exactly one sheet
- All material cost are integer values rounded
- Fixes#76253 Exosuit Fabricator sends the material container static
data to the UI so its material bar is not greyed out when there are
sufficient materials to eject
- Component printer material bar sends the material container static
data to the UI so its material bar is not greyed out when there are
sufficient materials to eject
- Autolathe Material bars now display number of sheets available
- Max printable amount of items are now computed & updated correctly in
the UI. They were displaying wrong values & now get updated when items
are printed, materials are removed
- Silo hold actually works now. When a machine is put on hold it calls
this proc
e929cf39cd/code/datums/components/remote_materials.dm (L78-L87)
Notice how the key is `src` so we should be consistent during checking
if a machine is on hold using the same `src` var. But for some reason we
did dumb shit like this
e929cf39cd/code/datums/components/remote_materials.dm (L150-L153)
What is category? Why do we care for the area the machine is in? None of
it made sense so i removed all that junk and just made it check for
`src` like it should
- Removed redundant `removable` & `sheets` var from the material
container ui_data. These vars are unused in the UI
- If an item does not have the required materials then upon clicking
that item you will not get any error message but instead nothing happens
## Changelog
🆑
fix: items can be printed from autolathe & protolathe when the exact
material amounts are present in them after upgrading
fix: max printable amount now shows the correct value & updates when
items are printed, materials are removed in the autolathe & protolathe
fix: component printer material bar is not greyed out when there are
sufficient materials to eject
fix: rcd and other devices that uses the silo link upgrade now have the
correct material usages
fix: silo hold actually works
fix: machines using local storage to hold materials will eject it's
materials as sheets when deconstructed/destroyed
refactor: Autolathe Material bars now display number of sheets available
refactor: printing an item that does not have enough materials will fail
silently with no error messages
refactor: Drone dispenser will eject sheets upon deconstruction
refactor: all things that store materials will auto ejects its sheets(if
there is sufficient material) when destroyed
refactor: inserting an item into the material container will display the
units consumed as sheets not absolute units
refactor: removed x25 & x50 print buttons from the autolathe
* Material container & related stuff ui refactors & clean-up
* Update ammo_workbench.dm
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@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>
* made the bee a basic insect (#76971)
## About The Pull Request
the bee now a baisc insect he will now go to find his home and he will
go and pollinated the plants and helped the queen make children by
polliniting the plants and he will. the queen will leve the hive more
rarely than the normal bees so she can stay in the hive to make kids
## Why It's Good For The Game
the bee now is a basic insect so it means he have a better ai
## Changelog
🆑
balance: the bee now can fly over the machines so its easy for him to go
to the hydroponics machine
fix: player bees now will not be stuck inside the hive if he entered it,
they can now leave it
fix: fixed a har deleted when the hive is deleted all the bees still
have a refence to the hive now its fixed
fix: now when a player interacted with the bee hive the bees will now
leave the hive to defend the hive (it was glitched)
refactor: the bees now are a basic insect.
/🆑
* made the bee a basic insect
* Merge conflict
---------
Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Adds a wizard Right and Wrong that lets the caster give one spell (or relic) to everyone on the station (#76974)
## About The Pull Request
This PR adds a new wizard ritual (the kind that require 100 threat on
dynamic)
This ritual allows the wizard to select one spellbook entry (item or
spell), to which everyone on the station will be given or taught said
spell or item. If the spell requires a robe, the spell becomes robeless,
and if the item requires wizard to use, it makes it usable. Mostly.
- Want an epic sword fight? Give everyone a high-frequency blade
- One mindswap not enough shenanigans for you? Give out mindswap
- Fourth of July? Fireball would be pretty hilarious...
The wizard ritual costs 3 points plus the cost of whatever entry you are
giving out. So giving everyone fireball is 5 points.
It can only be cast once by a wizard, because I didn't want to go
through the effort to allow multiple in existence
## Why It's Good For The Game
Someone gave me the idea and I thought it sounded pretty funny as an
alternative to Summon Magic
Maybe I make this a Grand Finale ritual instead / in tandem? That's also
an idea.
## Changelog
🆑 Melbert
add: Wizards have a new Right and Wrong: Mass Teaching, allowing them to
grant everyone on the station one spell or relic of their choice!
/🆑
* Adds a wizard Right and Wrong that lets the caster give one spell (or relic) to everyone on the station
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Make electrified grilles, APCs, SMES and buckled stuff shock as expected again (#77004)
## About The Pull Request
Fixes some issues form the #76075 rework.
1. Grilles didn't shock anymore unless placed on red (layer 1) wire. Now
it looks for any of the three layers.
2. APCs also didn't get the correct cable layer for shocking as you
build a terminal. So they wouldn't shock you if there wasn't a layer 1
cable that carried power. And no one ever uses layer 1 cables sadly. Now
they look for the cable layer you're building the terminal on.
3. SMES, like APCs, didn't check for the correct cable layer when
building a terminal. Now they do.
4. As far as I can tell, gas miners would also only have worked on cable
layer 1, now they work on all layers.
This is because before the #76075 rework, all machinery connected to a
"machinery" cable layer instead of an actual cable layer.
The reworks' `get_cable_node` assumes `CABLE_LAYER_1` as a default
parameter, causing only red cables to connect when no parameter is
passed, unlike before where all cables would connect.
The rework adjusted some machines to be able to connect to a specific
layer. But I think other "machines" such as grilles should just us all
layers available. So I adjusted the `get_cable_node` to look for all
layers unless a specific layer is specified in the call
## Why It's Good For The Game
Rage cages good
Maint shocking grilles good
No one knows to use red cable to shock stuff
🆑
fix: Cable connections on various structures including electrified
grilles, APC terminals, and SMES terminals have been rectified and will
shock as expected again.
fix: Gas miners draw power properly again.
/🆑
* Make electrified grilles, APCs, SMES and buckled stuff shock as expected again
---------
Co-authored-by: Inari-Whitebear <inari_whitebear@fastmail.jp>
* Allows PAI range restrictions to be toggled on/off
New setting to enable or disable the 'leash' on the PAI.
* Adds message when it's been deactivated as well.
* Apply suggestions from code review
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Update pai.dm
---------
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Automatic TGS DMAPI Update (#76845)
This pull request updates the TGS DMAPI to the latest version. Please
note any changes that may be breaking or unimplemented in your codebase
by checking what changes are in the definitions file:
code/__DEFINES/tgs.dm before merging.
Co-authored-by: tgstation-server <tgstation-server@ users.noreply.github.com>
* Automatic TGS DMAPI Update
---------
Co-authored-by: orange man <61334995+comfyorange@users.noreply.github.com>
Co-authored-by: tgstation-server <tgstation-server@ users.noreply.github.com>
* Removes two redundant components (#76866)
## About The Pull Request
We're starting to get to have enough components that people don't
realise that what they want already exists but doesn't have the name
they expect 🙃
I recently added `track_hierarchical_movement` which is similar enough
to `connect_containers` that it shouldn't independently exist, even if I
like sending a new signal more than the ugly setup pattern for
`connect_loc`.
`trait_loc` is actually older than `give_turf_traits` but
`give_turf_traits` covers more edge cases than `turf_loc` so seems like
the better one to maintain.
HOWEVER `give_turf_traits` held a list of references to atoms in it,
which isn't great in an element. I couldn't think of a way to completely
eliminate the list, but it isn't a list of references any more so it
shouldn't cause any hard deletions.
## Why It's Good For The Game
Having two components which do the same thing but marginally differently
is confusing and going to cause us trouble down the line.
## Changelog
Not player facing
* Removes two redundant components
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* No roundstart playable MULEs / Trampling requires hacking (#76837)
## About The Pull Request
Prevailing feedback has been:
- The player base cannot be trusted to control MULEbots.
- It should be clearer what bots can and can't do.
The former is easy to fix.
The latter is sort of a matter for policy but I'm going to investigate
giving bots a rudimentary laws system. Plus that sounds much more
controversial than this so I am going to atomise this outside of that
PR.
MULEbots can still be set to allow sentience by cargo technicians, but
don't start that way.
ADDITIONALLY this PR just changes it so that MULEbots do not crush
people unless:
- They have been emagged.
- Their safety wire has been cut.
Either means works, so it's not too hard to access for nefarious
purposes, but hard to do to yourself.
Otherwise they just slow down for a few seconds instead.
Also fixed an unrelated name bug while I was there.
Closes#76926
## Why It's Good For The Game
Players would take them, not deliver any cargo, and repeatedly ask
people to lie down in front of them.
Plus Tram has 5 of the things which is frankly too many to be wandering
around the bar.
## Changelog
🆑
balance: You can't possess a MULE as soon as the round starts, someone
will have to give you permission.
balance: MULEbots no longer crush prone characters unless they have been
hacked (or emagged).
fix: Bots can put numbers in their names, what with being robots.
admin: Adds attack logging when certain wires are cut (for instance:
MULEbot safeties)
/🆑
* No roundstart playable MULEs / Trampling requires hacking
* add missing arg
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@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>
* Adds in the smoothbore disablers.
* Resolve merge conflicts + ammo HUD stuff
* No better way to do this than a skyrat edit since the proc sleeps
* Fixes a changed path
---------
Co-authored-by: CRITAWAKETS <sebastienracicot@hotmail.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Fixes ethereals' hair. Separates fixed hair color from the 'fixed_mut_color' var (#76930)
The series of "species nuking" prs made it so that the `fixed_mut_color`
also applies to hair. The problem with that is you may not want that in
some cases. It also introduced a bug where that var prevents ethereals'
hair from changing colors when they die.
So I have moved hair out of the things that gets `FIXED_MUT_COLOR` trait
applied to it in favor of its own thing.
`FIXED_HAIR_COLOR` trait is now used for ethereals to get a fixed hair
color.
Ethereals' hair should go out now when they die again, and it comes back on when they are revived.
* Fixes ethereals' hair. Separates fixed hair color from the 'fixed_mut_color' var
---------
Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>
* Creates an ambience global list for icebox and adds 10 new tracks to the exterior! (THANK YOU JOHN WILLARD!) (#76905)
## About The Pull Request
Creates an ambience global list for icebox and adds ten new tracks to
the exterior. Among the tracks are 5 instrumental stings, 4 microsong
melodies, and 1 thematic song.
HUGE thanks to John Willard for managing the coding aspect of this. All
the music is my creation, but without him, it'd just be sitting on my
hard drive. Love the guy.
## Why It's Good For The Game
Differentiates lavaland and icebox stylistically in their tones, key,
and musical instrumentation. Makes the world feel more alive!
If you want to add more ambient tracks for the zone, all of the tracks
come in the following keys:
G# HARMONIC MINOR
G# NATURAL MINOR
Db NATURAL MINOR
## Changelog
🆑
add: Ambient tracks for icebox.
add: Independent global_list for icebox.
/🆑
---------
Co-authored-by: JohnFulpWillard <53777086+JohnFulpWillard@ users.noreply.github.com>
* Creates an ambience global list for icebox and adds 10 new tracks to the exterior! (THANK YOU JOHN WILLARD!)
---------
Co-authored-by: RICK IM RI <77305289+tommysalami3@users.noreply.github.com>
Co-authored-by: JohnFulpWillard <53777086+JohnFulpWillard@ users.noreply.github.com>
* SPECIES NUKING 2023 EXTRA: Makes skin tones a trait instead of a species variable (#76410)
very similar to https://github.com/tgstation/tgstation/pull/76297, much
simpler though
removes the uses_skintones variable for similar reasons
Species variables are less useful and modular than traits.
If for some reason we ever add a mechanic that for some reason makes
your character use skin tones instead of whatever their original color
is, it will be much simpler to be handled.
not player facing
* Fixes all of the remaining issues
---------
Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com>
Volume pump refactor (#76260)
## About The Pull Request
A new pull request that DOESN'T make Lemon and Ghil kill me. _[I had
made a previous PR about the same original commits that was going to
make Volume Pumps leave a lot more gas in pipenets then people would
want.]_
Removed Hardcoded values from Volume_Pump.dm and moved them to __DEFINES
Updated documentation on Volume pumps because it was copied from
Pressure Pump. Volume pumps attempt to move a certain volume and ignore
pressure limits until exceeding them. This can lead to pressures well
above the limit, so there is no ‘perfecting’ of pressures, as previously
detailed by documentation.
Edited to be more specific.
## Why It's Good For The Game
Less Hardcoded values.
Documentation more readily reflects the realities of the game.
## Changelog
🆑
code: replaced hardcoded values in volume_pump.dm with __DEFINES vars
doc: Volume Pump's basic introduction was copied and pasted from the
Pressure Pump documentation, and made mention of trying to 'perfect the
pressure'. Volume pump doesn't care about pressure until it exceeds it,
so there is no 'perfecting' going on.
/🆑
---------
Co-authored-by: EliteCreature <EliteCreature@gmail.com>
Co-authored-by: Riley Redd <riley@pcs-ms.com>
* makes the pinguin a basic animal (#76790)
## About The Pull Request
the penguin now is a basic animal and also now he can go and layed
penguin eggs to make penguin babys also the baby have a new behavier he
will now go and looked for his mom and when he found his mom he will
went to her and be happy when he close to his mom or if he mom is died
he will went to her body and he will be sad and also i putted this
behavier in the baby chicken. also now the pinguen mom will go and
looked for her eggs and when she find a egg she will putted it in the
middile of her legs and walked with it
## Why It's Good For The Game
the pinguen now is a advance ai
## Changelog
the pinguen now have a more advance
🆑
refactor: the penguin is a basic animal
add: the penguin now layed eggs
add: the penguin and the chicken babys will go look for adult penguin or
chicken and be happy when he is near the adult
/🆑
* make the pinguen a basic animal
---------
Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@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>
<!-- 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
Security Medic was removed in the latest upstream merge. This undoes
that, [as requested by the person who PRed said
merge](https://github.com/Bubberstation/Bubberstation/pull/236). I've
tested that the role can spawn, and that all sprites function.
## Changelog
🆑
fix: un-deleted the Security Medic
/🆑
<!-- 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. -->
---------
Co-authored-by: Cyprex <35031555+Cyprex@users.noreply.github.com>
Co-authored-by: nevimer <77420409+nevimer@users.noreply.github.com>
<!-- 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
Makes it so ghosts can no longer see emotes, PDA messages, and dialogue
by default. This can still be enabled in the game options. Only works on
new players going forward, unfortunately.
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
<!-- Please make sure to actually test your PRs. If you have not tested
your PR mention it. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
Del: Ghosts hearing all emotes and PDA messages by default
/🆑
<!-- 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. -->
* Ethereal Pirates (Re-pr) (#76554)
Other pr had some weird check failure, making a new pr to see if it
fixes it.
## About The Pull Request
After he ended up finishing his pirate pr before I could, SethLafuente
graciously offered to let me roll my in-progress pirate pr into his
overall pirate expansion project.
This pr essentially adds a new faction of pirates, along with a new
subspecies of Ethereals a-la silverscales.
- The Lustrous:
A unique subspecies of Ethereal, with years of exposure to bluespace
dust mutating them into crystalline abominations sporting a new pointy
head, pressure resistance, and a permanent bluespace prophet brain
trauma. They're still as fragile as ever, but far more capable of
getting in and out of sticky situations.
- Geode Pirates:
A hollowed out asteroid manned by three Lustrous, equipped with
switchblades, traitor PKAs, jump boots, two teleporting turrets, and an
upgradable bluespace launchpad.
However, they lack proper armor and ship defenses, forcing them to adopt
a coordinated hit-and-run playstyle.
## Why It's Good For The Game
When I started working on this project, I wanted to implement this
faction to cover for the loss of psykers and as a means of creating a
"rock-paper-scissors" system to how standard pirate playstyles would
work; with default pirates being offensive, Silverscales defensive, and
Lustrous mobile.
With Seth's pr, things are a little different now, but I still believe a
glass cannon mobility-focused pirate faction would be a welcome addition
to the pirate roster.
## Changelog
🆑
add: Adds the Lustrous, ethereal pirates in a big bluespace geode!
sound: Unique scream sound for the Lustrous species.
image: Unique head icon for the Lustrous species.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@ users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* Ethereal Pirates (Re-pr)
* Fixes some merge whackiness
---------
Co-authored-by: Toastgoats <63932673+Toastgoats@users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@ users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@ gmail.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Fixes carbon bodytypes not always being synchronized with bodyparts (#76522)
Fixes https://github.com/tgstation/tgstation/issues/76481
TLDR /mob/living/carbon/human/species subtypes were NOT updating their
bodytypes on spawn due to absurd and wacky carbon bodypart creation code
that meant try_attach_limb() never got called (What the FUCK?)
* Fixes CI too
* [NO GBP] Fixes dumb usage of TRAIT_LIVERLESS_METABOLISM i caused (#76500)
## About The Pull Request
TRAIT_LIVERLESS_METABOLISM should do what it implies, and make you
always metabolize as if you were liverless.
This was a stupid mistake on my part because I wasn't aware
TRAIT_STABLELIVER was a thing.
## Why It's Good For The Game
TRAIT_LIVERLESS_METABOLISM and TRAIT_STABLELIVER should not behave the
exact same.
## Changelog
Not quite player facing.
* I fucking swear I fixed this before
---------
Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com>
* PAI Holochassis are now leashed to an area around their card
* Fix diffs
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Basic mobs can emote when they get a new target (#76654)
## About The Pull Request
Fixes#76624
Restores lost functionality for a mob to play an emote when it acquires
a new target.
Also I added a generic blackboard key change signal which could
potentially have other uses in the future.
## Why It's Good For The Game
It's good feedback to know when a mob has chosen to target something.
## Changelog
🆑
fix: Carp, Trees, and Festivus Poles will once more sometimes emote at
you if they think you are looking at them the wrong way, before they
come over to beat you up.
/🆑
* Basic mobs can emote when they get a new target
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Alcoholic quirk (#76510)
So you're telling me we have a smoker quirk and we DON'T have an
alcoholic quirk?
What a travesty! Time to fix that.
This quirk is essentially equivalent to smoker, but instead of a
favorite brand you get a favorite *brandy* (as in, favorite type of
booze).
More quirk variety with decent roleplay value.
What will we do with a drunken sailor?
🆑
add: Added Alcoholic as a negative quirk.
/🆑
---------
Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
Fixes multiz gas not displaying properly (#76572)
## About The Pull Request
Broken by 51f02b5acc I introduced logic
that would use SET_PLANE_EXPLICIT's context arg's PLANE (if it had no
turf) as a source.
Since we use SET_PLANE_IMPLICIT in atom Initialize, if we set a plane
before Init, it'll end up double offsetting. This was effecting gas.
Solution, because this case is so rare, is just to set the plane on init
and store the offset on the object until then.
## Why It's Good For The Game
Closes#75709Closes#73642
## Changelog
🆑
fix: Gas, like plasma, will now properly display on multiz stations
/🆑
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
makes the rcd able to make girders (#76515)
## About The Pull Request
rcd can make girders at half the cost of making a wall in 1.3 seconds
## Why It's Good For The Game
more "rapid" than using iron for girders and putting whatever material
on it
## Changelog
🆑
add: rcd can make girders now
/🆑
Co-authored-by: jimmyl <70376633+mc-oofert@users.noreply.github.com>
* Removes shove knockdown protection from all chaplain clothes (#76810)
## About The Pull Request
Alternative to https://github.com/tgstation/tgstation/pull/76759
Removes all shove protection from Chaplain clothes.
## Why It's Good For The Game
This was accidentally added when Chaplain suits were refactored away
from being subtypes of riot suits (the TYPE was checked in tackling,
which is the only thing the clothes gained from being a subtype
previously) in https://github.com/tgstation/tgstation/pull/68417
People sorta just forgot that Chaplain gear never had this
functionality, or assumed it was intentional because it's been like that
for some time now.
Chaplains already have enough gear (Null rod, better armor than
Security, Bible healing, sects) as a ROLEPLAY-focused job that I do not
think they need more combat-focused buffs.
Also fixes an accidental bug.
## Changelog
🆑
fix: Chaplain armor no longer blocks being shoved down.
/🆑
* Removes shove knockdown protection from all chaplain clothes
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Rewrites anti-magic slightly to stop spamming anti-magic effects on the same mob to silly levels (#76616)
## About The Pull Request
Moves anti-magic effect off of the component and onto the mob. Fixes
some bugs while there.
Anti-magic effects will now only trigger on calls with a charge cost
associated.
If the user is under the effects of.. an antimagic effect, a new one
will not play. This cuts down on overlay and sound effect spam from
walking through forcewall or spacetime distortion, for example.
## Why It's Good For The Game
I just found it a little annoying to see a chaplain walk through a magic
effect and it just spams the fart sound over and over on repeat and
makes them completely impossible to see.
## Changelog
🆑 Melbert
fix: Anti-magic visual effects will no longer trigger overtop one
another
/🆑
* Rewrites anti-magic slightly to stop spamming anti-magic effects on the same mob to silly levels
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
