As you say, I like it and I don’t like it.
I really like to pass a current “context” to the object of where I am? Yeah.
Is it really necessary? Yeah.
Will it work well if I use callbacks in the future? Don’t know.
Will it work for any context? Don’t know.
Will I have context conflicts in the future? Don’t know.
Furthermore, the problem is not the class itself. The problem is the “Async Load Asset” (ALA) node/method, it does not have a context pin to overwrite it, even if the class that inherits from UObject passes it a context and it overwrites the “context” of the UObject itself, the node “ ALA” itself does not have or is not available to change the context. “ALA” needs a pin to establish context. I hope they put it up one day.
Now, as I said, if you have to do the “ALA” manually, you have to use TFuture and we’re getting into bigger words. That is, if it predicts wrong for some reason unknown to me, I will have headaches.
For now the Game Instance fulfills its purpose without problems.
It is a shame since you could have objects full of data (which is what they are for) and use them at a specific moment anywhere.
But as I said I have found two solutions:
- Blueprint Object (Inheriting from a C++ Object)
Put the async part from now on inside the Actor, Component, Controller, level… or others in the place where the object is called. - Directly put it in the GameInstance
There may be more solutions, but I have no problem with those two for now.