Hi - I don’t know exactly what information to provide so maybe someone can help me get started from some basic information. Whether this is a bug with the engine or the result of my poor programming skills, I don’t know for sure.
Our game is out on steam and is a Blueprint only project.
It relies heavily on the level blueprint in every level.
The basic structure is that Blueprint actors are placed in the levels performing generic tasks like “teleport the player to x location” and calling an event dispatcher like “Player TP”.
The level blueprint would respond to the event dispatcher and execute additional logic specific to the unique instance of the BP.
As our game is beginning to have some players, there have been a few cases come up where these events on the level blueprint will fail to trigger. In these cases, the event dispatchers are ALWAYS called on their blueprint successfully, but the bound events on the level blueprint are sometimes failing to execute at all.
In one level, the bound event began to fail every single time. This was resolved by duplicating the actor that called the dispatcher and replacing the original with the duplicate. Note that trying to delete the dispatched event on the level blueprint crashed the editor until the actor was deleted entirely from the level.
In another level, there is a boss fight that passed several events and data back and forth between a BP_BossChamber and the level blueprint. This one would fail to execute the final event on the level blueprint about 1 out of 5 times. It was resolved by moving all of the logic off of the level blueprint and on to the BP_BossChamber.
Currently we have a case of this that is so rare we aren’t able to reproduce it effectively, but common enough that we have seen it happen to a streamer playing the game. The Blueprint teleports the player to the other side of the level and calls an event dispatcher that the level blueprint is waiting for. Again, the dispatcher is called but the event sometimes does not go off.
this could be a curveball. There is a save point several minutes before reaching the #3 teleporter. This save point is nothing more than a generic Trigger Box. On the level blueprint, On Actor Begin Overlap, it executes a macro used for all saves in the game. It has failed in the same way exactly 1 time that we know of. (To us, testing a build just before release) - that is also the only time that we have created the result described in #3 ourselves.
The only other thing I can think to mention is that on level blueprints, there are two ways to set up an event binding:
One is the normal way, where you manually bind the event and pull the Red delegate wire to create a custom event.
The other, unique to level blueprints AFAIK, is by selecting the actor in the level and then right clicking in the level blueprint to select that dispatcher as an event, producing a node that looks like “on actor begin overlap” for example, which does not need to be manually bound to custom event.
We use both types quite a lot and have seen both types fail so maybe there is no point here…
Check if all casts are valid. I had similar problems, because of loading order. Things load differently in standalone game than in editor one. Sometimes actors load bit slower (or faster), and not all references are ready yet. Some time ago everybody was adding that 2 sec delays for this problem.
Also if your level is streamed, when it unloads actor and reloads it, actors are reset to default state. Not sure if binding to events/dispatchers survives it or not. I never use level blueprints.
this type of event binding is not bound manually. When we need a temporary binding we will make it on the fly when it’s needed. So very few bindings are happening on begin play, and none of the problems have arisen from that.
similarly, there’s often no additional casting taking place. Just a BP calling an event dispatcher and the level BP listening for it.
Two of the reasons we used the level blueprints so much during development.
“Also if your level is streamed,…” this is a lead I’ll have to look in to. Only 1 level is loaded at a time and some of them relatively large for a retro game. My best guess that something is happening with actors being culled or unloaded automatically for various reasons, but everything to do with any of this is well above my surface level understanding.
You can always make “middle men” like in game instance or game mode. Put all middle men events there, make actors call it there, then communicate with level blueprint from that place. I know it is basically redesigning whole game logic. And use game play tags to identify who/what calls event, they are great more advanced enumerators.
ps.
About level streaming, it simply resets all streamed in actors to default state. So if some box was opened and looted by player, it will be reset after streaming out/in. Then I need to design system for save and load that actor, make references to other objects like game mode, whole mess with coding, because it is streamed level, need to watch who references/keeps that chest object, etc.
At this point I’ve pretty much concluded that I’ll just resort to case by case workarounds - I don’t have any solid leads on what’s causing the issue and even if I did it could be over my head to directly fix it.
What all cases have had in common is that it was logic that lived on the level blueprint and all cases so far have been fixed by moving the logic elsewhere, except the first case I described where I just duplicated the actor and deleted the original.
-It seems like there could be a connection to play time since loading the level
-it seems like there could be a connection to “teleporting” (and in one case launching) the player a far distance without reloading, since this is a common gameplay mechanic in the levels where the problem has come up.
I feel suspicious that If I new what system caused the problem I could be a bool away from fixing it, but in the meantime I’m justing whittling a few things off of the level BPs and forcing a reload in 1 key area - where the player teleports back to the beginning of the map but certain things have changed - crucial that those changes happen!
This is a post mortem in case anyone runs into this issue but unless I’m missing something, this could be an engine bug…?
