Question: Tracking / accessing entities by their id about becsy HOT 5 CLOSED

Thanks Michael, it's great to hear that somebody's actually using this!

IIUC you have code that gets external objects as input (e.g., events from a framework) and would like to update corresponding entities in response. There's indeed no convenient way to do this right now. The __id is internal, but even if it wasn't there's no way to fetch an entity by ID. And the Entity instances themselves are flyweights and can get reassigned on the fly to different IDs.

My plan here is to allow you to "hold" entity objects to ensure that they don't get reassigned, so you can safely refer to them either directly from external objects or through an intermediate map. This will carry a small overhead but should be fine as long as you're not holding new entities every frame. For example, holding an entity when you create the corresponding external object ought to be OK.

Would this work for you? It's not implemented yet but I could throw it together pretty quickly, I think.

In the meantime, any entities that are in the results of a query will also be "stable" so as a workaround you can establish such queries (even if you don't use the results) and safely refer to those entity objects. You'd have to be careful about timing, though, since if you add a new entity in a system the query won't capture it until the next frame, and any reference you hold to the entity in the meantime is subject to flyweight reassignment.

It is fairly simple to maintain a mapping from entities to external elements

BTW, are you using Type.object for this, or some other approach?

from becsy.

Thanks heaps for the quick response!

IIUC you have code that gets external objects as the input (e.g., events from a framework) and would like to update corresponding entities in response.

Yep! My intention is to update entities in response to external events - and also to use the entities to update buffers on the GPU.

My plan here is to allow you to "hold" entity objects to ensure that they don't get reassigned, so you can safely refer to them either directly from external objects or through an intermediate map.

That sounds really powerful! Do you have any thoughts on how that'd play with write change tracking? We'd be holding onto entities for quite a while - rather than allocating per frame, so I think that'd be fine for our use case.

There's indeed no convenient way to do this right now. The __id is internal, but even if it wasn't there's no way to fetch an entity by ID.

Out of interest - I understand the Entity object is recycled, but is the EntityID still stable for the life of an entity (i.e. until it's deleted)? Even without a way to fetch an entity given this id, that'd be a useful thing to have - as it'd make it easy to reconcile changes outside the ECS.

BTW, are you using Type.object for this, or some other approach?

We were putting the external identifier into a component and had an external map that we were performing lookups into.

from becsy.

Do you have any thoughts on how that'd play with write change tracking?

Holding entities wouldn't affect write change tracking, as that happens at the component level anyway so it doesn't matter which entity object the write goes through.

Out of interest - I understand the Entity object is recycled, but is the EntityID still stable for the life of an entity (i.e. until it's deleted)?

Yes, entity IDs are stable, but they're aggressively reused after an entity is deleted so I consider it unsafe to expose them as you could easily end up referencing something random (especially as there's no hooks for entity removals). In fact, dealing with deleted entities is the main challenge in implementing the proposed hold mechanism, but at least I have access to the internal queues and routines.

We were putting the external identifier into a component and had an external map that we were performing lookups into.

You might want to try Type.object or Type.weakObject then. It should feel more natural and probably even perform a bit better.

Anyway, I'll take a swing at the problem soon and let you know how it goes.

from becsy.

All right, Entity.hold is implemented in 0.8.2. I also added safeguards against keeping a flyweight Entity object around, though those reduced entity create/delete performance by 50% in dev. Make sure you're using becsy/perf in production!

from becsy.

Amazing, thanks for looking into that, I'll give it a go.

from becsy.