Bevy internal entities need public visible marker. about bevy HOT 10 OPEN

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.

from bevy.

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.

from bevy.

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.

from bevy.

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.

from bevy.

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.

from bevy.

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?

from bevy.

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.

from bevy.

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.

from bevy.

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.

from bevy.

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.

from bevy.