I know the solution to this problem, but I don’t know how to stop the constant issues. This game engine has nice graphics, but it’s full of bugs. Unity is better than this.(I am not a Unity advertiser)
I’d also like to share my personal view: overall, the categorization of classes and components is very poor, making it take far too long to find something simple. In Blueprints, the node descriptions are often unclear, and being forced to use Visual Studio to write C++ classes is not an ideal solution.
And there are nonsensical constraints in the Blueprint system. I’m creating a delay system that shouldn’t be affected by time dilation for a legitimate reason, placing it inside a Macro Library, and because Macro Libraries can’t hold variables, I’m forced to put it in the Game Instance—when it makes no sense at all. Now, let’s instantiate the macrolibrary variables when the game starts, something like that. It would make more sense, I think. And it doesn’t make sense why we can’t call a macro in the game instance from outside the game instance.
For just an example, not being able to create a true “in-scope” local variable in a Blueprint (I’m not talking about function local variables), or the inability to use a delay inside a function. Or just not being able to get the game’s time dilation unaffected delta time, this is the meaning of “delta time”, it gives us the time elapsed between frames of the game, there is basically no point in it being affected by time dilation. However, purely Blueprint-related organizational constraints can disrupt the workflow. This is just one example; many similar things like that exist.
For example, why isn’t there some kind of “trigger” system in the animation blueprint? Was it so difficult to integrate this into the game engine? It’s a constant “activate the boolean, then immediately disable it again”
For example, let me write something more complex: why can’t the transform modify bone function move the bone independently of the current animation’s bone movement, but instead adds it on top of it? Then you have to create a rig, and things get even more complicated.
Such restrictions make it difficult to properly categorize or structure things. You can work around these by coding is nice thing, but doing so in C++ isn’t nice.
These problems may seem trivial, but a hundred things like this can turn a game that should take one month into three months, or a game that should take one year into three years.
(right click in a macro and type local to get all of the variants)
You can also access the current time dilation and use it to offset values if you need them to update a variable at “normal speed”, you also have access to world deltatime as well as time passed since the game started (both can be used to execute logic)
As for macro libraries not holding global variables, you could easily inherit your own subsystem to hold these values and split them off from the game instance to not pollute the class with unneeded data.
If you need persistence for that then either save data in a savegame or go the route of writing out the information to flat json file that can be written and read as needed.
As for your crash, you blurred out the information that caused it. Most people who are getting to know unreal usually have problems with null pointer exceptions trying to access variables that have either been destroyed or that were garbage collected (if a property is not marked as a UPROPERTY it will be collected)
