MarkusA380

Yeah, pretty much!

Not really, if I understand you correctly. For maneuvers to be executed the vessel must be loaded and simulated. It cannot happen in the background. As such, it makes no sense for this mod to only warp to the next maneuver - it will not be executed regardless. There is a theoretical possibility for an essentially different mod, that will only run when you are in flight, not in the space center or tracking station scene, and that would warp only until the next maneuver, wait until it has been executed (by MechJeb or manually or whatever) then continue the warp. But that's not the point of this mod, as it would not enforce the sync to realtime and give you free reign to do whatever you want while you are at a maneuver node in the "past".

New update! Changes: Auto warp when catching up with real time is much faster! The time format is now overridden to use real timestamps, e.g. 2024-07-27 23:29:00+02:00 You can choose between local and UTC time Time intervals use 24 hour days and 365 day years Mod will not unpause the game after 10 seconds to catch up with real time Add toolbar icon Warp forwards even when window is open Reset to default day and year length when no base time is selected

Exactly. This mod was born because I had a LMP server without timewarp running for a while and found the implications quite exciting, e.g. planning a Munar transfer in such a way that it would reach PE on the moon at a time I was available, then setting an alarm on my phone 30m prior to the burn time. It felt more... real, in a sense. Unfortunately, LMP does not simulate the orbits in the background, meaning changes of SOI simply do not occur if the vessel is not being controlled, and orbits shift all the time.

This mod does not change the length of Kerbin days. In the stock system, 4 days will pass for each real day. The mod just synchronizes the passage of time. If you shut down the game and come back 24 hours later, it will warp forward 24 hours. The game itself has a setting to display time in 24hour format instead of 6 hour format. This way, if a maneuver node is in 1 day, 1 hour, you will be able to plan ahead that you should return to the game on the next day, 1 hour later. But it's not required for this mod to work.

I created this mod exactly.

Realtime This plugin syncs the in game time to realtime. It's for those kinds of players. Yeah, you know which kind. How does it work? By default, the plugin will not do anything, except show a warning message when a scene loads at the top of the screen. In the Space Center, open the Realtime configuration window from the toolbar. There, you can select a "base time" - a point in real time which will be equivalent to the beginning of time in the current save. Once you hit "Set", the game's timewarp will be controlled by the mod alone, you will be fixed at warp factor 1x in all scenes. If the game time (offset by the base time) is behind realtime, the mod will automatically warp forward until it's in sync again, but only while the game is warping on rails (e.g. not during driving, atmospheric flight or burns). The game's times will also be displayed based on the real time, and durations will be based on 24h days and 365d years. The mod will only warp if the game lags behind by more than 10 seconds, to avoid constant micro-warps when the game is running slow. A warning will be shown and the mod will relinquish control of timewarp if the game time is ahead of real time by more than 10 seconds. SEIZURE WARNING: The automatic warping can, depending on the time difference, cause quick continuous flashing as days pass in the Space Center. I am planning to add a setting to limit the maximum warp factor to avoid this. Incompatible Mods: Kronometer Compatible Mods: Mods that do not modify timewarp or the time format should be compatible. Visual mods, part mods and system replacement / scaling should work just fine. Download SpaceDock

Thank you @HebaruSan!

I'm currently working on a small project which requires me to save and load some configuration on a per-save basis. I am however unable to find any examples or documentation on how to do this properly. I see some examples of people creating their own configuration file and storing per-save states there side by side, but I imagine the right way is to store the configuration right in the `persistent.sfs` config tree. Any advice is appreciated.

Goodbye.