Support for working with local elements
Is your feature request related to a problem? Please describe.
Local elements are elements that exist outside of the synchronized part of the world data model. Currently, these are only used by internal systems and aren't really usable by creators for their own use-cases. They could however be quite powerful, especially for systems that need to interact with parts of the world, but don't need to be part of the world themselves. (For example local avatar menus / overlays)
Describe the solution you'd like
I'd like local elements to become a feature accessible to creators. Creating and managing elements that exist outside of the synchronized part of the world data model.
Describe alternatives you've considered
Generally the alternative right now is always having the creations exist in the synchronized part of the data model, but only locally enabled for one person.
Additional Context
I noticed this was brought up as an idea in https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/4205, but I couldn't find a GitHub issue about it yet. I also planned to request this in the past, and now I got reminded to do so!
Requesters
No response
Ran into the local slots with @colintimbarndt's head pat detector when it was using a haptic collider - turns out trying to write the other (hand) collider's slot into a synchronized variable :D
I've been thinking some more about this, and I do think this will also have pretty significant performance implications in the long run. Right now I know that a LOT of people build custom "HUD" systems into their avatars. I've sort of been experimenting with making one myself, but feel hesitant about actually using it in public as the amount of functionality would bloat up my avatar quite significantly, and I don't want to do that for something only I would see. Having a mechanism to make those types of HUDs completely local would entirely remove those concerns. I think depending on how easy this would be to set up this could provide a very simple tool for creators to significantly optimize those kinds of systems.
I'm curious from a technical perspective, what sorts of mechanisms / prerequisites would be required for this? Would it be "only" expanding the inspector to be able to interact with those hierarchies, or is there more to it?
I think all the internal stuff is already there, since multiple systems already use local slots (haptics, UIX, ...), so the inspectors would be the main point 🤔
I mean you'd need mechanisms to allow the creation and deletion of such slots and how do you save an object which contains local slots. I don't think the file format supports this currently. You'd also have issues with sharing such items. If I spawn an item with local slots and you try to save it, you'd practically delete all the local slots in your version.
Ah yeah, that's true. Currently all the local slots are created on the fly by components on "global" slots