More transparent autosaving

Post your ideas and suggestions how to improve the game.
Post Reply
DigitalShadow
Burner Inserter
Burner Inserter
Posts: 13
Joined: Fri Feb 10, 2017 12:58 am
Contact:

More transparent autosaving

Post by DigitalShadow » Wed May 17, 2017 8:51 pm

I have noticed that while the game auto saves, there is a momentary dropout of responsiveness. This time gap is just long enough to be a little bit annoying without being outright distracting, usually resulting in just one or two keys or clicks missed. How feasible would it be to have an option to record keyboard inputs and mouse clicks during the autosave routine, and play them back to the game upon completion? This in theory would make it virtually transparent.

Also on this topic, is it possible to include another option to toggle a 5 second warning before an auto-save, to anticipate the dropout?

User avatar
Distelzombie
Filter Inserter
Filter Inserter
Posts: 336
Joined: Tue May 02, 2017 4:27 pm
Contact:

Re: More transparent autosaving

Post by Distelzombie » Wed May 17, 2017 8:59 pm

Youre right. It always annoys me to have to wait for autosave. But I think over time some dev will come up with a better solution to this, similiar to other games where you dont notice anything at all. So im not really pushing it.
Complete 2-Lane system as a Blueprint-Book! The perfect OCD reactor? Testing chained science lab efficiency Please use real prefixes and proper rounding!

BenSeidel
Filter Inserter
Filter Inserter
Posts: 543
Joined: Tue Jun 28, 2016 1:44 am
Contact:

Re: More transparent autosaving

Post by BenSeidel » Wed May 17, 2017 10:44 pm

I don't think that there would be a better solution than the current one. The amount of time & memory it takes to save a file in parallel to the game loop would cause massive performance issues in many peoples systems. As it stands they can currently scan the game's memory, compress it and save it to file in a single(ish) pass. If the game were to continue to update while this process is going on they would need to have lock memory, copy memory and generally just do far more work.

I'm with Rseding on this one... The amount of code complexity that would come from multithreading this aspect of the game would cause more bugs, less performance overall and all for the end user not to see a relatively minor pause while the file is saved to disk.

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 10467
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: More transparent autosaving

Post by ssilk » Thu May 18, 2017 7:12 am

Yes, agreed, autosave is too highlighted. Added to viewtopic.php?f=80&t=22760 Support for Color Blinds / Better Visibility ...
No, that's a joke. :)

Added to viewtopic.php?f=80&t=21367 Game Save File ans -Speed Related Suggestions
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

DigitalShadow
Burner Inserter
Burner Inserter
Posts: 13
Joined: Fri Feb 10, 2017 12:58 am
Contact:

Re: More transparent autosaving

Post by DigitalShadow » Fri May 19, 2017 6:21 pm

BenSeidel wrote:I don't think that there would be a better solution than the current one. The amount of time & memory it takes to save a file in parallel to the game loop would cause massive performance issues in many peoples systems. As it stands they can currently scan the game's memory, compress it and save it to file in a single(ish) pass. If the game were to continue to update while this process is going on they would need to have lock memory, copy memory and generally just do far more work.

I'm with Rseding on this one... The amount of code complexity that would come from multithreading this aspect of the game would cause more bugs, less performance overall and all for the end user not to see a relatively minor pause while the file is saved to disk.
What I was proposing was not multi-threading the game engine; That would obviously be far too much workload. What I was proposing was a simple piece of code that would sequentially record input events, but not do anything with them until after the auto save was done, then play them back to the game engine immediately after auto-saving. This should hardly take any resources to perform, and shouldn't have any noticeable effects on performance

There would still be the pause, but the presence of the pause was never my issue. Since the pause usually lasts less than a single second on my computer, my only real issue is that it tends to interrupt my routine and cause me to miss a single key press or click, usually ending up in a misplaced object that has to be removed and re-installed.

BenSeidel
Filter Inserter
Filter Inserter
Posts: 543
Joined: Tue Jun 28, 2016 1:44 am
Contact:

Re: More transparent autosaving

Post by BenSeidel » Sun May 21, 2017 6:25 am

DigitalShadow,
Yep, completely misinterpreted what you were saying. I took "record" and "playback" another way, like it was a suggestion to remove the pause caused by the save.

super_aardvark
Inserter
Inserter
Posts: 28
Joined: Thu Sep 15, 2016 6:27 am
Contact:

Re: More transparent autosaving

Post by super_aardvark » Fri Oct 06, 2017 11:22 pm

I second this motion. Some additional comments:

I think the biggest problem with the current experience isn't that input is ignored, it's that only some input is ignored. For example, mouse clicks are ignored, but mouse movement is not ignored. If the entire viewport were frozen for the duration of the save-game operation, I think it would make for a better user experience. You'd know right away that your inputs aren't doing anything, and you could wait until the operation finished. As it is, I'll just be cruising along in the interface, clicking on things, and then suddenly wonder why the click I made one or two seconds ago didn't do anything.

Of course, queuing the inputs for execution after the savegame operation is done would probably provide an even better experience -- but only if the operation is quick enough. If the player presses Q for pipette tool, notices it didn't work, and tries again, and then the operation finishes and the two 'Q' inputs are processed, nothing is gained -- the first Q selects the item, and the second Q unselects it, and the player is left with no item in hand just like when the key presses were ignored.

Edit: Oh, and text boxes lose focus when auto-saving. Focus should be given back afterwards, with the cursor in the same position as before. This would be a nice addition even if nothing else is done, and I'd think it'd be super easy to do.

Post Reply

Return to “Ideas and Suggestions”

Who is online

Users browsing this forum: mudcrabempire, Wizard Marcos