Class UniStormIntegration

Namespace

GrindFest

Assembly

GrindFest.dll

Rebuilds UniStorm's weather effects and sounds after the hero they hang under has been destroyed.

Why this is not a patch inside "UniStorm Weather System": that folder is asset-store code, replaced wholesale on upgrade, so every line written into it is a merge conflict waiting for the next version. This file touches only the asset's public surface - the two holder fields, the five effect/sound/prefab lists and WeatherType.CreateWeatherEffect / CreateAdditionalWeatherEffect / CreateWeatherSound - and it leaves the asset's own scripts byte-identical to the shipped version (git diff on them is empty).

The behaviour it works around is inside the asset: InitializeUniStorm() parents the effect and sound holders under PlayerTransform, so destroying the player - a new hero, a party change, a save load - takes the holders and everything under them, while WeatherEffectsList / WeatherSoundsList keep the destroyed objects (Unity's fake null) and UniStormInitialized stays true, so nothing ever rebuilds them. The next weather change or hourly update then reads .name on those objects and throws MissingReferenceException, and the weather stays dead for the rest of the session. Measured in play 2026-09-16 after one hero swap: 12/12 effects and 17/17 sounds destroyed, both holders gone, UniStorm still enabled and still updating.

Everything the game does to UniStorm's player binding goes through this class: FollowHero for the hero that is now selected, StopFollowing for the other direction. Party.SelectHero and Party.ClearHeroes are the only callers, so no other file has to know that UniStorm keeps a player transform, a camera, two holders, a lightning copy and an enabled flag - or the order they have to be touched in.

A hero swap is normally just a change of target: ClearHeroes stops following before it destroys the hero, which detaches the holders so the destruction cannot take them, and SelectHero hands them to the new hero. The 12 effects and 17 sounds are never re-created for it. That matters for a Tab through the party as much as for speed: a rebuild would cut every sound mid-fade and restart every particle. Rebuilding is only the fallback for holders that were gone before anything could detach them - the first initialisation, a scene load or a save load.

The asset has its own version of the first method, UniStormManager.ChangeCameraSource, and it does the same assignments plus the lightning copy. It is not used because it also re-initialises the camera and the cloud shadows, and it returns early until UniStormInitialized - neither of which belongs in a hero swap in this game, where the party camera is shared and only the target changes.

public static class UniStormIntegration

Inheritance

object

UniStormIntegration

Methods

FollowHero(UniStormSystem, Transform, Camera)

UniStorm follows this hero: player transform, camera, the weather holders, the lightning system's own copy of the transform, and the enabled flag - the first half of the invariant in one call.

StopFollowing(UniStormSystem)

The invariant, in one call: UniStorm follows a hero or it is off. Detaches the weather holders first, so the hero that is about to be destroyed cannot take them, then turns the system off and clears its player transform - a destroyed transform left in that field is what the next caller that does not check reads (a weather change, a spell), and the asset's own null checks only work on a real null.

Detaching is harmless when nothing is destroyed: the next FollowHero re-parents the same holders.