VR Panels disrupt the mouse's Target/Hit property

Repro: Use any weapon that relies upon Mouse.Hit, and look at a VR panel. You will shoot at the VR panel instead.

The best solution I can think of is to introduce a target filter list which can be accessed using add/remove methods; because it means that all the VR stuff won’t interfere with the mouse.

Alternatively, if you want to write the code yourself, you can add this feature and then add the VR HUD if the player is in VR mode.

1 Like

We’re working on a fix for this now. It’s pretty unfortunate, I know, but you can add workspace.CurrentCamera to your ignore lists as a temporary workaround.

Thats usually what I do. I just wanted to point this out, because I’ve seen this happening in a bunch of games I’ve played in VR so far.

Are you guys going to make it so SurfaceGuis can be adorned to objects that aren’t descendants of the Workspace?

They already can, you just can’t interact with them because they’re using physical raycasts to determine the 2D position. Which also means that if you have something “physically” in front of them, your input gets blocked.


The fix involves switching how SurfaceGui input works in general. There are some optimizations to be had there. For AlwaysOnTop=true SurfaceGuis like the VR panels, we’re probably going to do an explicit ray-quad intersect test rather than letting the physics engine handle it.

Shouldn’t you just project the mouse’s 3D location onto the SurfaceGui plane to determine the mouse’s 2D location?

… that’s what a ray-quad intersection test involves

Oh sorry, I didn’t see the edit.

Another quick bug I’d like to mention - The UserGui panel doesn’t rotate in 45* increments with the user’s head like the topbar does, it just stays in the relative location that it was activated at. Also, if you open the menu while the UserGui panel is active, it doesn’t come back when the menu is closed.

That’s intentional as far as I know. That way you can leave it up somewhere and look away from it. Also, it was decided at one point to not have the user gui panel come back up after closing the menu. Do you think that decision should be reverted? If so, I can mention it to product.

I would prefer options for it at least.