[SOLVED] Sim-eth-es which time source to use

ia97lies · June 8, 2017, 8:16pm

I’m currently thinking of how to implement the count down timer. Let’s say my games duration is 4 minutes. Let’s further assume that I do not have a lobby room but you can enter a running game any time. If player 1 joins the game 30 seconds later, then his count down should start at 3:30.

I started to analyse how timing is done in sim-eth-es and I found that in the ModelViewState.class you have this

        // Retrieve the time source from the network connection
        // The time source will give us a time in recent history that we should be
        // viewing.  This currently defaults to -100 ms but could vary (someday) depending
        // on network connectivity.
        // For more information on this interpolation approach, see the Valve networking
        // articles at:
        // https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
        // https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
        //this.timeSource = getState(ConnectionState.class).getRemoteTimeSource();
        // 
        // We now grab time from the TimeState which wraps the TimeSource to give
        // consistent timings over the whole frame
        this.timeState = getState(TimeState.class);

so you use the time from TimeState which is kind of a local time (the getRemoteTimeSource() is deactivated).

But for the HudLabelState.java

        // Retrieve the time source from the network connection
        // The time source will give us a time in recent history that we should be
        // viewing.  This currently defaults to -100 ms but could vary (someday) depending
        // on network connectivity.
        // For more information on this interpolation approach, see the Valve networking
        // articles at:
        // https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
        // https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
        this.timeSource = getState(ConnectionState.class).getRemoteTimeSource();

the remote time source is used. And due the comment above, I somehow have the feeling this is the correct one and I also think maybe ModelViewState should also use the remote time source. Or what is the reasoning behind to have a local and a remote time source?

Back to my problem, so I would solve my problem by the player entity and attach the game state and the current time and remaining time. That means the remote time. So shouldn’t I use the remote time on the client or the local time. I guess as this count down is not super critical the local time source is ok. Are there any down sides using the remote time source?

ia97lies · June 8, 2017, 8:29pm

Ok I maybe found an answer

But it looks more like, with remote time source I have those warnings and with the local I do not. So this local time source seems like a hack to avoid another problem (which seems not to appear with the HudLabelState)?!

pspeed · June 8, 2017, 11:51pm

TimeState should be using the remote time source. The point of TimeState is that it keeps a consistent time for the whole frame where as accessing the time source directly will give you a new time every time you ask.

See:

github.com

Simsilica/Examples/blob/master/sim-eth-es/src/main/java/example/GameSessionState.java#L133



EventBus.publish(GameSessionEvent.sessionStarted, new GameSessionEvent());

// Add a self-message because we're too late to have caught the
// player joined message for ourselves.  (Please we'd want it to look like this, anyway.)
getState(MessageState.class).addMessage("> You have joined the game.", ColorRGBA.Yellow);

getState(ConnectionState.class).getService(GameSessionClientService.class).addGameSessionListener(gameSessionObserver);

// Give the time state its time source
TimeSource timeSource = getState(ConnectionState.class).getRemoteTimeSource();
getState(TimeState.class).setTimeSource(timeSource);

// Setup the chat related services
getState(ConnectionState.class).getService(ChatClientService.class).addChatSessionListener(chatSessionObserver);
getState(CommandConsoleState.class).setCommandEntry(chatEntry);

InputMapper inputMapper = GuiGlobals.getInstance().getInputMapper();
inputMapper.activateGroup(MainGameFunctions.IN_GAME);
 
// Temporary FIXME

…which sets the time source that TimeState uses to the remote time state.

Time needs to be consistent everywhere if you want game time. That’s what RemoteTimeSource gives you.

In the linked thread, his problem was somehow that he was triggering the watchdog log statement about time not advancing. For some reason, in his case, subsequent calls to nanoTime() were returning the same value. By using the TimeState, nanoTime() is only called once per frame.

github.com

Simsilica/Examples/blob/master/sim-eth-es/src/main/java/example/TimeState.java#L87


}

public long getTime() {
    return frameTime; 
}

public long getRealTime() {
    return realTime;
}

public void update( float tpf ) {
    if( timeSource != null ) {
        this.frameTime = timeSource.getTime();
        this.realTime = System.nanoTime();
    }
}

@Override
protected void initialize( Application app ) {
}

So on the client, it’s best to use TimeState… especially if you will be updating multiple time related things in the same frame. The reason the HudLabelState gets away with it is that it’s only showing one time related thing, I guess. Likely I just hadn’t implemented TimeState yet when I wrote that.

ia97lies · June 9, 2017, 4:32am

Make sense. I missed to grep the usage of setTimeSource it seems. Thanks a lot.