Travel Log and the Events Recording system

[Vl3d]

After hearing other players mention it (because it takes up a huge amount of drive space), I have also taken a look at the structure of the JSON save files in "C:\Users\...\AppData\LocalLow\Intercept Games\Kerbal Space Program 2\Saves\SinglePlayer\..." and I have found the section called "TravelLogData". I believe this is evidence that KSP2's foundation supports recording mission milestones, actions and events - which will enable  a lot of features we have talked about in the past:

• colony delivery routes and seeing active flights
• parallel-sequential missions by returning to the past and seeing recorded mission play out
• in-space asynchronous multiplayer which allows time warp
• single player space races against an AI controlled agency
• vessel stage recovery flights (like FMRS)
• implementing the next gen MechJeb
• ...and much more

The structure of the Travel Log (as of 0.1.x) is:

• Objects
  • TravelObjectId
  • Statistics
    • DistanceTravelled
    • GroundDistanceTravelled
    • MaxAltitude
    • MaxGeeForce
    • MaxSpeed
    • MaxSpeedOverGround
    • MaxGroundSpeed
• ObjectEvents
  • TravelObjectId
  • EventKey
    • vesselLaunched
    • partCrashed
    • vesselSOIEntered
    • vesselLanded
    • vesselDestroyed etc.
  • Universe Time stamp
  • FlightReportArgs
    • can be parts or celestial bodies etc.

We will have to see if this will be expanded significantly as updates roll in.

The fact that the system is now mostly disabled would explain why the save game file sizes grow to GB with only repeated entries. The bug probably appeared when they decoupled the in-depth recording system from the game.

Edited March 5, 2023 by Vl3d

[MarcAbaddon]

I honestly think this is a huge stretch and I think it would be more beneficial for the community as a whole not to overhype the smallest hints.

Saving some very basic vessel statistics and milestones is very easy. Going to full flight record status (with variable physics and frame rate)... much harder. I doubt the engine even supports making sure that the same inputs at the same time will ensure the same results.

Which isn't criticism, it's really hard in a game with physics and variable frame rate.

Edited March 5, 2023 by MarcAbaddon

[Vl3d]

All related threads and posts:

1 minute ago, MarcAbaddon said:

Which isn't criticism, it's really hard in a game with physics and variable frame rate.

In a simulation game all ticks are exact and do not depend on frame rate interval.

I'm very curious what @linuxgurugamer thinks about this.

[linuxgurugamer]

5 minutes ago, Vl3d said:

In a simulation game all ticks are exact and do not depend on frame rate interval.

I'm very curious what @linuxgurugamer thinks about this.

That is in an ideal world.  Realistically, there are going to be variables.  In a game like this, even one tick can change things down the road.  Recording each and every input for each and every game tic will be unmanagable.  This thread has already shown the growth in the save file from just a few days of playing.

Personally, I'm starting a new save file every time I play right now.  This may change when I try to do a multi-vessel mission (such as station building, etc), but given the early, fragile state of the game, I'm not trying to stress out those parts which don't need to be overstressed.

[Vl3d]

3 minutes ago, linuxgurugamer said:

That is in an ideal world.  Realistically, there are going to be variables.  In a game like this, even one tick can change things down the road.  Recording each and every input for each and every game tic will be unmanagable.  This thread has already shown the growth in the save file from just a few days of playing.

Personally, I'm starting a new save file every time I play right now.  This may change when I try to do a multi-vessel mission (such as station building, etc), but given the early, fragile state of the game, I'm not trying to stress out those parts which don't need to be overstressed.

The fact that the system is now mostly disabled would explain why the save game file sizes grow to GB with only repeated entries. The bug probably appeared when they decoupled the in-depth recording system from the game.
Do you think this is evidence of the milestones recording system that we talked about before? Very curious about the diversity of events. For now there are just a few.

Edited March 5, 2023 by Vl3d

[Snafu225]

It's already ingame! /s

Spoiler

It's called flight report and is nothing new. This is everyhing you described being "recorded"

I feel the huge filesizes is something bugging out.
 

Also what Marc said is very important here.

24 minutes ago, MarcAbaddon said:

I honestly think this is a huge stretch and I think it would be more beneficial for the community as a whole not to overhype the smallest hints.

Edited March 5, 2023 by Snafu225

[MarcAbaddon]

I have looked at the code and the SAS updats are called per frame, not per physics tick. To SAS inputs are one example right away where the engine won't reproduce the same behaviour. 

[Vl3d]

1 minute ago, Snafu225 said:

I feel the huge filesizes is something bugging out.

Yes, because they probably disabled in-depth recording and it gets filled with repeated mostly empty data keys. The flight report holds just an overview of what the vessel has done. But most of it was just not recorded for now.

[Vl3d]

11 minutes ago, MarcAbaddon said:

I have looked at the code and the SAS updats are called per frame, not per physics tick. To SAS inputs are one example right away where the engine won't reproduce the same behaviour. 

Yes, but SAS is a real-time flight system that gets called per frame. It should be on a separate thread from the Universe Time background simulation as it only influences vessel orientation (and related control objects).

[MarcAbaddon]

5 minutes ago, Vl3d said:

