ID Name vs Label


#1

Consider the case where a level designer is iterating on item placement within the world, deletes a few, then creates some others, one of which happens to have the same name as a previously deleted object. Assume this object is named Pickup_Spawn.

pickupspawn1

If @‘Pickup_Spawn’ is referenced inside SK, its run time claims that it doesn’t exist.

But upon mouse hover-over in the World Outliner, it is revealed that the actual ID of the object is not just its label.

pickupspawn2

Specifying the object’s ID name in SK resolves the reference problem.

pickupspawn3

I’m not sure how to avoid this kind of problem in the future. I do not want level designers having to be careful about this, and I don’t want SK programmers having to doubt that their label references might not be correct after a level change. It seems to me that SK should determine what the object’s ID name is from the specified label by requesting it from UE4, assuming such functionality exists.

Ideally, UE4 would just recycle unused IDs, but they may have good reasons for avoiding that complexity. Maybe they do in 4.19+, but we’re on 4.18 right now with hopes to upgrade to 4.20 when SK support readies.

For us, a concern here is that a lot of aspects of the game are dynamic with objects coming and going, and we need to in a deterministic way know how to reference our objects.


#2

Hey Jesse,
First off, this is a bug that we need to resolve, thanks for reporting it.

Can you provide any examples of some of the dynamic moments you are hoping to create? I personally don’t like the types of systems that get created with fixed name references, they can be extremely brittle. A level designer changing the name of an innocuous cube in the level can blow everything up.

There are lots of other solutions, maybe we can find a better one for you if we knew some of the exact use-cases.


#3

I have experienced this many times.

It is a feature in the Unreal Editor.

If you mouse hover over the object in the Unreal outliner you can see the actual (often auto-generated) internal scene name.

I find that if you rename the object in the outliner once or twice you can get the actual name to match.

I complained about this to the guys at Epic and they agreed that it is not intuitive. There was some historical reason that escapes my memory. :thinking: I think it has to do with ensuring there are no name dupes though the editor name and the internal scene name may diverge even when the name is not conflicting. It may not be a necessary feature any more - in which case Epic should change this so it always has user editor names match the internal scene names.


#4

I’ll bring this up with Epic and see if it can be fixed for good in the Unreal editor - one way or another. :madsci:


#5

There’s a lot of issues here… and it all depends on how UE4 internally does things.
AFAIK Problem:Labels can be edited and changed and have almost nothing to do with the actual Name ID.
AFAIK Problem #2: Name ID cannot be renamed and once we delete an object we can’t recreate the object with the same Name ID, reliably without editor fudging.

Since UE4 Labels can be anything and having underlying “ID Name” that changes but can’t be changed manually… what are the possible fixes:

  1. Short Term: SK gives us a list of ID Names associated with a Label, so that we can use them. We know the fact that the ID Names may change, but it won’t matter because we handle that internally. So one question would be is if such a thing is easily doable to gather the ID Names of a referenced class in the UE4 engine from within SK?

  2. Other Ideas… IF Unreal were to change the way they display the way they reference objects so that they ALWAYS included the ID Name next to the Label name, this would be much less of a problem. So that we don’t have to hover.
    However, we would still need for UE4 to let us Modify the ID Name (and guarantee that no other object currently exists with the same ID).


#6

I may be unaware of some of the Unreal Editor considerations, though I think that:

  1. The editor labels should always match the internal scene object name. Any time a name is used to create or rename an object, the editor would give an entry error if trying to use a name that is already in use - and highlight/identify the conflicting object. Auto-generated labels would ensure they don’t use existing names - and sill match.

  2. If #1 above cannot be done then always display all the relevant names in the Unreal Editor (as mentioned in @Mack’s #2 suggestion above). Perhaps only show the two names if they do not match.


#7

So given we are following this method to reference:
“There just needs to be a class reference in the level blueprint or in some other actor that exists in the level.”
Is there not a way to get the list of ID Names associated with a label or actor from the SK side at this point in time?


#8

As far as I know, since this information only exists in the Unreal Editor, it would not be available in a cooked runtime and therefore would be of only limited use - i.e. it would only work when running a project via the Unreal Editor.


