Next Thursday (10.11.2018), provided no blocking issues are uncovered during QA, we will be shipping the new structure of Roblox PlayerScripts. In response to some loss of functionality the first time we deployed the new scripts, the structure has changed in such a way that developers will still have access to things they were directly requiring some of our modules for, such as GetMoveVector() and Enable()/Disable() for controls.
The new structure looks like this:
At the top level of StarterPlayerScripts, there is a LocalScript called PlayerScriptsLoader, which does nothing more than require the PlayerModule ModuleScript. The PlayerModule script requires and instantiates CameraModule and ControlModules, which manage the camera and character controllers respectively.
What’s new is that PlayerModule’s instance exposes getters for the camera and character control managers, and PlayerModule can be required by any developer LocalScripts to get access to all the PlayerScripts internals. If you require this module from your own LocalScript, you can freely delete the PlayerScriptsLoader stub.
Games that will be compatible:
Generally speaking, when these new scripts are turned on, the games that will be fully compatible without need for developer changes will be those which:
Use the default Roblox camera and controls, and have no camera or character control logic elsewhere (e.g. StarterGui LocalScripts, etc.)
Have a CameraScript or ControlScript (or both) in StarterPlayerScripts. It does not matter whether they are forked copies of the Roblox scripts or custom LocalScripts. Only the names matter. Games with these scripts will not automatically fetch the new player scripts.
Games that will not be compatible:
- Any game which tries to directly acquire references to the current player scripts structure, including requiring MasterControl to access moveVector or Enable/Disable.
Games which might have issues:
- Games with custom camera or character controllers that manipulate CurrentCamera.CameraType, or any of the camera or character control properties such as DevComputerCameraMovementMode, etc. These games are more likely to hit edge cases where the new script system’s behavior is not necessarily wrong or buggy, but does not exactly match that of the previous generation of scripts.
If you believe your game may have issues, or you just want to avoid any potential issues on update day, what you should do right now is fork our existing player scripts. In the past, we’ve discouraged making copies of these scripts, because it means a game will not get updates, but these two scripts (and their children) are now at the end of their run and will not be updated again. If you know how to copy-paste the scripts from a Play Solo session, that is the easiest way, otherwise I’m attaching an rbxl that has these scripts in StarterPlayerScripts. Once the new scripts ship, the Play Solo trick will not work as easily.
OldPlayerScriptsFinalVersion.rbxl (139.0 KB)
Pre-release versions of the restructured scripts are here, with a fix for poppercam classic:
Note: These pre-release scripts should be used for previewing and compatibility testing only. Developers should not publish these scripts to a live place or start coding against them as the internals are subject to change as these go through the QA process.
Prelease 3 Includes a fix to the CFrame Interpolation vs. PopperCam issue, in CameraModule:Update(). If you’re experiencing this bug, see if this version fixes the issue (it should):