Files
Bubberstation/code/datums/elements/screentips/contextual_screentip_tools.dm
SkyratBot 80d124a3c6 [MIRROR] Remove ELEMENT_DETACH on everything that doesn't need it, rename to ELEMENT_DETACH_ON_HOST_DESTROY + a PSA (about 0.2s init time savings) [MDB IGNORE] (#17384)
* Remove ELEMENT_DETACH on everything that doesn't need it, rename to ELEMENT_DETACH_ON_HOST_DESTROY + a PSA (about 0.2s init time savings) (#70972)

ELEMENT_DETACH is **not** a requirement to having `Detach` called.
Detach is always called when the element itself is destroyed.

ELEMENT_DETACH is a flag that when set, makes sure Detach is called when
the atom destroys.

Sometimes you want this, for instance:

```dm
/datum/element/point_of_interest/Detach(datum/target)
	SSpoints_of_interest.on_poi_element_removed(target)
	return ..()
```

This Detach cleans up a reference that would have hung if target was
destroyed without this being called.

However, most uses of Detach are cleaning up signals. Signals are
automatically cleaned up when something is destroyed. You do not need
ELEMENT_DETACH in this case, and it slows down init. This also includes
somewhat more complex stuff, like removing overlays on the source
object. It's getting deleted anyway, you don't care!

I have removed all uses of ELEMENT_DETACH that seemed superfluous. I
have also renamed it to `ELEMENT_DETACH_ON_HOST_DESTROY` to make its
purpose more clear, as me and a lot of other maintainers misunderstood
what it did,

---

An update to this, ELEMENT_DETACH *is* needed for anything that can
register to a turf, as turfs do not clear their signals on destroy.

* Remove ELEMENT_DETACH on everything that doesn't need it, rename to ELEMENT_DETACH_ON_HOST_DESTROY + a PSA (about 0.2s init time savings)

* skyrat elements

Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
2022-11-05 17:48:01 -04:00

49 lines
1.7 KiB
Plaintext

/// Apply basic contextual screentips when the user hovers over this item with an item of the given tool behavior.
/// A "Type B" interaction.
/// This stacks with other contextual screentip elements, though you may want to register the signal/flag manually at that point for performance.
/datum/element/contextual_screentip_tools
element_flags = ELEMENT_BESPOKE | ELEMENT_DETACH_ON_HOST_DESTROY // Detach for turfs
id_arg_index = 2
/// Map of tool behaviors to contexts to usages
var/list/tool_behaviors
/datum/element/contextual_screentip_tools/Attach(datum/target, tool_behaviors)
. = ..()
if (!isatom(target))
return ELEMENT_INCOMPATIBLE
src.tool_behaviors = tool_behaviors
var/atom/atom_target = target
atom_target.flags_1 |= HAS_CONTEXTUAL_SCREENTIPS_1
RegisterSignal(atom_target, COMSIG_ATOM_REQUESTING_CONTEXT_FROM_ITEM, .proc/on_requesting_context_from_item)
/datum/element/contextual_screentip_tools/Detach(datum/source, ...)
UnregisterSignal(source, COMSIG_ATOM_REQUESTING_CONTEXT_FROM_ITEM)
// We don't remove HAS_CONTEXTUAL_SCREENTIPS_1, since there could be other stuff still hooked to it,
// and being set without signals is not dangerous, just less performant.
// A lot of things don't do this, perhaps make a proc that checks if any signals are still set, and if not,
// remove the flag.
return ..()
/datum/element/contextual_screentip_tools/proc/on_requesting_context_from_item(
datum/source,
list/context,
obj/item/held_item,
)
SIGNAL_HANDLER
if (isnull(held_item))
return NONE
var/tool_behavior = held_item.tool_behaviour
if (!(tool_behavior in tool_behaviors))
return NONE
context += tool_behaviors[tool_behavior]
return CONTEXTUAL_SCREENTIP_SET