Does anyone know why references to SaveGame Classes only survive one series of pins? Is it because we’re dealing with a .sav file written on disk?
It’s impossible to save the reference in a variable and reuse it in another function, branch, or sequence, even in the same graph. It’s like the GC collects the reference after the last pin.
Using Game Instances doesn’t help either. I must use a unique Load+Cast combo every single time I need to retrieve or save data to any .sav file. Sync or Async doesn’t matter.
Thank you for the reply.
I’m just gonna assume it’s Unreal’s design and the safer option to call Load + Cast every single time data needs to be written or retrieved from the .sav file. Even if the project ends up with 100+ Load and Cast nodes.
Because I’ve been on an endless back n’ forth with a lot of people and I can’t get them to believe the SaveGame class and .sav files have special behavior.
They think I don’t know how to store and save a variable or use game instances without even trying to replicate the behavior I’m showing.
Another question, instead of .sav files and SaveGame class. What other options are there to store sensitive player data like quest progression, unlocked items and unlocked levels? Some people are telling me to use .ini files. Couldn’t they be easily modified by curious players?
I believe this behavior is by design. A Save Game object is only meant to exist temporarily — you create or load it, copy the relevant data, then save or discard it. The engine doesn’t keep the object alive after that; once it’s no longer referenced, garbage collection will clean it up, which is why you end up with a null value.
I would stick to .sav file. At the end of the day if someone really want to modify stuff, you can’t really stop them. Might as well use the system designed just for that. I believe this is where some form of obfuscation + sanity checks (check for outrageous values like 100M Life) would come to play too.
Thank you so much. At least now I’m sure there’s either something wrong with my project or my UE5.6 version, because I did exactly what you did. It’s not rocket science to store a ref in a var, Epic themselves released tutorials where they store SaveGame in vars to reuse later.
My BP graphs will be a little cluttered yes, but this is not a project-killing issue.
Thank you. I’m just gonna move forward for now. I was a little worried with how cluttered my graphs are looking with so many load and cast nodes, but at least now I’m sure it’s not a bad design or mistake on my part.
I’d actually advise against using a variable, even if you can get it working, because once things get complicated, you’ll have lots of thing reading and writing, and unless you keep the variable somewhere central ( like the game instance ), it won’t work.
And ( ) even if you get it working with a variable in the GI, a crash will mean the player loses everything they have changed after the last time you wrote the SG back to file. So it’s better to just update it right away.
I don’t believe SaveGame object’s life time is design only during save/load/read/write. You can have SaveGame objects at run time and keep them alive for Achievements/Progression. Accessing the class’s variable like it’s an UOjbect should be no problem. I load and save SaveGame in gameInstance and get reference from it.
Can I suggest post to open a new project and test out SaveGame reference there stays? Just to see if it’s a project issue or PC/Engine issue.
)
