For transparency, here is our thinking:
When you collapse the UI, BottomBar becomes the only visible UI. Just like the TopBar before which it replaces, it always has to be accessible. Security features but even just the options and leave buttons need to be easy to reach for users.
What we do consider is a blend-out of the bottom bar when you look away from it, would that help with your concerns ?
This should be fixed in last weekās release in 562. Purchase Prompt will be automatically dismissed if UI is collapsed, so you wonāt be able to purchase anything without seeing them. Also if any Purchase Prompt pops up while UI is collapsed, the prompt will force the UI to expand and show the prompt. Hope this could address your concern!
I love the design! I do think that there should be an extra button to like hide the bar since it sometimes gets in the way of gameplay.
The Bottom Bar should automatically fade out and hide when collapsed out of view now.
When you look down, it comes back into focus.
Let me know if you have any more feedback on the behavior.
Thanks, this seems like a good compromise. It would be nice if it was possible to hide it entirely, maybe moving the UI hiding functionality to a button on the bottom bar and using the physical menu button to hide the bottom bar as well, but that aside I understand that for security features it does need to be easily accessible.
Heya, im using a mod for the Rift S that removes Oculus dash and boots straight into steamVR. The problem is that when trying to load into roblox, it hooks onto the oculus openXR/openVR (dont know the difference) runtime and steam doesnt load it onto the screen/ steamVR environment. Can we please get a way to change the runtime manually? And if you cant do this with an in-game menu, can you at least provide steps (if there are any) to get it working ourselves. Thanks.
Technically this is simple : create a selection for the backend, pass it into the engine and pick accordingly.
The tricky part is where would this selection live?
We probably wonāt make space in the menu for this, so the most likely option would be a parameter that you pass to the executable.
a parameter would be ideal tbh
We are releasing a patch soon that updates our VR backend to OpenXR and solves this problem as well. When using OpenXR, you select which app will run it (Oculus or SteamVR) .
Cool! Will this be an update just for the client, or will Studio be affected too?
Iām on a desktop with one GPU so it didnāt affect me, but there was basically a bug on systems with multiple GPUs like laptops where Studio couldnāt find a connected VR headset, no matter what. I donāt think the client had trouble detecting headsets, only Studio for some reason.
I have a 3 step answer for this :
- If there is a bug in Studio, please post a report on the dev forum, we are working through these
- The VR architecture runs the same code in Studio as the client, so any changes should transfer.
- However Iām myself only working on the client, so if there are Studio specific issues then we donāt always catch them.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.