## About The Pull Request
[Fixes static lights not
moving](ffef43c05a)
Worked fine when the owner moved, but if the owner was inside something
else, it would try and trigger an update on the PARENT's lights, which
are obviously not us.
[Renames MOVABLE_LIGHT and STATIC_LIGHT to better describe what they
do](de73a63bd4)
People keep trying to change the lighting system of lamps and it makes
me mad.
I choose OVERLAY_LIGHT and COMPLEX_LIGHT here, I couldn't figure out a
better name for turf matrix lighting. Suggestions welcome
## Why It's Good For The Game
Closes#80005
Hopefully improves understanding of lighting at a glance
## Changelog
🆑
fix: Fixes fancy lights not updating their source location when picked
up and moved
/🆑
## About The Pull Request
FOV as it is currently implemented is incompatible* with wallening.
I'm doin wallening, so we gotta redo things here.
The issue is the masking of mobs. Wallening relies on sidemap (layering
based off physical position), which only works on things on the same
plane (because planes are basically sheets we render down onto)
So rather then masking mobs, let's reuse the masking idea from old fov,
and use it to cut out a bit of the game render plane, and
blur/over-saturate the bit that's masked out.
My hope is this makes things visible in light, but not as much in
darkness, alongside making more vivid shit more easily seen (just like
real life)
Here's some videos, what follows after is the commits I care about
(since I had to rip a bunch of planes to nothing, so the files changed
tab might be a bit of a mess)
Oh also I had to remove the darkness pref since the darkness is doing a
lot of the heavy lifting now. I'm sorry.
Edit:
NEW FOV SPRITES! Thanks dongle your aviator glasses will guide us to a
better future.
https://github.com/tgstation/tgstation/assets/58055496/afa9eeb8-8b7b-4364-b0c0-7ac8070b5609https://github.com/tgstation/tgstation/assets/58055496/0eff040c-8bf1-47e4-a4f3-dac56fb2ccc8
## Commits I Care About
[Implements something like fov, but without the planes as layers
hell](a604c7b1c8)
Rather then masking out mobs standing behind us, we use a combo color
matrix and blur filter to make the stuff covered by fov harder to see.
We achive this by splitting the game plane into two, masking both by fov
(one normally and one inversely), and then applying effects to one of
the two.
I want to make the fov fullscreens more gradient, but as an effect this
is a good start
[Removes WALL_PLANE_UPPER by adding a WALL_PLANE overlay to material
walls (init cost comes
here)](2548933739)
@Mothblocks see this. comment in commit explains further but uh, we need
to draw material walls to the light mask plane so things actually can be
seen on them, but we can't do that and also have them be big, so they
get an overlay. Sorry, slight init time bump, about 0.5 seconds. I can
kill it with wallening.
[Moves SEETHROUGH_PLANE above
ABOVE_GAME_PLANE](beec4c00e0)
I don't think it actually wants to draw here
@Time-Green I think this was you so pinging for opinion
[Resprites FOV masks to be clean (and more
consistent)](f02ad13696)
[f02ad13](f02ad13696)
This is 100% donglesplonge's work, he's spent a week or so going back
and forth with me sharpening these to a mirror shine, real chill
## Why It's Good For The Game
Walls are closing in
## Changelog
🆑 LemonInTheDark, Donglesplonge
image: Redoes fov "mask" sprites. They're clean, have a very pleasant
dithering effect, and look real fuckin good!
del: Changed FOV, it no longer hides mobs, instead it blurs the hidden
area, and makes it a bit darker/oversaturated
/🆑
###### * It's technically possible if we start using render targets to
create 2 sets of sources but that's insane and we aren't doing it
## About The Pull Request
I find the proc hard to read honestly. There's no reason we can't split
this into two functions - the secondary functionality is used only once,
in reader.dmm.
## Why It's Good For The Game
Code improvement
Glorious snake case
## Changelog
N/A nothing player facing
---------
Co-authored-by: san7890 <34697715+san7890@users.noreply.github.com>
## About The Pull Request
Implements /datum/pathfind/sssp, which generates /datum/path_map
/datum/path_maps allow us to very efficently generate paths to any turf
they contain from their central point.
We're effectively running the single source shortest paths algorithm.
We expand from the center turf, adding turfs as they're found, and then
processing them in order of addition.
As we go, we remember what turf "found" us first. Reversing this chain
gives us the shortest possible path from the center turf to any turf in
its range (or the inverse).
This isn't all that useful on its own, outside of a few niche cases
(Like if we wanted to get the farthest reachable turf from the center)
but if we could reuse the map more then once, we'd be able to swarm
to/from a point very easily.
Reuse is a bit troublesome, reqiures a timeout system and a way to
compare different movables trying to get paths.
I've implemented it tho. I've refactored CanAStarPass to take a datum,
/datum/can_pass_info. This is built from a movable and a list of access,
and copies all the properties that would impact pathfinding over onto
itself.
There is one case where we don't do this, pathing over openspace
requires checking if we'd fall through the openspace, and the proc for
that takes an atom.
So instead we use the weakref to the owner that we hold onto, and hold
copies of all the values that would impact the check on the datum.
When someone requests a swarmed path their pass info is compared with
the pass info of all other path_maps centered on their target turf. If
it matches and their requested timeout isn't too short, we just reuse
the map.
Timeout is a tricky thing because the longer a map exists the more out
of date it gets.
I've added a few age defines that let you modulate your level of risk
here. We default to only allowing maps that are currently
being generated, or finished generating in our tick.
Hopefully this prevents falling into trouble, but consumers will need to
allow "failed" movements.
As a part of this datumized pass info, I've refactored pathfinding to
use access lists, rather then id cards directly. This also avoids some
dumbass harddel oppertunities, and prevents an idcard from changing mid
path.
Did a few things to the zPass procs, they took args that they did NOT
need, and I thought it'd be better to yeet em.
If you'd all like I could undo the caching/can_pass_info stuff if you'd
all like. I think it's useful generally because it avoids stuff changing
mid pathfind attempt, but if it's too clunky I could nuke it.
Oh also I added optional args to jps that constricts how it handles
diagonals. I've used this to fix bot paths.
## Why It's Good For The Game
Much of this is redundant currently. I'm adding it because it could have
saved hugglebippers, and because I get the feeling it'll be useful for
"grouping" mobs like bees and such.
We're doing more basic mob work currently and I want to provide extra
tools for that work.
https://github.com/tgstation/tgstation/assets/58055496/66aca1f9-c6e7-4173-9c38-c40516d6d853
## Changelog
🆑
add: Adds swarmed pathfinding, trading accuracy for potential
optimization of used correctly
fix: Bots will no longer take diagonal paths, preventing weirdo looking
path visuals
refactor: Refactored bits of pathfinding code, hopefully easier to add
new pathfinding strategies now
/🆑
## About The Pull Request
I remembered today that blob code is ass, especially blob spores.
There's still a lot to improve but I cleaned up _some_ of it by
converting these mobs.
Now they use a newer framework and more signal handling as compared to
circular references.
I _expect_ the behaviour here to largely be the same as it was or
similar. I haven't added anything fancy or new.
This is a reasonably big PR but at least all of the files are small?
Everything here touched every other thing enough that it didnt make
sense to split up sorry.
Other things I did in code:
- Experimented with replacing the `mob/blob` subtype with a component.
Don't know if this is genius or stupid.
- AI subtree which just walks somewhere. We've used this behaviour a lot
but never given it its own subtree.
- Blob Spores and Zombies are two different mobs now instead of being
one mob which just changes every single one of its properties.
- Made a few living defence procs call super, because the only thing
super does was send a signal and we weren't doing that for no reason.
Also added a couple extra signals for intercepts we did not have.
## Changelog
🆑
fix: Blob spores will respond to rallies more reliably (it won't runtime
every time they try and pathfind).
fix: Blobbernaut pain animation overlays should align with the direction
the mob is facing instead of always facing South
refactor: Blob spores, zombies, and blobbernauts now all use the basic
mob framework. They should work the same, but please report any issues.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
## 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.
## About The Pull Request
Signals were initially only usable with component listeners, which while
no longer the case has lead to outdated documentation, names, and a
similar location in code.
This pr pulls the two apart. Partially because mso thinks we should, but
also because they really aren't directly linked anymore, and having them
in this midstate just confuses people.
[Renames comp_lookup to listen_lookup, since that's what it
does](102b79694f)
[Moves signal procs over to their own
file](33d07d01fd)
[Renames the PREQDELETING and QDELETING comsigs to drop the parent bit
since they can hook to more then just comps
now](335ea4ad08)
[Does something similar to the attackby comsigs (PARENT ->
ATOM)](210e57051d)
[And finally passes over the examine
signals](65917658fb)
## Why It's Good For The Game
Code makes more sense, things are better teased apart, s just good imo
## Changelog
🆑
refactor: Pulled apart the last vestiges of names/docs directly linking
signals to components
/🆑
## About The Pull Request
Adds defines for gasses and replaces uses I've found to instead use the
defines.
Can you believe I made this PR while trying to work with Xenos? This
sucks!
## Why It's Good For The Game
There's a lot of different uses of things like "o2" and "plasma", and
they are pretty inconsistent. In some places, it's "hydrogen", in others
it's "h2". In some it's "plasma", others "plasm". This unifies it all
under defines so it has a less chance of breaking in the future.
## Changelog
Nothing player-facing.
## About The Pull Request
- Fixes a runtime from foam being created inside plasmamen, instead of
at the plasmamen's loc, from the clown plasmaman suit
- Adds a stack trace for mobs having foam created inside of them
- So, in the past foam would runtime if created in a non-turf at all,
mobs or otherwise. I changed it so it creates a more helpful stack
trace.
- While tackling this, however, I realized that we may want to support
foam in non-turf, non-mob locs? Like closets? That is to say, if you
release a foam reaction while stuck in a locker and it floods the
locker, it would stay in the locker until it is opened, and affect other
people in the locker itself? Unsure, so I left it as an option, albeit
it may not function entirely correctly.
- This may also false-positive in some places, such as a mob within mob.
I'm unsure if it should have its own case, or of it should act like
closets are implied to do above? But that may produce some silent
errors. So eh.
## Why It's Good For The Game
Less runtimes, more intended code.
## Changelog
🆑 Melbert
fix: Fixes a runtime with plasmaman clown suit lube spray
/🆑
This tracks the seconds per tick of a subsystem, however note that it is
not completely accurate, as subsystems can be delayed, however it's
useful to have this number as a multiplier or ratio, so that if in
future someone changes the subsystem wait time code correctly adjusts
how fast it applies effects
regexes used
git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i
's/DT_PROB/SPT_PROB/g'
git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i
's/delta_time/seconds_per_tick/g'
## About The Pull Request
**This PR:**
- Reworks most* existing soup into reagents.
- Adds Stoves and Ranges. Ranges replace most* existing ovens.
- Adds soup pots, to cook soup
**How does it work?**
In the kitchen you will find a stove now.
Stoves act as a "reagent container heater", essentially a chem heater.
You can set a pot onto the stove.
To make soup, visit the cooking recipe book for a guide. Most recipes
are the same as before, just tweaked slightly - Add water to the pot (50
units for 1 batch generally), then add all the corresponding ingredients
to the pot. Set the pot out on the stove and right click it to turn it
on. If the recipe's correct, shortly it will start to mix and give you
soup!
One soup recipe will give you roughly 3 servings of soup. You can pour
our the soup into a bowl using a ladle or just by pouring it manually.
Of note: **All of the reagent contents of the ingredient are transferred
into the soup.** Better, more nutrient rich ingredients produces more
soup, and poisoned produce will pass it on.
If you place the soup into a chem master, you will notice it's roughly
half "soup reagent" and half a variety of reagents, including nutriments
/ proteins. This is your soup! It is recommended you serve your soup
with the reagents included, as they make up more nutrition for the
customer, however you can separate it out if you're picky.
**Todo:**
- [x] Fill out the PR body a bit more
- [x] Mapping (wait for big merge conflict pr to go past)
- [x] Soup colors
- [x] Balance pass over for soup recipes
- [x] TODOs
- [ ] Unit tests
- [x] Cullen Skink's recipe is invalid
- [x] Try to see if there's an easy way to prevent soup from fattening
you up too easy.
## Why it's good for the game
Adds some more depth to the kitchen and moves chef away from the
click-button-get-food style that exists.
Allows for inherently custom soups by the way of making it reagents, so
no need to support custom soup food items.
## Changelog
🆑 Melbert, stove and pot sprites by Kryson, ladle sprite by Kinneb
add: Kitchens are now stocked with Ranges.
add: You can now print (and create) Stoves.
add: The dinnerware vendor now dispenses ladles.
add: Spoons can now actually spoon... things.
add: Soup has been reworked entirely. Soups are now reagents, cooked via
a soup pot on a Stove or Range. Simply add water and your required
items, then apply heat. Be careful not to boil over!
add: Stoves, Ranges, and Griddles will now heat up their surroundings -
don't turn them on around plasma!
fix: Fixes being able to cook in an Oven while the room is depowered
qol: Hitting a customer bot with an incorrect recipe no longer counts as
a hostile attack leading to your demise shortly after
refactor: Customer bots that request a reagent now use custom orders
code: Cut down a lot of code in the crafting menu code, and removes some
ugly ispaths
del: Soup is no longer food items, so can't appear in random food pools
(at least not yet).
balance: Virus Food recipe now requires you cool it to 200k.
/🆑
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.
## About The Pull Request
Hey there,
This took a while to do, but here's the gist:
Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.
Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.
Scenarios this PR corrects:
* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*
(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game
If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).
Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.
I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.
(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
## About The Pull Request
Creates a short-lived foam with a lifetime of 1 SECOND instead of the
default 8 SECONDS to address some complaints about the scrubber overflow
event overstaying its welcome.
## Why It's Good For The Game
Fixes#69689Fixes#71830
## Changelog
🆑 Tattle
balance: the foam used in the scrubber overflow has a lifetime of 1s
instead of 8s
/🆑
Co-authored-by: tattle <article.disaster@gmail.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
All of these from what i heard were supposed to make all foam with range
"4" but most of these ranges were stupidly big so
Fixes 1 tile foam that was apparently not fixed after the foam refactor
in:
AI Upload Foam Dispensers, with a range of "4"
Hygienebot death, with a range of "2"
Clown cars taking damage, with a range of "4" and 25u of space lube.
(henk)
Clown plasmaman envirosuits extinguishment, with a range of "4" and 15u
of space lube. (hunke)
Soap suicide, with a range of "1"
Emagged cleanbots wetting the floor and making foam, with a range of "2"
Firebots when exposed to an atmos fire, firefighting foam with a range
of "3"
## Why It's Good For The Game
Fixes#68441
Makes firebots less ass
Also barely-functional code bad, functional code good
## Changelog
🆑
fix: Fixes 1 tile foam in Foam Dispensers,Clown Cars, Hygiene
Bots,Firebots, Soap Suicide, Emagged cleanbots, and the clown plasmaman
envirosuit
/🆑
* Removes ComponentInitialize()
Completely removes ComponentInitialize() as a proc, which was called on every single atom in the game, twice in some instances (like new players), over something that can already be done with Initialize().
This is the second attempt at doing this, after the first attempt fell apart for some reason. This time it was way easier though, since storages are no longer a Component.
* update icon blocker added before calling parent
* Update code/game/machinery/porta_turret/portable_turret.dm
Co-authored-by: san7890 <the@san7890.com>
* adds a mapload while I'm here
* moves human mood
* Does some UNRELATED thing to the PR
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Readds Alien Vore
Aliens can now eat people again. Behavior was removed by #43991 (b6c41e3b32)
because nasku thought it was weird, and the code was really bad.
I think it's funny, and I've made the code not trashtier.
Basically, an alien can agressive grab any living mob. If they stay next
to the mob, facing them for 13 seconds, they will "eat" the mob,
IE:insert them into a list on their custom stomach.
The xeno can then hit an action button to spit out the mob, alongside
some acid.
If the mob is alive enough to pull out a weapon inside the xeno/has one
on it, they can attack the xeno from inside, dealing damage to the
creature and its stomach. If the stomach drops below a threshold, the
mob gibs the xeno and escapes.
I've done my best to steer things away from horny and into gross, though
I'm aware you fucks do your best to blur that line.
Anyway something something balance change something something lets xenos
abduct people more easily, I'm mostly doing this cause I think it has
soul.
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
About The Pull Request
Makes smoke propagate the fingerprints of the last person to touch the source of the smoke.
This makes gunpowder smoke actually log the person responsible for the explosions.
Why It's Good For The Game
As of right now gunpowder smoke (and similar) doesn't actually have very good logging as as far as the smoke is concerned it's never been touched and so the resulting explosions are blameless. Obviously, scrolling up for a good minute looking for who has just obliterated the escape shuttle is slightly annoying for the admins. Ergo, making the explosions log who actually is responsible for making the smoke they originate from should reduce admin annoyance.
Changelog
cl
admin: Smoke now logs the last person to touch the source of the smoke as the last person to touch the smoke itself. Gunpowder smoke should be less annoying to log dive as a result as every explosion will log that person.
/cl
* Removes smoke and foam reactions
Turns out when you let reagents react in foam/smoke, people put bombs in
them.
This behavior was initially added to just smoke, accidentially in
(56f7ac0c0a) accidentialy (thalpy tried to
make both foam and smoke instant react, but instead made smoke's temporary
holder reagent instant instead. hhhhhhh)
Assuming this was intentional it was then extended to foam in
(1879e2d338)
Basically, we're idiots. Anyway lets just walk this all back to instant
reaction on smoke/foam formation. Hate you people
* Removes another source of gunpowder smoke
Temporal told me about this. Gunpowder uses an ex_act signal as a
starter, and that also counts for smoke objects.
Really don't want instant detonation smoke bombs, so let's just... not
shall we?
Makes smoke spread through newly opened airlocks if the cloud has spread past the airlock, but has not completely finished spreading.
More intuitive smoke behavior.
As funny as it is to open an airlock and see nothing but a wall of smoke it's even funnier to open an airlock and suddenly be inside a wall of smoke.
* Jetpack and spacedrift: Fixes and niceties
Ok so when I ported spacemovement onto movement loop,
I neglected to port this behavior that existed to support jetpacks.
Basically, if something that lets you move while spacedrifing
completes a move while you're spacedrifting, the
drift should "disable" to let it complete, and then later restart.
I neglected to add support for that, so that's what this does.
There's some other stuff going on here, mostly things to let jetpacks
ignore some of drift's extra behavior, since when a jetpack is not on
stablized, we want both to coexist.
It's a bit of a mess, I'm sorry about that.
Oh and at temporal's suggestion I've moved the visual_delay set from
newtonian move to an istype on the drift component, that was a good
idea, thanks quiet
* Makes dropping a pull while drifting carry the momentum into the pulled thing\
* Adds some extra context to Process_Spacemove, fixes a bunch of stupid
space bugs
It used to be, if you called Process_Spacemove with a direction, it
assumed you were an "action", so a client or mob trying to move in a
direction.
Unfortuantely for it, I needed to be able to use direction to make mob
pull drifting work. So we now actually pass in a second variable
called continuous_move, which tracks if this Process_Spacemove is on
behalf of a continuous move or not
In addition to this, I've added logic to bumping "off" someone to
prevent backbumping if that makes sense, since the bump is in the form
of a newtonian move that's run before the thing that's bumping actually
moves, we need some way to exclude it from holding the other object in
place.
* Adds a jetpack component, uses it to unify all three versions of
jetpacking
I hate you fikou
There were three copies of the same behavior, which made it hard to fix
stuff. Let's just componentize it
* Fixes jetpacks stabalizing even without fuel
This is mildly hacky. The real fix is to do this with events, but I
really don't wanna bend my brain like that. This'll do
* Ensures turn_off always has a user)
* Shut pu
* Bulky drags no longer effect your movespeed in space, fixing a consistency issue between them and all other forms of drags
* Removes some redundant code, cleans up some messy stuff
* Removes redundant safety checking from jetpack code
* see above
* Removes redundant signals
Have you ever noticed that the chemical smoke and chemical foam reactions are a lot less effective in confined spaces? This is because they currently attempt to spread to all tiles within n steps of their origin. If they can't expand onto a tile they get blocked and the expanding cloud/flood misses out on all the tiles that would be in range, but that can't be reached.
Obviously smoke and foam getting blocked by walls and the like makes intuitive sense, but it seemed a bit nonsensical that walls would basically delete a significant chunk of an expanding, amoebic mass. The solution I came up with is making smoke and foam expand until they cover a certain area, with a shared tracker for the target size and total size of the flood. The flood will simply expand as normal until it covers the desired target area. Blocked expansions just don't count and will be made up for with expansion elsewhere.
Attendant to these changes are a whole bunch of minor code improvement to smoke, foam, and one for wizard spells because I was already in the area and :pain:.
There have been some minor balance changes to the chemical smoke and foam reactions:
I converted them over to passing the desired area of the resulting smoke cloud/foam flood. The old equation for the resulting area was along the lines of 2sqrt(x)(sqrt(x) + 1) + 1 given reaction volume x and given unobstructed expansion. I've made them just pass around 2x instead. This is actually less than they used to try for, but now they're guaranteed to reach that unless the flood is fully contained. Not entirely certain if buff or nerf. Probably buff on the station.
Also, foam dilution is now based on covered area instead of target expansion range. Since this scales faster than it used to foam has been effectively nerfed at high volumes. To compensate for this I removed the jank 6/7 effect multiplier and increased the base reagent scaling a bit. Again, not certain if buff or nerf.
This PR refactors firestacks into two status effects: fire_stacks, which behave like normal firestacks you have right now, and wet_stacks, which are your negative fire stacks right now. This allows for custom fires with custom behaviors and icons to be made.
Some fire related is moved away from species(what the fuck was it even doing there) into these as well.
Oh and I fixed the bug where monkeys on fire had a human fire overlay, why wasn't this fixed already, it's like ancient.
Also changed some related proc names to be snake_case like everything should be.
This allows for custom fire types with custom behaviours, like freezing freon fire or radioactive tritium fire. Removing vars from living and moving them to status effects for modularity is also good.
Nothing to argue about since there's nothing player-facing
* part 1
* Merge branch 'master' of https://github.com/tgstation/tgstation into magnet-holster
* modsuit module update: replacement of holster and pepper spray, nerf to clamp
* fixes
* this for some reason renders shit badly
* h
* test
* handles deleting as an arg, hopefully fixing the runtimes
* dusk to dawn
* fucking idiot
* you too
* slight speedup
* stiupid
* less capsaicin
* Apply suggestions from code review
use the typecache
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Update code/modules/mod/modules/_module.dm
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* w
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
This PR buffs smoke and foam in two ways.
It increases the hardcap on carried reagent volume for smoke to 1000u. This is on par with foam, which also has a reagent multiplying effect that smoke does not have.
It permits reactions within both smoke and foam. This could be more dangerous as it could allow for smoke/foam to make more smoke/foam, but these reactions would consume the contents of the smoke and foam so it shouldn't cause too much trouble.
What this means for you.
In all honesty these changes won't make chemical weapons significantly more powerful than their current state.
While you would think that doubling the carrying capacity of smoke would make a significant difference in reality it really doesn't. The vast majority of chemical delivery methods had payload capacities too low to run up against the old hardcap. Of the ones that could only chemical payloads really have the capacity to take full advantage of it and when was the last time you saw an antagonist actually use a chemical payload with smoke? I don't think I ever have. For those still concerned about balance: a smoke mix with a 500u blend of acids optimized for damage deals 52.35 total damage each tick on an unprotected target. The same mix at 1000u deals 53.1 total damage each tick. This is a difference of 1.5%, hardly enough to notice.
On the other hand, the change to make foam mixes allow reactions within the foam would be a massive change..... but reactions have already been allowed within smoke for months now. That's probably been the case since #56019 dropped actually. All this PR does it allow them within foam as well. On that note, after some testing foam is significantly less potent than smoke in this manner for a few reasons. Firstly, foam is blocked by a multitude of common objects that smoke simply isn't: tables, lockers, and crates for a start. Secondly, foam divides the reagents used to make the foam by the range* of the foam when it is initially created. As such it is necessary to cram about twice as much reactant into the foam to get the same effect as the same mix (but smoke) with a lower dispersal range.
First off, the fact that smoke and foam have carry volume hardcaps at all is not well communicated. To my knowledge it is not mentioned anywhere in game or on the wiki. Essentially the only way to figure out that they exists is either to code dive or to build high density smoke chemical payloads and notice that they are somewhat less effective than they should be. I cannot remove the hardcaps entirely so the next best thing is making sure that both hardcaps are in the same place.
Secondarily, I have been enjoying applying delayed-reaction smoke for about a month now and haven't really seen a reason for it to be blocked in foam as well. I would like for other chemists to try to also use delayed-reaction smoke as well because I find it interesting and I'm pretty certain I haven't fully explored what is possible using it. After doing some testing this should not notably effect game balance as foam is significantly less effective than smoke in this manner of application.
About The Pull Request
Simply converts all instances of soundkeys that use get_sfx from strings into defines.
E.g. "sparks" is now SFX_SPARKS
Why It's Good For The Game
It makes life a lot easier when you're looking for a sound effect. You just type SFX_ and you get suggestions in VSC. Plus, it looks better.
image
Changelog
Not player facing.
* Fixes infi pushing off something in space
Right now you can just push "into" a dense object forever, and depending
on your move rate, just kinda glide
We can fix that by checking if we're trying to push "off" something
we're moving towards
* Makes pushing off something shift it instantly
Currently if you kick off something in space it waits the delay of the
move to start drifting. Looks dumb, let's not
* Updates backup movement to properly account for directional windows. GOD I HATE DIRECTIONAL DENSITY SHOOOOOT MEEEEEEEEEEEEEEEEEEE
* Uses range instead of orange so standing on the same tile as a directional counts properly, rather then suddenly entering a drift state. I hate it here
* Ensures all args are named, updates implementations of the proc with the new arg
Rather then sticking around till their 7 second delay, they dissipate
once they finish their movement. This dissipation comes with a fading
and such to make things look nicer.
I've applied the fading behavior to sprays too, since they could also
use the help.
I really hate how things look currently, makes me break out in hives
Broken Super_UV icon (big flashing red overlay), no icon to indicate its locked, and unscrewing it straight up broke the whole icon!
That's all fixed, along with some quality of life, including warnings explaining WHY stuff failed...
I even made the super_uv ACTUALLY output black smoke, as the description says it does, because its cool.
Tidies up something that sees more use now that we have MODsuits (and potentially will get them buildable if that other PR goes thru)
The Suit Storage Units now have a Locked indicator on their lights! In exchange, decontamination above safe levels has a slightly different indicator (flashing red/yellow)
SSU gives chat warnings as to why it blocks decontamination (no items/safeties on)
SSU panel/super-decontamination icons work properly now
The SSU super-decontamination also creates a plume of black smoke at the end, as the flavor description said it did.
About The Pull Request
Adds an argument to typecache generation that allows specifying the whether to include/exclude types in the input list.
Also adds another argument to specify whether to remove falsey values after the typecache is generated.
Why It's Good For The Game
Might make zaps slightly faster???
Honestly I just thought it would be a good way to condense some whitelist/blacklist typecache sets.
fixes#64029 (Springlock MOD module kills you even when you have Memento Mori necklace)
fixes#64136 (modsuits cant run out of charge)
fixes#64158 (trying to install a battery into a modsuit with free storage space places the battery into storage)
fixes#64186 (ModSuits : taking out cell doesn't give it back)
fixes#64161 (Modsuit cores disappear in construction)
makes mod jetpacks show particles indoors
gives the prototype suit back their upgraded cell (they literally lose 1% of power per 3 seconds with their current one)
Fully reworks the kinesis module to not be TK but lamer, it is now a gravitational anomaly locked module.
Unique stuff that can be used in fun scenarios
* Adds a subsystem to handle automated directional movement, replaces all instances of walk_towards with it. Makes meteors and immovable rods not drift in space, and makes immovable rods more destructive. Note, I've opted not to use byond's method of moving towards something, which is effectively Move(src, get_step(src, get_dir(src, target))) as it's cringe and doesn't make a smooth line. I've replaced it with a autoupdating rise over run setup, read the code for more details
* woop forgot the subsystem
* Documentation, contributing.md entry, and some cleanup
* Makes the moveloop datum more oop friendly, sets us up for a lot of conversions
* Converts the curseblob and walk_away() to the subsystem
* Changes the default for override from FALSE to TRUE
* converts walk() over, still need to add a replacement proc for it, but we didn't actually have anything that used the raw proc
* converts the rest of walk_to() over, nearing the end now
* cleans up some errors
* Fully documents everything, fills in some missing movement types, uses the power of oop to make things cleaner, and typepaths longer
* Finishes the contributing.md stuff
* Done
* Fefaults -> Defaults, can you tell I wrote this at 1AM?
* resolves bubblegum issues
* Roh's suggestions
Co-authored-by: Rohesie <rohesie@gmail.com>
* Cleanup
* Hey lemon, did you know that Destroy() lives on datums? ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
* Converts over the discrepencies created in my absense
* HAHA FUCK YOU I PAY MY DUES
* Whoops lost some stuff in the merge
* Converts the system from seconds to deciseconds to make dealing with the api more sane
* Some stuff I missed
* Makes movement an inheritable subsystem type, splits the moveloop file into two, one for the subsystem, and one for the datums
* Makes a subsystem that handles directing movers out to other subsystems. It's a bit bad right now, but it's a
good first step. I think I'll move the move loop datum to a lazy var on mobs instead of an assoc list, don't
like lists.
Also makes the movement procs global, I'll move em to the /movement subsystem at some point or something like
that
* Converts the existing uses of the procs over to the new format
* Adds support for subsystem precedence, so a type of A can override type B.
General cleanup, still kinda in debug mode but it's getting better
* I'll admit I'm not too familiar with this, but I think it will work
* Adds starting logic so movement types "pausing" makes any sense
Redoes how waiting is handled to make it based on world.time directly. I don't remember why. I think it's better
this way.
Adds a drifting movement type, moves space drift over to it.
Needs severe work before it's ready, too much info stored and modified on the moving object, see comment
Starts work on making drifting smooth
* Moves almost all space drifting vars over to signals on the movement datum
Properly implements glide size stuff for both the subsystem and the loops. Space drift will be smoother now.
It's not perfect, but it'll work just fine for now
Adds a way to override a client'd mob's glide size mid move, uses it to make entering a spacedrift look right
Adds a way to delay a client move outside of just move_delay, meant to be used for long periods, and setup such
that it doesn't make inputs persist
Adds flags to movement loops, alongside MOVELOOP_OVERRIDE_CLIENT_CONTROL, which blocks client movements while
the loop is firing, and for it's visual delay after
This means you can't exit a space drift until you hit the actual wall. This feels a lot better
Some general logic stuff, move() will return true/false if it succeeded or failed
Adds a stop_loop() proc that's called when a move loop is no longer active
Suck my nuts
* Moves precedence to the loop instead of the subsystem
* Moves drifting into a component, this lets me explictly block input after the move loop ends, so people can't
move the moment they functionally move onto a new tile
This is a bit underdeveloped currently, but that's a problem for another day
Cleans up some uses of move procs, fixes runtimes in metoer and curseblob code
Adds signals for stopping/starting a move loop, sending one for destroy is redundant.
Moves existing event signals from the movable being acted on to the loop itself, makes more sense this way
Makes the move handler return the created loop up the chain so we can register to it
Fixes a logic error in loop contesting code that lead to loops never actually being removed from subsystems
because they didn't know they should be.
Properly changes lifetime from a time to stop, to functionally an amount of moves to complete before stopping
Adds some new signals for pre/post loop process. This is to better tie into components.
I decided I didn't like the idea of tying all functionality to the loops themselves
The loop decides functionally how to move, components or just tied in signals can decide when/when not to move
and can modify properties of the loop
Making a new loop for things like atmos drift, something I'm interested in tackling in the future, seemed silly
* Moves movement procs directly to the subsystem for better namespacing or whatever
* Moves movement packets onto /atom/movable, no longer need the debugging
I've decided to not just put their contents fully onto atom movable, since it makes debugging on live much
harder, can't sdql for them anymore.
Fixes a runtime in meteor code, properly this time
Fixes a logic error in stop_looping
Makes move manager NO_INIT, because well, it doesn't init
* Commits human sin, makes Recover() work properly for movement subsystems
* Fixes immovable rod orbits not always working, they were returning too early in moved and fucking up the var we use to track move count, and thus not sending a signal properly
* Reworks the curseblob to use signals more, and to not use override
* Missed this in the movement ss commit
* Removes override, makes having a higher or equal precedence take its place
* Updates documentation
* Cleans up some unused defines
* Nukes the unused flags option
* Whoops forgot to qdel check
* Removes an unused var I had for client move prevention before I started using a component
* Let's do this properly
* Modernizes meteor code to better match how explosions actually work currently
* Some more cleanup
* Cleans up effect code a little bit
Nukes the effect system's sleep loop, we use movement loops instead
As a part of that, instead of 1 timer per effect spawned, we react to loop failure and make it 1 timer per
effect system
This should reduce the amoumt of slowdown we see after mass lighting break
It's not everything, we're still making a timer per spark effect, but it cuts things down significantly
* Updates explosions to not sleep
* Adds support for modifying a loops delay post process, makes extinguisher code suck less then it does currently, nukes some more sleeps and timer loops
* Converts water tank resin over to move loops rather then sleeps, minor behavior change mind, the cooldown starts on fire rather then on land, but I think that makes more sense anyway
* compile and runtime fix
* Fixes some runtimes, cleans up some code, ensures feature parity when it comes to logging
* Prevents resin foam from space drifting
* Adds support for flags back into the system, I need it for reasons
* Updates move_towards to fix some bugs and resolve some inconsistent behavior, implements a flag that makes a loop's first move start instantly
* Fixes extinguishers not actually transfering any reagents
* Converts sprays to the new system. This does actually minorly change behavior, in that I've changed the order of spray actions from step -> sleep -> wash to step -> wash -> sleep, but I'm not terribly torn up about it because frankly I think it feels better
* Converts grav catapults over to the new system
* Converts trays over to moveloops
* Converts robot streaking to move loops, the other two coming soon
* Compile you won't. Also fixes a behavior issue with oil streaks
* Does directional step_to properly, cleans up the other two streaking types
* Converts step_trigger over, not that it's actually used anywhere. Changes how stoping a move works, you need to explicitly qdel, other the step is just considered to be ignored. This will make life easier later
* Adds a jps movement loop. It's a bit bloaty, id is stupid, but it'll work just fine
* Makes the system support passing in a datum that's just used as extra context for the move. The hope is this makes signalizing things less of an absolute headache
* Begins the conversion of ai movement datums to movement loops
* These two are reasonably simple, only weird thing I'm doing is A: Not allowing target hotswapping, which I hope none is doing, and B: passing the controller into the move loop as extra context so things work properly
* JPS is a bit more complex, partially because the old implementation was a bit weird. 2 major things. 1: I'm dropping what I think was a redundant behavior minimum distance check from the premove bit of logic, since I'm pretty sure it didn't do anything. 2, instead of just stoping the step in an error state like being pulled, we count it against our max move total
* Audit
* Moves most forced movement to the framework, adds some components to make things nicer
* Implements a flag that makes the loop always operate, regardless of precedence and without impacting any other loops
* Moves movement subsystems into the right folder
* Hey potato what if you had two procs that did the same thing and one called the other? Wow it's useless
* Merges slipping and force movement
* Converys conveyors over to the system. It's a bit fragile, but I think it's totally worth it to save the sleep loop
* Precedence -> Priority, cleans up some logic errors, makes priority highest to lowest instead of lowest to highest, straight cleans some code up
* Makes poly and bubbles ignore spacedrift, now that precedence actually functions properly. I'm likely missing cases of this, will deal with it later
* Depression, thy name is linter
* Fixes linter, and hopefully fixes the runtimes in ci too
* Wew
* Sets sprays and extinguishers back to legacy, since people do actually seem to have noticed
* Spelling errors my beloved
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* More detail, moves return descriptions
* Converts transit tubes to the system?
* Adds the glide size modifier. Not honestly sure that this should be default, considering how crummy it makes things look for normal walking, but it's useful as hell here
* Adds a force move in dir template, actual support for fast initial steps (wtf old me) and a helper proc for setting delay
* Cleans up displosal code a bit, I thought about adding it to the system but it would functionally be just 'disposal loops'. Maybe I'll make a template subtype? not sure how I want to handle stuff like this
* Cleans up mob movement a bit
* Let's use the controller's visual delay
* Makes the resin thrower nicer, cries
* Cleans up some comments, replaces an implicit world.icon_size with an explicit one, fixes up a typecheck
* typecache instead of double istype. Can't do much about the !atom/movable, list would be too big I feel
* hhh
* bro wtf
* Documents the why of SS_TICKER
* Puts SSmovement on SS_TICKER. Lets us support tick steps
* Cleans up the charge action. Makes it use moveloops
* Fixes CI? kinda worried that this just got dropped
* Converts disposal pipes to move loops. They stutter a bit more then usual as of now, hoping that's a me thing, if it's not I'ma look at uping the priority of the base subsystem
* Moves the move subsystems off background, puts some on ssticker
* Prevents some things that shouldn't move in space from moving in space
* Documents the general form and usage of the system
* Virgin one vs chad once
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Removes unneeded check
* Moves appropriate movement subsystems into SS_BACKGROUND. Removes redundant SS_KEEP_TIMINGs
I do want the behavior of SS_TICKER, which at this point is tick based waits, and ignoring overtime when
calculating next fire.
Since honestly, these subsystems should ignore overtime in regards to next fire, the cost of moving A may be
nothing compared to the cost of moving B.
* Makes the MODULUS macro use floor. I knew our coders would never let me down, glad this exists, thanks ninja
Fixes teleporting caused by shitty round() behavior, adds a "you hit your target" case to homing loops
* Converts blood splatters to move loops, that'll do it
Co-authored-by: Rohesie <rohesie@gmail.com>
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
Turfs have a variable, intact, which conflates three meanings:
Determining whether there's something that can be pried out, such as directly with a crowbar or indirectly with a tile stack and a crowbar off-hand.
Determining whether underfloor pieces are visible.
Determining whether underfloor pieces can be interacted with - by players with tools, through interaction with effects like chemical acid, or foam.
When plating is hit with a stack of tiles, /turf/open/floor/attackby checks whether the turf is intact, and if so, ends the attack chain regardless of whether or not the attempt to hotswap a turf (with a crowbar) is successful or not. However, turfs which want the underfloor to be visible - such as catwalks and glass - set the intact variable to FALSE, and so can be repeatedly placed over one another, as if they were the first tile to be placed over the plating.
This refactors /turf/var/intact into two distinct variables:
/turf/var/overfloor_placed, for whether or not there is something over plating.
/turf/var/underfloor_visible, for whether or not the various underfloor pieces should be invisible, visible, or both visible and interactable.
All references to /turf/var/intact have been replaced with an equivalent overfloor_placed or underfloor_visible reference, depending on which check is appropriate. underfloor_accessibility can take one of UNDERFLOOR_HIDDEN, UNDERFLOOR_VISIBLE, or UNDERFLOOR_INTERACTABLE. This prevents cases such as acid foam or tools phasing through glass floors to affect the underfloor pieces underneath, and covers all kinds of unusual, not-wiring-visiblity usage such as Holodeck completeness, Revenant interaction, or station integrity checking.
major cleanup of modules/atmospherics folder and all related files, still many missing
-cleanup of procs name
-cleanup of vars name
-documentation of some of the procs
-minor changes to some for() logic (no in game changes just early continue or as anything checks)
No in game changes, only code and docs
When I gave vehicles the PASSMACHINE flag in #61793 I forgot that penetrator rounds existed leading to them completely ignoring mechs. This time I created a new flag for vehicles, added it to water particle effects, and excluded it from the penetrator rounds.
Additionally this flag has been added to the heretic's phasing ability.
## 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`
Adds some extra vars and logic to explosion code to make powerful logging entries that should help admins narrow down when explosives get misused.
Records this new info in the feedback database and bumps the explosion version +1 as a result of this.
