EntityCommandBuffer.Clear?

Will there be one? I want to allocate single EntityCommandBuffer with Persistent allocator to catch inputs events that can occur outside update loop to update EntityManager with a batch of commands.

It would be great to just clear buffer instead of re-allocating it constantly with Persistent in an Update.
If anyone know a workaround of how to re-use the buffer, please let me know.

I’ve ended up doing this in OnUpdate:

// Re-Use buffer
if (_postUpdateBuffer.ShouldPlayback) {
   _postUpdateBuffer.Playback(EntityManager);
   _postUpdateBuffer.Dispose();
   _postUpdateBuffer = new EntityCommandBuffer(Allocator.Persistent);
 }

This seems like a bad idea.

-edit- sorry should elaborate.

If you have to modify entities outside update look (in MonoBehaviour etc) you should probably just modify them directly with EntityManager. You’re just coupling everything together for no reason.

1 Like

Well, the other alternatives are:

  1. Modify entities at random position in Update loop, when the new Input System sends its messages.
    Which will cause operations out of system update order and potential sync points.
  2. Poll inputs manually in OnUpdate and only after that modify entities on the main thread.
  3. Set a flag and poll them in OnUpdate.

I don’t like any of those.

(Sorry I edited my post and elaborated a bit more)

I just want for those events to be gathered in a single sequence that is executed after my input processing system rans (at set update order). So that inputs are executed at the time input system update runs.

By using new Input System package you can define callbacks inside systems (for the input events, driven by HW).
So the callbacks are inside the system, just not inside an OnUpdate.

From profiling it doesn’t seems to have really that much of a performance impact (no GC alloc with leak detection disabled), so I’ll just leave it be.

ECB.Clear would be great though.

you can use Allocator.TempJob and create an ECB each frame, ComponentSystem does that for PostUpdateCommands, and the barriers even create an ECB each time you call them.

if you really want to recycle a single Persistent container, you can use NativeList and loop them yourself, then clear it

you also can try to manually update the Input System inside your OnUpdate, then you can even use Allocator.Temp (OnUpdate() → alloc ecb → update InputSystem → it calls your callbacks → playback ecb → dispose not needed for Temp → end OnUpdate)

It needs to persist outside OnUpdate loop to properly catch callbacks, otherwise I’ll just get not allocated exception.
I’ve already tried it.

Don’t think I can. Haven’t really digged into manual, but even though it is called Input “system”, I don’t think its an ecs system. Maybe I’m wrong.

if I remember right, they were talking about allowing to manually call the input update, to enable collecting the input events when you want, therefore allowing DOTS integration (a principle of dots is no random callbacks at random times)
it’s still in preview, so maybe the action stuff is still not supported. ask in the input preview forum
(Input should be processed entirely in a single “step” of the player loop, callbacks included, and there should be an API to control where it happens)

Allocator.TempJob can persist outside OnUpdate for up to 4 frames. (number is arbitrarily chosen by Unity devs)
Temp is freed as soon as you leave the managed code