Skip to content

Add MoveBundle command #3717

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed

Conversation

hlb8122
Copy link
Contributor

@hlb8122 hlb8122 commented Jan 18, 2022

Objective

Moving one component from a entity to another entity is a common operation. It would make sense if this was supported out the box.

Solution

Create a move_bundle API on EntityCommands which results in a MoveBundle command. The MoveBundle command peforms EntityMut::remove_bundle::<T> on the source entity and then EntityMut::insert_bundle::<T> on the target entity.

Possible Additions

It might be reasonable to also add a CloneBundle which does the same except replaces remove::<T> with get::<T> then a clone.

@github-actions github-actions bot added the S-Needs-Triage This issue needs to be labelled label Jan 18, 2022
Copy link
Member

@DJMcNab DJMcNab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also want a version to move a single component. The normal scheme would be to call that move:

fn move<C: Component>(&mut self,target: Entity) {
    self.move_bundle::<(C,)>(target)
}

And obviously these need some docs

But otherwise this looks good to me. Ideally we'd have an example of using this somewhere, but I don't know that any of our examples would want this.

@mockersf mockersf added A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible and removed S-Needs-Triage This issue needs to be labelled labels Jan 18, 2022
/// }
/// }
/// ```
pub fn r#move<C: Component>(&mut self, target: Entity) -> &mut Self {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should we do about r#move?

Copy link
Contributor Author

@hlb8122 hlb8122 Jan 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One possible side step here is to name these move_to and move_bundle_to.

#3820 could then be clone_to and clone_bundle_to.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would also allow for the addition of move_from, which would take the source Entity as an argument.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO move_to is probably better. And then do the same with clone_to.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alice-i-cecile Will do, I'm also happy with move_onto, if you'd prefer that?

@hlb8122 hlb8122 marked this pull request as ready for review January 31, 2022 00:28
@hlb8122 hlb8122 mentioned this pull request Jan 31, 2022
@hlb8122 hlb8122 force-pushed the add-move-component branch from d104951 to da17cc9 Compare January 31, 2022 11:15
@hlb8122 hlb8122 force-pushed the add-move-component branch 2 times, most recently from def26d4 to 2c769cb Compare February 6, 2022 13:33
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix up the names then this LGTM.

@alice-i-cecile
Copy link
Member

IMO we should add the move_from variants in the same PR. I've been writing the clonable-entities RFC and having both directions is very useful for ergonomics.

@hlb8122
Copy link
Contributor Author

hlb8122 commented Feb 17, 2022

@alice-i-cecile Should I link to the *_to methods in the *_from documentation and then omit the doc tests?

@@ -512,6 +512,95 @@ impl<'w, 's, 'a> EntityCommands<'w, 's, 'a> {
self
}

/// Moves a [`Bundle`] to a target entity.
Copy link
Contributor Author

@hlb8122 hlb8122 Feb 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/// {Moves/Clones} a [`{Component/Bundle}`] {to/from} a {target/source} entity.

I've picked this for all the documentation across the MoveBundle and CloneBundle PR. If anyone has some better suggestions I can change it because, as is, this is pretty aburpt.

let bundle_opt = if let Some(mut source) = world.get_entity_mut(self.source) {
source.remove_bundle::<T>()
} else {
panic!("Could not move a bundle (of type `{}`) from entity {:?} because it doesn't exist in this World.\n\
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: can we extract a function to do this panic instead of copying the message?

Copy link
Contributor Author

@hlb8122 hlb8122 Mar 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a slight difference between the two:

from entity

and

to entity

Which means it might be a bit gnarly. e.g.

fn panic_fmt<Ty>(verb: &'static str, preposition: &'static str, entity: Entity) {
        panic!("Could not {} a bundle (of type `{}`) {} entity {:?} because it doesn't exist in this World.\n\
                If this command was added to a newly spawned entity, ensure that you have not despawned that entity within the same stage.\n\
                This may have occurred due to system order ambiguity, or if the spawning system has multiple command buffers",
                verb, std::any::type_name::<Ty>(), preposition, entity);
}

Ye/nay?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I like this.

Copy link
Contributor Author

@hlb8122 hlb8122 Mar 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alice-i-cecile @B-Reif 8bc7023 hows that look?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes please; let's keep this consistent.

@hlb8122 hlb8122 force-pushed the add-move-component branch from 72a9056 to 8bc7023 Compare March 8, 2022 11:30
let bundle = if let Some(some) = bundle_opt {
some
} else {
return;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should it panic in this case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're being consistent, yes.

I dislike this behavior, but that's for a different PR.

@alice-i-cecile
Copy link
Member

@hlb8122 do you want to clean this up so we can merge it?

@NthTensor
Copy link
Contributor

This looks like it has gone stale, and required components change the landscape here significantly. Closing as not planned.

@NthTensor NthTensor closed this Sep 17, 2024
@alice-i-cecile
Copy link
Member

I still think this is a compelling idea, but I agree, this needs to be completely remade.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants