## About The Pull Request
A weather anomaly can spawn on the station, causing a sandstorm,
snowstorm, or rainstorm to affect the room (and nearby rooms). These
weathers range from "harmless" to "mildly damaging".
They last for around five minutes.
The weather doesn't start immediately, giving people time to neutralize
it before it causes damage.
Neutralizing the anomaly stops the weather.
If they detonate, it just throw objects away from itself.
<img width="407" height="225" alt="image"
src="https://github.com/user-attachments/assets/2de1b797-2b17-442c-9023-11085b4849cf"
/>
<img width="991" height="674" alt="image"
src="https://github.com/user-attachments/assets/afe5a21d-9cf8-4e9d-95ec-adef6fd12a93"
/>
A rarer version of the anomaly can also occur, which brings a lightning
storm, which may damage the station itself.
Also, reactive weather armor. When you are hit, it summons a lightning
strike below nearby assailants.
## Why It's Good For The Game
With the added rain mechanics I wanted to use them, but it's kinda hard
to shoe them into the station because, "why is it raining on a space
station that makes no sense"
However, anomalies are weird, so this fits perfectly
## Changelog
🆑 Melbert
add: Weather anomalies, in four variants: Rain, snow, sand, and the rare
lightning storm.
add: Reactive Weather Armor
/🆑
## About The Pull Request
I heard you liked commas.
## Why It's Good For The Game
Trailing commas make everyone happy!
## Changelog
Nothing anyone will notice besides downstreams adding to these lists
## About The Pull Request
While working on another PR, I noticed that there wasn't any real
distinction between subsystems that function as a network for various
logical components/systems in the code, and subsystems that are meant to
represent what is actually an in-game network. As such, I moved what
seemed to be clear representations of the functions of in-game networks
under their own subfolder.
This should have no effects otherwise.
## Why It's Good For The Game
Per an .md I added in the folder, it helps to clearly demarcate what are
backend programmatic networked systems, and what are meant to actually
be a network in the game itself; the radio jammer disrupts your suit
sensors and headset, not your signal relationships with DCS, and I
believe having that distinction be clear at a glance of the file
structure is valuable.
## Changelog
🆑 Bisar
code: Subsystems that are meant to represent a network in-game have been
moved into their own category inside the codebase.
/🆑
## About The Pull Request
I heard you liked commas.
## Why It's Good For The Game
Trailing commas make everyone happy!
## Changelog
Nothing anyone will notice besides downstreams adding to these lists
## About The Pull Request
While working on another PR, I noticed that there wasn't any real
distinction between subsystems that function as a network for various
logical components/systems in the code, and subsystems that are meant to
represent what is actually an in-game network. As such, I moved what
seemed to be clear representations of the functions of in-game networks
under their own subfolder.
This should have no effects otherwise.
## Why It's Good For The Game
Per an .md I added in the folder, it helps to clearly demarcate what are
backend programmatic networked systems, and what are meant to actually
be a network in the game itself; the radio jammer disrupts your suit
sensors and headset, not your signal relationships with DCS, and I
believe having that distinction be clear at a glance of the file
structure is valuable.
## Changelog
🆑 Bisar
code: Subsystems that are meant to represent a network in-game have been
moved into their own category inside the codebase.
/🆑
nevimer