New Player Scripts are coming (10.11.18), and how you can prepare

[AllYourBlox]

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:

BaseplateWithNewPlayerScripts_PreRelease2.rbxl (128.0 KB)

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):

BaseplateWithNewPlayerScripts_PreRelease3.rbxl (123.9 KB)

[Aorda]

Oh God, better get ready to update my skydiving script!

[colbert2677 (ImagineerColbert)]

Oh good lord for a moment I thought the PlayerScripts container itself was changing, but I realized that there is no real reason to change it that I know of. The change only applies to the former CameraScript and ControlScript.

I never really found a reason to modify these scripts, but to be frank the structure looks better than what it was before.

how to not read 101 with me

[buildthomas]

Thanks for the heads up!

It’s unfortunate that we can’t really dynamically switch over onto this, because if you update your code to rely on the new method, it is still broken right now, so the transition is really awkward. I guess we’ll have to fork until the update is fully pushed through, which is not ideal, but it works.

[nurgenius]

My 10 day old coding brain thought that using usual LocalScripts under PlayerScripts and CharacterScripts will stop functioning. Glad to know that this isn’t the case .

[GunsBullets]

Not super happy that this is announced AND will take place all during mid terms for most colleges, especially since a good chunk of top devs are college students…

[wravager]

Doesn’t affect all of us thankfully like a path change would, I dont even use StarterScripts, I delete them when the player loads in. Pretty sure a few other games do the same.

[AllYourBlox]

Attached here is a Baseplate with a pre-release copy of the new Player Scripts. Note that the ControlScript and CameraScript included in this file are Disabled, empty script instances that only exist to prevent the automatic addition of the old player scripts (which will continue to be added until the new scripts are released on production). These two scripts are not a part of the new scripts structure.

BaseplateWithNewPlayerScripts_PreRelease2.rbxl (128.0 KB)

[Maximum_ADHD]

Correct me if I’m misunderstanding, but are you saying the system will not load if your own forked CameraScript & ControlScript are present, or are we required to take action on this in order to avoid issues in our games?

[AllYourBlox]

@Maximum_ADHD

Correct me if I’m misunderstanding, but are you saying the system will not load if your own forked CameraScript & ControlScript are present

If your game has a LocalScript in StarterPlayerScripts that is named either CameraScript or ControlScript, your game will completely opt out of getting the new player scripts. The only games that will automatically start using the new player scripts are games that don’t have LocalScripts with either of these specially-handled names.

Just to clarify, for the vast majority of games which don’t fork either of these scripts, this update to the new format should be as smooth and issue-free as any other player scripts update. The games at risk are the few that do things like directly require our current module scripts (most often MasterControl) from a developer LocalScript.

[Maximum_ADHD]

Alright that sounds good. My only concern at the moment is with how my game is handling player scripts. It’s a bit of a hack.

Since there are ~25 places in my game that use the same codebase, I use a ModuleScript to distribute my games framework with a single call to a MainModule from the site ( AKA require(assetId) ), so I don’t have to manually leave copies of the game’s codebase in each place.

My framework does override the default camera script, but the module has to be loaded in first before those instances appear, and that can take some time depending on the connection.

If I need to tweak anything to work around this, I’d be fine with doing so. I probably should opt into using the new system anyway because it’ll be easier to add my own extensions to it.

I can follow up on this privately if needed.

[Maximum_ADHD]

One issue I’ve observed so far.

If you zoom the camera all the way out, push it against something so that it moves inwards, and then try to zoom in while the popper cam is trying to restore the zoom level, the camera forgets where the zoom presently was and zooms relative to where it “should” be.

[rbx_lua (Matthew)]

You know it’s something serious when Roblox gives you a date…

[subcritical]

This will be fixed when we turn on the new poppercam implementation.

[chesse20 (ChesseThe FluffyWasp)]

Wow I can’t wait use all these cool new player scripts .

[AllYourBlox]

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.

[xuefei123 (Xuefei)]

This releases on my birthday!

[AllYourBlox]

I updated the pre-release file this morning with a fix for classic poppercam (not CloneTroopers issue) that was due to the file having a version mismatch with the Poppercam_classic module.

[evaera]

Hello, thanks for your work on this update. While perusing the pre-release file, the first thing I noticed was this pretty extreme line spacing:

It’s double-, triple-, and even quadruple-spaced in places, seemingly at random. After digging in a bit deeper, I found several more inconsistencies and nonstandard practices within the code contained in this update.

As a Roblox developer, I think it is reasonable to expect code like this that is written with the intention of allowing us to fork it to conform to a more standard style guide. (It’s not even self-consistent )

List of grievances (with one example cited, though they all occur in numerous places):

• Inconsistent and nonstandard double-, triple-, and quadruple-spaced lines (LegacyCamera L52)
• Mixing use of double and single quote marks (LegacyCamera L47)
• Inconsistent spacing of infix operators (Poppercam L36)
• Inconsistent and unbalanced spacing in parenthesized expressions (leading and trailing space mismatch) (BaseCamera L57)
• Inconsistent use of spaces following a comma in a function call (BaseCamera L71)
• Too many statements occurring on a single line (BaseOcclusion L9)
• Unnecessary function calls in several places ( math.rad(0) ) (OrbitalCamera L33)
• Inconsistent and unnecessary square bracket syntax when accessing and setting table members (OrbitalCamera L59)
• Use of deprecated Instance methods (OrbitalCamera L215)
• Debug print statements left in source code (OrbitalCamera L437)
• Unnecessary use of parentheses wrapping if-statement conditionals (OrbitalCamera L547)
• Unused commented-out code left in source (BaseCamera L1289)
• Inconsistent property casing (Poppercam L70)
• Calling a method without parenthesis (SetTransparency L29)

(Most of the above points are related to the code being inconsistent with itself, but the list would be longer if compared against the official Roblox Lua style guide, which is meant to govern Lua content produced by Roblox.)

This is what I was able to come up with after a few minutes of looking through the code. Much of this code is unfriendly to new developers and is not the kind of thing veterans want to work with either. Please understand that this is not me trying to be pedantic, but rather an effort to ensure that any code the developer is exposed to and encouraged to fork should be grounded in best practices and serve as an example or blueprint for their own code. Every opportunity is a learning opportunity, and as it stands one may actually be better off not learning anything from the styles used in this code at present.

There’s nothing wrong with using whatever style you want for personal use. I just think that code like this that is automatically inserted and seen by the community at-large should be held to a higher standard.

Thanks for taking the time to read this, it was all written from a place of love for the platform.
-evaera

[Maximum_ADHD]

The spacing between lines seems to be an issue with the uploaded file itself, rather than the code.
I checked the code in my client watch repository and it seems to be normal.

https://github.com/CloneTrooper1019/Roblox-Client-Watch/blob/gametest1.robloxlabs/scripts/PlayerScripts/StarterPlayerScripts_NewStructure/RobloxPlayerScript/CameraScript.lua