Features: Each region could have its own weather.#281
Conversation
| public int thunder = 2; | ||
| } | ||
|
|
||
| public MergeStrategy mergeStrategy = MergeStrategy.KEEP_INTO; |
There was a problem hiding this comment.
add docs for this, see above in the class for how it’s done
There was a problem hiding this comment.
I added it here—is it in the wrong place? 
|
Generally appreciate this feature as it’s useful but the decision is up to @Dueris if we want to have such an invasive addition |
|
I like the idea in concept, but a few notes:
Generally speaking, I like this idea. However I do question how exactly this would work with parity with Vanilla and the APIs. Would this work more as an override? How would this work to keep plugin compat? Im just moreso wanting to keep Vanilla compat and plugin API compat while doing something like this if that makes sense. Idk, Im just more curious how this would work in terms of trying to make it so that it's compatible with plugins, while creating the system in question. It def could be useful for skyblock/oneblock servers. |
|
I think the weather command should affect the current region by default if executed by a player and the global one if by console. And we should also add a |
|
Plugin API should work globally by default tho with more API added to be able to change it per region |
|
Then would fetching the region(with no location specified) return the current region weather? And then setting it would set all regions? How would getting the region work from console or from a global perspective or the global tick? |
It should fetch from the context, so if you’re on the global scheduler then global etc, same could be done for setting. |
|
But if regions have their own weather, then what would it return from the global tick? |
The last set global weather/default |
|
What if it was never set? Would it return |
|
Yea |
|
I also think the per-region weather should be somewhat of an override, that all regions start out with the global weather whatever it happens to be and then change it on their own, and when new regions appear they should go through the same thing. So not eradicating global weather but treating it as the starting point |
|
I agree |
|
Should they fallback to the global weather too on occasion? |
I don’t think so. It would be cleaner if on creation, the regional would snapshot the current global weather and then change independent of the global one, unless changed by the /weather global command which could set it for all regions |
|
@Euphillya how does per-region weather persist across restarts? |
They aren't, given that the regions are dynamic. They are even reset to 0 ticks at that location: https://github.com/Euphillya/Canvas/blob/2faf0cb26120391927365f40e25fa8b23de09a6d/canvas-server/minecraft-patches/features/0003-Each-region-could-have-its-own-weather.patch#L56 |
|
Yeahh I figured. Given this, it would technically deviate from Vanilla slightly with this, but I dont think this is a very important thing to be blunt. A restart resetting the weather doesnt seem that bad |
|
When per region weather is off shouldn’t it behave exactly like vanilla and current canvas behavior though |
Then, when the region is created, I can take the global world value and pass it on to the
If the configuration isn't enabled, it remains completely vanilla. |
Good idea! |
4 participants
Description
Enabling this setting allows each region on Folia to have its own weather, rather than a single global setting for everyone (disabled by default).
This could be ideal for Skyblock, OneBlock, and similar server types.
Currently incompatible (for the time being)
Plugins that attempt to modify the weather, whether globally or otherwise.
WeatherControllerImpl is not called in API
Additional feature
Added a
getoption to the/weathercommand to check the weather in the current region.Note
This PR is essentially a copy-paste from my own fork.