-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Scene serialization doesn't work without field types being registered #8415
Comments
Original messageThis is actually expected behavior. The scene (de)serializer can only handle components and resources that register The fix here is to just register all types that need to be (de)serialized. It's a bit annoying, but it's the best solution we have given Rust's current tooling. So in this particular case, the solution would be to register And for reference, bevy/crates/bevy_core/src/lib.rs Line 83 in c488b70
But it doesn't need to be for Edit: Seems I'm wrong here. I mistakenly thought Still, the solution here is to just register the type in |
So it is expected from the user to register all the types their crate uses including the "nested" types? I am not an experienced library designer and I don't know the reasoning behind this decision, but tracking down if all types are registered can get difficult quick I would like to do the fix-PR if that's ok and will check if any other type in |
Yeah that's currently the requirement, and is likely to stay that way until a better solution is found. The main issue is that other crates that "solve" this use life-before-main and linker shenanigans to get it to work, which is not something we want to support right now. Mainly due to the fact that we don't build our reflection logic on top of a "hack" and we want the engine to be cross-platform (these other solutions break on platforms like WASM). As far as nested types go, there is #5781 which adds the ability to recursively register a type's fields (review very welcome on that PR btw 😉).
Sounds great, thank you! |
I am just an inexperienced user, but I can provide some feedback if it's welcome! |
"Experienced" or not, review is generally pretty welcome in this repo. Even if just asking a clarifying question or making a simple suggestion. It's very appreciated! 😄 |
Bevy version
Bevy
0.10.1
and c488b70 (latest commit onmain
so far)What you did
Consider the following code. Here I am trying to serialize just one entity from the scene -- a text entity I spawned during startup.
For bevy 0.10.1
For bevy 0.11.0-dev (c488b70)
What were you expecting
The app should have been working and spamming "yes" without any problems, since
bevy_text::BreakLineOn
implements all the needed traits. The struct containing it (bevy_text::Text) is registeredWhat actually happened
Both respective versions crash with a message saying that
bevy_text::BreakLineOn
isn't a registered type.Additional information
My guess is that the serialization implementation can't somehow poke the the serialize implementations of the fields without looking at the type registry.
At first I thought that this is a design choice. But it seems that it's not, since
bevy_text
is an official crate andBreakLineOn
isn't explicitly registered.Vec3
seemingly isn't explicitly registered either. Yet, when I do the same test with a loneTransformBundle
, everything just works.Force-registering
bevy_text::BreakLineOn
fixes the issue, but that is going to blow the amount of needed to plug things into bevy's reflection.The text was updated successfully, but these errors were encountered: