Prefer AsyncSaveGameToSlot of the synchronous SaveGameToSlot #292
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello! I'm working on a title where we essentially banned the use of the synchronous SaveGameToSlot method, in favor of AsyncSaveGameToSlot, which brought me to modify this code in our "fork" (we're in p4) and I decided to have my hand at giving it back.
I get that this save file would be so miniscule that the unease of "causing a hitch" should basically be zero, but I figure, if I understand the code correctly, the save object is synchronously written to memory and any node acting on it will be operating off the in-memory version, while the save object on disk can be written asynchronously as a fire and forget. One thing I'm unsure of is if there's a scenario where a BP author tries to call
UGameplayStatics::LoadGameFromSlot
using the "FlowSave" slot name, independently of FlowGraph, directly after a checkpoint node. 🤔Anyway, at least here for the discussion :)