making client sided effects are a lot easier now thanks to this update
6 Likes
No, they canât drive other peopleâs cars because of Network Ownership.
About other things, well, you have to secure remotes, just like you had to with LocalScripts.
1 Like
Cool I guess, but what is really the point of this?
I donât see anything super exciting about it.
This is absolutely awesome. I can think of one extremely cool use-case for this: a LocalScript under a model controlling visual effects for that model.
Before, you had to have a âmaster LocalScriptâ that keeps track of all the models, but now you donât have to! This is epic.
4 Likes
You are completely ignoring the advantages that this update gives.
If you werenât biased and actually took time to read the numerous use cases for this feature in this thread, youâd realize how much of a great update this is.
Large development studios might not benefit much from this. But for smaller developers (including me), this is an absolute game-changer as it allows to achieve many things much faster and more easily.
8 Likes
Having the freedom to put scripts anywhere is good. Personally though, I would not like to scramble through models and models and what not in the workspace or going through layers in the GUIs and such to find a single script. It makes the environment harder to work with, in my opinion.
I do not really see what sorts of advantages this brings to other specialities, as you had mentioned. However, it is up to the programmer of a project to figure out how they want to organize their stuff. For me, this update will have no use, but I am glad to see people are happy with it, nevertheless.
1 Like
Right, you reminded me very well that forcing the NetworkOwnership fixes the driving issue.
As for the remotes, the idea sounds great on paper, it could nicely resolve the issue⌠but in practice, because the cars are spawned in with a controller by the Server in them that can unfortunately be read by everyone, it means that it would slowly start increasing lag on the Client due to several scripts that are basically the same being ran over and over while simultaneously firing constantly for every tiny thing they do.
Ex.: Imagine you have Player1 and Player2 in a clicker-style game, both have their own buttons on the workspace, which are set to be pressed whenever they hit the E key on their keyboards.
For obvious reasons, keeping that action withinâ a player container to not cause interference would be great, but lets imagine you set it in a Script under each button.
Since both of their buttons have a Script running inside of the Client context, it means that, theoretically, if Player1 presses E, they are actually firing 2 different inputs, one being from their buttonâs control Script, and the second one being from Player2âs buttonâs control script.
Having a check being done with a remote in this case would prevent Player1 from accidentally giving both of them money at the same time, but it would not change the fact his Client is still reading the code from Player2âs button, despite it being pointless for Player1âs gameplay, which could hinder on FPS/performance.
Do take note that in this scenario the more people in the game, the more buttons there would be, meaning the more waste there would be on the Client, and the more signals wouldâve been firing to the server everytime one of them pressed E on their keyboards.
1 Like
Thank you for your kind words where you claim I donât read and Iâm biased in a topic where Iâve read well over a 100 messages.
I hope you donât always get this angry when somebody disagrees with you, but I will say Iâm in support of standardized processes and letting people do things right from the start. Bad habits and patterns can really put people in a spiral and I remember as younger, I said âdidâ in every sentence.
We all pick up patterns and itâs a lot better if those patterns are right from the start. As for use cases, not a single one I read isnât something I can already do but perhaps, in your own words Iâm ignorant and biased.
For this instance why would you not have a function that having received a car argument (passed by the server) would iniciate control? You give the player NetowrkOwnership of the car model, they have functions that control it and voilĂĄ! It works as expected without the need of anymore than two scripts (or more modules if you want to use them).
I am not understanding this problem? Why would you not loop through these buttons in the client and give them their respective function? Then you would fire a remote to the server, which can see what player fired it, do any necessary sanity checks, and apply the result.
4 Likes
I think this is a poor idea. I feel like giving scripts the ability to run anywhere is just going to encourage lazy programming and poor workspace organisation. Even before this change, in front page games, I see identical clones of scripts parented to different objects, such as a script inside every kill brick, and this change will just make that worse.
Personally, I think scripts should be limited to where they can run, such as server scripts only in ServerScriptService.
1 Like
This is really good update and I like it! Canât wait t try it out.
For the first one, I apologize for me being stupid LOL, I barely like using remotes for things, even then this entire thing was experimenting with this new Beta feature.
Truth is, I sort of lied about the cars, they are cars, yes, but they are also more-so of NPCs, they can pathfind and drive to wherever you ask them, which is why I really wanted to lock this to be only your Client to be in charge of said Scripts without adding a sorting system in the scripts themselves to allow who should/shouldnât be able to process them, since pathfinding is better done in the Client + your car is only your car, and no one else should really be able to drive it and things of the sort.
I guess for the second one Iâve stated already, I want to avoid the step of adding a sorting in the Scripts themselves.
To be fair, it would solve the issue, even if it takes a little bit of effort, but I think it would still be nice if you could avoid that step by letting the Server choose who it wants the Script to be read by, after all this is a feedback section, and if I feel that adding something of the kind could help on reducing work effort slightly, then I will gladly suggest it, even if solvable by doing something slightly annoying & hard to a certain point, but not impossible.
nice 
i really love this idea, will take some time getting used to it though.
I canât see any good use for this, it seems like I just wouldnât use it at all because legacy does everything I need it to do. The only use Iâve seen for it is switching a script to a local script. But I wouldnât really make the error in the first place. Anyone want to tell me other uses for this, donât want to judge it when I barely know anything about it!
On the other hand, if you want to add a clientside code for a single unique object, thanks to this update you donât have to keep the object and the code seperately.
I am not sure if I understand this problem correctly, to be honest. You can always have something around the lines of a module to be iniciated / stopped. You can have it change any behaviour. As long as the cars have the correct network ownership, they can do anything. You can have modules use the LocalPlayer for this circunstance.
I do not think this update enables any more that could be done already. In your circunstance, it is a matter of passing the player, and no one would have touched it. Having modules, as far as I know, do not hinder your performance as something like inserting a script would. They are just functions within the memory you can call anytime. Correct me if I am wrong, though.
From what I understood so far, it just enables more customization in how you can organize your stuff. I am trying to figure out if it allows for something more than adding LocalScripts to workspace and the likes of it. The engineers mentioned the plan to add new modes to this property. Perhaps then we can find some more significant uses.
1 Like
Yeah, it is in beta after all so I wouldnât expect much from it on the first day of release
I mean, I could make a short and simple video that explained the general idea I had, but the ideas you said obviously works, itâs just I wanted to avoid them.
This update has a lot of potential, and I mean it.
True. This update is all about making things easier and simpler, such as not having to use CollectionService for a single part.
This update isnât going to suddenly make all games an organisational mess. If they are a mess, they will be a mess anyway.
In fact, I feel that this update is going to make messy games less messy. As an example, if a game stores scripts in objects in Workspace, clientside scripts no longer have to be stored separately, making it easier to find code for a specific object.
5 Likes