Hi, I’m using an ‘Enemy_Parent’ class as the parent class for my enemy units. It’s basically derived from the character class. The actual enemy units used in the level are three child classes derived from this ‘Enemy_Parent’ class. All these classes including the parent are using the same third person hero skeletal mesh and animations. I’m spawning waves of the three enemy units and they’re working perfectly fine in the editor.
However yesterday I tried running it in Standalone and noticed that all the enemy characters are invisible. I can see that they’ve spawned, because I’m using a UMG Menu to show their health when my mouse cursor is over them. They take damage and get destroyed, but I can’t actually see any of that short of the UMG Health bar. They’re set to visible and not hidden in game, so that’s definitely not the issue. Besides it was running fine with the same settings in PIE.
After checking on the answerhub for other occurrences of the same issue, I found out that people have been having this same issue since last December, but unfortunately it hasn’t been taken care of. Here’s a link to another post where multiple users have come up with the same bug:
Anyways based on the suggestion given there by one of the users, the problem seems to arise when both your parent and child characters have a mesh. Removing the mesh from the parent character makes the child characters visible in the standalone game. However that results in weird animations/rotations and pathing issues as the characters try to walk towards their goal while floating in the air. So ultimately that’s not exactly a work around as it just kind of shows where the problem is at.
Meanwhile I tried spawning the ‘Enemy_Parent’ character with the mesh included and it’s visible. So that’s working fine in standalone. So just to make sure that this is not some code issue with the child characters that I created, I tried creating a new child of my ‘Enemy_Parent’ class and made no changes at all to it. So it was basically the same as the parent, just happened to be derived. Tried spawning this child replica and it’s invisible in the standalone as well.
Please let me know if you’re able to replicate this at your end. If not I’ll try moving my characters to a new project and see if I can get the same result. I’m done implementing all the functionality for my project and I can deal with other standalone bugs like the enumeration string conversions through some workarounds for now. But this one has got my hands tied and I’m unable to proceed any further.
Created a new child character and removed the mesh from the parent. It’s working fine in the stand alone. However the old characters are still having issues. I found out that their capsule is on the ground, but the mesh is floating even though the values are basically the same. I’ll look more into it.
Upon further inspection, it seems that this sort of weird floating behavior only arises when there is a reference to the child class anywhere in the blueprints. That counts the spawn actor drop down as well. If I remove all these references and place the child character in the level, it behaves normally in standalone.
However if there is some variable that stores a class reference into it, even if I do not choose to spawn from blueprint and instead add in the editor, it exhibits the floating behavior when i run the standalone.
So basically I’m not able to spawn any characters during the game without having atleast any one of them acting like this. All I can do is to remove all references to these child characters and place them in the level.
Here is a screenshot of the floating child character. Only the white colored one is being referenced in blueprints, hence the other child characters are walking normally. You can see that the capsule of the white characters is moving along the floor, but the mesh itself lies on the air facing in some other direction.
I haven’t been able to reproduce this in a new project. But I’ve posted a link to a stripped down version of my project to only the basic AI and player character. Here’s the dropbox link:
If you run it in standalone, you can notice that atleast one of the enemy bots will be having a floating mesh while moving towards the player.
In order to reproduce the invisibility bug, just add a mesh to the enemy_parent class and assign enemy ai anim blueprint. This will make atleast one of the enemy bots invisible in the standalone mode.
I do not understand what I should be seeing. I followed your instructions and added one of each type of enemy ai to be certain that I would be able to see the difference, however all of them spawned in visibly and reacted to the ai anim blueprint the way I expected them to. Are there any other steps I can take to reproduce this on my end?
HI @ , I had tried reproducing the bug in a new project. Unfortunately I haven’t been able to, yet. I’m gonna try implementing the whole enemy AI code in my project once again, to see if this crops up again. Maybe that might help figure out where the issue is.
For the time being, if you check out the ‘Inheritance Bug Test’ project I uploaded in my previous comment, in standalone version, hopefully you should be able to see the floating behavior. It’s a stripped down version of my project, where I’ve removed all the logic except the basic move and jump logic/animations and a very basic version of the AI that I’m using.
After running a few more tests I was able to reproduce this but only with the white enemy_child as you mentioned. If you create a new blueprint based on the enemy parent it does not adversely function as the parent_child does. It looks like this one blueprint became corrupt at some point. If it wouldn’t undo too much work you can delete the actor and simply create a new one with the same functionality and it may work as intended.
I had initially thought that the blueprint was corrupted as well. Actually the white child bot was a blueprint I created after I started encountering the floating issue. As soon as you put a reference to the new child class anywhere in the blueprints, it becomes a victim of the floating behavior as well.
For example, here I’ve changed the spawn order in the blueprint and replaced the second spawn class from white to orange bot. This event is called manually by the user and hence shouldn’t affect the already placed white and orange bots placed in the editor.
However what happens is that when the level starts, now the orange bot that is placed in the level starts floating while the white bot starts running fine.
However, similar to what you suggested, maybe some other blueprint got corrupted. Maybe the enemy spawner or the enemy parent class. I have already started working on a new enemy parent class with one child and haven’t encountered any issues yet. I will test out the spawner class by moving it’s code to some other class.
I’m going to go ahead and marked this as answered for tracking purposes. If the problem crops up again, please comment here and I’ll be happy to take another look!
Can you post a screenshot of your camera setup in blueprints? It will be easier to assist you with some context on how you are setting up your camera movement.
Yes, I pretty much had to rebuild all the associated classes once again. The same project has been used across all the newer versions of the engine since then & the issue hasn’t resurfaced in any manner so far.
Still I’ve encountered cyclic dependency issues occasionally which caused child classes in an inheritance relationship to reset their variables to parent values. As a result, I’ve started using actor components to handle code that can be used across multiple types of actors. Also reducing the number of multiple references to an actor from different blueprints also seemed to help once.
