Can anyone explain the concept of “SIMTIME” in version 3.2.3 in the log file when a scenario file is running, please. Here’s an excerpt…
[14:56:56 <<<2 EGPH_M_GND]
$CREGPH_M_GND:EGPH_GND:CAPS:ATCINFO=1:SECPOS=1:MODELDESC=1:ONGOINGCOORD=1:TEAMSPEAK=1:SIMULATOR=1:ICAOEQ=1
I was EGPH_M_GND running a scenario for about an hour. A logfile over 2 million lines long was generated but can’t be replayed in PLayback Logfile connect mode. The clock in the connect dialog goes to 00:01:06 and never goes any further, presumably because of the break in timestamp sequence after that.
This makes it impossible to replay sessions - an extremely useful feature of previous versions!. Is there any way to prevent the logging of events from other scenarios?
Thanks, Jonas. I don’t think I did anything - the time displayed when running the scenario, starts automatically at zero when the run button is clicked. The clock display in the main ES window changes to the elapsed scenario time only when the first aircraft connects. That issue maybe because there are no aircraft connected at the start of the scenario. I’ll test that, by putting an aircraft in at the start.
However, in the log file, the timestamp is something different and seems to be dependent on the scenario time of other sessions running on the server at the same time (?).
Because the timestamps are not chronological, the playback logfile function stops meaning a student’s session cannot be replayed either by me, the mentor and pseudopilot, or the student from his log file.
The problem appears to be the fact that ES logs entries from other scenarios running at the same time and the timestamp relates to those other sessions.
I’ve also seen the times flickering between scenario time and actual time from my computer. It seems there is no clear distinction (anymore) between the realtime and the simulation scenario, resulting in a mix of times which cannot be processed by the replay function afterwards. I think only using your local FSD instance would solve this problem. But this requires proper port-rerouting for another user to join the session.
Thanks for your engagement with this. I don’t know anyone who opens their local FSD server to access like you suggest - after all that’s what we have a Sweatbox server.
I suppose this is an unintended side effect of displaying sim time instead of current time during a scenario (the former is useful in some ways when running a scenario and changing the sim rate).
However I don’t see why the logfile on my PC should have timestamps derived from the time on someone else’s scenario (which is what seems to be happening). It seems to defeat the object of a timestamp in a logfile.
I do understand that logfiles and playback are not functions of the scenario system so it may not be a simple fix!