I wanted to touch a backpack sprite and got mad with everything being on the same dmi file sooo...
Creates a dmi for backpacks because we had everything shoved on the same back.dmi or storage.dmi which is a headache to work with.
I tried to standardize the name between backpacks, satchels and duffels and some minor clarity while I was there, stuff like:
securitypack -> backpack-security
satchel-sec -> satchel-security
brokenpack -> bag_of_holding-inert
Also made a new obj icon file for the ethereal backpack, it had it's own file for the mob worn icon so now both icons have their own dmi.
Probably should rename it to "species" if we ever add more species/lore related backpacks but that is a future issue.
I didn't touch the inhand dmis or "standardize" their name, they are well split enough and just to avoid making a zillion changes on the same PR.
I might look into it if this PR is merged.
About The Pull Request
Fixes#69043 assemblies not providing a UI when part of a one-tank bomb. (This doesn't count voice analyzers, which don't have UI)
Fixes#68139 assemblies triggering themselves (and often turning themselves off).
Fixes timers ceasing to loop if the timer is set to less than the 3-second anti-spam threshold.
#69335, #68733 signalers occasionally runtiming due to qdel'd weak reference datums. Already addressed by another PR
Proximity sensors and mousetraps work on more wire datums, but proximity sensors are still buggy.
Igniter-sensor pairs can detonate fuel tanks properly, including plumbed fuel tanks. Fuel tank explosions scale with how much fuel is in them; this is slightly nerfed from existing values.
The fuel tank detonation code has been made generic, but other reagent dispensers have rigging turned off. If turned on with a varedit, you can rig and detonate water and other reagent tanks. Reagent tanks can theoretically both explode and spread reagents if it should happen to contain both welding fuel and other stuff. I have not actually tested this part of it, but I have detonated both water tanks and fuel tanks and each works correctly.
In making mousetraps work on wire datums, I had the opportunity to make it so that you could place a mousetrap in a door's wire and it would activate when someone passed through the door (useful to bolt a door open when someone authorized goes through, for example). This is a fun mechanic but does not make sense for a simple mousetrap to be so powerful, so it is disabled. Ideally, you could put the laser tripwire in a door's wires to do the same thing, but that would be a massive rework. Mousetraps still work in on-found mode for all wire datums, and will work on items with wiring datums (like C4 and chem bombs) when stepped on.
The signaler runtimes were a result of weak_ref datums being deleted, and the communications system not handling that. It's probably not ideal to run null checks in the post_signal loop, but I am not going to worry about it.
Many of the assemblies were not properly registering when the assembly holder was attached to an item. This was most important for proximity sensors, but that also has other problems that I haven't been able to track down.
The problem with UI not appearing was a result of the transition to TGUI however long ago that was; the proc that assures TGUI that you have the right item needed to be aware of one-tank bombs and similar, or else when you pass along an interact request it says "but you can't see it" and ignores you.
Why It's Good For The Game
Bugfixen.
The thing with the reagent dispensers only got this complicated when I realized that the plumbed fuel tank variant wasn't a subtype and therefore couldn't be rigged. And then... I basically just scaled it because the flat scale no matter the contents of the tank offended me. You could wrench open tanks, drain them entirely of fuel, rig them, and they would still go off like a pile of dynamite.
I used to have code in my branch that turned chem bombs into variants depending on the trigger, with mousetraps being mines for example. That's honestly the main reason I went out of my way to make mousetraps work better as assemblies. I could wish it were better supported, but mousetraps on grenade wiring will have to do for now.
Changelog
cl
balance: Welding fuel tank explosions have been scaled slightly down and require the fuel tanks to actually be full of welding fuel
fix: You can detonate welding fuel tanks with an igniter-sensor assembly
fix: You can reach your one-tank bomb's assembly controls by activating the item in your hand.
fix: Certain assemblies should no longer turn themselves off.
fix: Clumsy fools handling a mousetrap-based multi-part assembly may set it off by accident
/cl
* Makes flags properly check themselves
Byond ref: https://www.byond.com/docs/ref/#/operator/&
Basically, flags should use & instead of ==
We can have more than 1 slot on any item, so it's preferred that we do this instead. Even if it doesn't immediately fix any problems, it's something that should be the standard anyways to prevent it from ever being a problem.
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
* 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
* Adds a base modsuit chestplate allow list, cutting down on copy paste
* Allows Jetpacks to work while equipped to a de-hardcoded slot_flags list
* Allows the Captain's jetpack to fit on space suits and MODsuits by default
* Makes the Captain's jetpack fit on the Suit storage slot.
Hey there,
Remember swiping credit cards, before everything was chipped? You know how sometimes if you went too slow, the transaction might fail, the cashier had to plonk in some digits on their machine, and you had to go again? That kinda sucked.
If you're too young to get that reference, just imagine the card swiping task in AMONG US. Doesn't that minigame suck? You know exactly what that is. Same principle.
Anyways, that's pretty much what was going on here. The reason why SS.Economy would break so god damn hard if you swiped an ID before the machine's "boot up" slowflake animation was complete is probably due to the line where it starts fast processing. I added an early return to check for if the animation was complete by leveraging a var we already set at the end of the process, because I am lazy.
There's probably a few other ways you can tackle this issue, but this feels right to me in a thematic sense. I'm willing to change it if needed though.
* Removes recharger tablet parts
Removes 'advanced' tablet subtypes that we used before PDAs were added, in some jobs.
Replaces Roboticist's advanced tablet mail with a laptop
Moves the notepad's note var from the tablet, to the note app
Moves modular computer's defines into their own file
Machine computers now directly use power from the machine they're in, while the rest uses power cells.
Silicon tablets don't use power at all.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Adds the installed message phrase for voice analyzers to logging
Hey there,
Sometimes, it's CBT to figure out what exactly made a bomb go off, especially when a voice analyzer is involved. Now, when a voice analyzer is involved in TTV Bomb/Grenade explosions (already logged), it will also output the recorded phrase when present.
To do this, I just span up a quick `isvoice()` macro define to ensure that we would get the variable, and it would just append the message that we were already spitting out into logs. I rewrote how grenade logs currently operate a bit, let me know if I accidentally omitted something critical.
* virtual limbsanity
* remove old file
* indent fail
* dumbassery cleanup
* unlint + tweak
* stop coding while high
* internal screaming
* kill another species dependancy
* make sure it has a default
* makes the unit test actually work
* fix monkeys
* Refactors hallucinations slightly, organizes them
* Refactors hallucination into a status effect
* Further hallucination proper refactoring
* Refactors battle hallucinations
* Refactors "fake item other" hallucination
* Gets it a bit closer to working state
* Refactors screwydoll and fake alerts
* Refactors fake inhand items
* Refactors a few more.
- Fake death
- Fake messages
- Fake sounds
- Projectiles
* Refactoring delusions, hallucination effects
* Furthering the hallucination status effect
- removes copypaste of hallucination pulses
* Almost finalizes the changeover to status effect
* Last staus effect stuff
* Delusion business
* Airlocks, fire, and more delusion stuff
* Finishes screwyhud. It compiles now!
* Swaps screwyhud over to a grouped status effect
* Removes hal_screwyhud
* Comment
* Bugfixing
* image cleaning
* Get rid of this it came back
* What if I finished this branch?
* Oops
* Messing with the randomness
* Mass hallucination tweaks
* +
* Some more mass tweaks
* Review
* Updates
* Unit tests hallucination icons
* More tweaks
* Move folder
* Another re-name
* Minor tweaks
* Anomaly unity
* Mass hallucination buffs
* t
* Sig
* Merge
* Lints
* Unit test already coming in clutch
* Another failure
* Use named args for cause_hallucination via some define trickery
* Some cleanup
* This is better
* adds some hallucinations
* Oops
* More sounds
* Tweaks
* Some additional documentation
* Flash
* Fixes mass hallucination
* Json changes
* Updates documentation
* Json conflicts
* Makes it work
* Missed that one too
* Helpers
* More signalization (WIP)
* Fixes bump
* Missed a helper use
* Dumb
About The Pull Request
First and foremost, guts out the previous, arguably cursed "rigged" functionality from light tubes. Light tubes now have a capacity of 20 reagents. Light tubes will now splash their contents upon shattering, instead of just releasing plasma gas into the air (if rigged). Lightbulbs with reagents inside of them will now transfer with them to the light fixture they're inserted into, which will slowly heat the contents to a maximum of 1000 degrees.
Heating the plasma reagent manually leads to it harmlessly boiling out of the container and dissipating, effectively ruining the original functionality. To account for plasma boiling over (when it should be bursting into flames) a SEALED_CONTAINER reagent container flag has been added. This is mostly just to prevent the plasma from leaving the container until it is ignition-ready. As a result, light tubes rigged the old way no longer harmlessly explode, and instead produce a small, (mostly) self-contained fire in the area surrounding the light.
Light tubes (and light fixtures with reagents in their lightbulb) now show their reagent contents upon examine. It's only fair to reward attentive people with a chance to avoid impending disaster, but on the other hand lightbulbs are transparent and you should just be able to look through them anyways.
As a bonus, all of this SHOULD be handled in a way that doesn't put any unnecessary strain on machine processing or anything. Rejoice.
Why It's Good For The Game
Lightbulbs being reagent holders was a huge missed opportunity, with their only use being for the disappointingly ineffective plasma-rigging functionality. This expands on the idea, and reworks the original functionality to be much more interactive. Bigger sandbox! Deeper sandbox!
Changelog
cl
add: Rigging light fixtures now works with more reagents than just plasma. Light fixtures will heat the reagents of their inserted lightbulb, up to a maximum of 1000 degrees. Lightbulb tubes now hold 20 reagents to make this more usable.
add: Lightbulbs will now splash their contents on whatever they're shattered by. Their contents are also now visible upon examination.
Brand new sec sprites. Done by yours truly. Revival of #68024.
Resprited Items:
Security Jumpsuit
Security Skirt
Warden Jumpsuit
Warden Skirt
HoS Jumpsuit
HoS Skirt
HoS Formal Uniforms
Armour Vest
Security Winter Coat
Warden Jacket
HoS Coat
HoS Parade Coats
HoS Wintercoat
Security Belt
* Basic outline for Bartender RCD
* Alphabetically sorted drink and booze dispenser reagent lists
* Added soda/booze synthesizers to the service plumbing constructor
* name change
* Syntax Error fixing
* Name and research updates
* Updated constructor selection
* Mixing chamber sister class
* brewery RCD redo again
* Custom Mixing Chamber UI
* Finalized plumbing reskins
* Allowed the service techfab to print chemical recipient boards
* added test sprites and removed un-needed renames
* Last Rename
* leftover whitespace fixes
* more whitespace removal
* one more name update
* refactor for upstream
* fixing TGUI i broke
* last whitespace fix
* last last whitespace fix
* please have this fix the whitespace
* updated doc comments
* updated ui_data and ui_act procs make more sense
* Update code/modules/plumbing/plumbers/reaction_chamber.dm
Co-authored-by: lex <alexdpow@gmail.com>
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* Fixes Bread Smite Causing Some Fucked Up Shit
Hey there,
So basically, when you had the bread smite done on you, you were _just_ added to the contents of the bread. Nothing more. That means that you could pick it up. You couldn't add it to your bag (it would always return back into your hand(?)), but it would create some weird oddities that was just cursed in general. Let's make it so you can't hold the container that you are contained within by giving you HANDS_BLOCKED.
* actually we don't need the named arg
lets get rid of the cursed thing entirely
* removes sanity check
* we do a bit of component trolling
THIS TOOK ME TWO HOURS FUCK YOU
* removes cruft comment
* cleans up code a teeny bit, upgrades to incapacitated
* wait that named arg is still there wtf
* Review Time
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* wrong operator and wrong order of operations
* null out the container
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* checks to see if container is qdeld
* weakref time
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Readds shoe stealing shortcut
Readds the shoe stealing shortcut! Everything is the same, you must have
legs selected, the target must be lying down, and now you must have the
slap emote enabled.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
When I moved asterioid stuff off /floor, I neglected some logic that
blacklists building on non floors.
Given that this USED to work on you know, asteroid tiles, I think this
is build to catch space and such
So I replaced it with a closed check, and a turfs_without_ground
typecache use, which should serve the same intent
So you can like, you know, ash lizard again
I swear I was gonna do this earlier, just sorta forgot all about it
first things first, back when LemonInTheDark changed the interact_range code he did a slight modification that broke the AI cards, namely, he did this (not saying its a bad change, it is actually a good change, just mentioning what change caused the issue im fixing now):
now, his change does make sense, since he changed the range default to 0 instead of 1, however "null" is also used as a range, specifically for AIs, now this normally isnt an issue for the AI itself, as the AI generally gets a TRUE in its interaction checks before it gets down this deep (machines have a bypass specifically for AI), but there is one situation in which it does go this deep: AI Cards, when in an AI card the AIs interaction range is set to 0 and their interaction is disabled, thereby making it impossible for them to interact with anything, now when a player opens the card UI and enables the AIs ability to interact, this sets their range back to null, aka unlimited, the issue now however, is that since "null" is treated the same as "0", and AIs in cards dont hit the same bypasses an AI core does, Lemons change to submit a false return for 0, is also submitting false for null, meaning the AI card cannot interact with anything except the tile its on, despite having null/unlimited range....
fixed by changing the null value to infinity where it is used
additionally my fix of can_interact() code apparently had the unintended side effect of not allowing rotations of machines if theres no power, i missed this entirely because thats such a specific situation, since you try rotating with APC power in most cases, it also didnt affect most machines, that said the fix was simple, just changed the proc being called to only check distance, not power. fixes#61852
and last but not least, fixes some code with the syndie bombs interactability, namely removes a redudant section, and adds a check for range, turns out there were no checks for range so you could in theory open the UI and walk away and then activate it from another location, so added a quick check to ensure you actually CAN interact with it before letting you push buttons in the UI
* Preset Boxes File De-concatenation
Hey there,
We had one file that was like eighteen-hundred (1800) lines full of just... box presets. There was no rhyme or reason to where anything was in the list, it just sorta got to the point where new features were found near the bottom with zero grouping. So, let's de-concatenate this massive file and give it some proper grouping.
While I was in the area, I did some file cleanup, using `snake_case` instead of whatever the fuck some vars were, alphabetizing and cleaning up lists to have trailing commas, that sorta stuff. Let me know if I broke something somewhere.
* documentations, var improvement
* adds some documentation, clears up some variables
* Optimizes away /obj/Initialize
We were spending like 0.15 seconds just checking for blueprints, obj
flags and network ids
All these things can just be applied where they're wanted, saves time
Oh and I replaced object flags with an emag injector. I'll give it a
sprite and name later I promise
* Requires a GenerateTag() call to set DF_USE_TAG, rather then doing a check in atom New
This is technically harder to use, but I don't really want people using
tags, and it saves 0.15 seconds
* Moves generatetag to /datum
* I am dumb
* Saves 0.5 seconds, makes init emissive blockers actually work
Ok so background. If an overlay is added with add_overlay, and not
"managed" somehow, it will effectively never be removed, because
nothing's tracking it.
Update_overlays uses the managed_overlays list/var (one of those) to do
this.
I'm gonna piggyback off this to make emissive overlays actually like,
respect overlay updates.
Oh and uh, I've saved maybe 0.5 seconds by caching the new emissive, and
not using add_overlay. There's a chance this will lead to overlay
corruption, but since we never readd the flattened, I think we'll be
safe
* Fixes plane not being set right, changes color logic too, since alpha will override past color sets
* Makes it actually work. also makes rand posters update appearance to clear away the overlay, since it shows on right click and looks bad
* Fixes blockers showing as emissives. It turns out alpha sets override the color list we use. Not sure why we pretend to support them
* Makes the injector support traits, adds an amazing sprite
* Micro optimizes ssair's turf init, saving 2 seconds
Most of this is making existing operations do more legwork, or cheaper.
I did add cycle checking to ONLY init turf linking, which required
creating a new proc.
Did some horrible horrible things in said proc to save like 0.8 seconds.
I think it was worth it.
* Reworks and resprites the metal hydrogen fireaxe
* Move the fireaxe icons around to fix the conflict.
Also kills the folder I made for items, as a previous PR splitting DMIs did that already.
* Deletes a DMI that I forgot to remove
About The Pull Request
Not without the help of my friend spriter, I added cucumbers, their seeds, the cultivation itself, so that they could be pickled and washed with a brine jar. I also added a Danish hot dog because it required cucumbers (perhaps that was the end goal), changed a couple of recipes to include cucumbers or pickles. Cucumbers have been added to both cargo orders and bounty cubes, as well as for the food order console
I think the Cucumber Update deserves its plush toy.
gg18b4b2cab0
Why It's Good For The Game
I think more food and drink... would add quite a nice role playing experience, and additional gameplay for hydroponics.
Changelog
cl Vishenka0704 and Ying-The-Pando
add: Cucumbers and pickles
add: Danish hot dog
balance: add cucumbers in dishes where they need
qol: add to bounty cubes, orders - new vegetables
/cl
About The Pull Request
Reorganizes the entire icons/mob folder.
Added the following new subfolders:
nonhuman-player (this was initially just called "antag", but then I realized guardians aren't technically antags)
simplemob
silicon
effects (for bloodstains, fire, etc)
simplemob/held-pets (for exactly that -- I wasn't sure if this should go in inhands instead)
species/monkey
Moves the following stuff:
All human parts moved into species, with moth, lizard, monkey, etc parts moved to corresponding subfolders. Previously, there were some moth parts in mob/species/moth, and others just loose in mob. Other species were similar.
icemoon, lavaland, and jungle folders made into subfolders of simplemob
All AI and silicon stuff, as well as Beepsky et al. into the silicon folder, simplemobs into the simplemob folder, aliens into the nonhuman-player folder, etc.
Split up animal_parts.dmi into two bodyparts.dmi which were put in their respective folders (species/alien and species/monkey)
Code changes:
Filepath changes to account for all of this
Adds a check when performing surgery on monkeys and xenos, because we can no longer assume their limbs are in the same file
Turns some hardcoded statues and showcases that were built into maps into objects instead
Things I'd like to do in the future but cant be assed right now:
Remove primarily-antag sprites from simplemob/mob.dmi (Revenant, Morph, etc.) and put them in the nonhuman-player folder
Split up mutant_bodyparts.dmi into different files for Tizirans, Felinids, monkeys, etc and put them in their own folders. Those may have once been meant primarily for mutated humans but that's now how they're being used right now.
About The Pull Request
Shadowpeople
brain now holds their healing properties.
while possible to extract the brain and put them in another species, the burn-in-light downside really makes it a lot more worth it to just stay a shadowperson and enjoy their other benefits than to swap.
Now use burning eyes from nightmares instead of an unsprited nightvision granting eyeball.
surgery.dmi split up
surgery_ui.dmi holds zone selection ui things for research
surgery_tools.dmi holds surgical tools
/organs folder holds organs.dmi, and species specific organ files for flies and shadowpeople
flies don't put in their random organs because of dmi memes, all their UNIQUE organs will be in the .dmi
Why It's Good For The Game
moving behavior onto the organ moves us closer to species as a blueprint, not species as something that magically grants immutable bonuses.
surgery.dmi is poorly described, holds many different things, and conflicts often because of it.
Changelog
cl
add: Shadowpeople now heal from their brains! Their brain-tumor-thingy!
code: split up surgery.dmi
/cl
This is a remake of #66106, with more thought put into the underlying balance. The main goal of this PR is to make fighting spiders more accessible and interesting for the majority of the crew while nerfing the extremely strong and boring option of simply using freezing temps to kill spiders. Also fixes#67765. The changes are as follows:
NEW SPIDER COUNTERS
Fly swatters now deal 25 damage to spiders on hit, increased from 1
Pesticide now deals massive stamina damage to spiders and a little bit of physical damage as well (the damage portion not added by this PR)
Spiders can now be caught on fire through any traditional mean of catching something on fire. Spiders will automatically put themselves out after a time. This was done instead of an active action because AI spiders are also subject to this change as well, and I don't feel like bloating the simple mob AI with putting themselves out
SPIDER CHANGES
NERFS
Toxin injection has been removed from all spiders except for the hunter, flesh spiders and the viper
Hunter toxin (used by hunters and flesh spiders) now only brings the afflicted down to 40 health, and will stop taking effect once the afflicted reaches that threshold. Should the afflicted still have the toxin in their system and get healed, the toxin will begin dealing damage again until the afflicted is at 40 health or below again
Viper toxin now only brings the afflicted down to 10 health, but also has the hallucination effects of Mindbreaker toxin. This hallucination effect is applied regardless of target health. It also no longer generates other harmful chemicals into the afflicted's system, but is much more potent at base
Flesh spiders cannot regenerate while on fire
BUFFS
Time it takes for spiders to normalize their temperature cut by half. While they will react faster when in cold or hot environments, when they leave said environments it will take less time to return to normal temperature
Unsuitable temperature damage reduced to 4 from 8
You can no longer push spiders by running into them
Webbing heat damage threshold increased from 300 to 350 (same temp where spiders also take damage)
Broodmother egg laying time reduced to 12 seconds from 15
Broodmother web laying time multiplier reduced to 0.5 from 1
Broodmother health increased to 60 from 40
Broodmother damage increased to 10 - 15 from 5 -10
BEHIND THE SCENES CHANGES
You can now make any simple mob able to be caught on fire by setting flammable to true
How fast a simplemob stops burning is controlled by fire_stack_removal_speed
Can now now control how fast simplemobs regulate their temperature using temperature_normalization_speed. Before this PR, this value was hard-coded at 10, I have set the default to 5 as 10 was too long in almost any case. This will notably affect slimes, who could easily die to being cold long after being removed from the cold area. I see this as purely beneficial
Toxins now have a health_required value. The afflicted has to be above this health value in order to take damage from the toxin. Only used in the spider toxins currently
When I was setting up simplemobs to be flammable, I noticed basic mobs can be glitchily set on fire, so I fixed it to where they can't be set on fire.
Why It's Good For The Game
Spacing something is very easy, but not very fun or interesting compared to starting and controlling a fire. Swapping spiders' temperature weakness from spacing to fire is beneficial to the fun of fighting them and playing as them, allowing more creativity and resourcefulness on both sides. Ideally, this should allow for atmosians and chemists to use their skills in a fun way.
Currently, ignoring spacing them, the only people who can reasonably take on spiders is security, since they have lasers which do burn and stuns to slow the spiders down. However, this small subset of players cannot normally destroy a spider infestation without spacing them, so letting fly swatters and pesticide be used to combat spiders allows other crewmembers to fight back, letting them actually enjoy facing spiders as a threat and allowing the crew to defend themselves.
Being killed by spider toxin after fighting off a horde isn't fun. The changes still make it a threat you have to be aware of, but not one which detracts as much from the combat loop. This also forces spiders to secure the kill themselves, which is more fun than having the toxin do it for you.
Broodmothers in their current state are incredibly weak by themselves, which is intentional by design. However, the new changes hope to make playing as a broodmother easier and hopefully allow more broodmothers to get the spider infestation started properly. After all, Dynamic is their common source now, and they should be consistently worth the threat cost to spawn them.
Previously, spider structures would seemingly vanish for no reason if the room was heated to be greater than 300 but less than 350, as the spiders would not be able to tell that it was too hot. Now, if the structures are taking damage, spiders will also be taking damage, so understanding what's going on should be easier now.
Pushing spiders into a corner by running into them was not a fun tactic to deal with as a spider and didn't make much sense seeing how big the spiders are.
Changelog
cl
add: Spiders can now be caught on fire
add: Spiders take significant damage from fly swatters and stamina damage from pesticide
balance: Spiders have been re-balanced. Their toxins can no longer kill but they are not as susceptible to freezing
balance: General stats of spider broodmothers have been buffed with more health, damage, and faster web and egg placement
balance: Flesh spiders cannot regenerate whilst on fire
balance: Simplemobs change their internal temperature twice as fast
fix: Basic mobs no longer glitchily catch on fire.
/cl
About The Pull Request
bgug fix stuff
APC controller UI has its elements section'ed off. The backend has been redone to make the behaviour of the APC controller a bit less janky. The console should be more stable, and all the soul has been removed from the code and the UI.
before this PR stales out from nobody wanting to review my pr, I should probably outline what exactly changed:
APC controller consoles have had their APC code almost entirely reworked. They no longer have to hold a reference to the person using the controller currently, and APCs themselves no longer hold a reference to the controller, instead to the person directly. A lot of code was moved to APC themselves to make it a lot more stable.
APC controller used to call toggle_breaker without passing args, causing a runtime. Fixed in
Fixes the power flow control console not actually being able to toggle breakers #69343
APC controller UI has had the Window.Content tags moved up to the top component, and a lot has been sectioned off to make the UI more sane.
AmpCheck used to look for a wire on it's turf, or as a fallback look for the Area APC. A check to see if the APC has a terminal did so on a weakref, causing a runtime and preventing the program from ever finding a valid APC in it's area, making it show nothing. This has been fixed. On the other hand, the power monitor console did not store the ground wire or APC terminal as a weakref, this has been updated. As a fallback, if there are still no APCs in the powernet, the UI will show a dimmer popup.
There was a "secret" power monitor variation in code so PDAs could not access monitors in hidden places. With the removal of PDAs, this control console is useless.
Why It's Good For The Game
Tiny bit of (much needed) polish on some useful tools in the engineering department.
Changelog
cl
fix: Fixed runtime when using AmpCheck without connecting the console with a wire.
fix: Fixed a few runtimes that could occur when using APC controller consoles.
qol: Sucked soul out of APC controller code and UI.
del: Removed "secret" power monitor console.
/cl
About The Pull Request
Everyone has been asking: "When will there be an anomaly like the bioscrambler, but for the space station? Please, we need more things which replace objects with different objects from the same typepath."
Well I made it and it looked like ass because non-tiling floor and walls look terrible, so then I made this instead.
Dimensional.mp4
The "dimensional anomaly" shifts matter into a parallel dimension where objects are made out of something else.
Like the Bioscrambler anomaly, it does not expire on its own and only leaves when someone signals it or uses an anomaly remover.
When it spawns it picks a "theme" and converts terrain around it until it covers a 7x7 square, then it teleports somewhere else and picks a new theme.
A lot of these themes are relatively benign like "meat", "fancy carpet", or "gold". Some of them are kind of annoying like "icebox" because it creates floor which slows you down, or "clown" because bananium is intentionally annoying. Some of them are actively dangerous, mostly "uranium" and "plasma".
The main problem this will usually cause for crewmembers is decreasing area security. When it replaces doors it replaces them with ones which don't have any access control, and it will also replace RWalls with normal and much more vulnerable walls which will make breaking and entering significantly easier until someone has taken the time to fix the damage. But also sometimes it will irradiate them, you never know.
The fact that sometimes the changes are benign (or provide uncommon materials) and might be happening in places you don't care about access to might encourage people to push their luck and leave it alone until it starts turning the captain's office into a bamboo room or repainting medbay a fetching shade of flammable purple, which I would consider a success.
Armour.mp4
If you successfully harvest the anomaly core you can place it into the reactive armour to get Reactive Barricade Armour, which shifts your dimension when you take damage and attempts to place some randomised (not terribly durable) objects between you and hopefully your attacker (it really just picks up to four random unoccupied tiles next to you). If you're EMPed then the changes it make to the environment will often be as unpleasant for you as they are for a pursuer, and significantly more likely to harm both of you rather than just provide obstacles.
Other changes:
I split anomalies out into their own dmi file, seems to be all the rage lately.
I moved the anomaly placing code into a datum instead of the event because I wanted to reuse it but if you have a better idea about where I could have put it let me know.
This also fixes a bug where the material spreader component wasn't working when I applied plasma materials to something, the extra whitespace was parsing as another argument for some reason and meant it would runtime.
Supermatter delamination was still pointing to Delimber anomalies instead of Bioscrambler.
