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

Make systems used in initialization of this Plugin public #8

Closed
tomaspecl opened this issue Feb 4, 2023 · 4 comments
Closed

Make systems used in initialization of this Plugin public #8

tomaspecl opened this issue Feb 4, 2023 · 4 comments

Comments

@tomaspecl
Copy link

It is often useful to create custom Stages or SystemSets but your Plugin does not allow for putting the systems into custom Stages or SystemSets. I need to be able to insert and delete Client and Server resource at runtime and run their systems when appropriate. Simply using the following is not flexible enough:

app
.add_plugin(QuinnetClientPlugin::default())
.add_plugin(QuinnetServerPlugin::default());

I need the controll so that I can manage when the Client and Server resource is created and manage when the systems run.

So make these pub please:

bevy_quinnet::client::create_client
bevy_quinnet::client::update_sync_client
bevy_quinnet::client::update_sync_client
bevy_quinnet::server::update_sync_server
and maybe also AsyncRuntime?

@Henauxg
Copy link
Owner

Henauxg commented Feb 5, 2023

Thanks for your input, I will have a look at it tonight as I may want to modify some bits about the Client and Server resources if I come to expose create_... as public.

Could you tell me a bit more about your specific use case, needing to modify the plugin scheduling ? In particular, I'm curious about Resource deletion.

@tomaspecl
Copy link
Author

So first: yes I need to (want to) be able to change the app scheduling / when the updates happen. I have an app which contains both the Client and the Server and which one gets used (connected to other instance) is determined at runtime. Currently I have to add both ClientPlugin and ServerPlugin and then at runtime setup (connect) one of them. Now why should there even exist a Client/Server instance (Resource) and why should its corresponding update system run when it is not in use?

And then lets say that inside my app I start running the Client and after some time I want to stop the Client and start running the Server. Then I could just remove the Client resource and insert the Server resource. And have all my custom systems set up to only run when the Client/Server resource exists.

If you want you can take a look at my work in progress game: https://github.com/tomaspecl/gravishot

@Henauxg
Copy link
Owner

Henauxg commented Feb 9, 2023

I made some changes to help with these needs. You can find them in a bevy-0.10.0 branch here.

I will wait for Bevy 0.10.0 (which should happen in a week or so) before releasing these changes as it directly relates to the bevy scheduling which is modified by the stageless RFC going live with the 0.10.0 release.

  • AsyncRuntime is now pub
  • [client & server] You can still use the convenient .add_plugin(QuinnetClient/ServerPlugin::default()) in the same way as before.
  • [client & server] In order to have maximal control and only do the strict necessary, which is registering systems and events in the Bevy schedule [*], you can also use .add_plugin(QuinnetClient/ServerPlugin { initialize_later: true }) which will not create the Client/Server Resource.
    • You can then do a commands.init_resource::<Client/Server>(); later on when needed.
    • Client & server plugins systems are scheduled to only run if their respective resource exists.
    • You can remove their respective Resource through a command at runtime.

[*] Events & Systems scheduling: you still need to provide Bevy with events and systems to be scheduled at initialization time as bevy schedule is not dynamic (events modify the schedule too by adding their own systems).

Note that, even in the current version, server and client update systems won't do any work and just return if respectively, the server endpoint is closed, the client connections are all closed.
With the above changes, the client & server systems simply won't get called instead of returning. This is also the difference between Bevy 0.9 and 0.10 with_run_criteria (return early from a system) versus run_if (before entering a system)

@Henauxg
Copy link
Owner

Henauxg commented Mar 7, 2023

Now part of main, released in 0.4.0

@Henauxg Henauxg closed this as completed Mar 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants