Bevy internal entities need public visible marker.

[brandon-reinhart]

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

As far as I know, RegisteredSystem entities are the first internal entity in bevy. Unfortunately, these have no property that makes them distinguishable as "owned by an engine service." Systems that clear large numbers of entities on state change (for example) will sweep up and nuke RegisteredSystems.

(In my case, this means by RegisteredSystems are blown away as soon as the game is loaded.)

What solution would you like?

A simple solution that also keeps internals private is to mark all Bevy owned entities with a common marker.

#[derive(Component)]
pub struct SystemEntity;

This way these entities can be selectively excluded by end users.

What alternative(s) have you considered?

Another possibility is to not keep internal components secret, but the above solution is meant to maximize keeping internal details hidden while also giving the user a hook to interact with system owned entities.

[alice-i-cecile]

Window entities are another place where I would use this marker. #12851 / #12770 is another example, and assets-as-entities and systems-as-entities would both benefit from this.

[SkiFire13]

With more x-as-entities I feel like the converse solution would work better: mark all the entities you are interested in and despawn only them.

[brandon-reinhart]

With more x-as-entities I feel like the converse solution would work better: mark all the entities you are interested in and despawn only them.

Either way, I need a way to tell what is system owned. Whether Persistent or NotPersistent. I could not add these by hand to every entity I spawn. If I missed even one, I'd get hard to diagnose bugs.

[rlidwka]

Systems that clear large numbers of entities on state change (for example) will sweep up and nuke RegisteredSystems.

Please no.

Systems that clear large number of entities should work on a whitelist, not on a blacklist. You mark your own entities when you create them, then only remove those entities.

Otherwise your code is gonna break every 3rd party plugin that decides to add an entity for internal use.

[brandon-reinhart]

Systems that clear large numbers of entities on state change (for example) will sweep up and nuke RegisteredSystems.

Please no.

Systems that clear large number of entities should work on a whitelist, not on a blacklist. You mark your own entities when you create them, then only remove those entities.

Otherwise your code is gonna break every 3rd party plugin that decides to add an entity for internal use.

I tend not to use third party plugins these days (too many are abandoned) so I didn't think about that. That example aside, don't I still need to know what bevy owns?

Also... I think I disagree with your claim. Usually there are a handful of things to persist, whereas 99% will be expunged when the game state is exited back to the main menu. Marking everything as Transient is pretty junky.

[rlidwka]

I could not add these by hand to every entity I spawn. If I missed even one, I'd get hard to diagnose bugs.

No, you can add those automatically with your own custom 5-line EntityCommands function (or whatever you're using to add them). Avoiding code duplication is a basic programming skill.

That example aside, don't I still need to know what bevy owns?

I'd guess that you don't. It might be used by folks in bevy_inspector_egui to highlight bevy entities in a pretty pink color, but whether that's worth maintenance burden is an open question.

Marking everything as Transient is pretty junky.

You don't mark everything as Transient, you mark 99% of entities that you know for sure are Transient. Why's that junky?

[SkiFire13]

I could not add these by hand to every entity I spawn. If I missed even one, I'd get hard to diagnose bugs.

In the same way if Bevy or some plugin missed even one you would still get hard to diagnose bugs, with the increased downside that you now have to debug code that's not yours.

[james7132]

I'd be in favor of marking components (in ComponentInfo) with additional metadata, like "managed by bevy_ecs" or "managed by bevy_window". That way systems that operate generically over all entities can be a bit more intelligent about how they work with those entities and resources.

We'll likely need something like this for the editor, where we probably don't want to be surfacing the Window entities in an scene view.

[alice-i-cecile]

I do think we want easier to use abstractions for entity cleanup too. I have a design cooking that adds and removes observers in concert with states to correctly mark and clean up entities that I'm happy with. Needs more ECS features first though.

[UkoeHB]

Also... I think I disagree with your claim. Usually there are a handful of things to persist, whereas 99% will be expunged when the game state is exited back to the main menu. Marking everything as Transient is pretty junky.

This issue is a great example of why I want world swapping.

[alice-i-cecile]

I'm going to close this as not-planned for now and we'll see how the state-scoped entities work to tackle this problem. If it's not sufficient, we can reopen this or make a new issue.