Server/Client scheduling questions

#1 Both options sound very possible. One question could be, is a 5 second update fast enough? If you think about the transition from day -> dusk or dawn -> day ... the transition can happen very quickly and perhaps a quicker update is necessary.

Also, relighting the TGE scene is not a quick thing to do ... If you are in the mission editor and change, say, the sunlight color, you will see no immediate change, you must tell it to "relight scene" first, and this doesn't happen very quickly either.

I'm not sure if you already have a conceptual idea of how you will accomplish this but I don't think it is supported by default and you will likely need to make C++ changes to the engine.

#2 Personally, I would do all the work on the server, then just modify the sun/sky objects to properly update their client ghosts via packUpdate. That way you won't need to run scheduled script events on the client, which is really an ugly way to get it done, and potentially breakable by malicious users. Anyone who manages to break into the client-side script elements would be able to control their view distance and lighting, or at least simply break the ToD system.

Actually, fxSunLight already has everything being sent in packUpdate, but it only does so when fxSunLightConfigChangeMask is set. As long as you use the correct console functions, setSunAzimuth/setSunElevation, this mask will be set and all clients will be updated with the new sun position. Just changing the value in script without using the set functions will not result in the mask being set, so don't do that.

The Sky class will take a little more effort, as it only sends updates on InitMask, in other words when first initialized. You could set InitMask, but that might result in sending way more data than you want to. Best to just add an update mask and send only the stuff you intend to change. There are no setFunctions for Sky's various parameters, so you'll want to add them and have those functions set your new update mask. Make sure to make consoleMethod links to those functions.

Probably sounds like more effort than you wanted, but that's the correct way to get it done, and the only way to be sure your time of day system isn't easily disabled by the client.

The best solution, but the one requiring the most effort, is to then actually build time of day into the appropriate classes. You'll still end up with script hooks, but all the work will be done in code. You'll want these script functions:
-setTimeOfDay(hours, minutes, seconds)
-setTimeOfDaySpeed(speedMultiplier) // can be negative to rewind time of day, 0 to stop
-setTimeOfDayState(hours, minutes, seconds) // save the current world state as the defined state for
hours:minutes:seconds.

Here's what will actually happen: Assuming at least 2 states have been saved, the sun and sky params will interpolate between states every frame. In other words, if you have a state set at 12:00 and another state set at 14:00, then at 13:00 it will be an exact 50/50 mix of those two states. When you reach 14:00, it will be 100% that state. The next minute, it will start interpolating with the next state (even if that next state is 12:00 again, it'll just take 22 hours of interpolation to get back to it).

You can set at many states as you want to increase the detail, but it'll always be frame by frame.

#3 Maybe you could find your answer in this resource celestial day/night

#4 Hmm, let me explain a bit...

James - I rewrote the lighting code. I will selectively relight 1 interior every 5 seconds, and the terrain every minute or so. Time isn't going by quick enough for it to be noticeable, and selective lightmap generation is fast enough for it to not hog resources.

Karen - The celestial day/night code is very old, and since I am new to the engine I didn't want to confuse myself. Its also better if I just design my own method as I don't think anyone has rewritten the lighting code like I have to do what I'm trying to do.

Henry - Ok so I'll do the scheduling on the server. When the game starts I will simply kick off a schedule that runs every 5 seconds. It will loop through all the clients and send them a clientcommand with arguments to run on the appropriate class functions.

When and where is a good place to setup this scheduler? I've traced the script code through the common directory/files into my game directory/files... it can be kind of confusing how it all works. I found that if I tried accessing the ClientGroup too early, no clients were present. Is starting the scheduler after onMissionDownloadComplete() a good spot? I figure I'll be adding more schedulers soon for things like AI and other fun stuff. So its good to put it in a place that makes sense.

Thanks for the helpful ideas everyone.

#5 Some other possibilities:

GameConnection::onClientEnterGame() // for time cycle scheduling

AIPlayer::OnAdd() // for AI stuff

#6 I was starting it in OnMissionDownloadComplete... but I guess that function gets called at the end of the relighting code. Created one nasty recursive loop that had me scratching my head for a while haha! I'll try one of those other two methods.

#7 When i have a schedule which i want to happen repeatedly, i generally do something like the following:

$gMyScheduleID = 0;

function foo()
{
   if ($gMyScheduleID != 0)
      cancel($gMyScheduleID);
   $gMyScheduleID = 0;

   // do stuff

   $gMyScheduleID = schedule(args);
}