#9

Ok thanks. We await any solution that you can convince them to provide.


#10

Just to underline how much I agree - I hit this issue years ago the first day that I tried to reference an Unreal object by name. I moved the same object around in various ways and then suddenly a lookup by name came up without finding the object that seemed to be in the outliner. Definitely confusing and annoying.


#11

As a side benefit, perhaps the Python side will also benefit. (hint hint)


#12

What are you guys trying to do? Example:

  • Spawn X random things and have them path to Y random objects
  • Spawn a character and have them path to a series of objects
  • Spawn X random things from Y random classes when Z gets near any object W unless object W has been fed ham_sandwich

I don’t feel like this issue should be a roadblock for you.


#13

Wow, you guessed ALL 3 correctly!
In this phase Jesse was implementing a specific AI test case: Spawning X number Spheres with Y number of Pickups, with the overall goal to path only to pickups that were closest based on some random weighting of the Pickup, while still heading toward “Player”.

The problem was simply that the initial name for the object pickup was something like: Pickup_Spawn. So at some point in the testing he deleted Pickup_Spawn, and replaced it. So the UE4 Label became different from the true Name ID. Just as Noolarch had mentioned, “If you mouse hover over the object in the Unreal outliner you can see the actual (often auto-generated) internal scene name.”
So he spent some time with initially working code that later failed and was semi-lost to understand why, eventually discovering the reason and posting in the hope that there might be an easy solution.

Unfortunately it comes down to simply having to be “burned” at least once to understand the nature of UE4 Labels and we apologize because we seem to be hitting a few of the stumbling blocks as we progress.
So I guess for now, we must “Hover” over any Label for anything that we change to make sure its ID Name is not changed from the Label that UE4 chooses to display.

This can be a serious challenge especially if we were much further along and had a lot of hard coded names in the SK code and then ran into a situation where we had a level editor (artist) change a few objects… the code would simply fail with no way for SK to recover without one or more internal SK code changes.

We were looking at how SK can discover the Name ID change and perhaps still work. Ultimately, I was hinting that since Agog is working on Python Implementation, this will almost certainly have to be solved in order for any Python script to say “delete / add or replace an Actor” in the engine and still have an SK script work. But our test case was just simply a spawn and pathing AI test.


#14

In summary: 2 settings in the editor something like:

  • Display ID_Names Column in World Outliner (Turns on a column to right of label)
  • Allow user to rename ID_Names

Would go a long way to making things easier. But ultimately, some method of iterating thru Labels and ID Names in SK would be very helpful provided it worked in a deliverable.


#15

So I know that a working object reference system is what you want but I don’t think it’s what you need. Let me explain, take it or leave it.

It sounds like one goal is to allow level designers the freedom of level design without requiring a programmer. But what is described would require a programmer for the following:

  • Changing the number or class type of characters that are spawned
  • Changing the class type of pickups that are spawned
  • Adding/removing pickup spawn locations
  • Adding/removing character spawn locations

I think a better and more modular architecture would allow a level designer to control all of these aspects without a programmer involved. This would allow rapid iteration of different scenarios and level layouts, all without bringing up a window with any code.

The way I would approach this would be to create a new actor blueprint that is a BP_ActorGoalSpawner. It would have the following data types defined in BP:

  • Array of classes to hold Characters to Spawn
  • Array of classes to hold Pickups to Spawn
  • Array of object actor references to specify Character Spawn Locations
  • Array of object actor references to specify Pickup Spawn Locations
  • Optionally I might turn Pickups to Spawn into a struct that also has a data member for an interest value to map desirability to a particular pickup type.

Now a level designer can drag a new BP_ActorGoalSpawner into a level and with a couple clicks can fill it full of the Characters and Pickups they’re interested in. Then they could drag out TriggerBox's or EmptySceneComponents to indicate where they want their Character Spawn Locations and Pickup Spawn Locations, simply add those to the relevant object array of their BP_ActorGoalSpawner through the world outliner and they’re done.

