Entity Markers

[DasLixou]

What problem does this solve or what need does it fill?

A Marker trait that can mark an entity. example

#[derive(Marker)]
pub enum Players {
    Red,
    Blue,
    Green,
}

then we can assign an entity with a marker

commands.spawn(PlayerBundle::default()).mark(Players::Red);

and we can easily query players

fn add_items_to_red_and_blue(red_query: Query<Player, Or<MarkedAs<Players::Red>>, MarkedAs<Players::Blue>>>) {
    // ...
}

What solution would you like?

An Marker that works like a Resource but holds a EntityID and the Marker can be used in Queries.

What alternative(s) have you considered?

Manually make Resources holding EntityIDs and then using a normal query and using .get with the entityID from the resource.

[harudagondi]

This requires enum variants as types, which is not possible in Rust. See:

• Types for enum variants rust-lang/rfcs#1450
• Enum variant types rust-lang/rfcs#2593
• Indexes: look up entities by the value of their components #4513
• Query filter for component value rather than component existence #5639

[DasLixou]

This requires enum variants as types, which is not possible in Rust. See:

* [Types for enum variants rust-lang/rfcs#1450](https://github.com/rust-lang/rfcs/pull/1450)

* [Enum variant types rust-lang/rfcs#2593](https://github.com/rust-lang/rfcs/pull/2593)

* [Indexes: look up entities by the value of their components #4513](https://github.com/bevyengine/bevy/issues/4513)

* [Query filter for component value rather than component existence #5639](https://github.com/bevyengine/bevy/issues/5639)

But it works for SystemLabel, and it is infact just a label. the whole entity it corresponds to wouldn't be stored in the marker directly but would be in a lookup table, wouldn't it?

[harudagondi]

This specific part would not work: MarkedAs<Players::Red>. You cannot use an enum variant as a type.

[DasLixou]

This specific part would not work: MarkedAs<Players::Red>. You cannot use an enum variant as a type.

oh! thats pretty sad. But with structs it would work? like

#[derive(Marker)]
pub struct RedPlayer;

?

[ickk]

You can basically achieve something to the same effect by just using individual "marker components":

#[derive(Component)]
pub struct Red;
#[derive(Component)]
pub struct Blue;

commands.spawn((Player::new(), Red));

fn system(query: Query<Player, With<Red>>) {
    // ...
}

[DasLixou]

You can basically achieve something to the same effect by just using individual "marker components":

#[derive(Component)]
pub struct Red;
#[derive(Component)]
pub struct Blue;

commands.spawn((Player::new(), Red));

fn system(query: Query<Player, With<Red>>) {
    // ...
}

Yes but that doesn't have to only resolve into one entity. it can have multiple when you don't do it quite well.. but thats probably a better thing than using a resource

[harudagondi]

If you need it to resolve it into one entity, why not store that entity in a resource? Like

#[derive(Resource)]
pub struct RedPlayer(Entity);
#[derive(Resource)]
pub struct BluePlayer(Entity);

So that you can guarantee you can have one entity for each color.

[ickk]

If you need a singleton but don't want to use a Resource, there is also the Query::get_single method, which will give you Result letting you know if there isn't exactly one match for the query. This won't actually guarantee you only have one, but it will at least let you detect/handle when the invariant is violated.

[DasLixou]

yeah but both of them are a little bit messy or don't really guarantee that you'll have one. And both of them make it hard for the scheduler to asynchronously handle them because the information that we only want that one specific entity won't be given to the scheduler (at least thats what i thought)