Skip to content
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

Inspect and edit deferred commands just before they are applied? #11950

Open
Architector4 opened this issue Feb 18, 2024 · 1 comment
Open

Inspect and edit deferred commands just before they are applied? #11950

Architector4 opened this issue Feb 18, 2024 · 1 comment
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible C-Usability A targeted quality-of-life change that makes Bevy easier to use

Comments

@Architector4
Copy link
Contributor

Architector4 commented Feb 18, 2024

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

It would be useful to have a way to inspect and edit deferred ECS commands before they are applied.

This may be a more efficient and generic solution to problems like retrieving data from resources and entities just before they are deleted, or for other applications.

What solution would you like?

I'm thinking of having some kind of a InspectDeferred schedule that is run by apply_deferred system just before applying any deferred commands, and an API to actually manipulate or at least read the deferred commands list from such systems.

A developer could then insert exclusive &mut World systems into that schedule, which, for example, read the remove commands that are about to be executed, and then read and preserve just the data it needs.

Or maybe even edit the list of commands, and add/edit/remove commands that may be undesired for some reason. That may make it easier to manipulate commands done by another plugin, perhaps from a crate developed by someone else, if it exhibits undesirable behavior in this sense.

(In my particular case, for something I'm slowly working on, it would be very handy to be able to have hold of the exact entity IDs of entities that get deleted, which sounds like it would necessitate having the ability to edit the deferred commands list to preoccupy an ID of an entity with World::get_or_spawn after it gets deleted but before any new ones are spawned, or outright replace the command with a personal solution.)

The proposed solution raises a question about inserting systems into that schedule that themselves send deferred commands. May be worth to make systems that have a Commands parameter panic when run in this context to prevent the possibility?

What alternative(s) have you considered?

Wait for some solution to just the problem of retrieving deleted components and resources. Personally fork and edit code of crates with undesired behavior, and hope users of your code don't perform such behavior too. Create a personal solution of a command that preserves component/resource data before deleting it and urge everyone involved to use that instead of the stock Bevy remove commands.

Additional context

Haven't looked much. I apologize if this was already considered.

@Architector4 Architector4 added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Feb 18, 2024
@TrialDragon TrialDragon added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use and removed S-Needs-Triage This issue needs to be labelled labels Feb 20, 2024
@Architector4
Copy link
Contributor Author

It sounds like Observers (#10839) are very relevant to this, but as I understand they are only applied after the commands and can't retrieve components before they are altered by it?

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 C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
None yet
Development

No branches or pull requests

2 participants