search

bevyengine / bevy

A refreshingly simple data-driven game engine built in Rust
https://bevyengine.org
Apache License 2.0
35.86k stars 3.54k forks source link

System ordering around BRP (Bevy Remote Protocol) #16042

Open inodentry opened 2 days ago

inodentry commented 2 days ago

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

Currently, Bevy's Remote Plugin adds its systems to the Update schedule (which is honestly quite confusing ... wasn't Update meant strictly for "user code" and not "engine code"?). Further, there is no system set (like most other bevy internals have) to allow users to order their systems before/after BRP.

Given that the whole point of BRP is to allow monitoring and messing with ECS data, the impact of this is quite severe. As is, BRP always runs with ambiguous/undefined/racy ordering with respect to all user systems in Update. Every frame, it may or may not see changes to component values made by various user systems.

What solution would you like?

Honestly, BRP should probably not be in Update in the first place.

Regardless of which schedule it runs in, there should be a system set, to allow people to order systems around it.

What alternative(s) have you considered?

There aren't any afaik?

torsteingrindvik commented 1 day ago

Haven't used BRP yet but I have a similar remote protocol for a project. I put all my handlers in a set which is strictly before Update for similar reasons.

It's very easy to end up having issues related to 1-frame delays if remote commands can intermingle with logic in Update.