Yes, because they probably disabled in-depth recording and it gets filled with repeated mostly empty data keys. The flight report holds just an overview of what the vessel has done. But most of it was just not recorded for now.

You are just setting up people for disappointment tbh. There's really zero evidence that those game objects are supposed to do anything except collecting the Flight Report.

You can also tell that it's not supposed to be used in the way you suppose because it has way to much overhead for that. You can't save with the below structure multiple times per seconds. You'd need a very minimalistic data structure for that. It's a good setup for logging important events, not for tracking the state of a vessel throughout the entire lifetime.
 

• ObjectEvents
  • TravelObjectId
  • EventKey
    • vesselLaunched
    • partCrashed
    • vesselSOIEntered
    • vesselLanded
    • vesselDestroyed etc.
  • Universe Time stamp
  • FlightReportArgs
    • can be parts or celestial bodies etc.

[Vl3d]

2 minutes ago, MarcAbaddon said:

You are just setting up people for disappointment tbh. There's really zero evidence that those game objects are supposed to do anything except collecting the Flight Report.

You can also tell that it's not supposed to be used in the way you suppose because it has way to much overhead for that. You can't save with the below structure multiple times per seconds. You'd need a very minimalistic data structure for that. It's a good setup for logging important events, not for tracking the state of a vessel throughout the entire lifetime.

• ObjectEvents
  • TravelObjectId
  • EventKey
    • vesselLaunched
    • partCrashed
    • vesselSOIEntered
    • vesselLanded
    • vesselDestroyed etc.
  • Universe Time stamp
  • FlightReportArgs
    • can be parts or celestial bodies etc.

The big save file size bug is an indication that the methods of the recording system get called very frequently. What you see in the save file and in the Flight Report is a massively filtered and truncated version of that.
The purpose of this tread is not managing expectations, but discussing what gameplay features this recording system (which IMO is one of the foundations of KSP2 gameplay) enables for the future.

[LameLefty]

Even the rudimentary recording systems as it is currently implemented is … interesting.  Most of my flights, after a safe recovery of the crew,  show absurdly high maximum G forces. A standard orbital flight will almost always show about 138Gs. One was well over 1,000Gs.  That alone to me indicates that there’s some seriously buggy physics math in the game someplace and probably also helps explain why ships fall apart, and phantom rotational forces causing ships to spin uncontrollably, etc. Assuming that data is valid, of course.

Recording all that data in high fidelity tick-by-tick might be very useful for a development/debugging perspective but it will completely overwhelm local storage in all but the simplest save file.

[Monger]

edit: double post. Sorry. 

Edited March 5, 2023 by Monger

[schlosrat]

1 hour ago, Vl3d said:

The big save file size bug is an indication that the methods of the recording system get called very frequently. What you see in the save file and in the Flight Report is a massively filtered and truncated version of that.
The purpose of this tread is not managing expectations, but discussing what gameplay features this recording system (which IMO is one of the foundations of KSP2 gameplay) enables for the future.

Thanks @Vl3d for collecting all the reports in one place! It's good to know this is being seen by more people and not just some weird thing in my game.

I would agree it's probably a bug, but I believe @MarcAbaddon has it dead on. I think this is unlikely to be used in most of the ways you've imagined it. The list of info in the structure wouldn't support most of those uses, and the structure itself would be a pretty poor way to try to implement some of those things. Maybe the resource delivery to colonies part (that would lend itself to events like they're recording), but not multiplayer or other things where physics will matter much more. It may be a clue, but it's also probably a bug currently. I'm frankly more interested in them fixing that than us figuring out what it's eventually going to be - though I am curious about that too.

Edited March 5, 2023 by schlosrat

[Monger]

Dear Devs, 

if you read this: json is an excellent format, but please consider zipping it. Zip Streams are blisteringly fast, take little CPU time, and save a lot on I/O access time.

[darthgently]

7 minutes ago, Monger said:

Dear Devs, 

if you read this: json is an excellent format, but please consider zipping it. Zip Streams are blisteringly fast, take little CPU time, and save a lot on I/O access time.

This would be so easy.  Even have a check box in the debug screen to turn it on and off on the fly with no restart for debugging purposes

[Periple]

2 hours ago, Vl3d said:

which IMO is one of the foundations of KSP2 gameplay

That's a really big stretch! I think most likely you're engaging in big wishful thinking here.

The feature set you have in mind can't be supported by a flat file savegame like here. You would need a database that continuously records your game, and even so it would be spectacularly hard to keep coherent. I don't see any sign of anything like that in the game, and even if it was, the data wouldn't show up in the savegame like this. 

It's great to be enthusiastic about the game and have ideas about what it could be like, but imagining that it's definitely going to be some way because you'd really like it to be that way is not so great. You're likely to be disappointed and if you get other people hyped up they'll be disappointed too.

[darthgently]

KSP1 has a travel log in the savefile for each command pod with a similar structure.  Not willing to prognosticate on any of this

[WingC3]

But something is triggering this misbehaviour. Ever since I sanitised my file of the 3 objects that were constantly repeating, I have played for hours without issue. I've constructed and reverted craft, flown to other planets. The save file has grown by a couple MB, but not the hundreds of MB it was doing after just a little bit of play early on.