Recently there was a change to how the ControlScripts are initialized under PlayerScripts. In Robloxian Highschool, we use the MasterControl module under PlayerScripts.ControlScript and with the relocation of it, all of our players joining new servers are hanging on the loading screen waiting for this script to show up but never does. Right now the LocalScript is called “RobloxPlayerScript” and it seems to house the CameraScript and ControlScript modules.
This happens in all testing and production instances. Does not happen in our development play solo because our team create server is using a previous version of the flagset.
We’re turning this flag off now, to examine why some games that are not forking the PlayerScripts, are using hard-coded paths to them. If there is some usage pattern here we need to accommodate, we will, but even then it’s going to require developers to also make code changes. Please see the announcement here regarding this change of PlayerScripts structure:
Had we known this change would have been set to live today, we could have changed how we require the script. Advance warning on these things would be great!
I feel like this should have received a heads-up in advance before just toggling it, or asking on the forum beforehand whether many games rely on the structure while not forking (to which the answer is yes). Yes it’s not proper API, yes we shouldn’t be relying on it, but the reality is that many games do this even though it has always been bad practice, just because sometimes it’s the easiest way to get it done.
I know there are engineers who know about this project that could have warned about this as well. I was talking to an engineer a week ago who knows about this project and warned them that a heads-up needed to be given well before this goes out, so it’s a little bit unfortunate, but I guess there was just a lack of communication in that regard.
As an example of why I personally don’t override:
I was asked not to by Roblox because they wanted to do testing with playerscripts changes on our game.
If I had overridden the playerscripts, I would not have the updated “dynamic thumbstick” and updated jump button texture in the game right now, which would have made my game look different from all other mobile games.
Can’t get bug fixes from Roblox if you override because of the bad old control script structuring.
So firstly, we are going to give a generous heads-up before turning this on again, so that developers will know the specific timing. Having it on for just an hour made us aware that there is one bad practice in particular that we need a good solution for. Only a handful of games were broken by the new scripts, and they appear to all have the same thing in common: calling require() on MasterControl to use the Enable/Disable methods to temporarily disable character control. I’m going to fast-track adding a BindableFunction to do this within the new structure so that this can be done in a supported, best-practices way with a proper external API.
@AllYourBloxGetMoveVector() is essential to our game, and it will not function without it. Do you have plans to retain GetMoveVector() or offer equivalent functionality?