So a bit of background, Click to Move movement mode completely breaks my vehicle chassis for some reason. I haven’t the foggiest idea why it behaves like that, but disabling Click to Move seemed like the obvious route to fix this. Boy was I wrong, disabling Click to Move is completely and entirely impossible because the API surrounding it doesn’t seem to work at all.
First off, the client does not respect StarterPlayer.DevComputerMovementMode half the time. On a blank baseplate, this setting only seemed to work on rare occasion, and on a live game of mine it never works. Any setting of either the StarterPlayer property or the Player property allows the client use the settings menu to toggle between whatever setting they please as if it were set to UserChoice. Setting the property via the client throws a permissions error and setting it via the server seems to have little effect. To make matters even more confusing, sometimes the client gets stuck on a random mode that isn’t set by either DevComputerMovementMode properties. Toggling between settings in the settings menu only sometimes gets this unstuck.
I’m at a loss for what to do, because of this I’m dealing with a subset of players set to this movement mode who are essentially barred from driving my vehicles because the control scripts don’t play nicely with the chassis scripts and there’s no way to force them to a movement mode that actually works. I’ve been playing with this API for a couple hours and can’t seem to produce any consistent results aside from it doing the last thing I expect it to, I’m convinced this isn’t on my end and that the API needs a serious rework.
The shenanigans have been reproducable on a blank baseplate. Here you can clearly see me stuck in Click to Move despite having all appropriate properties set to KeyboardMouse.
Setting both properties back to UserChoice reveals that it was still stuck on Click to Move the whole time, it’s as if revoking UserChoice only revokes the ability to switch your mode, as opposed to being able to force set it.
3 Likes
I noticed this when I was documenting the current player scripts behavior and deciding where the new playerscripts should retain legacy behavior for backwards compatibility reasons. The good news is, I agree with you that this is currently broken, and when the new playerscripts structure is enabled for everyone, the developer choice to force a specific movement mode will be respected: setting KeyboardMouse will not allow ClickToMove to be used, and forcing ClickToMove will not allow WASD control of the character. The space bar will still make the character jump, as ClickToMove does not provide an alternative.
The new player scripts are going to be available very soon. We are in the final testing phase where these scripts are enabled for a subset of live games that have opted in.
Anyone who will be keeping and maintaining forked copies of the older playerscripts will not automatically get the fix for this issue, but if you fall into that case I’d be happy to show you what small edit you can make to disable ClickToMove entirely.
1 Like
How soon is this change coming? It may be worth it for me to temporarily fork the current control scripts to disable click to move until the fix goes live.
Hopefully, if testing doesn’t find any showstoppers, less than 2 weeks. The ControlScript being replaced is likely at its final revision, so forking it is not going to be of much consequence. Find line 299 in ControlScript and comment it out (you can comment out the whole if-then):
if FFlagUserNoCameraClickToMove and UserMovementMode == Enum.ComputerMovementMode.ClickToMove then
--ClickToMoveModule:Enable()
end
The old playerscripts actually instantiate all the controllers, and the ClickToMove module is running concurrently with the Keyboard module. You just want it never to be enabled on desktop. If your game is on mobile too, you might want to see if TapToMove breaks your vehicles too, as it uses the same module and commenting out this line only stops it running on desktop PCs.
4 Likes
OK, I think there is something going on apart from just the DevComputerMovementMode not being respected. Is it possible you have some older camera or control script in this place? I ask because in Ultimate Driving: Westover Islands ClickToMove is active all the time, even when I have not enabled it as a user choice (My settings are on Keyboard (Default)). I can’t get this to happen in any other Roblox game. Do you have any LocalScripts or settings anywhere else that could be forcing ClickToMove on?
There are no old camera scripts, control scripts, or instances of me setting anything to ClickToMove anywhere in Ultimate Driving. I have a hunch what you’re experiencing is ClickToMove getting stuck as your movement mode despite the settings menu indicating you’ve toggled it to something else, and I was able to reproduce that on a blank baseplate. I haven’t the foggiest idea why Ultimate Driving would be any different as I’m fairly certain I’m not doing anything screwy with the controls anywhere.
