Honestly, I was having a great time thinking on the great usages that would be possible with this feature, I was pratically day-dreaming already finishing several of my ideas with such ease…
When I hit the Roadblock™ ever when I started working with Scripts running under the Client, which is the fact you are unable to select if you want to let either everyone be allowed to run the script, or if you want it to just target someone in specific without requiring to outright use a LocalScript.
And why has this bothered me? Well, to put it short, I wanted to convert a vehicle system I am working on to be fully client-sided, my idea was to let the server create a vehicle with a controller Script running under the Client context, when I realized that because there is no way I can isolate who I want the script to be read by… it meant everyone could control eachother’s cars, from a simple action such as driving to outright just locking doors and stuff.
I think it would be great if Scripts had a new property called “PlayerTarget”, only changeable by the server-side, in which setting a player on that property would make it so that only the player who was set there can run the Script, and by setting the property to nil, it would basically mean everyone in a server can simultaneously run said script.
This update is really great and has been the beloved replacement I was mindlessly awaiting for when you guys removed the ReplicatedScriptService class, but it really has this one hurtful issue of not allowing to select who you want the Client context Script be ran by.
Yeah, and the scripts that I have tried to commit changes to end up becoming a completely blank script as a result, and it’s genuinely infuriating to have a couple scripts of mine end up like that from start to finish. I thought I was the only one having that issue, and the game I’m currently working on is a team create place too.
Same, I also seem to be having an issue publishing packages with scripts in them currently. Due to the timing of of this issue and the nature of these changes I assume they are related.
Right, may I add, before anyone tells me to utilize LocalScripts in player containers: That is exactly what I am trying to avoid.
My idea is to have the server to place the controllers under the cars and only allow the owner of said car be able to process the Script, which means they would immediately gain control of the car without having to do a really complex code on things like ReplicatedFirst to achieve said effect or shoving the car inside of the Player’s Character… which for the latter I can only say it always causes really awkward RootPart flings.
Having this issue as well. Scripts which are packages say that they always changed and that they need to be published, but every time you try to publish them the cycle just repeats. Makes it so you can’t publish the game since the script needs to publish its changes.
Unfortunately, Engine Feature requests are locked for Regular or higher only.
I’ve had several ideas I wanted to share in the past year that could really improve the overall Server & Client boundary management, but I have to yet get the rank to even have the slightest of chances to get them across, including that one I’ve sent as my personal feedback to this Beta.
What happens to scripts that are set to run on clients that are inside player containers? Players replicate so would a client load and run a script that’s inside another player with context set to client??
Is there any plan for client/server only modulescripts ?
it would be great for structuring, for example,
in replicatedstorage, we could have folder for each feature and have both client and server modules inside.
server modules would not expose bytecode to client (just like server/client scripts)
I think this idea is okay… but I do like how you can currently …easily tell the difference between a script that’s going to run on the client, and a script that will run on the server, in the Explorer… I hope scripts set to run on the client only, will have a particular look to their icon… Otherwise, it’ll be a pain to pick them out if they’re not named something obvious, denoting client or server… , especially on a vehicle or weapon tool/model. We shouldn’t need to depend on the Properties window to be open or referenced, to do this check.
From what I’m getting from this update, the change makes it so all Player Containers (StarterPlayerScripts, StarterCharacterScripts, etc) will replicate and run the script on all Clients if the script RunContext is set to Client (if the client in question is able to see that script, that is)
What is the point in having both those player containers, if it’s going to lead to me having undesirable results, and probably a game breaking issue?
No hate, I encourage the change, it makes things a lot easier, don’t get me wrong here.
I’m well aware we don’t have to switch over to the new system right now, but the fact that I’ll have to move/reconfigure my whole setup to compensate for this change (which likely will be forced) in the future is way over mildly concerning.
I don’t get the change. It’s a bit confusing. From what I can tell it is going to make, of all things, a bit of a problem for games as a whole.
The announcement wasn’t thoroughly explained enough IMO. Kinda leaves people in the blue on what to do or even what this feature does. All I can get from it is that scripts can run from Storage Services, which, is normally meant to… y’know, store things? not run them?
Overall, This beta feature is a bit… confusing. I dunno how to go about using this, or how it could help in terms of organizing scripts or helping with the creation of games. It only seems to create issues in storing scripts that aren’t disabled.
Don’t worry! That behaviour does not change as long as RunContext is set to Legacy. This update does not force any changes on developers that would require an update to the existing codebase.
I’m genuinely not sure what purpose this serves. All I gathered from this is you can make a regular script instance handle identical to a local script.
