I’m encountering issues where the activeController can be nil on spawn and not change to an actual controller. This seems to happen when the player’s character is morphed into something else upon spawn(?)
Seems to be a race condition because it doesn’t happen consistently, only about 20% of the time when LocalPlayer.Character changes almost immediately after set to the default character.
I’m going to have to fork the new player scripts because of this, because I need a fix right now, can’t wait X weeks, but I hope this will be eventually addressed.
(If you would like a repro file please DM me here, I unfortunately don’t have time to make it minimal and it and it’s covered by an NDA)
@AllYourBlox There is a slight problem with the enable/disable.
Those two scripts are parented to a character depending on the buttons we click on the GUIs it will disable and enable the movement of the player.
ControlModule is required for both scripts.
ControlModule:Enable()
ControlModule:Disable()
The Module allows you to disable but when you click to re-enable the module it doesn’t allow you to move, I think this is caused by having two scripts instead of one. Shouldn’t module’s functions be shared through scripts?
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.
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).
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 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.
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.
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
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.
