## About The Pull Request
A deal with @Fikou
- https://github.com/DaedalusDock/daedalusdock/pull/106
In layman's terms, you can grab this wrench now.
Adds a new pass_flags_self value for click transparency, allowing
objects to be dense without blocking click attempts.
## Why It's Good For The Game
## Changelog
🆑
add: Lockers, crates, and machines no longer block click attempts in
adjacency checks. Basically, you can reach tables cornered between
lockers/machines.
/🆑
## About The Pull Request
Replaces a ton of `turn(dir, 180)` calls with the aforementioned macro.
## Why It's Good For The Game
Afaik, `REVERSE_DIR` was coded to be faster than the classic `turn(dir,
180)` call, being a simple set of binary operations. To sum it up, micro
optimization.
## Changelog
N/A
In #74306, I _thought_ I knew what the cause was, and I both attempted a
potential fix _and_ made tracking it easier. The fruits of my labor paid
off, I know exactly what caused it now.
Basically, the demonic portal will scrape away all turfs in a 5-tile
radius on its `Initialize()`, and if a spawner spawned right next to the
hermit ruin... it would count it as a mineral turf and scrape it away as
well. That's so fucking silly. At least we know now.
## Why It's Good For The Game
The fix is to just make those tiles unscrapeable, which is accomplished
via another turf_flag and filtering those out in the `Initialize()` of
the demonic portals.
I also cleaned up the calls to scrapeaway being `null`, which is really
weird because it just defaulted to the normal proc behavior. Naming the
arguments instead does the same thing (I checked)
## About The Pull Request
It was config'd off to save init time, but having it function in testing
and mapping is more valuble then the time spend on it.
On that topic, we spend roughly 1.7 seconds of init on this.
~1.3 is spent handling the light sources and their light object
modifications (this is potentailly inflated since other sources could
cause the same objects to need updates)
~0.3 is spent searching for space turfs around lighting_objects during
init.
This will impact change_turf slightly too, costing about ~0.07 in local
testing.
It does save time for live however, since we avoid these config checks.
## Why It's Good For The Game
I believe this time is worth spending.
I've had people try to "fix" artifacts of starlight not being enabled,
things that aren't bugs.
The test environment should as much as we can make it reflect the visual
reality of the game. This helps ensure that
## Changelog
🆑
server: The starlight config has been removed, as it is enabled by
default
/🆑
## About The Pull Request
This is a remake of #70242
Replaces all instances of ``do_mob`` and ``do_after_mob`` with
``do_after``.
## Why It's Good For The Game
All 3 of these are just copy pastes of eachother but some miss some
features (like do_after not checking for target loc change, which helps
towards fixing https://github.com/tgstation/tgstation/issues/66874
though it doesn't because mechs are setting ``do_after`` on the mob in
the mech) and signals only being used on ``do_after``.
## Changelog
🆑
fix: Mechs should now cancel out of drilling when they move.
/🆑
<!-- 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
Hey guys, it's your boy. Back at it again with another meteor-adjacent
event PR.
Adds the Sandstorm random event, inspired by the long-unused admin only
one. It picks a direction to approach from, alerts the crew of its
imminent arrival, and after a little over a minute of preparatory time,
sends waves of sand and dust to grind down everything in that direction.
To accomplish this, some minor adjustments had to be made to meteor
generation code. They can now be passed an optional arg for a direction
to be thrown from, and will pick a random one if no direction is given.
Also introduces the newest addition to our cast of meteors -- space
sand! It's even weaker than space dust, and shows up exclusively in this
event. Space sand is **ineffective against rwalls**, and will not damage
the arrivals area's high-tech sand-resistant glass. This is to prevent
this event from venting one of the most dust-vulnerable areas on the
station, and to make sure new players aren't shafted into firelock hell
when the right angle is picked.
I did a lot of testing and tweaking of numbers to get the damage to
average at about the level I'm comfortable with. This is meant to be a
high-impact event that isn't as destructive (or unavoidable) as a meteor
wave. Speaking of avoidance, let's talk about mitigation:
You get an early warning and a direction the sand will come from. You
have time to grab repair supplies, move to safety, get a MODsuit. You
can make worthwhile repairs as the sand comes in from inside (or
outside, if you're brave enough) with nothing more than a welder and
iron sheets. If you're feeling particularly spicy, you can leverage your
prep time setting up shield generators, which spawn in engineering and
have been added to the maintenance machines loot pool. Anyone can
contribute, so do your part as a good crewmate and help out!
All that being said, the event can't be prevented entirely. Shit's going
to get shredded, especially on the outside of the station. Damage will
vary heavily based on the station and direction, ranging from
inconsequential to threatening. It should happen late enough into the
round that, at the bare minimum, the crew shouldn't be caught
unprepared.
For those of you who are worried, the ORIGINAL sandstorm admin event is
still with us too. It's been moved from the space dust file into the
Sandstorm event file. This PR also makes a very minor change to the
naming of the space _dust_ events, for better menuing.
So, to sum it all up: Sand hits grinds down one side of the station, you
get a minute of warning, shield generators now spawn in maintenance. Be
a good crewmate and help where you can.
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
More event variety is good, and events that give the players agency on
how bad the impact will be is even better.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## 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. -->
🆑 Rhials
add: Sandstorm random event! A random side of the station is pummeled by
an onslaught of sand and dust. If you hear that one is approaching, grab
a welder and some iron to help with repairs!
add: Space sand! It's weak and doesn't hurt reinforced walls, but
shouldn't be underestimated in high quantities.
code: You can now pass a start direction to the
spawn_meteors/spawn_meteor global procs.
/🆑
<!-- 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. -->
## About The Pull Request
[Saves 0.2 seconds of init time. 50% of emissive
blockers](8318b648f6)
Emissive blockers are a decent expense during init, even these, which
are the ones that update outside of initialize.
I've inlined them, removed some redundant vars and checks, reduced the
arg count, and shifted some things around. This ends up saving 200ms, or
50% of its total cost.
I also shifted mutable_appearance about a bit. it's not a massive
saving, but it is technically faster
[Prevents a few redundant appearance_updates, saves 0.8 seconds of
init](5475cd778b)
Prequisit info: update_appearance is decently expensive
It's good then to only do it if we have a reason to, right?
Me and moth were shooting the shit about just general init time, and we
came up with the idea of tracking which update_appearances actually
"worked" and which didn't.
That bit comes later, let's enjoy the fruits of that work first
First, holograms were calling update_appearance on process, for almost
no reason.
I patched the one event they don't already "react" to, and then locked
it behind a change decection if.
good for live, doesn't impact init.
Next, decals. If you add a decal to something before it inits, it'll
react to the after successful init signal.
The trouble is the same atom could have its appearance updated from this
MORE then once, since decals can be stacked on tiles, and signal
unregisters don't work once the signal is sent.
So we add a flag to track if we've had this happen to us or not, so it
only happens once.
saves 80 ms
Power! lots of things call power_change on init, often more then once.
We'll update appearance for each of those calls, even if only one is an
actual change.
That's silly, better to track what sort of power we're using for our
appearance and go off that changing
This was taking about 300ms. Really stupid
Icon smoothing. After emissive blockers were added, any change to
something's icon smoothing would lead to an update_appearance call.
Nasty shit, specially cause of walls, which don't even use emissive
blockers.
Ok then, so we'll always update appearance for movables, and will allow
turfs that are interested to hook it manually.
Not many of those anyhow
This is slightly a dev ux thing, but it saves 600ms so I think it's
worth it. Rare case anyway
Telecomms:
telecomm machines were updating appearance on process. This is to cover
for them turning on/off on process.
Better then to just check if on actually changed.
This cost adds up midgame, doesn't impact init tho
Materials:
There's this update_appearance call in material on_apply. it doesn't do
anything.
The logs will lie to you and say it does, but it's just like reapplying
emissives. It doesn't need to exist
Saves like 50ms
Canisters:
Live thing, lots of time wasted updating appearance for no reason, lets
see if we change anything first yes?
[Uses defines to wrap update_appearance for
tracking](4fa82e1c9d)
[Undoes _update_appearance changes, instead reccomends 2 regexes to
use](a8c8fec57a)
I need file and line number for my tracking, so I need to override
update_appearance calls, and also preferably not require every override
of update_appearance to handle dummy file + line args.
So instead, I created a wrapper proc that checks to see if appearanaces
match (they're unique remember, the two of the same visual appearance
will be equivalent)
The trouble is I can't intercept JUST proc calls, or JUST function
definitions with defines. it needs to be both.
So I renamed the /update_appearance proc to /_update_appearance
this way I can capture old uses, and don't need to worry about merge/dev
brain skew
~~It does mean that all update_appearance proc definitions now look
weird tho.
My profiling is leaking into dev ux. I wish I had better templating.~~
**The above is no longer being pr'd**, it's instead just recommended via
a few regexes adjacent to the define.
Smelled wrong anyhow
[Adds a setter for panel_open, so I can update_appearance on
it](cf1df8a69f)
## Why It's Good For The Game
Speed
* Makes only station areas part of Statioj
* Makes only subtypes of /area/station be part of the station
* Removes Icemoon and Shuttles as a check for Anomaly placers as they aren't needed anymore, not being part of shuttles.
* Removes a ton of uses of NO_ALERTS where it is no longer needed.
* Removes overlay queuing, saves 6/7 seconds of initialize. Lightly modifies stat tracking macros
So we have this overlay queuing system right? It's build with the assumption
that the "add to overlay list" operation is real expensive, and is
thus useful to queue removals or additions.
It turns out that it just isn't, at least during init. In my testing the
operation of queuing took LONGER then the actual overlay add/remove did.
That's ignoring the cost of the subsystem's work.
I've also modified part of the stat tracking macro, since it took a good
bit of cpu time, and didn't seem to well, do anything. So far as I can
tell it always evaluates to 1
* Replaces `being_shocked` and `shocked_1` with `TRAIT_BEING_SHOCKED`, removing a flag_1, taking us away from the possibility of hitting the flag limit.
Currently, storage works as a subtype of /datum/component, utilizing GetComponent() and signals to operate. While this is a pretty good idea in theory, the execution was pretty trash, and we end up with alot of GetComponent() snowflake code (something that shouldn't even need to be used frankly), and a heaping load of scattered procs that lead into one another, and procs that don't get utilized properly.
Instead, this PR adds atom_storage and proc/create_storage(. . .) to every atom, allowing for the possibility of storage on quite frankly anything. Not only does this entirely remove the need for signals, but it heavily squashes down the number of needed procs in total (removing snowflake signal procs that just lead to one another), reducing overall proc overhead and improving performance.
* organizing flora file and icon states, & flags
Changes the typepath for a lot of flora, and adds new paths depending on the amount of icon states the flora had, for better modularization on mappers. Also adds flags to the flora depending on what type it was, instead of 3 bools
* Getting ready to attempt to modularize flora
Moving most vars and procs from ash flora into the normal flora type path, as a general preparation to add more here
* Weighted products & Region Messages
Rewrites flora code so a flora's produced items can be initialized with a weighted list. Also has some improvements, relating to item stacks.
Adds an option via variables to separate 3 messages into 3 possible regions, or the old method where the message changes when the value is exactly the same as the low or high harvest value
* organizing + documentation on procs
* Documentation, Organization & Modularization
(DOMing) yeah, I dom
Gives variables for tools that can harvest flora, a blacklist of them, and modularizes variables a bit.
Retypes the stump to be a subtype of a tree, which just deletes after being harvested
* Adds the ability to uproot flora with a shovel
* added eswords to the list of things that can cut
* ausbush junk
* code review appreciation + changing drag_slowdown
* more code review appreciation
* kirbyplants ComponentInitialize() -> Initialize()
* forgot glob.
About The Pull Request
Alternative to #65354
Ok so like, there was a lot of not floor types on /floor. They didn't actually want any of their parent type's functionality, except maybe reacting to breaking (which was easy to move down) and some other minor stuff.
Part of what we don't want them to have is "plateable" logic.
I should not be able to put floor tiles on the snow and be fine. It's dumb.
Instead, I've moved all non floor types down to a new type, called /misc.
It holds very little logic. Mostly allowing pipes and wires and preventing blob stuff.
It also supports lattice based construction, which is one of the major changes here. I think it makes more sense, and it fixes an assumption in shuttle code that assumed you couldn't place "a new tile" by just hitting some snow with a floor tile.
Oh and lattices don't smooth with asteroid tiles anymore, this looks nicer I think.
Moving on to commits, and minor changes
Changes clf3 to try and burn any turfs it's exposed to, instead of just floors
Moves break_tile down to the turf definition, alongside burn_tile
If you're in basic buildmode and click on anything that's not handled in a targeted way, you just build plating
FUNCTION CHANGE: you can't use cult pylons to convert misc tiles over anymore
Generalizes building floors on top of something into two helper procs on /turf/open, reducing copypasta
Adds a new turf flag, IS_SOLID, that describes if a turf is tangible or not.
Uses this alongside a carpet and open check to replace plating and floor checks in carpet code. This does mean that non iron tiles can be carpeted, but I think that's fine
Moves the /floor update_icon -> update_visuals call to /open
This change is horrificly old, dating back to 8e112f6 but that commit describes nothing about why it was done. Choosing to believe it was a newfriend mistake. Uncomfortable nuking it though, because of just how old it is. Moving down instead
Create a buildable "misc" type off open, moves /dirt onto it
Basically, we want a type we can use to make something support
construction, since that can be a messy bit of logic. Also enough
structure to set things up sanely.
I'm planning on moving most misc turfs onto it, if only because
constructing on a dirt tile with rods should be possible, and the same
applies to most things
Murders captain planet, disentangles /turf/open/floor/grass/snow/basalt
Adds a diggable component that applies the behavior of "digging"
something out from a turf.
Uses it to free the above pain typepath into something a bit more
sensible
The typepaths that aren't actually used by floor tiles are moved onto
/misc
The others are given names that better describe them, and kept in
fancy_floor
Oh and snowshoes don't work on basalt anymore, sorry
Snowed over platings now actually have broken/burned icon states, fixing black holes to nowhere
Misc turfs no longer smooth as floors, so lattices will ignore them
Placing a lattice will no longer scrape the tile it's on
Ok this is a really old one.
I believe this logic is a holdover from kor's baseturf pr
(97990c9)
It used to be that turfs didn't have a concept of "beneath" and instead
just decided what should be under them by induction. This logic of "if
it's being latticed scapeaway to space" made sense then, but has since
been somewhat distorted
We do want to scape away on lattice spawn sometimes, mostly when we're
being destroyed, but not always. We especially don't want to scape away
if someone is just placing a rod, that's dumb.
Adds a path updating script for this change
I've done my best to find all the errors this repathing will pull out, but I may have missed some. I'm sorry.
Why It's Good For The Game
Very old code made better, more consistent turfs for lavaland and icebox, better visuals, minor fix to snowed plating, demon banishment in lattice placement, fixes the icebox mining shuttle not being repairable
Changelog
cl
add: Rather then being tileable with just floor tiles, lavaland turfs, asteroid and snow (among other things) now support lattice -> floor tile construction
fix: Because of the above, you can now properly fix the icebox mining shuttle
refactor: Non floor turfs are no longer typed as floor. This may break things, please yell at me if it does
/cl
Adds the foundational system for contextual screentips, which will show you what you can do with objects/items, including through context, such as what you are holding.
Provides several helper elements for most use cases, and applies it to a handful of common objects in order to show the full breadth of the system.
Changes screentips preference from on/off to on/off/only with context. Players who originally had it on off will have it migrated to only with context, though can re-disable it.
Kudzu's mutation's "severity" now reflects its gameplay severity, which factors into its maximum severity as well as chance of appearing, which is determined by its potency.
The old severity values were moved to defines.
Kudzu now stops spreading if the tile that the vine is on has a temperature lower than 100K.
Maximum spread and spread rate of kudzu have been lowered, productivity and potency for random event kudzu have been increased to compensate.
Adds a new "cold-proof" mutation for kudzu that a) allows kudzu to spread in low temperatures, and b) gives any venus human traps that spawn from the flowering trait cold-proofness
Code-wise, instead of using process_temperature, a new flags system is used.
Readds cold damage to venus human traps (although at a lower rate than before).
Venus human traps now inherit temperature-proof traits (and those only) from their parent plant (although fire-proof + flowering should not be possible without admin intervention).
Venus human traps have had their damage reduced (from 25 to 20) and have their hardstun replaced with 85 stamina damage (contractor baton level) and a 1 second knockdown. They are still very deadly but now hopefully at least people can fight them without getting immediately stunned and killed.
The kudzu thorns and toxicity traits have been buffed to reflect that they now cost severity and that they only have a 10% chance of even affecting people to begin with.
This removes code/__DEFINES/misc.dm and moves all the defines to either:
another existing define file
new define file
local .dm file if the define was only used in one file
I also deleted defines that were not being used and added documentation to all of the ones that were moved out of misc.dm
Why was this needed? People were basically using the misc.dm file as a dumpster to toss all their defines into that was creating one giant mess. The defines have been organized into their proper groups and files now.
* Fix blastcannon typo. Hopefully fix blastwave phasing.
* Fix projectile phasing on direct target
* Should unspaghetti sniper bullet var definitions
* Makes phasing rounds phase
* Preserve original behavior of sniper rounds
Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else.
Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter.
Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away!
Added a couple components that convert a number into an array of binary digits and viceversa.
May help players mak more complex and advanced components without filtering those lacking knowledge in the binary field.
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.
fixes#60197
woke up today with a ridiculous idea of semi-automatic compile time loop unrolling, wasnt worth the complexity in the least but it made the basis of this PR which i then continued work on. makes area_sensitive_contents into a more general system of important_recursive_contents where we can define reasonable uses to replace recursive contents iteration of the type found in get_hearers_in_view() as long as everything that uses it isnt something incredibly common to the point that it noticeably increases memory usage.
* optimizes some internals of signal and component code
* comment and a better var name
* gets rid of DF_SIGNAL_ENABLED and all referencing code because its dumb
* gets rid of NONE | CallAsync(stuff)
* fixes conflicts
* puts NONE back in
* Nonfunctional greyscale code
* Functional greyscale sprites via filter
Probably going to set the icon instead later
* Switches to greyscale json config
* Adds the reference layer type and converts the other canister types
* Working previews
* Adds readme
* Fixes overlays and breaking
* Removes old canister sprites
* Removes an unused var
* Fixes tgui lints
* Removes a bunch of the old canister icon states
Yeah I need to fix relabeling as well
* Removes some debug sprites
* Sorts canister type list and breaks up base shader step
* Removes an unnecessary preview hack
* Makes prototype canister greyscale
* Properly sizes the ui
* Fills in the canister map sprite
* Adds some more warnings to layers
* Makes broken overlay more prominent
* Removes a preview var that isn't needed anymore
* Cleans up client ref in Destroy
* Cleans up the tgui window a bit
* Update GreyscaleModifyMenu.tsx
* Animates the canister falling over
* Removes a commented out line that's no longer needed
Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
When I was in the process of developing my atmos fixes/optimizations, I focused heavily on maintaining the area
of excited groups, since growing delayed self_breakdown(), and lead to shitty behavior which I thought was the
result of my sleeping changes.
This was not the case, those who came before me knew better, as always.
Especially now, since I've unhooked breakdown from excited groups gaining new tiles, my concern was unfounded,
and actually lead to shitty behavior and wasted time.
I failed to recognize the value in random garbage_collect()s, they help prevent mass gas equalization over large
spaces, they make gas appear to move more consistently when in these large spaces, and they lessen the amount of
self_breakdown()s over large turf lists, which is very helpful for lowering the overall overtime of the
subsystem.
This fixes my mistake, and purges the excited cleanup subprocess from the air subsystem. It's free real estate
babyyyyyyyy.
Creates update_name and update_desc
Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together
Less non-icon handling code in update_icon and friends
Signal hooks for things that want to change names and descriptions
99%+ of the changes in this are just from switching everything over to update_appearance from update_icon
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
* Moves /datum/var/signal_enabled to datum flags
`signal_enabled` is a variable on /datum, so present almost every object
in the game. Folding it into the existing `datum_flags` variable will
save allocating a variable on every datum in the game.
- Clown weaponry was using the `signal_enabled` variable to turn their
attached slippery component on and off when the shield/sword was
toggled. They now just remove/add the component, rather than touching
deep datum internals.
There is now a mobility flag that determines a mob's ability to rest. Only works with living mobs. Most living mobs shouldn't be able to rest, so it's only true for carbons, cats and PAIs. Fixes#56034. Fixes#55975 by making borgs unable to rest.
Speeds up gas movement significantly
Documents the intent and finer details of the atmos system (Thanks dunc)
Fixes excited groups constantly rebuilding, this broke 4 years ago
Fixes superconductors just straight up not working
Allows turfs to sleep while inside an excited group
Adds a new subprocess to SSAir to support rebuilding in this state
Most heat based behavior no longer relies on being inside a fire
Adds a new element to support doing this cleanly
Adds a new subprocess to SSAir to support doing this while a turf is asleep
Refactors air_update_turf to allow for finer control
Makes apcs take damage in heat to prevent infinite plasma fire diffs
Cleans up immutable gas mixtures to make them work properly when the mix has gas in it
Planetary turfs no longer create a new copy of themselves each time they process. We instead use a global
immutable mix
Cleans up a typed for loop in reactions
Canisters will take damage from outside heat now
Speeds up excited group dismantle
Increases the superconductor threshold by 200k
Cleans up some roundstart ATs on some ruins
Uses /turf/open/var/excited to track if a turf is actively processing, preventing a |=
Prevents openspace from trying to melt
Tweaks a canister examine line
Makes planetary turfs reset to base when broken down as part of an excited group
Makes it impossible for planetary turfs to rebuild, just like space tiles
Fixes closed turfs not activating their replacement when destroyed by moving closed -> open turf activation to
the adjacent air subsystem. They were activating and then going back to sleep before adjacent air got a chance
to tick.
Fire alarms will trigger when the area gets too cold for humans
This PR essentialy moves away from the extremely microwave dependent cooking we have for meat right now, and making it a bit more sensical by making you use a grill to grill meat. The grill takes a different time (with variation) for different grilled things. Once finished it will turn that food into something else.
Yes, this does mean creating burgers takes longer, but in return you can make more patties at once, and you are not required to stay at the grill while its going. This lets you cook as much as you want at once, just make sure your meat doesn't burn!
In the future, I hope to move more things like this to machines similar to this (Pasta boiling, putting eggs on the griddle, soup making, etcetera) to create for a more interesting cooking experience.
This replaces lavaland's old diagonal tunnel gen which was really
horrendously jammed into asteroid floor code (?????) with Cellular
Automata which runs in rust (PR for that here:
https://github.com/tgstation/rust-g/pull/57 ). The new code is a bit
cleaner, but also looks better.
VID: https://streamable.com/a45ke2
Things to do:
- Make an icemoon version
- Fix the roundstart atmos adjacency issues
I asked AnturK if this was an acceptable PR for this month; he said it
was okay as long as I didn't add new areas, which I don't plan to do.
But if anyone thinks this PR breaks the spirit of the month I'll open
it again in december.
Yeah uhh this'll probably need testmerging even after it's done because yeah it's a bit big.
If y'all want me to atomize this into two PRs (pass flags vs projectiles) tell me please. Pass flags would have to go in first though, in that case, as new projectile hit handling will rely on pass_flags_self.
Pass flags:
Pass flags handling now uses an atom variable named pass_flags_self.
If any of these match a pass_flag on a thing trying to pass through, it's allowed through by default.
This makes overriding CanAllowThrough unnecessary for the majority of things. I've however not removed overrides for very.. weird cases, like plastic flaps which uses a prob(60) for letting PASSGLASS things through for god knows why.
LETPASSTHROW is now on pass_flags_self
Projectiles:
Not finalized yet, need to do something to make the system I have in mind have less unneeded overhead + snowflake
Basically, for piercing/phasing/otherwise projectiles that go through things instead of hitting the first dense object, I have them use pass_flags flags for two new variables, projectile_phasing and projectile_piercing. Anything with pass_flags_self in the former gets phased through entirely. Anything in the latter gets hit, and the projectile then goes through. on_hit will also register a piercing hit vs a normal hit (so things like missiles can only explode on a normal hit or otherwise, instead of exploding multiple times. Not needed as missiles qdel(src) right now but it's nice to have for the future).
I still need to decide what to do for hit handling proper, as Bump() is still preferred due to it not being as high-overhead as something like scanning on Moved(). I'm thinking I'll make Moved() only scan for cases where it needs to hit a non-dense object - a prone human the user clicked on, anything special like that. Don't know the exact specifics yet, which is why this is still WIP.
Projectiles now use check_pierce() to determine if it goes through something and hits it, doesn't hit it, or doesn't go through something at all (should delete self after hitting). Will likely make an on_pierce proc to be called post-piercing something so you can have !fun! things like projectiles that go down in damage after piercing something. This will likely deprecate the process_hit proc, or at least make it less awful.
scan_for_hit() is now used to attempt to hit something and will return whether the projectile got deleted or not. It will delete the projectile if the projectile does hit something and fails to pierce through it.
scan_moved_turf() (WIP) will be used for handling moving onto a turf.
permutated has been renamed to impacted. Ricocheting projectiles get it reset, allowing projectiles to pierce and potentially hit something again if it goes back around.
A new unit test has been added checking for projectiles with movement type of PHASING. This is because PHASING completely causes projectiles to break down as projectiles mainly sense collisions through Bump. The small boost in performance from using PHASING instead of having all pass flags active/overriding check_pierce is in my opinion not worth the extra snowflake in scan_moved_turf() I'd have to do to deal with having to check for hits manually rather than Bump()ing things.
Movement types
UNSTOPPABLE renamed to PHASING to better describe what it is, going through and crossing everything but not actually bumping.
Why It's Good For The Game
Better pass flags handling allows for less proc overrides, bitflag checks are far less expensive in general.
Fixes penetrating projectiles like sniper penetrators
This system also allows for better handling of piercing projectiles (see above) without too much snowflake code, as you'd only need to modify on_pierce() if you needed to do special handling like dampening damage per target pierced, and otherwise you could just use the standardized system and just set pass flags to what's needed. If you really need a projectile that pierces almost everything, override check_pierce(), which is still going to be easier than what was done before (even with snowflake handling of UNSTOPPABLE flag process_hit() was extremely ugly, now we don't rely on movement types at all.)
