I have a few additional notes regarding this coming update.
Firstly, we’d like to encourage you not to add the end-of-life copies of the old player scripts to your game unless you have reason to believe your game is going to break. We’re recommending adding these only to games that are known to have issues with the new scripts, in order for the developers to buy time to make their game compatible with the new format. You can copy-paste the 4 scripts from the pre-release rbxl linked above into your game’s StarterPlayerScripts to check compatibility. Just as with making forked copies of the scripts prior to this update, having copies of these old Roblox player scripts in your StarterPlayerScripts folder will prevent you from getting any player scripts automatic updates.
Secondly, developers who include these legacy scripts in the coming weeks should do so as a short-term solution only. Games should be migrated to the new structure as early as possible while the functionality between old and new is very similar the corresponding parts are easily identified. As the new scripts evolve, migration will naturally become more difficult.
Thirdly, we have exposed getters for the camera and control manager classes, which give full access to their class members and methods.
PlayerModule:GetCameras() -- gets reference to the camera manager instance
PlayerModule:GetControls() -- gets reference to the character control manager instance
This is a short-term solution for those developers that needed immediate access to the following specific functions of ControlModule that used to live in MasterControl:
ControlModule:GetMoveVector()
ControlModule:Enable()
ControlModule:Disable()
That said, no other functions within the player scripts modules are guaranteed to remain available with their current names. We’re going to follow up this initial release with an update which exposes more functions and clearly separates the members of these classes into Public API members whose names and availabilities we will commit to supporting, and private, internal members that could change or go away at any time. We are still deciding how best to do this (e.g. by naming convention, public API table, etc.) For now, all methods other than the 5 listed above should be considered to be in this latter category of members whose existence should not be relied upon.