Open Zyzyl opened 2 years ago
shadowpanther
commented
2 years ago For context, we have the option to hide custom submenus natively (from the ContextMenuSubmenu component), but not the root menu item and not the root context menu itself. Also, this is not a world/session-wide setting and requires to be set on the menu source itself.
Ruikio
commented
2 years ago Being able to natively just hide the menu would be beneficial for things like streams, videos, sessions that require immersion. Allowing for quick access via the radial menu and not showing up on video.
Frooxius
commented
2 years ago We could definitely do this, since we already have a mechanism for hiding it, so it's just extending that with new rules. So if I understand correctly we'd have two mechanisms:
@Ruikio Would that mean hiding it on the camera view even for the person streaming? We could do that the way badges and lasers are hidden as well, so the streamer can see their menu in-game, but it doesn't show up on stream, although it's a bit separate mechanism / setting for that.
shadowpanther
commented
2 years ago I guess the third separate toggle might be on the user/avatar to hide their own context menu entirely from everyone else for privacy considerations.
Zyzyl
commented
2 years ago @Frooxius I'm mainly asking about situations where it would be good for a user to be able to see and use their own context menu, but that they should not be able to see the context menus of other users. I think that could reasonably be handled either at the world/session-level or as an opt-in/opt-out system much like the current nameplate visibility facet.
I see a potentially separate use case for a world-level or session-level block on context menus being usable at all which users could not opt-out from.
Ruikio
commented
2 years ago We could definitely do this, since we already have a mechanism for hiding it, so it's just extending that with new rules. So if I understand correctly we'd have two mechanisms:
- World could specify that they should always be hidden within that session. This would be for immersion worlds and so on.
- User would have a setting to forcefully hide them everywhere. This would be if they just don't like seeing them.
@Ruikio Would that mean hiding it on the camera view even for the person streaming? We could do that the way badges and lasers are hidden as well, so the streamer can see their menu in-game, but it doesn't show up on stream, although it's a bit separate mechanism / setting for that.
Wait I didn't even consider for it locally on stream camera. Wait that would be even better. Wait why is this such a good idea. I forgot we can exclude things from camera view. Roleplay streamers as an example could keep the immersion for their viewers.
This is a great idea. I dig it.
Frooxius
commented
2 years ago @Zyzyl Would the two options I suggested satisfy that or am I missing something?
@shadowpanther You can already hide custom menus, but I'd strongly advise using it for privacy. Even when hidden, the context menu and its actions are still part of the world and its data model. For privacy put the UI in Userspace, which is running separately from the world.
Zyzyl
commented
2 years ago Yes, I believe your suggestions would satisfy those use cases. Thanks for the consideration!
Is your feature request related to a problem? Please describe.
The radial context menus are generally really useful and helpful. However, there are some contexts where the current behaviour of making them visible to everyone when opened may be undesirable.
The default global visibility of opened context menus may be undesirable in worlds aiming for greater immersion. An example might be a roleplay map where users may have custom buttons/functions in their menu (so the menu should not be completely removed), but it would be preferable for other users not to see opened context menus. Similarly a cinema world may wish to prevent context menus being globally visible to avoid viewing experience being disrupted. I assume this would not present any fundamental issues since it is currently possible to only locally show menus when navigating custom submenus.
Relevant issues
https://github.com/Neos-Metaverse/NeosPublic/issues/503 is a related request for laser visbility where many of the comments focused on immersion etc.
Describe the solution you'd like
A way to specify whether context menus should be locally or globally visible. Default should be the current behaviour where menus are globally visible.
One possible world-level solution would be to add an option to the CommonAvatarBuilder component.
Another possibility would be to make this an option local to each user (similar to how the hide/show namebadges facet works) rather than making it a world-level control. That way users could flexibly choose whether they wished to see other people's context menus.
Another non-world-level option would be to make this controllable for all users at the session level by e.g. Admins or the host.
Describe alternatives you've considered
It is possible to localise context menu visibility, or outright delete them, with LogiX. However this relies on searching for the Context Menu slot under a user's root slot. Searching for slots whose names users have no control over is explicitly called out and advised against in https://wiki.neos.com/Things_to_Avoid#Names_or_Structure_of_a_User_Root.
Additional context
In addition to determining the local vs. global visibility of context menus, there may be situations where it would be desirable for only some of the standard menu options (e.g. locomotion switching but not Undo/Redo) to be available. An example might be a game world where being able to undo grabs would not make sense for the gameplay. Furthermore, there may even be situations where it would be desirable for context menus not to be available at all e.g. hardcore roleplay worlds where all intented interactions / behaviours are implemented via world elements or custom UI.
These are not specific situations I'm concerned about right now, but I mention them as it may make sense to cover these various possibilities with a common approach.