## About The Pull Request When it comes to deconstructing an object we have `proc/deconstruct()` & `NO_DECONSTRUCT` Lets talk about the flag first. **Problems with `NO_DECONSTRUCTION`** I know what the comment says on what it should dob5593bc693/code/__DEFINES/obj_flags.dm (L18)But everywhere people have decided to give their own meaning/definition to this flag. Here are some examples on how this flag is used **1. Make the object just disappear(not drop anything) when deconstructed** This is by far the largest use case everywhere. If an object is deconstructed(either via tools or smashed apart) then if it has this flag it should not drop any of its contents but just disappear. You have seen this code pattern used everywhereb5593bc693/code/game/machinery/constructable_frame.dm (L26-L31)This behaviour is then leveraged by 2 important components. When an object is frozen, if it is deconstructed it should just disappear without leaving any traces behindb5593bc693/code/datums/elements/frozen.dm (L66-L67)By hologram objects. Obviously if you destroy an hologram nothing real should drop outb5593bc693/code/modules/holodeck/computer.dm (L301-L304)And there are other use cases as well but we won't go into them as they aren't as significant as these. **2. To stop an object from being wrenched ??** Yeah this one is weird. Like why? I understand in some instances (chair, table, rack etc) a wrench can be used to deconstruct a object so using the flag there to stop it from happening makes sense but why can't we even anchor an object just because of this flag?b5593bc693/code/game/objects/objs.dm (L368-L369)This is one of those instances where somebody just decided this behaviour for their own convenience just like the above example with no explanation as to why **3. To stop using tools to deconstruct the object** This was the original intent of the flag but it is enforced in few places far & between. One example is when deconstructing the a machine via crowbar.b5593bc693/code/game/machinery/_machinery.dm (L811)But machines are a special dual use case for this flag. Because if you look at its deconstruct proc the flag also prevents the machine from spawning a frame.b5593bc693/code/game/machinery/_machinery.dm (L820-L822)How can 1 flag serve 2 purposes within the same type? **4. Simply forget to check for this flag altogether** Yup if you find this flag not doing its job for some objects don't be surprised. People & sometimes even maintainers just forget that it even existsb5593bc693/code/game/objects/items/piggy_bank.dm (L66-L67)**Solution** These are the main examples i found. As you can see the same flag can perform 2 different functions within the same type and do something else in a different object & in some instances don't even work cause people just forget, etc. In order to bring consistency to this flag we need to move it to the atom level where it means the same thing everywhere. Where in the atom you may ask? .Well, I'll just post what MrMelbert said in https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862 > ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION handling as it wants, Yup that's the ideal case now. This flag is checked directly in `deconstruct()`. Now like i said we want to give a universal definition to this flag and as you have seen from my examples it is used in 3 cases 1) Make an object disappear(doesn't dropping anything) when deconstructed 2) Stop it from being wrenched 3) Stop it from being deconstructed via tools We can't enforce points 2 & 3 inside `deconstruct()` which leaves us with only case 1) i.e. make the object disappear. And that's what i have done. Therefore after more than a decade or since this flag got introduced `NO_DECONSTRUCT` now has a new definition as of 2024 _"Make an object disappear(don't dropping anything) when deconstructed either via tools or forcefully smashed apart"_ Now i very well understand this will open up bugs in places where cases 2 & 3 are required but its worth it. In fact they could even be qol changes for all we know so who knows it might even benefit us but for now we need to give a universal definition to this flag to bring some consistency & that's what this PR does. **Problem with deconstruct()** This proc actually sends out a signal which is currently used by the material container but could be used by other objects later on.3e84c3e6da/code/game/objects/obj_defense.dm (L160)So objects that override this proc should call its parent. Sadly that isn't the case in many instances like such3e84c3e6da/code/game/machinery/deployable.dm (L20-L23)Instead of `return ..()` which would delete the object & send the signal it deletes the object directly thus the signal never gets sent. **Solution** Make this proc non overridable. For objects to add their own custom deconstruction behaviour a new proc has been introduced `atom_deconstruct()` Subtypes should now override this proc to handle object deconstruction. If objects have certain important stuff inside them (like mobs in machines for example) they want to drop by handling `NO_DECONSTRUCT` flag in a more carefully customized way they can do this by overriding `handle_deconstruct()` which by default delegates to `atom_deconstruct()` if the `NO_DECONSTRUCT` flag is absent. This proc will allow you to handle the flag in a more customized way if you ever need to. ## Why It's Good For The Game 1) I'm goanna post the full comment from MrMelbert https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862 > ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION handling as it wants, but there's a shocking lack of consistency around NO_DECONSTRUCTION, where some objects treat it as "allow deconstruction, but make it drop no parts" and others simply "disallow deconstruction at all" This PR now makes `NO_DECONSTRUCTION` handled by `deconstruct()` & gives this flag the consistency it deserves. Not to mention as shown in case 4 there are objects that simply forgot to check for this flag. Now it applies for those missing instances as well. 2) No more copying pasting the most overused code pattern in this code base history `if(obj_flags & NO_DECONSTRUCTION)`. Just makes code cleaner everywhere 3) All objects now send the `COMSIG_OBJ_DECONSTRUCT` signal on object deconstruction which is now available for use should you need it ## Changelog 🆑 refactor: refactors how objects are deconstructed in relation to the `NO_DECONSTRUCTION` flag. Certain objects & machinery may display different tool interactions & behaviours when destroyed/deconstructed. Report these changes if you feel like they are bugs /🆑 --------- Co-authored-by: san7890 <the@san7890.com>
Contextual screentips (and when to not use this folder)
Contextual screentips provide information in the form of text at the top of your screen to inform you of the possibilities of an item. The "contextual" here refers to this being handled entirely through code, what it displays and when is completely up to you.
The elements (and this folder)
This folder provides several useful shortcuts to be able to handle 95% of situations.
/datum/element/contextual_screentip_bare_hands
This element is used to display screentips when the user hovers over the object with nothing in their active hand.
It takes parameters in the form of both non-combat mode and, optionally, combat mode.
Example:
/obj/machinery/firealarm/Initialize(mapload)
. = ..()
AddElement( \
/datum/element/contextual_screentip_bare_hands, \
lmb_text = "Turn on", \
rmb_text = "Turn off", \
)
This will display "LMB: Turn on | RMB: Turn off" when the user hovers over a fire alarm with an empty active hand.
/datum/element/contextual_screentip_tools
This element takes a map of tool behaviors to context lists. These will be displayed when the user hovers over the object with an item that has the tool behavior.
Example:
/obj/structure/table/Initialize(mapload)
var/static/list/tool_behaviors = list(
TOOL_SCREWDRIVER = list(
SCREENTIP_CONTEXT_RMB = "Disassemble",
),
TOOL_WRENCH = list(
SCREENTIP_CONTEXT_RMB = "Deconstruct",
),
)
AddElement(/datum/element/contextual_screentip_tools, tool_behaviors)
This will display "RMB: Deconstruct" when the user hovers over a table with a wrench.
/datum/element/contextual_screentip_item_typechecks
This element takes a map of item typepaths to context lists. These will be displayed when the user hovers over the object with the selected item.
Example:
/obj/item/restraints/handcuffs/cable/Initialize(mapload)
. = ..()
var/static/list/hovering_item_typechecks = list(
/obj/item/stack/rods = list(
SCREENTIP_CONTEXT_LMB = "Craft wired rod",
),
/obj/item/stack/sheet/iron = list(
SCREENTIP_CONTEXT_LMB = "Craft bola",
),
)
AddElement(/datum/element/contextual_screentip_item_typechecks, hovering_item_typechecks)
This will display "LMB: Craft bola" when the user hovers over cable restraints with metal in their hand.
The basic system (and when to not use this folder)
The basic system acknowledges the following two interactions:
Self-defining items (Type A)
These are items that are defined by their behavior. These should define their contextual text within themselves, and not in their targets.
- Stun batons (LMB to stun, RMB to harm)
- Syringes (LMB to inject, RMB to draw)
- Health analyzers (LMB to scan for health/wounds [another piece of context], RMB to scans for chemicals)
Receiving action defining objects (Type B)
These are objects (not necessarily items) that are defined by what happens to them. These should define their contextual text within themselves, and not in their operating tools.
- Tables (RMB with wrench to deconstruct)
- Construction objects (LMB with glass to put in screen for computers)
- Carbon copies (RMB to take a copy)
Both of these are supported, and can be hooked to through several means.
Note that you must return CONTEXTUAL_SCREENTIP_SET if you change the contextual screentip at all, otherwise you may not see it.
COMSIG_ITEM_REQUESTING_CONTEXT_FOR_TARGET
This signal is registered on items, and receives the hovering object, provided in the form of obj/item/source, list/context, atom/target, mob/living/user.
/atom/proc/register_item_context(), and /atom/proc/add_item_context()
/atom/proc/add_item_context() is a proc intended to be overridden to easily create Type-B interactions (ones where atoms are hovered over by items). It receives the exact same arguments as COMSIG_ITEM_REQUESTING_CONTEXT_FOR_TARGET: obj/item/source, list/context, atom/target, mob/living/user.
In order for your add_item_context() method to be run, you must call register_item_context().
COMSIG_ATOM_REQUESTING_CONTEXT_FROM_ITEM
This signal is registered on atoms, and receives what the user is hovering with, provided in the form of atom/source, list/context, obj/item/held_item, mob/living/user.
/atom/proc/register_context(), and /atom/proc/add_context()
/atom/proc/add_context() is a proc intended to be overridden to easily create Type-B interactions (ones where atoms are hovered over by items). It receives the exact same arguments as COMSIG_ATOM_REQUESTING_CONTEXT_FROM_ITEM: atom/source, list/context, obj/item/held_item, mob/living/user.
In order for your add_context() method to be run, you must call register_context().
When using any of these methods, you will receive a mutable context list.
Context lists
Context lists are lists with keys mapping from SCREENTIP_CONTEXT_* to a string. You can find these keys in code/__DEFINES/screentips.dm.
The signals and add_context() variants mutate the list directly, while shortcut elements will just have you pass them in directly.
For example:
context[SCREENTIP_CONTEXT_LMB] = "Open"
context[SCREENTIP_CONTEXT_RMB] = "Destroy"