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
Spaceship.lua - A server class that handles the creation of the spaceship, stores info such as the owner, stats, etc.
SpaceshipService.lua - A service that handles communication between spaceships and the client, and, most importantly, handles information about all the spaceships in the game.
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:
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: https://github.com/CFox04/RBX-Spaceships/tree/master
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
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:
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
runService.RenderStepped:Connect(function(dt)
fixQueue()
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
x[1](dt)
end
end
end)
workspace.DescendantAdded:Connect(function(h)
if h.Name == "UpperTorso" then
addToQueue(h.Parent)
end
end)
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.
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.