Need advice in implementation of spaceship system

I could use some advice here… I am making a spaceship system, and the flight mechanics work fine, but I am struggling with the thruster effect. Also, I am not confident that the system is efficient and secure. I feel like if I have better insight on the design, it will be much easier to fix the thruster effect.

The whole system is handled by four scripts

  1. Spaceship.lua - A server class that handles the creation of the spaceship, stores info such as the owner, stats, etc.
  2. SpaceshipService.lua - A service that handles communication between spaceships and the client, and, most importantly, handles information about all the spaceships in the game.
  3. FlightController.lua - A client-side controller that handles flight mechanics and is activated when a player sits in a spaceship. The main fly function and thruster function are called under renderStepped:
SteppedEvent = RunService.Stepped:Connect(function(first, dt)
    Thruster.ThrustAll(ThrusterGroup, CurrentSpeed / 30)

4. Thruster.lua - A client-side class that handles the thrust effect of spaceships. The parts used in the thrust effect are created server-side, though. However, currently, thrusters do not show up to other players.

So, the gist is
Player sits in seat, Spaceship tells SpaceshipService to give the client ownership and controls of the ship, FlightController handles the flight mechanics, and Thruster handles the thrust effect of the spaceship.

Current Issues

  • Replicate thrusters to the client
  • Improve upon any design flaws

What I have tried:

  • For client replication of the thrusters I have tried setting the network owner of each part to the player. I then realized that this won’t replicate the sizing and appearance of the part, as it only has to do with the physics.

Code on Github:
FlightController is in Client/Controllers/FlightController.lua
Thruster is in Client/Modules/Thruster.lua
Spaceship is in Server/Modules/Spaceship.lua
SpaceshipService is in Server/Services/SpaceshipService.lua
Weld script used is in Shared/WeldUtil.lua


1 Like

Hmm, why not in a local script in playerscripts, just use CFrames to position the thrusters at the end of the ship then do the resizing to create the effect?

This would solve replication as all clients see the thruster effect locally since they all have the same local script, and remove the weird welding client replication issues.

Edit: An example of this client replication technique would be in this IK procedural animation resource:

1 Like

I don’t think IK is applicable in this case, but kind of you to link me.

I would recommend using Motor6D instead, you may get better results, and you allow room for animation as well.

Or, you can anchor all of the parts, and instead move the model with SetPrimaryPartCFrame.

Hopefully that helps a bit.


Yeah maybe I should elaborate further, yeah it’s not the IK portion it’s the replication technique used.

There is a bit where DescendantAdded was used to make the local script render the IK animations in a queue.

I was thinking it could be applied here as well, instead of applying IK animation in a queue you would add the thruster fire resizing animation in a queue instead.

This way the client-sided animation of one person replicates to the rest since I believe the part is created locally.

Portion of the queue system
	for _,x in pairs(queue) do
		local pos = x[2].HumanoidRootPart.Position
		local mag = (pos-camera.CFrame.Position).Magnitude
		local _,onScreen = camera:WorldToViewportPoint(pos)
		if mag <= 150 and onScreen == true then

	if h.Name == "UpperTorso" then

Edit: yeah it’s for this issue


That’s a good idea. I’ll give it a try and report back my success.

I actually managed to get it working by using Welds and offsetting Weld.C0 vs changing the part’s position last night. I forgot to update the post which I’ll do now. Thanks for the idea, and I will still look into Motor6D.

1 Like

I got client replication working by creating a client-side script that watches changes made to the spaceship and notifies the other clients. I am also going to only replicate the changes if the player is within a certain distance. Is this what you mean? After making this, though, I realized that it could be exploited. For instance, if players used an exploit to change the BodyVelocity of the ship, it would replicate to all other clients. I was thinking a way of “solving” this would be a blacklist parameter that excludes certain parts from being watched (i.e. BodyVelocity), but I am not sure that would do enough.