* Removes some duplicated and redundant components from _datum_components() (#77615)
## About The Pull Request
As it stands, `_GetInverseTypeList()` (as used in `_JoinParent()` and
`_RemoveFromParent()`) has two issues:
1. As described in #76678, it adds duplicated components because even if
`current_type` is `/datum/component` AND we've already added it in `. =
list(our_type, current_type)`, the final line is outside the while loop
and adds it again.
2. Currently every `_datum_components` list has all of it's components
listed under the `/datum/component` key. It's used as an all-encompasing
list for when all the components an atom has need to be looped through,
but I think that's a questionable implementation. Making an entire new
list doesn't make much sense, given that accessing elements of an
associative list is very cheap, and it nearly doubles the work we do
when adding components to `_datum_components`.
Doing it with other parents at least removes the need for type checks to
get components of a given type, so I think those are fine to stay.
## Why It's Good For The Game
Closes#76678.
Avoids the questionably useful list of components with
`/datum/component` as its key from `_datum_components`.
I don't think there's anything player-facing here.
* Removes some duplicated and redundant components from _datum_components()
---------
Co-authored-by: A miscellaneous Fern <80640114+FernandoJ8@users.noreply.github.com>
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.
6edb56f5ac