Now a level designer could try various scenarios without any programmer involved:

  • A group of pirates invade a space station searching for power cores and food.
  • A group of scientists enter a space station and are looking for research.
  • A bounty hunter enters the station and is looking for his kidnapped daughter.

Another bonus of this architecture is that if someone were to try and delete any of these objects that are referenced by the BP_ActorGoalSpawner, it would pop up a warning saying that the actor is in use. Also, if they rename any of these pickup locations, the underlying references would remain intact.

Now, none of what I’ve outlined has anything to do with :sk:. But obviously where :sk: would shine here is that the implementation side of this blueprint is so simple that you could sketch it out during a casual conversation on your lunch napkin. Things similar to this:
characters.any.spawn(spawn_locations.any)

Anyway, food for thought, this is an architecture I would lean towards and advocate.


#16

I am still very much wanting a “working object reference system”. I just think its good stuff.
Your idea is very good because it provides more functionality to One object. Additionally, the idea to “drag out TriggerBox’s or EmptySceneComponents to indicate where they want their Character Spawn Locations and Pickup Spawn Locations” helps the Designer to visualize where the action is at.
The bonuses to the architecture are compelling as well:

“if someone were to try and delete any of these objects that are referenced by the BP_ActorGoalSpawner, it would pop up a warning saying that the actor is in use. Also, if they rename any of these pickup locations, the underlying references would remain intact.”

I was not aware of those bonuses!
I am beginning to think this might have enormous expansion capability… where everything important to SK on the level is connected to it.

Thanks again.


#17

Thanks error, you anticipated many of our needs. Thanks for the direction. =)

In situations where it is natural to speak in terms of any element of a set, such a general approach is preferred. However, I can imagine instances where we want to speak of a particular element - especially while we are converging on a more general design. Given what I know of UE4 and SK together, I can think of ways of addressing this indirectly, say, by creating a custom ‘singleton’ type derived class, and restrict it to only a single instantiation, so the any in this case is the particular, but that is a high friction, high overhead solution that trades the reference problem for a maintenance and complexity problem.

What we’re looking for is as natural a way of referring to the particular as to an any. Labels, if they didn’t change from under our noses, would get us 80% of the way 90% of the time with only 10% of the effort of the other competing approaches in my head.


#18

We are encountering a problem with implementing this suggestion:

“Array of object actor references to specify Character Spawn Locations
Array of object actor references to specify Pickup Spawn Locations”
image

It seems UE4 refuses to allows to specify default values to ANY actor references such as a TriggerBox, or really any actor.

So for example, Jesse created TriggerBox on the Level and tried to create a variable of type TriggerBox but UE4 won’t let us specify “Any Actor” for defaults.

We found this: https://issues.unrealengine.com/issue/UE-60132
and it is sort of freaking us out because we are seeing this behavior in 4.18 and it seems that officially, “Going forward with 4.20 you will only be able to set actor references on an instance of a Blueprint in a level, but not in the class defaults of a Blueprint.”

I guess one specific question:
So we are trying to perform this: “Array of object actor references to specify Character Spawn Locations” and we are using the TriggerBox to specify the location.

We want to reference that TriggerBox in a BP so UE4 and SK can access it. We need this so we can spawn using SK inside that TriggerBox and keep the references in the BP so the Level Designer can’t change it as suggested.
However, UE4 refuses to let us set any actor references to a Variable.

This is just crazy… I don’t even understand how this could possibly be something Epic could do and still make a game… so I am sure someone has a workaround?


#19

By design. You need to drag one of these blueprints into a Level and then that dropdown will contain a list of objects that exist in the level. You are trying to add to the default class variables of the blueprint, it has no level to query existing actors from. You need to be doing this from World Outliner in the level by selecting a created instance of this blueprint in the world outliner of the level.


#20

The Actor does exist in the level. We’ve tried a BPified actor and just a generic one too. Same problem. Here’s a trigger box (generic) and 2 BP driven Characters.

select3

If I set the variable type to an array, the “Class Default Object” error disappears, and lists compatible actors from in the world.

select1

But UE4 does not allow us to select the object listed in the drop down menu. It just refuses to set the default value with no warning or error or any message of any kind.

select2