I’m frequently using Blueprint Interface to communicate between actors.
One problem occurs very frequently, and I’m still not satisfied with the solutions I found to solve it.
These problems happen mostly when something is called during the begin play. On the example below, I refresh the UI to ensure the level is correctly shown (SetLevelProgress). However, I get the following error: “Blueprint Runtime Error: “Accessed None trying to read property LevelProgressMI”. Blueprint: Level_UI Function: Execute Ubergraph Level UI Graph: EventGraph Node: Set Scalar Parameter Value”
The “LevelProgressMI” is inside the construct event. I also tried “Pre-construct”, but didn’t help.
The only way I managed to solve it is to add a delay before the begin play event. However, I feel like this is a patch and there is a better way to do it. The delay works at 10ms, but not at 5ms.
Using “Is Valid” doesn’t work, as the Widget reference is inside the character blueprint it’s running, thus is valid. Hoever, the material instance from the UMG interface is not yet created / loaded.
The only ‘neat’ solution I’ve found for these timing problems is basically a delay loop. So, you would check the MI for validity, if not valid wait .1, then try again.
You can make it seem slightly more elegant using a ‘while delay’ macro, which is basically the same thing hidden in a macro:
The only way to get around the issue cleanly would be to make the call with an event dispatcher, but then that’s not always appropriate.
PS: I do recall sometimes trying to do this with a dispatcher, only to discover the triggered blueprint isn’t ready to service the call. So sometimes, delay is all you have…
I had thought of that. But if the delay is .1, it wont be a problem if you only have a few. Also, if it never comes out of the loop, you probably have other problems anyway…
Thanks for your reply and for your suggestion! I’ll probable keep my delay as you suggested.
I think the while loop can be at risk, if something is not loading et all for a reason, a max counter could be a great addition to avoid any infinite loop.
I totally agree ' This solution will do until we find an alternative!
100ms is quite little indeed, and found that 10ms was needed in that case.