KSP2 should quicksave upon receiving some POSIX signal

[darthgently]

This is probably not most accessible idea, but hear me out. Sometimes a physics-based game's UI locks up for severely lags because the UI plays second fiddle to most everything else. 

Under high part count low memory, game bug, or mod issue situations, it would be nice to be able to send the game process a signal, like HUP, or USR1, that would attempt a quicksave and given it is a signal it would have the necessary priority to get it done. 

User friendly standalone utilities could be based on such a mechanism, or more savvy players could just send the signal from the OS command line

Edited December 24, 2022 by darthgently

[Drakenred65]

So when the game is having issues processing stuff, you want another script running (using more processing power) co constantly analise your systems current processing  to issue a quick save, doing which ,again , uses processing power to do?

 

Ok, moving on. . . . .

[t_v]

Is this to stop from losing progress during a game crash? I don’t know enough about performance to say whether this system would worsen the problem it is trying to solve, but it might be good to not save during a crash, in order to avoid potentially carrying the issue over upon re-launch (if the crash is based on something that gets put into the save file, like craft positions or states)

[intelliCom]

I feel like you're just describing an overcomplicated autosave. It would take far less processing to just have it perform autosaves regularly, by an interval of the player's choice. (E.g., between 5 and 30 minutes)
Also, stockpiling a number of autosaves instead of just having one would be great, so you can fall back on an earlier one in case the latest autosave is inconvenient.

Edit: Misunderstood OP. What I think it's supposed to be is a way of doing a manual save in the case that performance is completely awful. Then again, such a situation is rare, so I don't know how important such a saving system would be.

Edited January 5, 2023 by intelliCom

[Ashandalar]

A few people here don't seem to know how signals work in modern operating systems and CPUs, which I don't blame them for, but they really should understand what OP's suggestion actually means if they're going to engage with it.

The suggestion doesn't require Intercept to manually fork a new thread that constantly polls for a specific signal, taking up CPU cycles. Signal-handling functionality is implemented by interrupts at the operating system level, and signal-handling code will already be present in the KSP2 executable (for example, it's how programs react to you pressing Alt+F4, or Ctrl+C in a terminal). OP is suggesting they add a quicksave call to the signal-handler for a particular signal. This additional code is only executed when that specific signal is caught and adds no overhead at all (aside from a trivial increase in executable size) when the process is running normally. Because the signal-handler is run as an interrupt, it can progress even if the main process is completely locked-up for whatever reason.

Edited December 25, 2022 by Ashandalar

[intelliCom]

5 hours ago, Ashandalar said:

A few people here don't seem to know how signals work in modern operating systems and CPUs, which I don't blame them for, but they really should understand what OP's suggestion actually means if they're going to engage with it.

The suggestion doesn't require Intercept to manually fork a new thread that constantly polls for a specific signal, taking up CPU cycles. Signal-handling functionality is implemented by interrupts at the operating system level, and signal-handling code will already be present in the KSP2 executable (for example, it's how programs react to you pressing Alt+F4, or Ctrl+C in a terminal). OP is suggesting they add a quicksave call to the signal-handler for a particular signal. This additional code is only executed when that specific signal is caught and adds no overhead at all (aside from a trivial increase in executable size) when the process is running normally. Because the signal-handler is run as an interrupt, it can progress even if the main process is completely locked-up for whatever reason.

I accept that my technical knowledge is lacking.

But it is still far easier to implement and debug code for regular autosaving instead of condition-specific autosaving.

Edited December 25, 2022 by intelliCom

[linuxgurugamer]

1 hour ago, intelliCom said:

I accept that my technical knowledge is lacking.

But it is still far easier to implement and debug code for regular autosaving instead of condition-specific autosaving.

Given that I have written two different mods that do various types of automating,  and support another as well, I think I can comment on this.

Believe it or not, doing regular autosaves can be more problematic than condition specific.  The devil is in the details.  

Once you have _any_ autosave code written, the rest is easy.  Conditional or timed, doesn't really matter.  Only thing about timed saves is if you keep multiple saves, you then have to implement a cleanup routine

[intelliCom]

