Is having a Localscript inside server script good idea?

It’s not really that hard of a question, I just wanted to know is having a localscript inside server script a bad practice?

What I mean by “localscript inside a server script” is that is it good idea if I have a disabled localscript inside a server script, and then later have that server script teleport that localscript to the player. I have seen a lot of car chassis in free models use this, but I have been avoiding it, as I think it’s a bad practice compared to just having a localscript in StarterPlayerScripts.

-- below isn't really a code from my car, but rather an example what it would look like.
local InputControlls = script:WaitForChild("LocalScript");
InputControlls.Parent = Player

I personally don’t think it’s a bad thing to do, but other people can have different opinions. Also I think it might be even a good thing to have it like this, because the script won’t run in Workspace, ServerScriptStorage, etc… so it could save some preformance. This is just my opinion, I’m not really specializing to these kinds of things.

1 Like

I guess you are right, I am just thinking of coding outside roblox too much. I mixed it up because outside roblox it doesn’t work like this, as in you don’t have scripts directly in another script in the directory.

1 Like

This practice is actually extremely outdated and was created a long time before FilteringEnabled was a thing.

Does it work? Yes. That isn’t to say that there’s better practices you can use to achieve the same thing you would by dropping LocalScripts from a ServerScript.

1 Like

The one problem currently is that local scripts that involve player can only be in 3 places the character, playerGui (), and playerscripts, so I would recommend placing it in playergui

That is actually why I was trying to avoid it, as you can have localscript inside the StarterPlayerScripts or StarterGui. Having localscript inside scripts seem to be inside free models that were made long ago like Jeep in free models.

Yeah, I believe it’s just an organizational thing that is usually only available to free models as @Semistare puts it because well how else is a free model going to be able to read player input as they can’t directly put the player scripts in starter player scripts and only in the model which the user puts from the toolbox into the workspace with no setup required usually.

However, yeah it’ll of course be hard to manage if you have 500 cars or 500 different local scripts doing the samething so yeah having one local script manage it as just one singular controller would be better according to how Aeroframework would structure it, you would create a script in starter player scripts which does the listening and stuff which was your idea initially.

IDK, as long as you know where each script is and what each script does easily it should be fine.

1 Like

Now that I think about it, you are absolutely right because free models can’t place localscripts in players automatically, that makes tons of sense.

That’s not exactly what OP is asking about. I’ll give you a really basic example of what is going on behind the scenes of systems like this:

local Seat = workspace.Car.Seat
local VehicleInputController = script.VehicleInputController -- this is a localscript

Seat:GetPropertyChangedSignal("Occupant"):Connect(function()
  local Player = game.Players:GetPlayerFromCharacter(Occupant.Parent)
  VehicleInputController.Parent = Player.PlayerGui -- allows the client to pass input to the vehicle
end)

As I stated in my earlier reply, this is a really outdated practice and could easily be achieved by using RemoteEvents.

1 Like