Skip to content

Query filter for component value rather than component existence #5639

Open
@ItsDoot

Description

@ItsDoot

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

I'm working on a game that uses a lot of different 'status effects'. These status effects are presently implemented on each character as an inserted/removed component, but I am interested in exploring these with always-inserted bool fields instead (akin to Visibility). The main issue I have is that I won't be able to filter out entities as easily as I can presently (like finding all poisoned entities by using With<Poisoned>).

What solution would you like?

UPDATE: Working proof of concept: https://crates.io/crates/bevy_mod_check_filter

A Query Filter pair akin to With/Without, that instead of checking for component existence, checks for component value. Given we don't have full const generics yet, this should probably be limited to true/false for simplicity. Alternatively, the current value could be compared to the Default value.

The name for these filters? Unsure. Maybe Truthy/Falsey or Enabled/Disabled?

Illustration

Today:

#[derive(Component)]
struct Poisoned;
fn all_poisoned(entities: Query<&Name, With<Poisoned>>) {
    // ...
}

New query filter (see how we don't lose the ergonomics of marker components?):

#[derive(Component)]
struct Poisoned(bool);
// We will need some machinery like Deref or Into to extract the current value, but I'll leave that for discussion.
fn all_poisoned(entities: Query<&Name, Enabled<Poisoned>>) {
}

What alternative(s) have you considered?

Filtering the way that the Visibility struct does presently. It's not the best ergonomics, though.

Additional context

Related to the discussion found in #3796.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ECSEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleD-ComplexQuite challenging from either a design or technical perspective. Ask for help!X-ControversialThere is active debate or serious implications around merging this PR

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions