Need advice in implementation of spaceship system

[blazar04]

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)
    self:Fly(dt)
    Thruster.ThrustAll(ThrusterGroup, CurrentSpeed / 30)
end)

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

Thanks!

[dthecoolest]

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:

Free R15 IKPF System (Inverse Kinematics Procedural Footplanting)

Open Source IKPF System Derived from @Scarious’s code, revamped by @iGottic What is IKPF? IKPF (Inverse Kinematics Procedural Footplanting) is world-influenced animation done entirely in code. Inverse Kinematics (IK) is a series of mathematical calculations done to “guess” how parts of a limb should appear based on an origin and vertex. Procedural Footplanting (PF) is hard-coding animation, typically influenced by the direction the character is moving. You may also know that as “IK Animation…

[iGottic]

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

@ItzFoxz

There is an issue with how the ship and the thruster parts are welded (WeldConstraints).

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.

[dthecoolest]

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)

Edit: yeah it’s for this issue

@ItzFoxz

However, currently, thrusters do not show up to other players.

[blazar04]

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

[blazar04]

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.

[blazar04]

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.