Make more use of <tool>_act (#64375)

Replaces a bunch of tool behavior checks in attackby to instead use the respective procs.
For instance, the behavior under a if(I.tool_behaviour == TOOL_SCREWDRIVER) check in attackby() will instead be found under that same object's screwdriver_act() proc. This is the first of a few PRs that I'd like to make to address this, since there's going to be a lot of code shuffled around.

This shouldn't have any impact on players, though some super observant folks might notice that they don't bash some items with tools when they meant to interact with them. I've tested all of these in game and they seem to still have the same behavior as before.
This commit is contained in:
Luc
2022-01-25 10:17:30 -05:00
committed by GitHub
parent 4626105bf9
commit 4fd16bcbdb
29 changed files with 624 additions and 523 deletions
+28 -25
View File
@@ -44,35 +44,38 @@
if(can_hack_open)
. += "The service panel is currently <b>[panel_open ? "unscrewed" : "screwed shut"]</b>."
/obj/item/storage/secure/attackby(obj/item/weapon, mob/user, params)
/obj/item/storage/secure/tool_act(mob/living/user, obj/item/tool)
if(can_hack_open && SEND_SIGNAL(src, COMSIG_IS_STORAGE_LOCKED))
if (weapon.tool_behaviour == TOOL_SCREWDRIVER)
if (weapon.use_tool(src, user, 20))
panel_open = !panel_open
to_chat(user, span_notice("You [panel_open ? "open" : "close"] the service panel."))
return
if (weapon.tool_behaviour == TOOL_WIRECUTTER)
to_chat(user, span_danger("[src] is protected from this sort of tampering, yet it appears the internal memory wires can still be <b>pulsed</b>."))
return
if (weapon.tool_behaviour == TOOL_MULTITOOL)
if(lock_hacking)
to_chat(user, span_danger("This safe is already being hacked."))
return
if(panel_open == TRUE)
to_chat(user, span_danger("Now attempting to reset internal memory, please hold."))
lock_hacking = TRUE
if (weapon.use_tool(src, user, 400))
to_chat(user, span_danger("Internal memory reset - lock has been disengaged."))
lock_set = FALSE
return ..()
else
return FALSE
lock_hacking = FALSE
return
/obj/item/storage/secure/wirecutter_act(mob/living/user, obj/item/tool)
to_chat(user, span_danger("[src] is protected from this sort of tampering, yet it appears the internal memory wires can still be <b>pulsed</b>."))
return
to_chat(user, span_warning("You must <b>unscrew</b> the service panel before you can pulse the wiring!"))
return
/obj/item/storage/secure/screwdriver_act(mob/living/user, obj/item/tool)
if(tool.use_tool(src, user, 20))
panel_open = !panel_open
to_chat(user, span_notice("You [panel_open ? "open" : "close"] the service panel."))
return TRUE
// -> storage/attackby() what with handle insertion, etc
return ..()
/obj/item/storage/secure/multitool_act(mob/living/user, obj/item/tool)
. = TRUE
if(lock_hacking)
to_chat(user, span_danger("This safe is already being hacked."))
return
if(panel_open == TRUE)
to_chat(user, span_danger("Now attempting to reset internal memory, please hold."))
lock_hacking = TRUE
if (tool.use_tool(src, user, 400))
to_chat(user, span_danger("Internal memory reset - lock has been disengaged."))
lock_set = FALSE
lock_hacking = FALSE
return
to_chat(user, span_warning("You must <b>unscrew</b> the service panel before you can pulse the wiring!"))
/obj/item/storage/secure/attack_self(mob/user)
var/locked = SEND_SIGNAL(src, COMSIG_IS_STORAGE_LOCKED)