## About The Pull Request
- Complete rewrite of borg omnitool code;
- - Borgs that use omnitools now have a "Omni Toolbox" that holds
whatever tools the Omnitool would cover. The toolbox keeps track of
Omnitool "Arms" in a list, as well as when to upgrade (or downgrade)
tool speed. The toolbox is not seen by the player directly.
- - Omnitool "Arms" will display available tools based on the Omni
Toolbox's contents. Selecting one does not move the tool out of the
toolbox, but instead simply overrides any following clicks with a melee
attack chain of the selected item. This is reminiscent of how borg
apparatus tools work. When selecting a tool, the Omnitool "arm" will
also set its own icon state to match the tool selected.
- - Because all Omnitool "arms" are using the same tools from the same
toolbox, actions done with one can be seen from another. For example,
using the first Omnitool to scan the Silo with the engineer borg's
multitool will update the tool's buffer, and it can be used later, even
if the multitool is selected by the second Omnitool.
- Because we're now using real tools, rather than a single tool item
faking tool usage via tool flags, almost all interactions with tools
should properly carry over.
- Added Cyborg versions of the medical toolset, for use with the Medical
Cyborg omnitool, so that we can finally use the really nice borg-version
medical tool sprites.
## Why It's Good For The Game
Easier to read code.
Fixes#83667Fixes#83537Fixes#83077Fixes#82918 partially; Heating beakers works, but the tile quick-swap
function will not function; the action is initiated by a click from the
tile stack rather than the crowbar.
## Changelog
🆑
fix: Refactored borg omnitool code, fixing most of the unique
interaction issues.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Loosely adapted from /vg/. This is an entity component system for adding behaviours to datums when inheritance doesn't quite cut it. By using signals and events instead of direct inheritance, you can inject behaviours without hacky overloads. It requires a different method of thinking, but is not hard to use correctly. If a behaviour can have application across more than one thing. Make it generic, make it a component. Atom/mob/obj event? Give it a signal, and forward it's arguments with a SendSignal() call. Now every component that want's to can also know about this happening.
70d26adf1c