Files
Bubberstation/code/datums/elements/screentips
SyncIt21 6dc40ca522 Standardizes object deconstruction throughout the codebase. (#82280)
## 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 do

b5593bc693/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 everywhere

b5593bc693/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 behind

b5593bc693/code/datums/elements/frozen.dm (L66-L67)

By hologram objects. Obviously if you destroy an hologram nothing real
should drop out

b5593bc693/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
exists

b5593bc693/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 such

3e84c3e6da/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>
2024-04-04 18:55:51 -06:00
..

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"