3 minutes ago, linuxgurugamer said:

Only thing about timed saves is if you keep multiple saves, you then have to implement a cleanup routine

Cleanup routine could be as simple as deleting the oldest save so only the three latest saves are present. Doesn't seem so hard at a glance, but feel free to explain.

Also, 'conditional' means checking various statistics in the computer's performance to decide whether to autosave or not. Again, seems more complex than a timed autosave.

[Ashandalar]

40 minutes ago, intelliCom said:

Also, 'conditional' means checking various statistics in the computer's performance to decide whether to autosave or not. Again, seems more complex than a timed autosave.

No one is suggesting "checking various statistics in the computer's performance" to automatically detect when to save. The suggestion is that the program responds to a signal by saving the game.

Ever played a game which saves your progress (up to the last moment) when you exit with Alt+F4 without you explicitly pressing any "save" button? That's the game process responding to the SIGINT signal by first saving, then exiting.

Edited December 25, 2022 by Ashandalar

[linuxgurugamer]

1 hour ago, intelliCom said:

Cleanup routine could be as simple as deleting the oldest save so only the three latest saves are present. Doesn't seem so hard at a glance, but feel free to explain.

Also, 'conditional' means checking various statistics in the computer's performance to decide whether to autosave or not. Again, seems more complex than a timed autosave.

Easy to say just the last three.  What if someone wants more?  I can think of many options which can be done, writing the code, while not complex, still needs to  be as bulletproof as possible.

And your idea of "conditional" is actually the strangest I've ever heard.

[darthgently]

9 hours ago, Ashandalar said:

A few people here don't seem to know how signals work in modern operating systems and CPUs, which I don't blame them for, but they really should understand what OP's suggestion actually means if they're going to engage with it.

Bingo.

This post is actually something I hope the actual game devs see as they will know what I'm getting at.   Someone who doesn't know what I'm getting at isn't going to provide very useful feedback.

Clarifying for multiple replies:

1) Interrupts operate at very high priority and if one wants to save then the cycles for saving aren't "wasted" are they?

2) By far, most of the time the game is lagging, it isn't crashing, just running from swap or something.  But it might crash if memory is leaking or something else so I'd like to save before it does, or just want to start with fresh mem from that point. 

Very often, restarting and reloading the game from that save file removes the lag as everything is fresh.  Currently getting the attention of the GUI under these conditions can be a pain.  A signal based approached bypasses that

 

On 12/24/2022 at 11:44 AM, [email protected] said:

So when the game is having issues processing stuff, you want another script running (using more processing power) co constantly analise your systems current processing  to issue a quick save, doing which ,again , uses processing power to do?

 

Ok, moving on. . . . .

Ok, have a good move along...

[linuxgurugamer]

On 12/24/2022 at 11:15 AM, darthgently said:

This is probably not most accessible idea, but hear me out. Sometimes a physics-based game's UI locks up for severely lags because the UI plays second fiddle to most everything else. 

Under high part count low memory, game bug, or mod issue situations, it would be nice to be able to send the game process a signal, like HUP, or USR1, that would attempt a quicksave and given it is a signal it would have the necessary priority to get it done. 

User friendly standalone utilities could be based on such a mechanism, or more savvy players could just send the signal from the OS command line

Would certainly be an idea for a mod, if  and when the game is released

[intelliCom]

2 hours ago, linuxgurugamer said:

Easy to say just the last three.  What if someone wants more?  I can think of many options which can be done, writing the code, while not complex, still needs to  be as bulletproof as possible.

And your idea of "conditional" is actually the strangest I've ever heard.

OK, I'm apparently talking too much stupid stuff here, and probably won't learn anything by trying to discuss it further. I'll just accept that this proposed system works somehow and move on. Sorry if I made a mess of the conversation by not knowing how computers work.

EDIT: Re-reading what OP said, I'm interpreting it as just quicksaving but more nerdy? Again, sorry for not having the technical know-how here, but I fail to see the benefit of a quicksave with extra steps.
Is it like attempting a quicksave if performance is really bad?

Edited December 26, 2022 by intelliCom

[Drakenred65]

4 hours ago, darthgently said:

