## About The Pull Request
Hey there,
Space Ruins all use the same name "Unexplored Location", and one of them
is conflicting:
I have no fucking idea which one this is though, given that I took this
screenshot a week ago. It doesn't fail unit tests since it's on a space
ruins Z-Level, which are exempt from those checks. So, let's just at
least put the type in the message so someone can figure it out sooner.
## Why It's Good For The Game
We shouldn't be having duplicate APCs, and this problem is very hard to
fix right now. At least if I had a type, I would be much more able to
tell which subtype of `/area/ruin/space` is fluking on us.
## Changelog
Nothing that affects players.
## About The Pull Request
Removes errant mole scaling for the thermal energy loss of gases
entering the turbine. Limits the amount of work it can do to only cool
gas down to TCMB, preventing it from creating power from no thermal
energy.
## Why It's Good For The Game
It was too silly when the turbine can cool a raging fire down to 2.7
Kelvin. Creating power from energy it can't take was also too silly.
## Changelog
🆑
fix: Fix unnecessary mole scaling with gas turbine gas thermal energy
loss from work done.
fix: The gas turbine no longer creates power from thermal energy it
can't take.
/🆑
## About The Pull Request
Atomisation of #71421
This moves the attack function of "environment smash" flags which allow
simple mobs to attack walls into an element, so that we can put it on
other things later.
For some reason while working on carp I convinced myself that they had
"environment_smash" flags, which they do not, so this actually is not
relevant to carp in any way.
While implementing this I learned that the way wall smashing works is
stupid, because walls don't have health and so resultingly if a mob can
attack walls it deletes them in a single click. If we ever decide to
change this then it should be easier in an element than in three
different `attack_animal` reactions.
This is especially silly with the "wumborian fugu" item which allows any
mob it is used on to instantly delete reinforced walls, and also to
destroy tables if they click them like seven or eight times (because it
does not increase their object damage in any way).
## Why It's Good For The Game
Eventually someone will port a basic mob which does use this behaviour
(most of the mining ones for instance) and then this will be useful.
If we ever rebalance wall smashing to not instantly delete walls then
this will also be useful.
Admins can apply this to a mob to allow it to delete walls if they
wanted to do that for some reason, they probably shouldn't to be honest
at least until after we've done point two unless they trust the player
not to just use it to deconstruct the space station.
## Changelog
🆑
refactor: Moves wall smashing out of simple mob code and into an element
we can reuse for basic mobs later
/🆑
<!-- 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
This pull request adds a variety of Supermatter delamination effects to
make the crystal a bit more fun to watch and stare at. The initial
filter effects and animations are from Baystation12, but I have adapted
it to make it fun to watch!
It'll be a bit hard to explain in text, so this is the text explanation.
For normal running conditions, the Supermatter will emit pretty golden
rays, and a large campfire like that glow that grows and shrinks based
on it's power level.
For high power conditions, such as high O2 or CO2 amounts, the
Supermatter's rays will glow red and it will emit red light, aswell as
turn red (like before, unchanged).
https://user-images.githubusercontent.com/77420409/174471693-e191ee47-1a01-4b76-8570-9d12b994c2d4.mp4
When the conditions for a cascade, singularity, or a tesla are met, the
colours and rays emitting from the crystal will change to match!
https://user-images.githubusercontent.com/77420409/174471747-dffb3beb-dd38-42a1-a97b-7262dabd60af.mp4https://user-images.githubusercontent.com/77420409/174471765-af1927e8-a48e-4fd5-a35c-6b3aa53c5add.mp4
Also, I've added more sucking power to the crystal during its final
countdown for DRAMATIC EFFECT. If the singularity conditions are met,
the supermatter will SUCK THINGS INTO IT, even if they are bolted to the
GROUND. Just like a singularity! It's REALLY COOL.
https://streamasaurus.com/sharing/singularity_full.mp4 <--17MB video.
UPDATE 1: New rays for the singulo
https://user-images.githubusercontent.com/77420409/174933219-0118748a-02da-40f8-9b99-06009e197cc8.mp4
UPDATE 2:
Singularity delamination final countdown effect??:
https://user-images.githubusercontent.com/77420409/175421220-66bae109-204d-44ee-8a67-c18ce8eff3ba.mp4
When the supermatter has reached the FINAL COUNTDOWN but does NOT meet
the criteria for a singularity, it will simply YOINK everything
unwrenched towards, like a gravitational anomaly, range based on power
at the time. Not as crazy as the singularity. Most things will get
slapped against walls.
Here, have another cool delamination demo showing the criteria's
swapping mid countdown!
https://streamasaurus.com/sharing/modeswapping.mp4 <-- 17.5MB
I am likely missing something important from this body as I am drowsy
making this! I will update this body with anything I forgot to note that
I did.
## Why It's Good For The Game
The supermatter is a a very cool thing, but it could be cooler. I think
the visual experience could do with a bit of an upgrade, as visual
feedback is really cool and impressive to watch! You could tell more
about the crystal without looking at the console, but not everything or
precise numbers.
## 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. -->
🆑
add: The Supermatter crystal will now emit rays of light, varying on
it's power level and situation.
code: improves a formatting and comment spelling
fix: The Causality field now actually shows up!
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com>
So i left over some basic `/whatever/proc/format` uses in the original
PR this fixes it.
Notable exceptions to the rule:
- Paths in add_verb/remove_verb, we need full path instead of a name
there to access verb metadata so we can't use proc ref macros there.
- regex.Replace, found out that it does not accept call by name. Instead
i added new REGEX_REPLACE_HANDLER so we can at least try to mark these.
There's still leftover global procs that do not use GLOBAL_PROC_REF but
they functionally equivalent so that's for later.
I don't see any reasonable way to grep for this. But if you got any
ideas please share.
- Makes QDELETED use isnull(x) instead of !x, giving about 0.2 to 0.25s
of speed.
- Make disposal constructs only update icon state rather than go through
expensive overlay code. Unfortunately did not have much effect, but is
something they should've been doing nonetheless.
- Makes RegisterSignal only take signals directly as opposed to
allocating a fresh list of signals. Very few consumers actually used
this and it costs about 0.4s. Also I think this is just a bad API anyway
and that separate procs are important
`\bRegisterSignal\((.*)list\(` replaced with `RegisterSignals($1list(`
## About The Pull Request
This pull request adds logging and flags the start of the supermatter
from environmental starts. It also makes the log generation and started
flag flipping a proc. This means that atmospheric starts are now logged
(co2, o2, trit, etc), and so is touching/running into the SM.
[Dreamseeker
9Gkzvyfwdp-1.webm](https://user-images.githubusercontent.com/77420409/195494711-d9295b23-3ec3-447e-b255-fd14454bab5c.webm)
## Why It's Good For The Game
Just a tad more log clarity when you go to investigate. Allows
accidental/intentional/grief starts to be diagnosed easier.
## About The Pull Request
Hey there,
force_ending was a boolean (with inconsistent usage, flip-flopping
between using TRUE/FALSE and 1/0 variables), so let's just change it all
over to the macros and call it a good day.
I also updated documentation of the variables in that "code block" in
SSTicker while in the area because changing just one line made it look
ugly. Some of the documentation was no longer current to it's... current
use in code, so I updated those as well.
## Why It's Good For The Game
Pure code improvement, DMdocs are swell, and readability is kino.
## Changelog
Nothing here should affect players.
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>
Replaces a timer with just calling the proc directly. This saves 0.28s
of making timer events.
This timer exists as an artifact of being a `spawn (1)` since r4407.
Local testing suggests it is completely unnecessary (lights work, lights
break, new lights show)
Replaces the internal_energy is below powerloss_linear_threshold check with a momentary_power is below powerloss_linear_threshold check.
Fixes supermatter powerloss threshold check to check for the momentary power instead of internal energy.
The powerloss math is based on the momentary power, but the if check checked for the internal_energy instead, which made it continue using cubic power loss at inappropriate situations.
If a light has flicker() running and the light is turned off/disabled, it would ignore the light being turned off and continue flickering. This could lead to lights remaining on despite the area not having power, or having the lighting disabled in the APC.
* Fixes Unreadable APC Balloon Alerts as Ethereals
Hey there,
So basically, when an ethereal on combat mode would try and discharge an APC, they would get this, which is completely unreadable:
So, let's add a small sleep at the end of `togglelock()` for ethereals, and then proceed to continue on with the proc chain of whatever an ethereal might want to do with an APC.
* swaps the balloon alerts to add timers
less elegant, but it does do the job nicely
About The Pull Request
We apply the damage hardcap individually now, split off the old flat 1.8 into individual caps for heat, moles, and power.
Set it to 1.5 for heat, 1 for mole and 1 for power. This means for most delams it'll be a tad slower! But its possible to make SM delam nearly twice as fast if you combine all 3. (3.5). Be pretty hard tho.
Set the heat healing to -1 so you can counteract one factor at most (except heat since you'll never get both heat healing and heat damage at the same time anyway).
I'm not hell bent on any of the numbers, just picked round even ones and ones that i think will make sense. If you want them changed lmk.
Got rid of the cascade mole and power multipliers since there's probably like three people that are aware that it even exists. Ideally we just add another entry to the CIMS but its already pretty crowded. Figured nobody is gonna miss it anyway? Sorry ghil.
Got rid of the moles multiplier thing since its nicer to keep the temp damage fully based on temp damage instead of adding another multiplier. I just applied the .25 to the damage flatly, meaning it slows down delams again!
And some space exposure stuff: #70347 (comment)
Why It's Good For The Game
Hardcap: Discrete, less randomly interconnected factors are easier to present and remember. The calculation procs are also made to be additive so we had to hack a bit and do some rescaling to accomodate the old behavior in my original PR #69240. Can remove the hack if this pr goes through.
Cascade and mole multiplier: The rest are just getting rid of underutilized factors so we have a cleaner behavior to maintain, present, and understand. (In a perfect world modifiers that aren't visible to the players shouldn't have been merged in the first place smh smh)
Changelog
🆑
fix: Fixed sm space exposure damage going through walls
del: got rid of the molar multiplier for sm heating damage. It will now only impact molar damage and temp limit. We apply the lowest value directly so this slows down sm delams a tiny bit.
del: got rid of cascades making sm delam at 450 moles and 1250 mev. It delams normally now.
balance: Applied the sm damage hardcap of 1.8 individually to heat (1.5), moles (1), power (1). Meaning most sm delams are slower now, but the really bad ones can be faster.
balance: Halved sm temp healing across the board. Temp limits are still the same though so you shouldn't notice it that much.
balance: Halved SM power damage across the board.
balance: Changed sm space exposure damage to just check for the current tile and adjacent atmos connected tiles.
/🆑
fix: Fixed a bunch of missing inhand icons.
fix: Fixed cables in electrical toolboxes not randomizing their colors.
fix: Fixed the wrong colored icon showing when trying to make cable cuffs out of cables.
fix: The collectable SWAT helmet is now using the proper icon again!
refactor: Pipecleaners and power cables now share a unified color system, so they're once again available in ALL the same colors.
imageadd: Updated the screwdriver belt overlay to represent the newer sprite.
imageadd: Added a bunch of new inhand icons. Special thanks to Twaticus for doing the helmets! <3
fix: Wirecutters now have an icon when inside a belt again!
admin: Added a new omnitool subtype that allows you to spawn all items in a typepath!
fix: Explorer gaskmasks now properly reflect their adjusted state when held.
fix: Fixed balaclavas having the wrong icon when pulled up.
fix: Fixed the base energy sword (admin spawn only) being invisible.
fix: The rainbow energy sword is now a little bit more rainbowy!
fix: Fixed an tk exploit with orange handcuffed shoes.
fix: The traitor outfit in the select equipment panel is now actually functional!
Basically all what I'm doing is categorize and display whatever modifiers are currently applying to the SM. This way players can see powerloss, temperature generation, damage taking, temp limit adjustment etc all in live instead of diving code or looking it up in the wiki.
I have taken the liberty of making most of these modifiers additive instead of multiplicative since it's easier to illustrate how much a given modifier is doing when they are all additive. E.G: The gas you added gave you an extra 2500 joules instead of the gas you added gave you a 1.2x multiplier.
To make this job not CBT there are a few gameplay changes that are needed to make things fall into the framework and some general cleanup. Most noteworthy might be:
Space damage taking (opted for
SM damage and balance #66692 instead of SM can explode on space tiles again #35275 just because it's newer. Wont mind changing if asked). Also removed the power gen see the edit in
Changed Supermatter Internal Math + UI Additions #69240 (comment). Wont mind bringing it back and tweaking if asked.
SM will now use the same heat limit for everything that once used variations of it. Unified healing temp limit (influenced by psychologist) with damage heat limit (influenced by gases and low moles, yeah that's a thing). In practice this means your rock will heal at higher temps instead of the old one.
Heat output production. See:
Changed Supermatter Internal Math + UI Additions #69240 (comment) and heat penalty from gases.
I'm really sorry for tacking this on to this PR, but there's no good way to present the heat output effect of gases to the SM in a way I'm satisfied with if I don't do this. Kinda hard to atomize too since it relies on the cleanup. Rolled back!
Work left:
Oh and need to make the NTOS things work.
Ntos Done! Since the active crystal is now deprecated and we use localstate, the notification system got changed a bit. SM will now ping you if you subscribed to it. Only works when minimized and not closed, like the old one.
Oh and also documentation.
Think its in an ok spot now.
Reimplement transmission view and low pressure power bonus. Yeah thats a thing.
Looks like the low pressure power bonus is actually broken. It evaluates to ~2 for pretty much any x given. So im axing it.
Reimplement moles doubling heat resistance. Yep thats also a thing.
Readd the pluox and miasma pressure scaling thing.
Done, also multiplied the reaction rate by half but multiplied the mole manipulation by 2 for pluox gen. Did this so it's easier to understand.
Dump shit into the changelog.
Why It's Good For The Game
Future coders will now need to write a bit more code when they want to add another modifier. Meaning it's a tad more rigid if someone wants to go out of the existing framework. Also demands a little bit of math but nothing more than basic algebra.
But on the flipside, this means future coders that want to add a brand new modifier to the SM will need to justify and document it (with only a single string descriptor so its not even that much work). Makes the work of people maintaining the code waaay easier at the expense of feature coders. Also makes whatever change they want to apply be relayed immediately to the players.
I mean jesus christ we didnt even know PN was really good for SM until it's added to the wiki.
Changelog
🆑
del: Removed the broken pressure power multiplier which always evaluates to 2. Multiplied base SM power production by 2.
del: SM will no longer gain power when exposed to space. It actually used to do that, but only when the tile it's on has gas so you don't really notice it.
qol: added the factor breakdowns to the SM ui.
qol: added the gas effect breakdowns to the SM ui.
qol: Made the supermatter selection in NT CIMS ui frontend based. Notifications will be based on you pressing the bell button instead of opening a SM page.
code: Instead of showing the environment breakdown of the SM tile, the NT CIMS will show you the exact gas mixture that it uses for calculation.
code: Total moles in NT CIMS will now be substituted with absorbed moles, which is the thing we use to calculate scrung delams. Scrungs at 1800.
balance: Unified the SM taking damage on space (last modified 2018) with SM taking damage around space (added 2020, last modified 2022). Chose the latter formula, it's significantly stronger.
balance: SM will start healing at the same damage at which it stops taking heat damage. Instead of the old fixed healing at ~313K.
balance: made the low mole heat resistance thing on SM not scale with heat resistant gases.
balance: Made the supermatter temperature power gain multiplier thing linear at 1/6 instead of 50/273 or 30/273.
balance: Psychologist heat reduction is weaker on high heat gas.
refactor: rerouted how external damage (bullets) and external power (emitter) is applied to SM.
refactor: restructured the internal power calculations for SM. Power should be applied on each atmos tick instead of separately.
refactor: restructured how the SM calculates the damage that it takes. No changes expected except for the low mole temp limit multiplier thing.
refactor: Restructured SM pluox generation and miasma consumption. No changes expected though.
\🆑
* canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE
The most idiotic thing I've seen is canUseTopic's defines, they literally just define TRUE, you can use it however you want, it doesn't matter, it just means TRUE. You can mix and match the args and it will set that arg to true, despite the name.
It's so idiotic I decided to remove it, so now I can reclaim a little bit of my sanity.
* 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
* 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.
* 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.
* 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
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
Title!
The CO2 thing is there because it makes my job much easier. Can probably find a way to make it move slowly if a maint insist on it. Prefer not to though.
Drafting because I want to make a second PR that have more sweeping changes (clean vars up, make a simpler formula for damage and heat production, delete underused behaviors, etc). Would honestly prefer if both this and that gets merged at the same time but I'm separating it out since it might be rejected. Or maybe ill combine it here we'll see.
Ignore that, looks like i can keep this one absolutely atomic.
Why It's Good For The Game
Had a lot of trouble when trying to document the SM gas interactions into the wiki, the interactions are all scattered and tracking down everything a gas does is extremely annoying. Hopefully this fixes that.
Changelog
cl
balance: CO2 powerloss inhibition now works immediately based on gas composition instead of slowly ramping up.
refactor: refactored how the SM fetches it's gas info and data. No changes expected except for the co2 thing.
/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.
Doing some mapping work downstream and I noticed there were both directional and non directional high caps. Code dived to figure out which was the valid one to use and found the directional high caps were not actually inheriting the upgraded power cells do to bad name structure. Corrected inheritance structure. Updated Kilo and Icebox to use directional high caps as standard and updated several ruin and gateway missions to standard directional high caps
* Unit tests range suck
Ok so we currently rely on some undefined behavior in energy_ball code
Namely, the range() family will return turfs in least/greatest get_dist
This is VERY useful for optimizing the tesla, but it's also undefined,
and lummy could change it any day now.
So let's at least unit test it so if it breaks we can remove it
Moves singulo and supermatter dmis into obj/engine, renamed from obj/tesla_engine
Moves Halloween, Christmas, and misc holiday items to obj/holiday
Moves lollipops to obj/food
Moves crates, closets, and storage to obj/storage
Moves assemblies to obj/assemblies
Renames decals.dmi to signs.dmi ...because they're signs and not decals
Moves statues, cutouts, instruments, art supplies, and crayons to obj/art
Moves balloons, plushes, toys, cards, dice, the hourglass, and TCG to obj/toys
Moves guns, swords, shields to obj/weapons
san7890
