-
-
Notifications
You must be signed in to change notification settings - Fork 31
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
Add support for full component paths, to avoid collisions from short_names #166
Comments
Sorry @janhohenheim , I reread your message a few times, and I still don't understand either the issue or what you mean with the "collapsible grouping" ? |
This: Foo- ObjectiveBar- Objective |
Ok, but what is the actual issue ?
|
It doesn't really matter, as long as there is a way to register and differentiate two components with the same name. bevy_core_pipelinecore_2dcamera_2dCamera2dother_bevy_cratesstuffmy_gamefooObjectivebarObjectivethe obvious issue here is that the nesting can get quite deep for Bevy types. Maybe we'd have to filter those and put them all into a single flat group called "Bevy". Alternatively, I can also imagine passing a group along as metadata for the registry export, e.g. as extension methods on app
.group_type::<foo::Objective>("Foo")
.group_type::<bar::Objective>("Bar") The downside here is that the registry is no longer a simple dump of reflection data. |
My core issue is that I want to organize my Rust code into different modules that all don't know about each other. However, the Blender addon effectively forces me to use only unique names for components that I wish to use in the Blender UI, so there is a weird coupling between modules now. My modules |
Does this make sense now? Sorry if what I wrote before was confusing :) |
Ah yes, It makes sense now ! :)
|
Good point :/ |
Some more thoughts:
|
Apparently the same limit exists for other names as well: https://blenderartists.org/t/material-name-character-limit-63/1146620/18 |
As far as I can tell, the 63 char limit only exists on the names of the properties. What if the addon used only a single property called "bevy_components" that contained a RON array of all components with their full paths? |
Yep, ran into that one multiple times while developing bevy_components (and the reason for the first breaking change), sigh
...hmm packing it all into one could work, but yeah, waay too much work for now for all the rest. |
Fair enough, it's not that important. As I said on Discord, I'm very happy with the workflow as-is, even if it never supported any additional features from now on ❤️ |
Say I have two quests
Foo
andBar
. They might both have a componentObjective
, but in order to disambiguate them in the Blender addon, I have to name themFooObjective
andBarObjective
. If we instead had some kind of collapsible groupings, I would not have to do this.The text was updated successfully, but these errors were encountered: