Multi-Shard Server With Varying Seasons

[Joachim]

Dear all,

I am currently running a multi-world server with more than two different worlds (not just caves). I have noticed that days and seasons are synchronized and dictated by the master shard. Is there any way (e.g., by creating a mod) that allows me to override the season settings for individual shards? For example, it would be interesting for a shard to be in winter, while the other shard is in summer, or you could even have a shard where it is always winter.

Thanks in advance.

[DarkXero]

 

[Joachim]

12 hours ago, DarkXero said:

 

Thank you, that is very helpful. This is basically all I need to get what I want. However, you mentioned in that thread you would have to "perform surgery on the clock". Can't I just do something similar to what you did with the seasons update function, by removing the listeners from the clock synchronization on the slave shards?

[DarkXero]

11 hours ago, Joachim said:

Can't I just do something similar to what you did with the seasons update function, by removing the listeners from the clock synchronization on the slave shards?

I feel uneasy about desynching the only constant the shards have.

If your servers have "pause when empty" enabled, then you are going to have 50 days on one, and 20 days on the other one, if one is populated and the other is empty.

But you can go right ahead and do:

local function UpdateClock(self)
	local world = GLOBAL.TheWorld
	world.event_listeners.slave_clockupdate = {}
	world.net.event_listening.slave_clockupdate = {}
end

AddComponentPostInit("clock", UpdateClock)

 

Edited June 29, 2016 by DarkXero

[Joachim]

Thank you very much. I am slowly getting more insight into how the game logic works. 

But yes, I would prefer that each world runs while the Master shard is running (and paused when no one is playing). In this way, you could have one world in autumn and the other in spring. When one world enters winter, then the other enters summer, and vice versa.

This may be a little demanding, though. Since if one machine slows down for some reason, it may become desynchronized over time. Initially, this may be a few seconds, but eventually the seconds will accumulate and become significant. So, assuming that each day should be equal in length (regardless of how the day phases are divided), there would also be a need for a synchronization event that forces every server to go to the next day when the Master shard goes to the next day (while at the same time being desynchronized for day phases).

Is this difficult to implement?

 

Edited June 29, 2016 by Joachim

[DarkXero]

10 minutes ago, Joachim said:

Is this difficult to implement?

It kinda is, because when the clock updates it sends this information to the slaves:

            segs = {},
            cycles = _cycles:value(),
            moonphase = _moonphase:value(),
            phase = _phase:value(),
            totaltimeinphase = _totaltimeinphase:value(),
            remainingtimeinphase = _remainingtimeinphase:value(),

So you can comment segs out, so the day segments are different between servers.

cycles and moonphase refer to day count and moonphase, so you don't comment those out.

phase and totaltimeinphase and remainingtimeinphase refer to day, dusk, and night, and how much of it elapsed.

It the servers have different segs, then the clock will put its arrow on the middle of the dusk in one and in the middle of the dusk in the other one. So the dusk of the slave will last as long as the dusk of the master.

So you would need to send the time elapsed in the day, and then recalculate it in the slave, and then update the phases in the slave.

[Joachim]

So, let me get this straight.

- I need to remove (or ignore) the information about phase, totaltimeinphase and remainingtimeinphase.
- I need to add information about the elapsed time, since the master only sends the remaining time in a specific phase.
- Then I need to override the listener that responds to clock update events and remainingtimeinphase for the slaves. If it reaches 0, then I jump to the next phase.

I am currently looking in the code of clock.lua, but it is kind of messy. There is a lot of things happening, so it is easy to miss something.