About weather
#1
Hello all,

I've been pondering about the weather system in MCS for a few days now.

The current system of changing the weather isn't optimal for a few reasons:
  • Causes strain on the server by checking weather every tick
  • Is a little too random
  • Almost guarantees a thunderstorm will happen

As a matter of fact, a feature request was opened in the bug tracker and I could keep the discussion there, but I feel more people will read it here and possibly come with suggestions.

I've been reading the bukkit source (around line #1773) to figure out how they were doing it, but this only describes some of the logic that needs to be implemented.

I've seen a comment in the MCS source questioning whether each world should have its own thread, which seems like a reasonable start.

My current thoughts on improving the weather system are as follows:

1.
  1. Implement an observable weather management class, which would run in its own thread.
  2. Make the world respond to the weather management.

In this scenario with the current world implementation, all worlds would have the same weather.

Discuss Smile
Reply
Thanks given by:
#2
I'm not sure I'm following what you're suggesting. What exactly does "observable" in this context mean? Why would you need a weather management class, why not add just a member or two to the cWorld class?

I've already mind-designed a system for weather that would be, I believe, adequate. Doesn't require any new classes, doesn't require any changes to the threading model, it's pretty and simple:
1. Each world starts with Sunny
2. An interval is selected, depending on the weather type, how long the current weather lasts.
3. When the interval runs out, a new weather and according interval are selected.

So, this change would require:
1. Add the interval member to cWorld
2. Add or modify cWorld::ChangeWeather() function to change weather and set a new interval
3. cWorld's TickWeather should only check the interval and once it elapses, call the ChangeWeather() function with weather.
4. Make cWorld::ChangeWeather accessible from Lua.

I don't think adding a thread just for weather is a good idea. A thread consumes quite a few resources that we cannot spare on some small-footprint platforms (stack RAM) and brings synchronization issues with it (critical sections with possible deadlocks).

However, I'm totally for the idea of each world having a separate tick thread. This is out of the scope of this post, though (not that it would be that difficult to implement that).
Optional configuration: world may have no weather changes (think Nether) -> ChangeWeather checks if a change is allowed. Even more comfortable - allow the kinds of weathers and their interval lengths to be ini-adjusted.
Reply
Thanks given by:
#3
Your proposal sounds nice, but in my understanding we would still be making a check each tick, now whether the interval was reached.

(06-11-2012, 11:59 PM)xoft Wrote: Optional configuration: world may have no weather changes (think Nether) -> ChangeWeather checks if a change is allowed. Even more comfortable - allow the kinds of weathers and their interval lengths to be ini-adjusted.

Better yet, make worlds without weather skip weather altogether (small change to world.ini)
Reply
Thanks given by:
#4
(06-12-2012, 12:10 AM)cedeel Wrote: Your proposal sounds nice, but in my understanding we would still be making a check each tick, now whether the interval was reached.
Yes, but the check is much less strain than an extra thread. The check is a simple substraction and then comparison, about four CPU instructions. An extra thread means extra thread context switching and synchronization.

(06-12-2012, 12:10 AM)cedeel Wrote: Better yet, make worlds without weather skip weather altogether (small change to world.ini)
Implementation details, of course.

Reply
Thanks given by:
#5
Just give me OnWeatherChanged() hook to start thunderstorms with lightning strike at 0,0 in case you'll remove that feature one day >:-D
Reply
Thanks given by:
#6
Lightning strike at 0,0,0 will probably go away completely as part of this undertaking.

I suppose a method to strike a given position could be made and exported.
Reply
Thanks given by:
#7
It is made Smile Called cWorld::CastThunderbolt
Reply
Thanks given by:




Users browsing this thread: 5 Guest(s)