I’ve noticed that names of actors on levels aren’t unique anymore. At least when it comes to a level that consists of multiple other levels. In my test case, I have a level that has another level loaded as a sub-level.
The issue that I have is, that it’s possible to have multiple actors that use exact same name. As you can see on the picture below, the two ExampleFloor actors have exact same label and ID name (and since the GetFName uses name from the same place as the ID Name on the image it basically means that both these actors have exact same names).
NOTE: Both these actors are placed on different levels. One is placed on Persistent Level and 2nd resides in SubLevel.
The above case was achieved by renaming actors manually, but it’s not the only way to make such thing happen.
Another way to encounter this issue (and way more crucial for my actual case) is the fact that when you spawn two actors of the same class on two different levels, they might end up having the same name. And that, unfortunately causes that the perception system (sight at least) that is made in UE4 doesn’t work properly. Also, from what I’ve heard it messes up with TWeakPtr’s a bit/lot.
FYI: Perception system used to work fine (so I’m assuming that there was no issues with unique names across all loaded levels) when the project was based on 4.10.X version of the engine and the started to appear after migration to 4.12.X.
I’m attaching an example that shows the issue and some more info about the example itself:
The project is made in blueprints, but from what I see, the GetObjectName node that I’m using there is using GetFName under the hood.
Red spawner (cube) and its spawned red blueprints (cones) always reside on SubLevel. The… “blue-ish” spawner and its spawned blueprints are always placed in Persistent Level.
Each of spawners keeps spawning a blueprint and prints its name. Color of printed text obviously matches to the color of the spawner (just for identification purpose).
Project is made in 4.13.1 version of UE (tho I’m also having the same issue on 4.12.5)
[Example project download][3]
Is this intended behaviour or is this some kind of a bug?
Thanks for the reply however your solution doesn’t solve the problem with TWeakPtr’s nor perception system. Also, it won’t help with the thing I’m working on.
We already have a workaround implemented (at least perception system-wise) but it’s not perfect and it would be way better just to fix the issue with actor/object names not being unique across all loaded levels.
Hey, for the name problem you could add the sublevel name + actor name to get a unique name (it is manual but if you need it this seems a good way to get it), but it is weird you have trouble with the perception system, could you show some screenshots how you set it up?
Unfortunately I have been unable to reproduce this issue on my end. These are the steps I took, do you have any additional steps I can take to reproduce this on my end:
Open Editor (any project)
Create a sublevel
Change streaming method to always loaded
Add a cube actor to each the persistent level and the sublevel
In the level blueprint, print string a reference to the cube in the persistent level
In the sublevel blueprint, do the same for the cube within the sublevel.
When I put actors manually, their names seem to be unique indeed. But that’s not the main issue (however, you should be able to rename actors by hand to have exact same name, unless both actors are on the same level).
The example project I uploaded and linked in OP shows something that is closer to our case. You can see there, that when you spawn actors in runtime, they do have the same names if both are spawned on different levels
Thank you for submitting a bug report. I have reproduced this issue and logged a report for it here. You can track the report’s status as the issue is reviewed by our development staff.
There’s one thing about the issue from issue tracker tho. In the description, you wrote that the names will not be unique if actors are spawned simultaneously. And that’s not the case.
I’ve uploaded alternative version of the project from OP where each spawner spawns actors with different delay and you still can see that names aren’t unique either.
I’ve seen that you (or someone else) changed the issue to ‘resolved by design’ despite the fact that it was marked as bug that will be fixed in 4.15. Kinda weird. Is this seriously intended to break couple of your own systems?
I had a look at the internal notes and that is correct. The system in place endeavors to keep the name the same as the template, which if it is the first spawn from that template in to a level will be possible. Otherwise, it begins to use the create unique name system using a global counter on the class to add in a number to give unique names after this point.
What specific steps are you taking to call on the actors? Are you referencing the names directly or do you have a specific reason this system does not function the way you need it to?
In the project, you can see a main level (called Level) that has two sublevels: Level_A and Level_B.
On each of these 3 levels, there’s a spawner that spawns some simple pawn controlled by an AI controller.
Each of pawns has an AIPerception component with basic sight sense set up. Because of these settings and positions of all AI pawns, every pawn can see two other pawns that are placed on the level (well, at least they are in each others fields of view).
However, when I debug the information about who see who (the arrows) it’s obvious that the result is far from the expected and desired one. As you can see on the picture and in the project, green AI can see orange one, and blue can see orange one as well. But that’s it.
In above example I’m not using names at all. The perception system does. I’m getting list of seen actors by ‘GetPerceivedActors’ (or smth like that) called on perception component of pawn controlled by AI. That’s all. How would using tags change anything here?
Spawn timing changes only which pawn is the only one perceived in the game. Also, pawns aren’t spawned at the same time. There’s a delay of 1 sec (or smth) between each spawn.
I’m a bit confused. I’ve looked at the blueprints provided and I do see what you are talking about, but this appears to be a different issue entirely. If the orange is set to inactive, the blue and green see each other as expected. It looks like the error you are seeing is in the validity check, not the actor name. If you add a print string to the “Is Not Valid” pin within your pawn ai, it looks like at some point one of your actors is either not getting populated with an ai controller or one of the blueprints is not given the information that the other has an ai controller.
With orange being inactive you mean this variable that can be set on spawner?
If so, I can’t make them see each other when i deactivate orange actor this way. It always ends up on blue pawn seing the green one.
As for the check, I added it just to prevent from detecting player’s pawn there. Without it, AI pawns were able to see me and spawn arrows into my face.
While I am not certain this is a bug, I was able to reproduce what you are seeing. I have entered a bug report for further assessment by the development staff. This bug has been entered as UE-37850 and is specific to the AI perception component.
