Hi! I’m looking for a way to tell which Off-Mesh Link is being traversed by a FollowerEntity in pure ECS way. I see the AgentOffMeshLinkTraversal component. Is it possible to add an ID/handle of sorts to uniquely identify a Link2 component so that I can do my own traversal logic? I’d much rather not touch ManagedAgentOffMeshLinkTraversal since it’s a managed component.
Thank you!
Hi
Not at the moment.
However, I would also caution against trying to do everything in a pure ECS way with no classes at all. It’s often premature optimization.
In this case, agents traversing off-mesh links is typically a comparatively rare operation. So handling those using classes is not really a problem in practice from either a performance or memory standpoint.
Hey Aron,
Thank you for your quick reply! I’m still relying on classes for UI and Input. However, my concern comes from what’s stated in Unity docs for managed components (I can’t post links here since I don’t have permission, but it’s titled “Managed components” in Unity docs)
Namely, can’t access in jobs means I can’t just schedule it and run it asynchronously. I’ll look for a workaround for that. Maybe by extracting the relevant data from the main thread and then scheduling a job with that data 
Thanks again for taking the time to reply! Appreciate your continued effort in maintaining this framework!
That’s true. Even in this package they run synchronously. But I’ve paid a lot of attention to scheduling conflicts, and trying to minimize the impact of this.
It is actually possible to run such jobs in parallel, but it requires some boilerplate code and tricking unity. See the RepairPathJob for an example. I would not recommend it unless the profiler indicates that this code is really a hot spot.