Resonite-Issues icon indicating copy to clipboard operation
Resonite-Issues copied to clipboard

Support for working with local elements

Open JackTheFoxOtter opened this issue 8 months ago • 5 comments

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

JackTheFoxOtter avatar Apr 30 '25 09:04 JackTheFoxOtter

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

Banane9 avatar Apr 30 '25 10:04 Banane9

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?

JackTheFoxOtter avatar Nov 25 '25 10:11 JackTheFoxOtter

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 🤔

Banane9 avatar Nov 25 '25 10:11 Banane9

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.

art0007i avatar Nov 25 '25 11:11 art0007i

Ah yeah, that's true. Currently all the local slots are created on the fly by components on "global" slots

Banane9 avatar Nov 25 '25 11:11 Banane9