-
-
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
Expose SystemMeta
fields
#5497
Comments
I'm on board. Can you make a PR? Very curious what your plans are here though. |
Sure!
I'm working on a deterministic entity ID allocator (in addition to |
I'm not sure I want users to be implementing I suppose unless/until we can work out a nicer API for dynamic components it's inevitable. For your use case, we cannot provide the guarantee that the SystemMeta's name is unique per system as you seem to require it to be (since it's built on https://doc.rust-lang.org/std/any/fn.type_name.html) - the system name is absolutely not guaranteed to be the same across compilations too - e.g. for different platforms (or even within the same compilation, going by a strict reading of the docs). You need to do your own book-keeping. E.g. with a |
Ping @BoxyUwU and @TheRawMeatball for opinions here. I share @DJMcNab's concerns, but I also don't like how the trait is public (and not sealed) but not feasibly implementable. |
Yes that's unfortunate, but I've never run into problems [yet]. I'd prefer eventually using a stable TypeID (like #32). Nonetheless, it'd be nice to have the name and access information on-hand for debugging, although I'm sure you can get it from Schedule.
Yes, I see now that locals can be created with In the past, I've used a hash of a type's AST (along with the definition file location), but it's only marginally safer as a unique, binary-agnostic ID than |
This should be, but I don't think we explicitly make any guarantees to this effect yet. |
I'd be OK merging such a change until we make a proper API for creating dynamic SystemParam s, though I still think the ideal version of such an api would involve
|
Just ran into this again, so I pushed some changes in #7119 . Some comments/questions:
|
What problem does this solve or what need does it fill?
bevy_ecs
' internal implementation of the defaultSystemParam
s useSystemMeta
to initialize their states. Yet, only theis_send()
field accessor is public to end-users and all other fields arepub(crate)
.Given that it's possible to directly implement
SystemParam
(andSystemParamFetch
) for user-defined types in anunsafe impl
, these fields should be exposed to advanced users.What solution would you like?
Add unsafe mutable and safe immutable accessors for
component_access_set
andarchetype_component_access
, and immutable accessors forname
andlast_change_tick
.The text was updated successfully, but these errors were encountered: