Better way to use TweenService with physics related mechanics

Alright, so i want to make a piston that pushes other objects, that’s pretty easy, just tween the position and push objects, now my question is,

It’s more efficent to tween on the client, but I want that tweening to influence the server, to push objects, so what should I do? just tween on the server? I really have no idea.

Any tip would be great!

Tweening server side is going to really lag the client (network side) because it replicates too much data to them and it will make it also look choppy and the server (performance side) because I really see how server script with tweens have an exaggerated cpu usage. In my opinion you should make it client sided.
But there is the problem that I don’t think the objects pushed by the client is going to be visible also to the server but there possible is something about physics ownership. I’m not sure but I guess if you have the physics ownership to a random part and you have a client sided piston or something that pushes it most probably the server will see the modification.

Alright, ill try that , thanks a lot

I also forgot to mention that the pushed objects will have to interact with the server based on their position

maybe this could help this.

yeah thats what i need, actually it could solve the problem all togheter

A little update, it does work, the problem is exploits, how do i deal with that? also what if i move the object only like 10 times on the server, and tween on the client?

This depends on who owns the part being moved by the piston.
If the part is owned by the nearby player, and the player is tweening the piston client-side, then they’re responsible for the part’s physics and will move the part as if the tween were real-time. And since they own the part, their view of the world is what others see. The obvious downside to this is the vulnerability to exploits; an exploiter can yeet the part and ruin the game.

If the piston is moved serverside 10 times, and the part is owned by the server (e.g. if it’s explicitly set that way, or there’s no player nearby), then the part will also move 10 times, regardless of how the players see the piston moving.

As an aside unrelated to your question, when dealing with tweens, always be mindful of the Velocity of the parts in question. If your piston is tweening but has no Velocity, then players and parts standing on it will fall off it because it doesn’t pull them along, and being pushed by it is a little glitchier.

Would move the piston head with velocity, fix all my problems?, also thanks for the really detailed explanation, it means a lot

There’s little else to do other than Try It And See. But you should always keep the behavior of network replication in mind.

Im messing around with some PrismaticConstraints, those should be perferct. some network ownership, collision groups, and it should turn out perfect, ill send the results once im done

That’s not necessarily true. The server’s latency is a factor to how it replicates. The slower or more under load the server is, the worse it replicates. Clients won’t experience that issue, but the difference is that the clients with worse replication speed happens to see it stutter.

@CringeEngineer, just…

External Media
2 Likes

Thanks to the script below, a method that is composed of PrismaticConstraints, some CFrame and later Collision groups for when I need it, it runs on the server, changing the propieties of this piston I made
image
The results is this:
YZDCzusVmO

The Module:

local Piston = {}

local NoVelocity = Vector3.new(0,0,0)

function Piston.Push(PISTON,KW,BATTERY,POWER,MAX_LENGHT)
	
	local Head = PISTON.Head
	local Base = PISTON.Base
	
	local IsActive = PISTON.ACTIVE.Value
	
	if IsActive == false then
	
	local PrismaticConstraint = Base.PrismaticConstraint
	
	local function Distance()
		return (Head.Attachment1.WorldPosition - Base.Attachment0.WorldPosition).magnitude
	end
	
	if Distance() > .2 then
		PrismaticConstraint.UpperLimit =.1
		wait(.1)
	end
	
	PrismaticConstraint.UpperLimit = MAX_LENGHT
	Head.Velocity = Head.CFrame.lookVector * POWER
	wait((1/POWER)+.1)
	Head.Velocity = -Head.CFrame.lookVector * POWER
	PrismaticConstraint.UpperLimit = .1
	print( Base.CFrame.lookVector )
		
	end
end

return Piston

Oh and, let me know if the script can be optimized, its pretty bad right now, ill test for performance in a moment, Thanks again for all the help!

1 Like

Alright, so when the pistons are about 50-100 its ok
https://gyazo.com/c8e4769ba527845d24b54748aee5ae3a
when the number increases to about 500 it starts having problems
https://gyazo.com/ba1e078f9b4af1531297ba739876d897

as for the local , is pretty dramatic : https://gyazo.com/b72f01a39d43be01a2b9a368f78b39ad