Files
Bubberstation/code/datums/components
Stonetear 07ac92015c Fixes stowing suit storage jetpacks when retracting modsuit chestplates (#75844)
## About The Pull Request

This is a bizare bug I discovered while trying to develop another
feature, so let's just get into the reproduction steps:
- Wear a modsuit and extend it's parts
- Put a jetpack in the suit storage slot and turn it on. Currently, the
only jetpack that fits in the storage slot on TG is the captain's
jetpack.
- While the jetpack is activated, deactivate your modsuit using the UI,
which stows the jetpack into your storage module automatically.
- This fails to unregister some signal thing because it can't find the
user.

My fix *could* be shitcode, so any feedback would be appreciated.

Jetpack activation and deactivation signals now pass a user.
`/datum/component/jetpack/proc/activate(datum/source, mob/user)`
`/datum/component/jetpack/proc/deactivate(datum/source, mob/user)`

Some jetpack `pre_move_react` thing now has a check to see if it's
argument is null.
```
if(!trail)
	return FALSE
```


## Why It's Good For The Game

Stops a crash/runtime.
## Changelog
🆑 stonetear
fix: jetpack signals now pass a user argument. This fixes an error when
automatically stowing a captain jetpack into your modsuit.
/🆑
2023-06-17 09:28:18 +12:00
..
2022-11-15 03:50:11 +00:00
2023-05-07 23:52:03 -07:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2023-06-14 19:32:08 -07:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2022-11-15 03:50:11 +00:00
2023-05-21 21:37:10 -06:00
2022-11-15 03:50:11 +00:00

Datum Component System (DCS)

Concept

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.

HackMD page for an introduction to the system as a whole.

See/Define signals and their arguments in __DEFINES\components.dm