Entity SetName with EntityCommandBuffer?

Does setting entity name, with EntityManager is only one possible way?
Are there any plans, to allow setting names via command buffer?
Is it feasible?

 

SetName is only for debugging purposes as it is wrapped in #if UNITY_EDITOR

 

Sure, that makes sense.

The reason I ask is, using set name allowed me to detect extra entities, which I wasn't aware of and which shouldn't be there. These are only generated via EntityManager.

However, many of my entities are generated via command buffers. So indeed, I would like easier to debug, ensuring I have no left over entities, where not suppose to.

I am just thinking of creating temp debuging system, which purpose is just to set names on main thread.

 

Makes sense. A reactive system responding to a component with a NativeString256 would likely do the trick.

 

+1 would love something more here. I have systems in place creating entities in which I just don't add names even though it would be helpful only because it's not worth changing the structure of my systems to be able to get main thread access to rename them. An ideal solution would be an optional name parameter in CreateEntity that would just get ignored when not in the editor.

 

Same, I've set names to entity's for debugging purposes and didn't realise you could only do so with the Entitymanager. Something like this would be really useful when dealing with lots of entity's.

 

+1 Same.
ecb.SetName(entity, "LookAtMe");
Was hoping to do this...

 

I wanted something similar a few months ago and solved it by simply creating prefabs that I set the name on. Lets say I have a system that creates event entities in a job. In the system's OnCreate I typically create prefabs for the events and set proper names on them. In the job I then just pass in the prefab Entity and instantiate it in the ECB, instead of creating it from scratch in the job.

I did however eventually run into the issue that I had set names on too many entities, so Unitys built-in name handler ran out of names or something. I seemed to have reached a limit for how many entities could have custom names. This was when I tried to put custom debug names on a few hundred thousand entities.

 

@Zec_ did you use SetName for each individual entity?
Or have you used instantiating of prefab entity (or similar)?

 

3 Arguments come to my mind:

• There is no need to identify an entity (code-wise) using a name (exception: debugging, as in distinguishing the entities in the Entity Debugger)
• Even if that would be the case, there is no need to change the name at runtime out of a job (components should be used instead for basically anything you'd want to achieve with the name change)
• The

  EntityCommandBuffer

  is one of the types that's supposed to be usable out of Burst-compiled jobs. In order for Code to be Burst-Compiled, only specific types are allowed, and

  string

  isn't one of them. So supporting a

  SetName

  would cause all Jobs using the command buffer to not be Burst compilable.

Instead of using the command buffer, if you need to change the name, you could use a

ComponentSystem

(not

JobComponentSystem

) that assigns the name according to the component data present on the entities.

 

For the first example with how I handled the prefabs, the name is set on the prefab, and not on the instances.

For the second part where I described how my names started failing in the hundreds of thousands, I was setting the names per entity. I attempted to set the names on entities loaded from subscenes based on the prefab they were serialized from.

 

Here probably where the problem lies. Since naming is mainly for debugging purpose, giving individual names beyond thousands of entities, misses the purpose. I can not think of any feasible way, debugging 10s of thousands of entities, by looking into names. We can use components as tags for that purpose.

Unless you have specific use for that, which I am not aware of?

In any case, I would give group of entities same names, by spawning from prefabs, then filter by component when debugging, and identity individuals by entity index / version.

 

Yup. For debugging purposes, being able to set names from systems, via command buffers, would be tremendously useful. This, plus being able to sort entities in the Entity Debugger and Entities panels in the editor would make certain debugging tasks significantly easier.

To give an example: I have (Entity-)Prefabs and their instances. Those instances are created in a system, so I can't rename them. The name used automatically is the name of the prefab. So, yeah, I could click on every entity with a given name (or even search for those prefabs in particular), and then look at the inspector to see if it's the prefab or an instance (prefabs have an extra component) ... but ... that's not a very efficient workflow.

Also, tagging entities just for debugging seems like a lot of boilerplate for something that could be done comparatively easily with naming (and as naming only works in the editor, there's no risk of burdening an actual build with this).

 

Just ran into this problem. I was able to fix it because you can now run main threaded jobs:

Code (CSharp):

1.  
2. #if UNITY_EDITOR
3.     //Just a NativeList<(int, Entity)> that holds the new unique ID of the Entity and that Entity.
4.     var shieldIDDatas = createShieldEntitiesSystem.shieldIDQueue.newUniqueIDs;
5.     //This is a just a property of the custom system I am running in that returns the World's EntityManager
6.     var entityManager = EntityManager;
7.     Job.WithName("AssignShieldNamesJob").WithReadOnly(shieldIDDatas).WithoutBurst().WithCode(() =>
8.     {
9.         for (int i = 0; i < shieldIDDatas.Length; i++)
10.         {
11.             var shieldIDData = shieldIDDatas[i];
12.  
13.             entityManager.SetName(shieldIDData.entityData, $"ShieldEntity (shieldID: {shieldIDData.UniqueID})");
14.         }
15.     }).Run();
16. #endif
17.  

Hope this helps