Files
Bubberstation/code/datums/components
Chubbygummibear 22d319fa86 Weather planes from The Wallening to fix multi-z weather overlays (#86733)
## About The Pull Request

I started doing this for Yogstation, but ended up doing all my testing
on TG code since there's more debug tools to use, and @LemonInTheDark
said I should upstream it when I was done. So I'm just gonna start here.
The whole point of this is to stop multi-z maps from stacking weather
overlay effects like

![dreamseeker_FBUu3nPLCJ](https://github.com/user-attachments/assets/52559dfc-68d2-403d-8148-b410750f78c4)
Old pic I know, but you get the point

Now it behaves as expected


https://github.com/user-attachments/assets/6d737eae-2493-4b48-8870-e4ac73dcbbeb



https://github.com/user-attachments/assets/b253aa97-c90d-4049-a97d-940b0ec386d0


<details>

<summary>Note: this does not fix the issue of areas out of your view not
updating their appearance. 90% sure that's a Byond™️ issue</summary>


https://github.com/user-attachments/assets/3db5ce28-2623-4d3e-a5f4-bd561d96010a

</details>



## Why It's Good For The Game

Isolating weather to its own planes is good for having better control
over how it behaves. Since weather overlays are tied to areas it makes
them kinda hacky to begin with, but this is a step in reigning them in.

## Changelog
🆑
fix: fixed multi-z weather overlays stacking and not hiding overlays
above you
/🆑
2024-10-02 22:49:09 -07:00
..
2024-08-21 17:07:02 +12:00
2024-05-16 19:54:00 -07:00
2024-08-15 01:28:21 +01:00
2024-05-16 19:54:00 -07:00
2024-06-13 13:29:45 -07:00
2024-05-16 19:54:00 -07:00
2024-08-23 21:49:46 +02:00
2024-08-21 17:07:02 +12:00
2024-03-27 16:49:46 -06:00
2024-07-15 16:28:41 +01:00
2024-05-16 19:54:00 -07:00
2024-08-02 23:12:35 +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 its 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