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.
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.
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:
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.
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.
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
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.
It’s a consequence of exporting some of these from Studio, just after a bug got introduced that exports scripts (Save as File…) with \r\r\n (CR CR LF) line endings. I didn’t catch it because my diff program ignored it. I have since corrected this, though depending on the timing of the release, these stretched out versions may be live for a week or so. Functionality is not affected.
Many of these inconsistencies are simply being carried over from the currently-deployed player scripts. The complete reworking of the player scripts is being rolled out in stages, with each stage addressing particular issues while trying to maintain status quo with regard to function. This stage is about restructuring, while trying to touch the underlying code as little a possible, so that any issues which arise are clearly the result of the structural changes and not hundreds of tiny differences introduced by code cleanup. I agree the cleanup is needed, I just want to isolate it from the restructure.
Just to be clear, you should not be forking or putting this pre-release code in your actual live game, it should be used only to evaluate whether or not having the player scripts restructured in this way affects your game. Things like commented out code, debug prints, etc. I’ve already removed from the build that will follow up a week later (a cleanup pass).
Additionally, this refactor is not about “allowing forking”, the whole point of the restructure is to minimize the need for developers to fork the scripts and forgo updates by letting them require the player scripts modules and call methods on them. Forking will still not be encouraged, apart from the special case of forking the old version while you adapt a game to the new structure.
Is this the correct way to get the move vector in the new scripts?
-- In a local script
local PlayerModule = require(game.StarterPlayer.StarterPlayerScripts:WaitForChild("PlayerModule"))
local ControlModule = PlayerModule:GetControls()
if ControlModule then
local MoveVector = ControlModule:GetMoveVector()
end
There seems to be a change compared to the old player scripts in terms of GetMoveVector’s behavior. When you are just spawning, there is no control module set yet, so the returned control vector is nil. I would recommend returning a default value here (i.e. Vector3.new()) to minimize compatibility issues. @AllYourBlox
@MapleMarvel as such that is not enough, you’ll have to add “or Vector3.new()” behind the call for now, otherwise it might be nil.
@buildthomas@AllYourBlox So is it the ControlModule that can be nil, or is it the GetMoveVector() call that can return nil? And is this every time the character spawns, or just when the player initially joins?
It’s the vector. I haven’t seen the PlayerModule code, but you can check yourself if the module can return nil.
On another note, you want to use the PlayerModule given to the local player, not the one under StarterPlayer. I believe it appears under an object called PlayerScripts in each player.
What do you mean no info? (Did you read first post fully?) You should just fork the control script until this update goes through, and then update your codebase to work with the new structure whenever you get around to it.
.
)