I cannot find any clearly outlined property that would allow me to affect VR and any search for the term “disable VR support” only turns up results about using VR and trying to switch to normal play.
Earlier I encountered a user floating around in my game with just a hat and two bricks representing the position of their arms. I don’t want that; players should not be using VR in my game. It’s not something the game supports, users are able to go outside of the game’s bounds and things break with its use.
Is there a way to disable VR that flew over my head completely, or how can I remove all scripts related to VR to hamper its use?
From my knowledge, no there isn’t anyway to disable VR support.
However, you could use VREnabled and Kick the player - even if this unfortunately lowers UX.
That’s stupidly silly. We should have the option as to what platforms a user can play on in our games. I don’t understand why an easy way to disable VR support isn’t in. It’s highly intrusive to my game.
I don’t want to rely on VREnabled because that’s a client-side property and it can be bypassed by either modifying your settings on your local filesystem or by exploiting. Unless there’s a server-side way to check for VR use as well, it just won’t fly.
Will wait and see if there’s anything else viable or if there truly is a way to disable VR. If not, it’s a feature request. I honestly do not want to settle for an absurd answer like “you can’t disable VR”.
Just for the sake of clarification, I should ask: is this an exploit?
If it is, that changes my goal completely. I still won’t know what the circumstances are on VR support but I will need to patch this.
EDIT: It’s an exploit and I’ve found the source code for it. I haven’t a clue how to patch it since it’s completely client-sided. That aside, I still need to know if there’s a way to just stop any kind of VR interaction from occurring in my game.
Instead of kicking the player you can see if they have vr enabled then separate them and just have a gui that says “Please disable VR to continue.” as Roblox recently added an option to disable vr easily in the Escape menu.
This may not be a viable solution for the reason that the exploiter does not specifically have to execute their script before the game fully loads, meaning there will be a delay between checking VREnabled when the game first loads up and when the exploiter executes the script.
From what I can understand from the source code you can actually use one of the events under VRService which is fired when a controller is moved, this makes for a low memory check, but certainly isn’t secure as the exploiter could just remove the script.
--// Services
local Players = game:GetService("Players")
local UIS = game:GetService("UserInputService")
local VRService = game:GetService("VRService")
--// Variables
local Player = Players.LocalPlayer
--// Main Code
local function KickPlayer()
Player:Kick("VR is not enabled for this game.")
end
if UIS.VREnabled then
KickPlayer()
end
VRService.UserCFrameChanged:Connect(KickPlayer)
@Proxus@ReturnedTrue
VREnabled is part of UserInputService which must be called from a LocalScript - would this not mean that exploiters would be able to circumvent this by simply removing or modifying the script to not kick them or take action?
After all, VR can break the game and that could very well be the exploiter’s intention.
Yeah that’s quite right, exploiters can circumvent this and there comes the lack of VR support overall.
UserCFrameChanged in a LocalScript within ReplicatedFirst might be possibly fast enough to Kick them however some exploiters have the ability to inject the exploit before the LocalScript begins to run.
@bt5191 So far they haven’t broken the game or damaged anything, the exploit is fairly passive once it’s executed. It’s only really used to annoy people and so far, it’s worked very well on getting me to that point. I’m still devising a way to catch it from the server side, my hope on this is not lost.
@ReturnedTrue Speed wouldn’t even matter. Exploiters would be able to bypass my checks at any given time. I may be able to deter exploiters initially but it’s only a matter of time before they stop blindly injecting and check for any blockers first. If not them, someone will develop a bypass especially if multiple games start to adopt it.
What about using a custom rig? Default characters also have other issues such as holding a tool at different heights based on meshes etc, so in my game I forced a blocky rig on all players as startercharacter, and then add their appearance like colors, clothing, accessories, face at runtime. You’ll notice most games don’t use default, because they’re flawed for everything except maybe those social games.
Creating a custom rig to resolve one exploit is more trouble than it’s worth. It also contains all the issues of standard rigs (I don’t understand why clients are change-authoritative of their characters beyond physics and animation replication) and no benefits of them either (I have to code the behaviour from ground up - see: Luanoid).
This is in no way viable for my use case, especially since the provided list of “issues” are non-problems and easily resolvable. If I were solving a multitude of issues regarding characters and a custom rig was warranted, maybe. It would be more worth my time to patch the VR exploit than to write a character from zero. That just introduces more issues and complexity to my game.
Yeah it kinda sucks that it’s this way, but as I’ve stated above, depending on the game, it has other issues too not just one. You don’t have to ‘create’ a rig, just copy the default (from like animation editor or your own character) and put it in startercharacter, and load the appearance selectively as I mentioned above.
I’ve had issues with mesh characters holding the tool improperly, etc. I use the block r15 rig for all characters, worked out fine. I’d recommend this for all games whose character rig matters.
Though it kinda makes sense that roblox behaves this way, because by putting no rig, you kinda ask for player-custom characters (but yeah they should have a setting).
That isn’t creating a custom rig then, that’s just forking the character. There’s no difference between doing that and using the default character: again, all the problems of the initial remain with no benefits to be gained. It’s more trouble than it’s worth.
Are you sure? StarterCharacter is supposed to force the rig on all players by default; Shouldn’t this mean that they won’t just be head & arms floating, but a proper rig? If that’s the case, then at least it would solve part of the problem.
Or what about cloning a rig model to workspace and doing Player.Character = model with CharacterAutoLoads turned off?
Unless I’m wrong (which I don’t know for sure), both of these should ensure the player’s character is a proper rig with proper movement.
But in any case, I realize this is not a proper solution, and agree this should be fixed.
I think if there is no way to disable VR, you should submit a feature request. I think most of us would like to see this added, as not all games are meant for VR.
That won’t change anything. It’s copying and pasting the exact same rig that’s used internally to build the character. The exact same exploits are still applicable. I’m not sure how you think that copying and pasting the character would make a difference in this scenario. StarterCharacter doesn’t force characters to a mould, it determines how the character is built.
The VR exploit don’t use any pieces of the character in the first place, it’s based off of their accessories and is fully client-sided. That’s why worrying about anything other than how to combat this from the server is futile. Roblox’s replication model is flawed and allows client-side changes regardless to propagate if done on the character, so I need to take advantage of that flawed model and check what the client’s replicating server-side if at all possible.
I probably will end up submitting that feature request regardless of if I resolve the exploitation issue or affirm that there really is no way to disable VR support for games. Thanks for raising the suggestion. We as developers should have full choice as to what platforms our games can be ran on. We have it partially: don’t understand why a toggle wasn’t natively supported from the start.
Sorry for the bump, but over a year on from this post, this is still an issue. I just had a player submit a bug report because the fighter they were flying in didn’t aim its weapons properly in VR. Before seeing that bug report, I had no idea you could even use VR in my game. I’ve looked all over, and can’t find anything that explains how/if you can completely disable VR for a game. This forum post is the only thing I’ve found even acknowledging the issue. I’ve tried editing StarterPlayer and setting DevComputerCameraMovementMode to “Classic”, and setting DevComputerMovementMode to “KeyboardMouse” in the hopes that might force it, but as I don’t have a VR headset there’s no way of confirming whether this has worked.
Other than that, I’ll try the method of just kicking a player from the game when they try to use VR, or something like that. But there really should just be an option for it somewhere, like in Game Settings…
Please create a feature request instead, bumping this thread won’t yield a better answer. The intent of this thread is asking if there is a way to do so, it’s not requesting for a method to be added. As there is no way to disable VR natively without kicking if VREnabled goes true (and therefore a client-sided solution which is bad), it’s a missing feature and therefore belongs as a feature request.
