PlanetsCentral

Hi,

we (the players of pleiades 14) just had a break and therefor two scedule changes. And while there was no problem with the first one, we had two important missing turns at the last one (well at least one was important).

Personally I find it highly irritating, that the game page tells you about a scedule change on day x hour y but what it is actually doing is a host run at exactly that time. Scedule changes should happen right after the usual hostrun-time never ever right before to avoid this very problem.

thank you

Personally I find it highly irritating, that the game page tells you about a scedule change on day x hour y but what it is actually doing is a host run at exactly that time. Scedule changes should happen right after the usual hostrun-time never ever right before to avoid this very problem.

"Schedule change after a host run" doesn't make sense: if a schedule change is planned on Thursday, and host runs Wednesday 12:00, should I already change it? What if another host runs Wednesday 18:00? What if host doesn't run at all until Thursday? What is the usual hostrun-time during a pause? I find this hard to put into words, and even harder to put into code.

I always set the end of a host pause interval to exactly a host date. This means that, in general, a host runs at that time.

However, you are absolutely right that the display on the game page is not optimal. It just displays the scheduler's next action, which is the schedule change, but that's an unnecessary technicality that you're not interested in. You want to see the next host date.

I know the system has some limitations here. The other big one is that the schedule details view cannot "look across" a host pause.

I use your message to increase the priority of improving the host time prediction displays

--Stefan

"Schedule change after a host run" doesn't make sense: if a schedule change is planned on Thursday, and host runs Wednesday 12:00, should I already change it? What if another host runs Wednesday 18:00?

On the contrary its perfectly sensible.

I totally don't understand you here. There is exactly one reason to do a scedule change - which is to prevent host from running. There is absolutely nothing else. The general reason for that is a player not present for a limited time, but even if there is another reason I can't grasp your problem.

The only reason to do a scedule change is to prevent the host from running. So if you did prevent the host from running change the scedule right away. This means you change the the scedule right after the hostrun you wanted to prevent on wednesday 12:00 if that was the last one you wanted to prevent. Which should in itself answer your secondary question.

So let's say usual hostrun is wednesday 12:00 but you wanted to prevent this one. Change scedule at 12:30 the same day. When the usual next hostrun will be at saturday 12:00 and that will be written in the game page.
Nothing else will change - there should not even be a need to change the auto checks. The host will still run if turns are in, and if there is a hostrun in that very time the hostrun at saturday will be delayed to next wednesday as usual because you want to prevent a host from running at saturday 12:00 when the last host ran friday evening due all turns were.

I really think that feature is what is causing so much trouble here because that's the reason for the host to run sometimes right after scedule changes and sometimes not. Which makes perfectly sense afterwards yet is practically impossible to predict.
(but naturally we want to keep that feature and just make the next host run predictable from the game page)

The only reason to do a scedule change is to prevent the host from running. So if you did prevent the host from running change the scedule right away. This means you change the the scedule right after the hostrun you wanted to prevent on wednesday 12:00 if that was the last one you wanted to prevent. Which should in itself answer your secondary question.

So let's say usual hostrun is wednesday 12:00 but you wanted to prevent this one. Change scedule at 12:30 the same day. When the usual next hostrun will be at saturday 12:00 and that will be written in the game page.
Nothing else will change - there should not even be a need to change the auto checks. The host will still run if turns are in, and if there is a hostrun in that very time the hostrun at saturday will be delayed to next wednesday as usual because you want to prevent a host from running at saturday 12:00 when the last host ran friday evening due all turns were.

No. If I did that, host would wake up at 12:30, look a little confused "whoops, I'm on a 12:00 wed/sat schedule, I must have forgotten the Wednesday host", and will run a turn. The scheduler must be able to deal with delayed hosts. Hosts can be delayed by other hosts running at that time, general system load, unplanned reboots, etc. You wouldn't want to skip a host because it was delayed by a few seconds? There needs to be a grace period. Right now, that grace period is set to 6 hours for most games.

Thus, the "pause end" time needs to be after the grace period. There is some pretty complex logic there to try to do the "obvious" thing. Setting the "pause end" time precisely on a host date makes everything clear.

I really think that feature is what is causing so much trouble here because that's the reason for the host to run sometimes right after scedule changes and sometimes not. Which makes perfectly sense afterwards yet is practically impossible to predict.
(but naturally we want to keep that feature and just make the next host run predictable from the game page)

It's actually simple: host runs at the schedule change time unless the host before was too close. "Too close" means: after the previous host-that-would-have-been. For a Thu/Sun schedule starting Sunday, the Sunday host will run if the previous all-turns-in host was on Thursday or before. This condition applies all the time: a scheduled host will run unless the previous all-turns-in host was too close.

Again, the logic is not easy, and the best way to get out of the situation is to let the computer to it and just show the next host run.

--Stefan

Again, the logic is not easy, and the best way to get out of the situation is to let the computer to it and just show the next host run.

--Stefan

If that is the most simple way for you than that's it.