SimTimes returned by GameLoop and GameSystemManager are different (SiO2)

[pspeed]

But baseTime was broken. I can’t put it back without breaking the other things again.

[asser_fahrenholz]

Is this “ActionArbiter” service something that could be added to SiO2 as a base service with some abstract class as “Action” ? Seems fundamental to have some service that orders all “actions” - or am I misreading this thread? I have some implementation of “Action” as well in my game and (I think) some queue system to execute them.

[pspeed]

Maybe. But in the simplest case, you can already enqueue one-time tasks in the TaskDispatcher if you don’t care that it currently only accepts Callables.

I will be building out a bunch of these services in MOSS and probably backport some stuff to SiO2. I’ve already been doing that as I go. (See Blackboard, JobService/State, etc.)

Sometimes it’s game specific. Like the ‘modify block’ commands in Mythruna are queued up by the world service and executed as part of its update. Controlling this queue itself means that it can collect changes together into larger change events if it wants to.

[pspeed]

@Ali_RS

Could it be that lastRealTime and gameTime values are not cached at once but at different times in the networking thread? (for example, the thread reset lastRealTime cache at time X while resetting gameTime cache at time Y) In that case, the returned unlocked time will be invalid.

Thinking about this some more, I think practically speaking this may not be an issue… at least not with SimEthereal and I’d hope it was true for other networking approaches.

I’m 99% sure that SimEthereal’s updates to the clients (and things that would get timestamped with SimTime times) are pushed based on the zone updates which are typically pushed by the physics engine… which should be already managed by the game system manager.

For games that don’t update the state from the game system update loop then it was unreliable of them to depend on SimTime’s non-thread safe implementation. Proper update loop shunting would be needed with synchronization, etc.

So I think I’m going to leave it for now.

[Ali_RS]

@pspeed

I’m 99% sure that SimEthereal’s updates to the clients (and things that would get timestamped with SimTime times) are pushed based on the zone updates which are typically pushed by the physics engine… which should be already managed by the game system manager.

I might be wrong, but isn’t it the StateCollector thread that is responsible for collecting, time stamping, and publishing the states? That is where I get when I traced back the calls to the ethereal host time source.

[pspeed]

Yeah, but it’s not providing any timestamps. Those were set to the frame times when the updates happened.

I need to look deeper into the code when I get a chance because even my gut says you are right on some level… else I can’t figure out why we needed unlocked time in the first place.