* Synchronise AI and Player basic mob melee behaviours (#78337)
## About The Pull Request
I like for things that mobs do to be consistent regardless of whether
they are controlled by a player or by the AI.
One big offender of this is the melee behaviour cooldown. Basic mobs
piloted by AI have arbitrary melee attack cooldowns which are not
reflected when they are controlled by players who can generally attack
much faster (but in _two_ instances, slower).
To remedy this I added `melee_attack_cooldown` as a var on
`living/basic` (sinful) and the ai now uses NextMove to not click too
often, meaning that players can only bite things as often as the AI can
and also that if you VV the cooldown it can speed the AI up (or slow it
down) as well as a player.
This also gets rid of a lot of subtypes of that datum, as we mostly made
them to change the cooldown.
I also hunted down a few places where there was behaviour placed inside
an AI behaviour which wasn't easily replicable by a player piloting the
same mob, preferably a player should be able to do everything that the
AI can.
Fixing this was largely a simple case of moving code from
`ai_behaviour/melee_attack/perform` to `basic/mob_subtype/melee_attack`
and also adding an element for one thing shared by three different mobs.
Strictly speaking I didn't need the element that much because a player
is perfectly capable of clicking on something they attack to drag it,
but it's nice for it to be automatic?
## Why It's Good For The Game
If you see a mob do something then you should also be able to do it.
Mobs shouldn't have significantly different capabilities when controlled
by a player (aside from usually being smarter).
## Changelog
🆑
balance: Player-controlled basic mobs attack as fast as those mobs can
when controlled by the AI
balance: Player-controlled Faithless can paralyse people they attack,
like the AI does
balance: Player-controlled Star Gazers (if an admin felt like making
one) apply the star mark on attack and deal damage to everything around
them, like the AI does
/🆑
* Synchronise AI and Player basic mob melee behaviours
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* `mob_transformation_simple` sends a `COMSIG_MOB_CHANGED_TYPE` signal, letting `content_barfer` mobs spit things out (#78093)
## About The Pull Request
Title; also makes bileworm devour message have a warning span.
~~it's a bit cheeky but i didn't want to add a deletion signal to the
content_barfer's signal list, and the wabbajack signal here kinda makes
sense?~~
## Why It's Good For The Game
Fixes#76791
## Changelog
🆑
fix: fixed bileworm evolution deleting anything they devoured; they will
now eject their contents upon evolution to vileworms
/🆑
* `mob_transformation_simple` sends a `COMSIG_MOB_CHANGED_TYPE` signal, letting `content_barfer` mobs spit things out
---------
Co-authored-by: Sealed101 <cool.bullseye@yandex.ru>
* [no gbp] Dump consumed mobs when shapeshift effect ends (#77574)
## About The Pull Request
Fixes#77536
When you stop being shapeshifted we delete the mob you were previously
transformed into, which obviously also deletes everything in its
contents. If that mob can eat other mobs it deletes those mobs too.
We have an element "content barfer" which resolves this, I have made it
register to the "unshapeshift" signal to trigger dumping the contents
too, and added it to some mobs which were missing it.
## Why It's Good For The Game
Players were surprised by consuming player corpses after transforming
into a gelatinous cube and thus permanently deleting them.
## Changelog
🆑
fix: If you shapeshift into a mob which can eat things such as player
corpses, those things will fall out when you stop shapeshifting
/🆑
* [no gbp] Dump consumed mobs when shapeshift effect ends
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Save 0.6-0.7s of init time by splitting registering lists of signals into its own proc, and optimizing QDELETED
* modular RegisterSignals
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* Improve the naming of the element argument hash index selector (#71319)
So confusing name
* Improve the naming of the element argument hash index selector
* sr sync
Co-authored-by: oranges <email@oranges.net.nz>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* 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>
Ghom