## About The Pull Request
Fixes#76495
This PR prevents (most) screen elements from running base
`/atom/proc/Click` and `/mob/proc/ClickOn()` when clickend.
(The only exception I found to it was the cursor catcher for scopes.)
Why?
Most, if not everything in `ClickOn` is considered "in world"
interacting. It abides by `incapacitated`, runs `faceAtom`, etc.
This means, currently, you can "interact" with screen elements using in
world elements. For example, TK-ing / pointing a gun at your mood face.
Right now this affects very little, but there is a large potential for
errors. All you have to do is forget a sanity check in `afterattack` and
suddenly you have an item that can affect your screen objects.
The only example I found was the `/item/godstaff`, which can color some
of your screen elements. But there may be more. Like guns.
Note:
Many, many screen elements ALREADY do not fall down into atom click.
They simply don't call parent. Which is totally fine.
I am just ensuring ALL* screen elements do not fall down into atom
click.
## Changelog
🆑 Melbert
fix: Blocks mobs from trying to "physically" interact with some of their
hud elements, such as using Telekinesis or point a gun at your mood
meter.
/🆑
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.
MrMelbert
21d72c49c0