Readds the changeling hivemind, but in a simplified form.
There is no linglinking. It was rarely used and imma be real with you, stupid.
Hivemind isn't an unlocked ability, it is just a default.
Bz still mutes lings
Fallen changelings now get an agonizing message about being locked out. We love fallen changeling flavor
Changelings have their Honorific names back! Hello, Mr. Omnicron!
This does NOT readd changeling team objectives, or really anything encouraging teaming beyond the hivemind itself.
I think antagonists have generally lost a lot of power versus the station, and this is one big way to pump up the heat for this antag in particular. Changelings, given an ability to possibly team up, are much MUCH scarier.
One reason it was removed years ago was because teaming was too often, but back then there were entire gamemodes about changelings having team objectives and many other things to encourage it. I'm bringing us back to a point BEFORE all those design ideas were explored, because I don't think they worked out.
Add information about the changeling hivemind, and the dangers of being turned into a fallen changeling if you get betrayed to the Changeling Antag Info UI
Changelog
add: Changelings once again have reestablished their changeling hivemind, and can secretly communicate between each other.
fix: Fixed up the Changeling UI a bit, like for example some dimmers would never render.
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
messed around with these the other day and got a little annoyed with how they work.
mostly copied existing code from the space heater
Why It's Good For The Game
this should clear things up a bit
Changelog
cl
qol: you can now right click an electrolyzer to toggle it on & off
/cl
Changes the limit of paths to spawn via game panel from a hardcoded 5 to be based on the admin spawn limit.
Why It's Good For The Game
5 is a bit limiting, especially as it's easily possible to spawn more than five types of something in other ways. QOL.
Changelog
cl Melbert
admin: The game panel now lets you make more than five different types of something at once.
/cl
Adds the moffra wing pattern and antennae based off of mothra.
New choices to express yourself is always good and it seems like a fun reference.
cl
imageadd: Adds Moffra wing and antennae sprites
/cl
About The Pull Request
Removes a ton of unused vars
Replaces blood/trash/pests/drawn vars with flags
Adds docs to most remaining vars
Registers cleanbot's on_entered when they get deputized instead of on initialize, removing calling procs uselessly.
Also makes the title only update when they get a new one, also removing useless proc calls.
Reworks how updating titles work so it isn't copy pasting its own code.
Cleanbot stealing names now check for the mind's assigned job, rather than the living's job.
Replaces single letter vars in many areas
Removes two places of checking what targets to scan for, makes use of the generalized scanning proc instead.
Slightly reworks process_scan to return null
Replaces cleanbot's cleaning time with a define
replaces 'initial' weapon force with just initial(weapon.force)
Why It's Good For The Game
Continuing my past work that since I haven't done a bot code improvement PR in a pretty long while, I thought I would try to get back into this with cleanbots, which used to be one of the worst bots but I fixed some major problems in the past already, so it wasn't too bad.
Changelog
cl
refactor: Cleanbots have been entirely reworked, please report any bugs you might find.
/cl
Simply removes the requirement to be conscious to pump your blood with a cursed heart.
Why It's Good For The Game
Entering crit or falling asleep is basically a life sentence since you are unable to pump your blood while asleep. The player still is manually pumping it, I don't see any reason why the user has to be awake for it.
This also means medical can't revive you, as you'll instantly lose all your blood before you have enough time to wake up to start pumping again. The only IC fix would be to remove your heart entirely, something most doctors wouldn't even notice.
Changelog
cl
fix: You can manually pump your blood while asleep/in crit, rather than instantly lose all your blood and die forever.
/cl
About The Pull Request
Native FOV is now tied to the eyes instead of the mob, and Flypeople are immune to it.
This doesn't affect TG because it's disabled in config, but I played on a server that does have it enabled, and I found it strange that Flypeople had it.
Why It's Good For The Game
Quickly searching it up says that Flies can see nearly in 360, so I think this should be reflected in-game too.
It give Flypeople a small benefit to being flashable from all directions, and while it could be implanted in regular humans, they'd have to then live with them big ol' eyes.
This was taken from #67742 by @soapstain22 and I really liked the idea. Not sure why the original author closed it but here it is again.
Adds red and blue nightcaps to the pajama lockers.
There's an old issue report that detailed how, using the Summon Cultist rune, you could be able to escape the Admin Prison (!!!) from CentCom (and could even go back to the station from CentCom using this in general!). This is very bad! So, let's do TWO things to fix this issue report.
The first is just to ensure that you can not summon a cultist from CentCom. They are "too far away from the veil" to be reachable. I can un-add this, but I think there's no reason we shouldn't leave it in.
The second is to ensure that the Summon Cultist rune respects TRAIT_NO_TELEPORT, so let's do that. I also whipped up a fast component that tracks the location of the "prisoner" that we send to Admin Prison, and ensure that the trait easily clears if an admin determines they are worthy of re-entering the game (so they don't have to delete the trait/component/whatever themselves, because that is non-intuitive). Should be all good now in this edge-case.
* 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
Heretics can no longer be converted to a cult, as they follow their own Forgotten Gods.
Instead, Nar'Sie will reward the cult for managing to sacrifice one, with the bastard sword.
The bloody bastard sword has been cleaned up codewise and all that. Because it is a free reward instead of a (removed) progression mechanic of cult, it swings just a bit slower during the spin and doesn't have a jaunt. It's still a !fun! swinging sword of hilarity and death.
BLOODY BASTARD https://www.youtube.com/watch?v=ukznXQ3MgN0
Fantasy weapons can now roll "soul-stealing" weapons. They, on killing something, capture its soul inside the item.
Add fail conditions that instantly end a spin2win, ala how
Mimes can now hold a baguette like a sword by right clicking it #69592 works
Why It's Good For The Game
Bloody bastard sword was fun, it made no sense that heretics were valid converts when they're already worshipping a DIFFERENT evil god granting them powers. Should be in a good spot as a nice little antag to antag special interaction. I fucking love antag to antag special interactions, we should have more of 'em
Fantasy affixes are always a neat thing to throw a new component into
Changelog
cl
add: Heretics can no longer be converted to cult. But sacrificing them is very valuable to Nar'Sie, and she will grant special weapons if you manage to do so.
add: Fantasy affixes can also include soul-stealing items!
/cl
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
About The Pull Request
Micros lighting objects, and their creation
We save a good bit of time by not walking space turfs adjacent to new objects.
We also save some time with micros in the actual underlay update logic.
I swear dude we spend like 0.8 seconds of init applying the underlay. I want threaded maptick already
Micros lighting sources, and corner creation
A: Corners were being passed just A turf, and then expected to generatecorners based on that. This is pointless.
It is better to instead pass in the coords of the bottom left turf, and then build in a circle. This saves like 0.3 seconds
B: We use so many damn datum vars in corner application that we just do not need to.
This resolves that, since it pissed me off. It's pointless. Lets cache em instead
There's some misc datum var caching going on here too. Lemme see...
Oh and a bit of shortcutting for a for loop, since it was a tad expensive on its own.
Also I removed the turfs list, because it does fucking nothing. Why is this still here.
All my little optimizations save about 1 second of init I think
Not great, but not bad, and plus actual lighting work is faster now too
Why It's Good For The Game
Speed
Aki Ito