Add more CommandBuffer APIs

[sapir]

It would be nice if the new CommandBuffer supported all the update operations that are available for World. In particular, I find myself missing despawn, but looking at the list of World methods, I think the following are relevant:

• insert_one
• despawn
• remove
• remove_one

[Ralith]

despawn and remove have been added in #251.

[RybekU]

The mthods listed by the op are already available. The issue could be closed, or...

• exchange
• exchange_one
• spawn_at
• spawn_batch could be considered?

[Ralith]

exchange

What would this do?

spawn_at, spawn_batch

These are fairly niche, and mostly expected to be used in cases where unique access the world is straightforward. I'd like to hear about a concrete use case before complicating things for their sake.

[cjhowedev]

It would be great if we could add our own commands to the command buffer as lambdas that accept the world as an argument, allowing us to perform whatever set of operations we want done atomically when the command buffer is applied. I would be able to use this to write an entity command to manipulate a number of components on an entity simultaneously. This way, I can ensure the component that stores my list of child entities is in sync with the parent components in the child entities. This means I need to be able to "atomically" update components on multiple entities.

EDIT: I thought of a simpler solution in #307, which is sort of like the above.

[adamreichold]

https://docs.rs/hecs/latest/hecs/struct.World.html#method.exchange

exchange

What would this do?

I think this would be a delayed version of World::exchange, i.e. remove some components and then add some others with less overhead than calling World::remove followed by World::insert by avoiding copying into and from the intermediate archetype.

[RybekU]

https://docs.rs/hecs/latest/hecs/struct.World.html#method.exchange

exchange

What would this do?

I think this would be a delayed version of World::exchange, i.e. remove some components and then add some others with less overhead than calling World::remove followed by World::insert by avoiding copying into and from the intermediate archetype.

This is exactly what I meant with exchange.

[RybekU]

spawn_at

I'd like to hear about a concrete use case before complicating things for their sake.

Currently if one entity is spawning another in a system there's a way to pass the parent Entity's ID to the child easily, but not the other way around. In a hypothetical game If a larger enemy (let's say a huge spaceship with multiple guns) has destructible turrets all of them function correctly separately, and the code is very easy to reason about. However, if we want some action to happen on all ship parts (for example: ship's main body got destroyed, play destruction sprite on top of all remaining turrets in addition to the body) it's required to go through hoops (such as: checking parent body's state every frame) to pass that message.

Of course there are different ways to resolve the situation described above, but it would be handy to be able to just reserve some entities (user implementation) and then use them together with spawn_at.

[Ralith]

Is that not addressed by the combination of World::reserve_entity and CommandBuffer::insert?

[RybekU]

Oh, the wording

Add components from bundle to entity, if it exists

has thrown me off a little. Nothing to see here then!

[Ralith]

Closing as most concrete proposals here have been addressed; any remaining/new extensions desired for CommandBuffer should be discussed in new issues.