Fixes a bug where MMIs would be sent into the nullspace room when in an MMI component inside of a BCI that is inserted into a BCI manipulation chamber.
Stores the BCI in the chamber's contents, instead of nullspace, allowing the MMI to talk, the BCI to still act as it would normally and overall just solves the issue and maybe some others alongside it.
Fixes#70349
* Fix xeno hivemind talk causing hissing sound
* Fix dullahan speech arg
Add message_range and saymode to say arguments
Add new say args to other say procs
Add new say args to other say procs
* Revert "Fix dullahan speech arg"
This reverts commit abff2bec1a03c1270b2896faa547c465e046ad78.
* Fix speech_args to be list
* Refactor hulk speech signal handler
* Revert "Revert "Fix dullahan speech arg""
This reverts commit 58997930096ef6b7fa8a1c79395595e61db954c6.
* Change filterproof to be null like other say procs
* Remove unused COMSIG_MOB_SAY defines
* Readd defines for COMSIGH_MOB_SAY
* Fuck you (refactors ur tails)
* Errors
* Wow. Pain.
* Fixes up probably everything
* finish up here
* Fixes hard del maybe
* original owner hard del
* garbage collection runtime
* suck my peen byond
* Mapped tails
* motherfucker.
* motherrfucker. again.
* Whooopppppsie
* yeah bad idea
* Turns out external organs literally just sat in nullspace forever if their parent was deleted, and didnt Remove() themselves, causing harddels.
* So anyways I repathed all organs
* Fixes
* really.
* unit test... test
* unit test-test but it passes linters this time because im a moh-ron
* I've lost track of what im doing at this point
* Hopefully fixes hard del?
* meh
* Update code/datums/dna.dm
* things n stuff
* repath from master pull
About The Pull Request
I noticed a lot of strange and un-intuitive behavior in action buttons, and got stung by the bloat bug. Damn it hug #58027
I'll do my best to explain what I've changed and why, might get a bit long.
If you want a better idea, read the commits. Most of em are pretty solid, if long.
Whelp. Here we go.
How do action buttons currently work
All action buttons are draggable, to any place on the screen. They're held in an actions list on the player's mob.
Their location in this list determines their position on the top of the screen. If one is dragged away from the top, its position in the list is "saved". This looks really bad.
If two buttons are dragged over each other, their positions swap. (inside the actions list too)
If a button is shift clicked, it is brought back to the position it started at.
If the action collapse button that you likely just mentally edit out is alt clicked, it resets the position of all action buttons on the screen.
If an action is ctrl clicked, it is "locked". This prevents any future position changes, and also enables a saving feature. With this saving feature, locked button positions persist between rounds. So your first o2 canister will always start where you saved it, etc.
Actions and buttons are a one to one link. While there is functionality to share action buttons between two players, this means showing the same object to both. So one player can move a button on another's screen. Horrendous.
This also makes code that modifies properties of the screen object itself very clunky.
Why is this bad
A: None knew pretty much any of this information. It is actually documented, just in a horribly formatted screen tip on the collapse button, you know the one we all mentally delete from the hud.
B: None of this is intuitive. Dragging buttons makes the hud look much worse, and you get no feedback that you even can drag them. Depressing
C: We use actions to make new options clear to the player. This means players can have a lot of action buttons on the hud. This gets cluttery
D: The collapse button is useless. It lets you clear your screen if someone like me fucks up and gives you 2000 actions, but outside of that it just hides all information from you. You never want to see none of your action buttons, just a filtered list of them.
E: On a technical level, they're quite messy, and not fully functionally complete. This is depressing.
What I've done
Assuming the above to be true, how do we fix them?
Well first I'm going to go over everything I changed, including links to major commits. I'll then describe the finished product, and why I made the decisions I did.
Oh and I've moved some of the more niche or technical discussion to dropdowns. Hopefully this makes finding the major functional changes easier
Adds helper procs for turning screen_loc strings into more manageable arrays. This doesn't fully support all of the screen_loc spec, but it's enough for what I'm doing. (f54865f)
Uses these helper procs to improve existing code (6273b93)
Fixes an issue with tooltip code itself. If you tried to hold down a mouse button while dragging onto a tooltip enabled object, it would silently fail. The js made assumptions about the order args came in, which broke when buttons were held down (e0e42f6)
Adds a signal linked to /client/Click(). Surprised we didn't have this before honestly (c491a4a)
Makes /client/MouseDrag() return parent. If we don't do this, any overrides of MouseDrag will never actually be called (2190b2a)
Refactors how action buttons work under the hood (53ccce2)
Basically, rather then generating one button per action, we generate one button per viewer
Starts to change button behavior, more cleanup
Changes the mouse cursor when an action button is dragged. Hopefully
this makes moving things feel less like an accident, and makes you doing
it more clear
Removes the moved and locked vars. This will be more relevant later, but
for now:
Moved exists as a sort of budget "We've been dragged" variable. We can
handle this more cleanly, and the movable type doesn't care about it
Locked is a very old variable that is also not something that the
movable type "owns". It's more an action button thing that's been moved
down.
It exists so an action can be locked in place, and in that locking, be
treated as a "saved location"
(21e20fc)
Because I've nuked move, we don't need to directly set our button's
position. We can use the default_button_position var instead. This is
quite handy.
Please ignore position_action, I will explain that later
(83e265e)
Removes the buttons locked pref
It was another obscure part of action buttons, basically do buttons
start "locked" or not. See previous discussion of locked
(b58b1bd)
Major rework starts here
Alright. Sorry for this, this is where me not commiting regularly starts
to suck. I'll do my best though.
Rather then figuring out an action button's position via a combination
of the moved and ordered vars, we use a separate location var to store
one of a few defines. This makes life later much easier.
Adds tooltip support for dragging action buttons. The way the tooltip
just froze in place when dragging really bugged me, and lead to some
nasty visual artifacts.
This is a bit messy because the drag procs are horrible, but it's
workable
Dropping a button on another button will no longer swap their positions
Behavior instead depends on the target button.
If it's a part of a group (A concept I will explain later) the dragged
button is simply inserted before it in the group's list.
If it's floating on the general hud, we instead position the dragged
button to its right. There's extra logic here to ensure buttons will
never overflow the screen, but I'll get into that later.
Alright. That's most of the refactoring. Time for the larger behavior
changes.
Adds a button palette. This is a separate dropdown that renders
underneath buttons.
image
The idea is to allow for a conceptual separation between "important"
buttons and the ones that end up cluttering the screen.
You can click on the dropdown to open it, then any later clicks that
don't involve actions in some way will autoclose it.
My goal is to come up with an alternative for the action button that
just acted as a way to hide all buttons on screen. Not convinced it saw
much use.
As a side effect of removing that, I've moved its tooltip stuff to the
palette. I've properly formatted it, so hopefully it's easier to read
then the jumble that we used to have.
(You can alt click the palette button to reset all button positions)
Oh and the palette can scroll, since as you'll see later it has a
limited size.
image
Moving on from that, I've added what amounts to action landing buttons.
These allow buttons to rejoin groups, or be positioned at the end of a
line of buttons.
image
They've got a 32x32 hitbox, and only show up when dragging. Hopefully
this makes the system more clear just by dragging an action.
Oh and I've changed how button position updating works. The old system
of calling update_action_buttons on mob every time an action button
changes position is gone, mostly because I've setup more robust
grouping. Will discuss when I get to huds
(0d1e93f)
Adds the backbone behind action button position changes (94133bd)
Moves hud defines to the global folder, safer this way (7260117)
Adds color changing to the palette button, giving some heads up for buttons being inserted into the palette automatically
image
image
Ensures a landing button is always shown, even if it needs to break the
max row rule
Makes palettes auto contract if they have no buttons inside them
Prevents palettes from being opened if they have no buttons inside them
(f9417f3)
How it looks
2022-02-26.02-30-10.mp4
Why It's Good For The Game
Players have more control over the clutter on their screen.
Buttons are available, but not in the way,
Since any player move of a button saves it, any lack of clarity in the way buttons work will be forced out by buttons not just resetting when a new game starts.
We don't overlap any existing screen elements, unless the upper button list gets really long.
The code is much less crummy (I think, may have made it worse it's hard for me to judge my own work)
If it ends up not being as usable as I'd like, I'll rip out the existing changes and just implement the qol and backend stuff. I think it's worth doing though.
Changelog
cl
add: Expanded heavily on action buttons
add: Adds an action button dropdown that sits just under the normal list in the top left. You can drag new buttons onto it to insert them. Click on it to show its contents, do what you want to do, then click again anywhere to contract it. Alt click it to reset all button positions
add: Action buttons will now remember their position between rounds. So if you really like your flashlight right next to your player for some reason, we support that now
add: When you start to drag an action button, docking ports will appear in places that it can be inserted into. (Outside of just floating somewhere on your screen of course)
del: Removed action button locking, and the associated preference. I'm reasonably sure literally none uses this, but if you do hit me up
qol: Dragging an action button will now give you an outline of its size around your cursor
fix: You can no longer cause the screen to expand by putting an action button on the edge of widescreen, and then resizing to standard.
refactor: Refactors action and button code significantly. lots of little things.
/cl
This makes several small changes to the MODsuit circuit module:
Adds the MODsuit Action component. When selected, the circuit module opens a radial menu with which to select an action component to trigger.
Due to its similarity to the BCI Action component, both it and the BCI Action component have been made subtypes of an abstract equipment_action component that implements their shared functionality.
Renames the MOD component to the MOD circuit adapter core component.
Changes the "selected module" port on the MOD circuit adapter core to a string port, for consistency with the corresponding input port.
The circuit in the circuit module can be removed. Consequentually, the circuit module no longer comes with a pre-installed circuit.
The "Toggle Suit" signal port on the MOD circuit adapter core can now activate the modsuit.
Makes the circuit module printable in the component printer, for consistency.
Moves the circuit module's code to modules/wiremod, for consistency.
BCI action component properly typechecks the shell it's inserted in.
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
* Removes like 50% of the cost of using the ui, it turns out that the storage component is fucking moronic. Likely significantly reduces the overtime of typecacheof
* Reduces the cost of reloading the dummy by ~50%
Turns out just initializing and deleting organs was like half the cost of reloading a default dummy.
It occured to me (Mothblocks) that we don't actually care about any organs we can't see or that don't effect visuals. So almost all of our organ loading can just be skipped.
This saves a significant chunk of cpu time, items next!
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
Exactly what it says in the title. Implanters used to drop the BCI they contained when opened up. Now they don't. For good measure I made them drop their contained BCIs when deconstructed as well in case they already did that as a consequence of the BCI being located inside the implanter, which was the cause of the issue in the first place.
## About The Pull Request
stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it
for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload
## Regex used:
procs without args, not even regex
`/Initialize()`
procs with args
`\/Initialize\((?!mapload)((.)*\w)?`
cleanup of things i didn't want to mapload:
`\/datum\/(.)*\/Initialize\(mapload`
* tgui bsod
* debug disconnections
* prelim
* recomment
* set_value -> put ._.
* DAMN IT
* reinsert subsystem
* prepare
* unditch signals
* remove combiner
* remove combiner some more
* how did router.dm get here? deleting.
* These two COMSIGS should be one.
* critical typo
* inline cast
* have your signals
* Have your set_input & set_output.
* make compile
* upgrade save/load to n-to-n-wires
* have your documentation
* have your unsafe proc
* pay no attention to the compile errors
* unlist the ref
* paste my for block back in ._.
* fix manual input
* oops pushed too soon
* Have your !port.connected_to?.length
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Examining a mob with a BCI inside them will now give you the ability to look at it. Helpful for admins, but also keeps in line with every other circuit shell.
BCIs are a new shell that can be implanted in your brain through surgery or through a BCI Manipulation Chamber, which provide the ability to easily implant and remove BCIs. They are the same size as compact remotes and generally share the same limitations.
Also adds CIRCUIT_FLAG_HIDDEN, to hide components from the UI. I didn't end up needing this, but Watermelon said he had ideas for it, so eh.
Why It's Good For The Game
BCIs provide an interesting, stealthy input method for circuits. They are seen as a healthier alternative to nanites, and improve on them in several ways:
Circuits have limited manipulation of the world, and intentionally do not perform the ability to provide passive healing, revives, etc.
Circuits have a significantly better UI and UX than nanites.
Circuits regularly get content expansions, which means that as a side-effect, there'll often be new things to play with for BCIs.
Other point to make:
BCI implanters have no cloud, and instead require the BCI to be put inside the machine. This means it requires the attention of the scientist (or even just a box with them inside). With
Adds the ability to save/load circuits for admins. Adds the ability to duplicate modules in a round. #60222, which lets you reprint a circuit you made that round, this means you can print out lots of BCIs, rather than going through the tedium of constantly remaking it.
BCI implanters are not roundstart, but rather in the advanced shells node. This is essentially the same as nanites, except for the difference of nanites starting with all the machinery, but none of the powers.
Changelog
cl
add: Added brain-computer interface circuit shells.
/cl
