You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having two distinct systems use Local<T> (for the same T) creates a dependency between them. I believe this is due to the mutable access being declared the same way for ResMut<T> as with Local<T>.
I agree that a newtype is a quick fix for this (and it will work with the current Bevy releases). But I also think we might be able to solve this problem by just removing the T access entirely (and the borrow locks). The instance of the type is guaranteed to be uniquely accessed by the system, so theres no need to synchronize here. The only way to get an aliased reference is to directly access the Resources collection, which can only happen from a "thread local system" (which is guaranteed to have unique Resources access).
I think TypeAccess should be extended with Option<SystemId>. The actual access is already scoped by that parameter, IMO it's confusing that hazard inspection doesn't know about it.
Having two distinct systems use
Local<T>
(for the sameT
) creates a dependency between them. I believe this is due to the mutable access being declared the same way forResMut<T>
as withLocal<T>
.bevy/crates/bevy_ecs/src/resource/resource_query.rs
Lines 281 to 285 in 3bc5e4c
bevy/crates/bevy_ecs/src/resource/resource_query.rs
Lines 322 to 326 in 3bc5e4c
Is there a way to make this more granular and remove dependencies between such systems?
The text was updated successfully, but these errors were encountered: