-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
bevy_app: Allow SubApp
s to be modified at runtime
#6700
Comments
As a workaround can you use std::mem:swap in the sub app runner? It gives &mut access to the sub app. |
thanks. that should work for what i'm doing (swapping |
This seems to have changed with #6503. |
it's still impossible to remove a sub app after |
I'm currently trying to figure out how to do this, so seeing that someone else has considered it is nice to see. I'm partial to the third option of AppCommands as it takes less boilerplate code to make changes, and you don't need to worry about the multiple world scenario. Maybe information about the subapps should be accessible via AppCommands as well? Sorry, know this is an old thread. |
What problem does this solve or what need does it fill?
Currently, Bevy provides no way to add, remove or replace
SubApp
s while the app is running.One can currently (IIRC): end the running of the app, recreate the app with the changed
SubApp
and then run the app. This is unwieldy, slow, and prevents one from easily maintaining parent app state (e.g. windows).I use
SubApp
s for "sandboxed" loading of dynamic plugins, where their initialization and updates can be controlled separately from the parent app. Without a way to modifiySubApp
s after the parent app starts running, hot-reloading is impossible.What solution would you like?
SystemParam
which provides access to the list ofSubApp
s (but i'm not sure how this would be done considering the app is outside of the scope of the ecs and in the future one app may have many worlds), e.g.run_once
, theScheduleRunnerPlugin
runner or thewinit
runner) e.g.or
What alternative(s) have you considered?
Not allowing
SubApp
modification.Additional context
None.
The text was updated successfully, but these errors were encountered: