That would be perfectly fine. If you send me the link either here or in a private message on the forums I will be happy to take a look and let you know what I find.
If you go to the forums and look for my name it will appear as it does here. Send a private message with the link to that account and I’ll be able to check into this for you.
I was able to reproduce this on my end and have confirmed that it does seem limited to save/load data with text boxes in UMG. I attempted this with a simple text alteration without load/save and the text box updated correctly. I’ve entered a bug report, UE-23839, to be assessed by the development staff.
It appears to be something sketchy the save system is doing that must bypass the standard FText set process and is coming through as the same text even though it’s really different, confusing the FText system into thinking the text hasn’t really changed.
You can work around it by either saving a string (which you might actually want to save instead, since the user entered data isn’t going to be localized by some external entity. Or you can convert the text to a string first, and then convert back to text, that appears to fix the confusion post load.
How did the value of “12-0002” originally get saved into that save file, and have you manually edited the save file at all?
The issue we’re seeing is that two pieces of text, “12-0002” and “12-0003”, have both received the same key for the localisation system. This means that when “12-0003” is used, it overwrites the “12-0002” value in the localisation system with “12-0003”, and the UI doesn’t think anything has changed as both the snapshot and the new text point to the same source string, which now reads as “12-0003”.
I can confirm that changing the key in the save file fixes the issue of the text not updating, so I’m really curious to know how that came about. If we’re handing out the same key to different texts then something is really wrong
Delay 0.05 (a delay of 0.01 doesn’t seem to do the trick)
StudentID = ID (from save game data)
this seems to work, too
Btw, i will try this on a network-based project. I want my players (students) to see updated data real-time, that’s why i need the data to be changed and seen real-time.
Right now i’m working on my prototype. so let me know what and where you want me to look at.
How did the value of “12-0002” originally get saved to that save file (eg, was the value “12-0003” that I can see in the BP originally “12-0002”), and have you manually edited the save file at all?
I ask as I can’t find “12-0002” anywhere in the BP, and once the value has been saved as “12-0003”, it’s always re-saved as “12-0003” for every re-run of the BP. This leads me to think that either the BP has been changed since the initial save file (the one included with the project you sent to ) was created, or that the initial save file was edited to hold a different value than the one the BP saves.
→ “12-0002” was the first value that I tested, this is when the Save Data doesn’t contain anything yet.
→ “12-0002” was save through the BP by pressing [ Enter ] (for the meantime).
→ In the Save Data (last pic), I am changing the value that will be saved in the Save Data manually through the [ Set Array Element ] and this is “12-0003”
→ The project I sent was the latest test (that time) that’s why you see the updated value of “12-0003” instead, if you’re testing it, just change the value in the Item of the [ Set Array Elem ] to anything you want.
I’ve found the cause of this, and it will be fixed in the next 4.11 preview.
The keys used for text pins were deterministic (based on the GUID of the node, and the pin name), which meant that even if you changed the text, you’d still be using the same key; that lead to the key conflicts you were seeing here.
It won’t magically fix anything that’s already broken, but once you change the text on the pin you’ll be assigned a new, unique, key.
