Add SystemIdTemplate to allow one-shot system in bsn!

[hxYuki]

Objective

• Fixes Allow registering one-shot system in bsn! #24002

Solution

• Add SystemIdTemplate
• Implement FromTemplate for SystemId
• Add a helper function system_value<M> to convert a system to SystemIdTemplate

Testing

• A ad-hoc test nested in 3d_scene.

---

Showcase

#[derive(Component, FromTemplate)]
struct Callback(SystemId);

fn callback_scene() -> impl SceneList {
    bsn_list! {
        Callback(system_value(|| {
            println!("Hello from the callback!");
        })),
        Callback(system_value(callback_system)),
    }
}

fn callback_system(){
    println!("Hello from the system!");
}

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide, as well as our policy regarding AI usage, and we look forward to reviewing your pull request shortly ✨

[hxYuki]

Not sure where to place these codes. I've searched impl FromTemplate for in repo and got only Entity here.

[hxYuki]

What should be the default value for a SystemId?

[SkiFire13]

IMO this is becoming pretty complex and I'm kinda losing track of how everything fits together.

[SkiFire13]

I don't think this is guaranteed to run after relationship has been removed from SystemRefs

[hxYuki]

Relationship connection is maintained in on_discard and this happens in on_remove.

As documented in lifecycle.rs:

An on_discard hook always runs before any on_remove hooks (if the component is being removed from the entity).

Relationship must have already been removed before this hook.

[SkiFire13]

Makes sense, I would document it here though.

[SkiFire13]

The CI warning looks legit ("Sytem" instead of "System")

[hxYuki]

Yhea, didn't run ci locally yet as drafting.

[SkiFire13]

Even with the documentation it's not clear to me what these are actually doing.

[hxYuki]

erDiagram
    TemplateEntity ||--o{ MiddleEntity : "link lifetime"
    MiddleEntity ||--|{ SystemEntity : "reference count"
    SceneSystemRegistry ||--|{ SystemEntity : stores
    TemplateBuild }|..|{ SceneSystemRegistry:"check system existence, create relationship"

    TemplateEntity {
        CallbackComponet systemId
    }
    MiddleEntity {
        LinkLifetimeWith templateEntity
        RefToSystem systemEntity
    }
    SceneSystemRegistry {
        Hashmap system_id_map_to_entity
        Hashmap type_id_map_to_entity
    }
    SystemEntity {
        SystemId systemId
        TypeId systemType
    }

Loading

It simulates a many-to-many relationship between template and system. It should be a little simpler than it looks if we have many-to-many relationship.

[SkiFire13]

I can understand MiddleEntity, however SceneSystemRegistry is still unclear.

system_id_map_to_entity looks like it's just the same as SystemId::entity? While type_id_map_to_entity doesn't look correct since there might be different systems with the same type.

[hxYuki]

We may get a BoxedSystem or a SystemId on build_template. I need to connect the two "key" together. And a Relatioship targets to an Entity. So I spawn new entities to save these.

I forgot the SystemId has a field. Maybe I can reuse its entity and get the map eliminated.

there might be different systems with the same type.

What is it exactly? I tried fn callback_1(mut call_counter:Local<u32>) and fn callback_2(mut call_counter:Local<u32>), they have different TypeId. And I copied the assertion in World::register_system_cached to system_value, I assumed the TypeId have same mechanism like type parameter.

[SkiFire13]

fn make_system(a: u32) -> impl System {
    bevy_ecs::system::IntoSystem::into_system(move || {
        println!("{a}");
    })
}

make_system(0) and make_system(1) have the same type but are different systems (running them will produce different outputs). In general closures used as systems cause this issue.

register_system_cached has a ZST check precisely to avoid this issue (because ZST systems are always equal).