Hi! Thanks for Dynamic Rain — it looks and sounds great.

I'm building a large overhaul mod (EternalIndustry) where rain has gameplay effects: short circuits in unsheltered electrics, humidity-dependent defect rates, weather stations that forecast rain. I already follow your weather through the remote interface (is_raining / time_left), so the visuals and our mechanics stay in sync.

What I can't do is drive the weather: my mod has its own climate (seasons, per-planet profiles, forecasts decided in advance), and there is no way to tell Dynamic Rain what to do. Could you add a few remote functions? For example:

set_phase (surface_index, "wet"/"dry", duration_ticks)
- start/stop rain now

set_external_control (surface_index, true/false)
- pause your own scheduler, so another mod decides phases

set_intensity *(surface_index, 0..1)
- visual density per surface

add_surface (surface_index) / remove_surface (...)
- beyond the settings list

on_phase_changed event (surface_index, phase, duration)

Even just set_phase + set_external_control would be enough for me. I'm happy to test it or send a PR if you have a repository.

Hi! Thanks for the suggestion! Your EternalIndustry mod sounds interesting.

How about start_phase(surface_index, "wet"/"dry", duration_ticks) with this behavior?

• Disables Dynamic Rain’s own scheduler on that surface
• Automatically enables rain on the specified surface
• If the requested phase is already active, resets its timer to the duration_ticks passed to start_phase
• Otherwise, takes 600 ticks (10 seconds) to fade rain in or out before starting the requested phase (standard mod behavior)
• After the duration ends, switches to the opposite phase with an "infinite" timer, until your mod gives another instruction
• Raises on_phase_changed when the phase actually changes

Would this work for your climate and forecasts?

Yes, that works well for us - thank you! Our climate decides rain episodes ahead of time (forecasts need that), so we would call start_phase(surface, "wet", duration) when an episode begins, and your "infinite dry" afterwards is exactly right. Clouds and solar we handle ourselves. Auto-enabling rain on the surface is great too: our other planets (e.g. Gleba, almost constant rain) would get your visuals.

Three small additions, if possible:
1. Optional intensity: start_phase(surface, "wet", duration, {intensity = 0..1}) scaling drop density and rain volume. Our episodes range from drizzle (~0.15) to downpour (1),and the strength matters for our mechanics.
2. A way to hand the surface back: release(surface_index) returns it to your own scheduler. Ideally also automatic: e.g. start_phase(..., {owner = "EternalIndustry"}) and on_configuration_changed releases surfaces whose owner mod is no longer active - otherwise removing our mod would leave a surface dry forever.
3. Optional thunder toggle per call ({thunder = false}) - for dust storms or blizzards we may want no thunder.

One question: does the requested phase start exactly 600 ticks after the call? Then we will call it 600 ticks ahead so your fade matches our episode start.

Thanks again!

Yes, the transition takes 600 ticks; that’s a mod constant. When switching from dry to wet, you can call start_phase 600 ticks ahead, and is_raining will become true when the wet phase starts.

1. Drop density should be straightforward. Volume needs more work: the new sound system uses a speaker, while the old system made rain louder by overlapping sounds
2. If your mod enabled rain on a planet that normally has none (by calling start_phase), should release(surface_index) disable rain there, or keep rain with Dynamic Rain’s own scheduler? On a planet where rain is normally enabled (Nauvis for example), should release(surface_index) simply restore the normal scheduler?
3. For thunder = false, do you mean disabling both thunder sounds and lightning flashes for that episode while keeping the rain?

Thanks, that all sounds right.

1. 600 ticks, perfect, we'll call start_phase 600 ticks ahead.
2. Drop density alone is enough for us. If volume is hard with the new speaker system, skip it or leave it for later - density matters more.
3. release(surface_index): please return the surface to whatever your settings say. If the planet is in your allowed list (Nauvis), restore your normal scheduler; if it isn't (a planet we enabled only via start_phase), turn rain off there again. That way the player's settings stay the authority once our mod lets go. It would also help if this happened automatically when the controlling mod is gone (e.g. an owner name passed in start_phase, checked in on_configuration_changed) - otherwise removing our mod would leave a surface stuck in an endless phase.
4. thunder = false: yes - no thunder sounds and no lightning flashes for that episode, rain itself stays.

Hi! I decided to simplify a few things compared to what we discussed:
- After the requested period ends, Dynamic Rain resumes its own scheduler instead of entering an “infinite” opposite phase. Your mod would need to request a dry period between planned rain episodes
- There is no owner or release. Removing your mod won’t cancel the current period, and surfaces enabled through the API will remain enabled. If needed, players can reset this by removing Dynamic Rain, saving without it, and reinstalling it.

I've added the Remote API functions in 0.7.0. The details are in the mod description. Hope this covers your use case!

Hi!
Even this is already good. Will it be available for version 2.1 soon? I noticed that you’re using 2 parallel versions.

Sure. I'll support 2.1 as well soon. 2.1 is still experimental and has at least some performance issues. That's why I decided to keep developing for 2.0