I can’t use my gamepad at all in Studio now. If I touch it while playtesting, I can no longer move my character, even if I try using the keyboard again, until I close out and start a new playtest session.
2 Likes
Any chance you’re mistakenly requiring the ControlModule in StarterPlayerScripts rather than the one that is running on your player at Players.LocalPlayer.PlayerScripts.PlayerModule.ControlModule? When a ModuleScript is copied with Clone(), the clone and the original are not recognized by Lua as being the same script, and they will return different instances.
That said, we are not going to support developer scripts requiring ControlModule directly. The supported, future-proof way to access Enable() and Disable() is to require PlayerModule and use the PlayerModule:GetControls() function to get the running ControlModule instance. I created the GetCameras() and GetControls() functions specifically to provide a layer of indirection so that we have the freedom to do future restructuring and re-organizing of the player scripts modules underneath PlayerModule without breaking games the way the removal of MasterControl did.
I don’t just mean moving modules around either; for example, right now CameraModule returns a singleton instance by return CameraModule.new(). In the future, it’s possible (likely even) that this module will return a table of its public API methods, rather than an instance. Any code requiring CameraModule and expecting a singleton instance will break, but code using PlayerModule:GetCameras() will still work as expected (since it will have been modified to return the running instance).
2 Likes
We haven’t been able to reproduce this. Is there anything special about your setup? The ControlModule should be automatically switching back to Keyboard and Mouse (the Keyboard control module) any time the keyboard or mouse is used.
PlayerModule:GetControls() returns nil. In the old module enabling and disabling the controllers would not lead to anything breaking. What would I exactly do to make it so I can enable and disable the controllers from different localscripts requiring the module without having the bug of not being able to enable it again?
How would you go about enabling the controllers when resetting? It seems to break the controllers sometimes when set to enabled.
You have to require the module to use it’s returned functions.
It is.
You require’d the ControlModule, not the PlayerModule. The error that you are seeing is because you are trying to perform “:GetControls()” on the literal PlayerModule instance instead of the returned code.
One of my old feature requests about controlscripts has been gaining attention again for some reason (it just reached 100 likes)- any chance this could be considered for the PlayerScripts refactor? Adding a built-in way to let us have the default character controls’ arrow keys act like WASD (or vice versa) without having to fork would be handy. Certain games use fixed cameras & the arrow keys only let you move up & down in that case, and a default setting to have the camera move with the mouse without having to hold right-click (without being a toggle-able, auto-strafing mode like shiftlock) would also be handy for creators and players alike.
I know this has been brought up, but Tweening the Camera CFrame is still broken when I try to test it in Play Solo… Is there a fix I’m not seeing?
The problem is I need the camera to zoom in on something, but when I try to do that it seems to bounce forward:
https://i.gyazo.com/b5305b133f63270f80bd25712187ed16.mp4
It didn’t do this before the player scripts update, and I saw in a bunch of threads from about 2 weeks ago that this was supposed to be fixed, has that happened yet? I haven’t seen any mention of it, and it seems to work in a real game, but testing it is really annoying…
It’s an issue with poppercam as far as I know, it compeltely wrecked a few of my game’s aspects as well.
So I hope a fix for this will come out very soon.
1 Like
Like the others above, you are also using require on the ModuleScript in StarterPlayerScripts. Requiring the modules in StarterPlayerScripts is going to start second copies of these controllers running and conflicting with the ones that are already in use (the ones Clone()'d to Players.LocalPlayer.PlayerScripts). Scripts in “Starter” places like StarterPlayerScripts, StarterCharacterScripts, and StarterGui are not executed, the client always clones scripts from these locations onto your player, and those are the copies that are actually executed.
1 Like
As others have already pointed out, your screenshot shows that you are missing a require. Specifically, the line
local PlayerModule = PlayerScripts:WaitForChild("PlayerModule",10)
should be:
local PlayerModule = require(PlayerScripts:WaitForChild("PlayerModule"))
Just a heads up, since it seems to be a fairly common mistake to make–requiring modules from StarterPlayerScripts–and the resulting bugs are difficult to diagnose if you don’t know what you’ve done wrong, I’m probably going to add a safeguard against this to the top of each of the player scripts ModuleScripts, something like this:
if script:FindFirstAncestorOfClass("StarterPlayerScripts") ~= nil then
error("Do not require modules directly from StarterPlayerScripts, require the copies cloned under Players.LocalPlayer.PlayerScripts")
return nil
end
4 Likes
We sorted out the require yesterday but the main problem is to re-enable the controllers again as it seems to break. Let’s for instance say that you disable the controllers but then a player kills you and you die. The controllers still will be disabled after respawn. Even if there is a localscript that replicates inside the character each time you spawn in, that enables the movement using the ControlModule:Enable(), it seems to break every so often and still make the player not able to move. This is only fixed once the player rejoins. Would the right thing to do be to require the current controllers from playermodule and then enable it? That seems to also break sometimes.
Thanks.
1 Like
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.