Conversation
i'm not fully convinced that occasion is rare. with the existing system, if a player has autosave set to "New Location + Any Item" - there is zero fear of losing anything when hitting ctrl+r at any time. the benefit i get from autosave is from that peace of mind - never needing to ask myself "did i save?" when soft resetting the other benefit is not worrying that you've lost progress when closing the application, which i think an interval based system is perfectly good for i don't love the idea of recommending adding another ui element, but an "autosave on soft reset" checkbox next to the interval slider would definitely provide that peace of mind for me |
|
I actually really like the autosave on soft reset idea. I could never figure out how to provide the same kind of experience as the other options before did, but this feels like a very easy way to catch all of those scenarios in one. I'll look into getting a hook going on soft reset and add it to that. |
|
Thinking more on it, is there a scenario where someone wants to enable autosave and also not just be certain there game is always saved on sensible times? What if we just have a checkbox for autosave with a default interval of something like 3 minutes, and also always save on soft reset (with the tooltip reflecting both)? |
that sounds like a good plan to me! i'd like to hear what others think about the default interval and not being able to change it, but overall the "always autosave on soft reset when autosave is enabled" seems like the move |
|
I agree with just having the soft reset behavior tied to auto save as a whole. The only counter to all that is save-scumming, and in my opinion anyone relying on save-scumming should not be using auto save anyways. |
|
Yeah that was basically my thought process too. |
Pepe20129
left a comment
There was a problem hiding this comment.
Small things, nothing blocking.
|
Autosave now revamped to operate on a 3 minute interval and on soft reset. I've tried to keep the checks for autosaving as lenient as possible because we don't want players to expect autosaves on soft resets and them not coming through. I can't say with 100% certainty this catches every edge case where the save can fire off, but honestly I think that's a better fit to be tested when it's merged. |
| areasFullyChecked[area] = areaChecksGotten[area] == checksByArea.find(area)->second.size(); | ||
| if (checksByArea.contains(area)) { | ||
| areasFullyChecked[area] = areaChecksGotten[area] == checksByArea.find(area)->second.size(); | ||
| } |
There was a problem hiding this comment.
This was changed because it was referencing data that no longer existed. According to Malk this may have been the cause for a remaining save corruption glitch (occuring most frequently on console), but I was running into it 100% of the time with the soft reset saving.
briaguya0
left a comment
There was a problem hiding this comment.
one non blocking comment because something piqued my curiosity, but let's 
Part of an ongoing effort to reduce code and UX bloat. For more information about my reasoning, please see #5013
This re-implements the autosave to be purely interval based like I've done for 2ship in the past. It also now uses the notification system instead of the older LUS provided one (and updated triforce hunt saving to do the same).
I know there was some feedback when this was brought up a while ago that saving on major items would still be something people want, but honestly I don't think it's worth the added complexity over asking a player to manually save on that rare occasion this would be useful for.
Build Artifacts