It’s hard to tell what’s going on…but it looks like youre doing a lot of overwriting of your own save files. I’m not surprised you’re having troubles.
I’m going to walk through what it looks like happens, from what I can tell. You can tell me if these things are not what is SUPPOSED to happen:
After clicking the newgame widget:
In 2-ngs1BP.jpg you CREATE and SAVE a new savefile. That will fill in alignment/class/etc with default values. The only thing that’s set freshly is the name. Even the slot index and saveslotname are defaults, since you reference a freshly created savefile to get those. That means if you manually set those somewhere else well, that’s not going to do you any good…whatever is set by default in the savegame blueprint becomes the slotID/slotname.
In 3-ngs2, you CREATE a new savefile…which brings with it all the defaults for things like Playername (which is…blank? Make it something silly to help you test) . Then, onclick, you set a a “player class” variable on it and SAVE that file to the default SlotName and UserIdx. This will remove the playername AND playeralignment variables you set earlier, since you just saved over them.
In 4-ngs5, you CREATE a new savefile…which brings with it all the defaults for things like Playername and PlayerClass. Then, onclick, you set a a “player alignment variable” on it and SAVE that file to the default SlotName and UserIdx. This will remove the playername AND playerclass variables you set earlier, since you just saved over ithem.
In 6-sandbox.jpg you poll the scene on an event (like hit) to see what the saved variables are. You load from the savegame’s slot and ID.
The way I see it, only one of your three variables will ever be saved at any one time: either the name, the class, OR the alignment. Your process of setting each those variables wipes everything else.
Some good habits for the future:
Don’t store and change stuff in the savefile during gameplay: on load, copy ALL variables values out to matching variables in a “storage blueprint”, or a “manager blueprint”…or heck, even to the Pawn itself. Make your game do any changes to THOSE versions of the variables, and then, when it comes time to save, transfer everything at once back to the savefile and save it. This isn’t really a requirement, but it does usually help keep the workflow clear and prevent situations like yours.
It helps to have only a single function for saving and loading savefiles. That could be in the game mode, it could be in the pawn, or it could be in a special save-game mananger blueprint.
Give the default values of your savegame helpful values so you can tell if it’s loading or using defaults immediately
And finally, as it is right now you use some default values (as in, you made them the default value within their variable settings in the blueprint, not like “engine default”) as the slotname and Index. This might work fine if there’s only ever a single savefile, but it’s going to be a no-go if you ever want to have multiple savefiles. If you isolate all your saving and loading stuff each in a single function then it’s pretty easy to pull from a list or an array of slotnames and IDs, depending on which “savefile” the player wants to load/save.
Goodluck!