Bingo.

This post is actually something I hope the actual game devs see as they will know what I'm getting at.   Someone who doesn't know what I'm getting at isn't going to provide very useful feedback.

Clarifying for multiple replies:

1) Interrupts operate at very high priority and if one wants to save then the cycles for saving aren't "wasted" are they?

2) By far, most of the time the game is lagging, it isn't crashing, just running from swap or something.  But it might crash if memory is leaking or something else so I'd like to save before it does, or just want to start with fresh mem from that point. 

Very often, restarting and reloading the game from that save file removes the lag as everything is fresh.  Currently getting the attention of the GUI under these conditions can be a pain.  A signal based approached bypasses that

 

Ok, have a good move along...

Basically the only real problem I have left (the other was explained)with this is your trying to save a game pre crash. The problem to me is your basicaly trying to create a auto save, right before a crash or freeze, which is kind of like auto saves in some games that unfortunately kick in just before you die in game creating a infinite loop of Die-reloaddie-reloaddie-reloaddie, because your hoping that somehow your save will not have whatever caused  the slowdown, because I don’t think there is a practical way to predict incoming lag.

[darthgently]

2 hours ago, [email protected] said:

Basically the only real problem I have left (the other was explained)with this is your trying to save a game pre crash. The problem to me is your basicaly trying to create a auto save, right before a crash or freeze, which is kind of like auto saves in some games that unfortunately kick in just before you die in game creating a infinite loop of Die-reloaddie-reloaddie-reloaddie, because your hoping that somehow your save will not have whatever caused  the slowdown, because I don’t think there is a practical way to predict incoming lag.

No, as I wrote, it is just running slow, usually because of memory constraints and swapping activity.  Maybe under Windows mere swapping would cause a crash, but under linux it is just 1000x slower.

But more to the point, I have saved via GUI under these conditions many times, exited the game, restarted with the save, and no lag.   I've never had a corrupted save doing this; only patience is required. Being able to trigger the save via external signal would bypass the tedium of wrestling with the low priority GUI running at 1000x slower.

Is that clearer?  I think I just repeated myself, but I hope that helps.

I've been a software developer for 35 years, I'm not making stuff up to vex you

And no, this is not an auto save.  I never wrote that.  This would be manually sent from the commandline using normal os process signaling commands 

5 hours ago, intelliCom said:

OK, I'm apparently talking too much stupid stuff here, and probably won't learn anything by trying to discuss it further. I'll just accept that this proposed system works somehow and move on. Sorry if I made a mess of the conversation by not knowing how computers work.

EDIT: Re-reading what OP said, I'm interpreting it as just quicksaving but more nerdy? Again, sorry for not having the technical know-how here, but I fail to see the benefit of a quicksave with extra steps.
Is it like attempting a quicksave if performance is really bad?

As I wrote, a signal interrupt is processed at much higher priority than the GUI in game.  If it takes 5 minutes to get the game to pause by hitting escape and entering a filename etc then 15 seconds to trigger a signal is a big savings.  

Even hitting F5 can take a very long time to get processed under high swap lag

[intelliCom]

11 minutes ago, darthgently said:

As I wrote, a signal interrupt is processed at much higher priority than the GUI in game.  If it takes 5 minutes to get the game to pause by hitting escape and entering a filename etc then 15 seconds to trigger a signal is a big savings.  

Even hitting F5 can take a very long time to get processed under high swap lag

So, from what I can tell, this is really only useful for cases of high lag? Is it supposed to be common for quicksaving to take a long time?

[darthgently]

If you are up against RAM limits then yes, it can take awhile.  If you don't encounter this then this would appear to be a solution without a problem to you.  Which is why I took care to specify from the very start that this was for memory swapping conditions mostly; to make that clear

[Skorj]

You can also get into this situation from misbehaving mods, where some mod loses its mind and the GUI becomes non-responsive.  Of course, quicksaving in this situation could easily result in an unrecoverable quicksave, so it would need to be a distinct save file from the normal quicksave. 

[SOXBLOX]

Sounds like a great idea! This has my seal of approval!

[SenatorSteam]

I support this idea