Wondering if the World parameter in the closure should be non-mut for this requirement. And if so, would we still need to remove the Resource from the World like in resource_scope if we make World read-only?

Wondering if the World parameter in the closure should be non-mut for this requirement.

I would keep it mutable for consistency with resource_scope. In this example I don't need it to be mutable, but there are some cases where it's needed.

Interested in picking this up with my group. Purdue Team

@Shatur I was trying to follow along both bevy_replicon and bevy's code base at these function calls.

• I was wondering in your proposed function signature what is exactly meant by id?
• How do you see id being used in your code?

I was wondering in your proposed function signature what is exactly meant by id?

Resources have functions like this: https://docs.rs/bevy/latest/bevy/ecs/prelude/struct.World.html#method.get_resource_by_id

How do you see id being used in your code?

We no longer need it in Replicon :)

The signature should look something like this. Basically, you're adapting the get_resource_by_id method with the resource_scope method :)

impl World {
    fn resource_scopy_by_id<U> (id: ComponentId, f: impl FnOnce](&mut World, Ptr<'_>) -> U,) -> U { todo!() }
}

How can this behavior be expected from passing one id. From what I've been reading it seems like a given ID is used to access one resource at a time without the type being know.

• What is being accessed by id? It doesn't seem to be the elements in the closure as they are retrieved by type.

To me it seems like this could only be used to do one resource at a time if nesting isn't used. Please explain how the dynamic access can be used on multiple resources at once by id when only one id is given.

world.resource_scope_by_id(id, |world, resource| {
    let mut registry = world.resource::<AppTypeRegistry>();
    let mut entity_map = world.resource::<ServerEntityMap>();
    let mut server_events = world.resource::<ServerEvents>();
    // ...
});

Thanks!

To me it seems like this could only be used to do one resource at a time if nesting isn't used. Please explain how the dynamic access can be used on multiple resources at once by id when only one id is given.

This isn't the goal. The goal is simply to create an equivalent to World::resource_scope that works when a ComponentId is provided. You would only access one resource at once (dynamically): the benefit is reduced boilerplate.