However, it has also been said that in places where no replication is made, the script (obviously) won’t execute. While there isn’t a script replication for the server this confuses me because it’s kinda inconsistent with client behavior. I also missed this question’s answer:
which answers the question now. I was asking for the definition of anywhere by the way.
For any teams approaching development with a single-script architecture this probably won’t have a significant use case because your architecture runs off of little to one script per environment (sans engine-injected scripts) and you do the rest in ModuleScripts which can already be required anywhere.
I can see a use case for casual projects and non-power teams that don’t need or care for a deeply architectured codebase but are still capable of maintaining good practices with it or for resources that try to cover as many installation options as possible.
Seems like this is supposed to be the replacement for what was ReplicatedScriptService but instead this removes hierarchical dependence and leaves execution context on an instance-level.
Glad to see this, I often made mistakes with script placement only to spend 5 minutes trying to figure out what went wrong.
Will this mean that some locations like ServerScriptService and PlayerScripts could get replaced with a more “universal” location in the future, to reduce potential clutter? (e.g SSS being merged into ServerStorage to form a uniform “ServerAssets” location or similar?)
I don’t get why so many people are being negative about this update. If you don’t like it… Keep the RunContext to Legacy? No one’s forcing you to use the new feature, maybe it’s not useful to you but it may be to someone else.
I can see why ReplicatedScriptService was canceled. This change is huge for me as someone who creates free models that add local scripts while being self-contained. The loading code I had in the Innovation Inc Railgun, Nexus Admin, and Nexus VR Character Model is something I will be happy to finally remove.