So I have a game called Rage Table Showdown, and sometimes when there is around 10 people in the game, it seems to glitch a bit. What happens is sometimes the tables freeze, or when they hit the player, they just barely fling them. Is there any way to fix that? Here is the script.
function FindAttachedHumanoid(part)
local tpart = part
while tpart.Parent do
if tpart.Parent:FindFirstChild('Humanoid') then return tpart.Parent.Humanoid end
tpart = tpart.Parent
end
return nil
end
function MakeValue(class,name,value,parent)
local temp = Instance.new(class)
temp.Name = name
temp.Value = value
temp.Parent = parent
return temp
end
local Tool = script.Parent
local Handle = Tool:WaitForChild('Handle')
local YellSound = Handle:WaitForChild('Sound')
local AniScript = Tool:WaitForChild('AnimationPlayerScript')
--http://www.roblox.com/Asset?ID=111898513'--http://www.roblox.com/Asset?ID=111880514'
local ThrowAnimation = 'http://www.roblox.com/Asset?ID=111898867'
local ThrowFace = 'http://www.roblox.com/asset?id=111882478'
local ThrowTable= Instance.new('Part')
do
--ThrowTable.Shape = 'Ball'
ThrowTable.FormFactor='Custom'
ThrowTable.Size = Vector3.new(6.8, 2.43, 3.63)
ThrowTable.CanCollide = true
local tmesh = Instance.new('SpecialMesh')
tmesh.MeshId = 'rbxassetid://4496006009'
tmesh.TextureId = 'rbxassetid://138946892'
tmesh.Parent = ThrowTable
end
local LookGyro= Instance.new('BodyGyro')
LookGyro.maxTorque = Vector3.new(0,math.huge,0)
local ActivateLock=false
Tool.Activated:connect(function()
if ActivateLock then return end
ActivateLock = true
local character = Tool.Parent
local humanoid = character:WaitForChild('Humanoid')
local torso = character:WaitForChild('Torso')
local head = character:WaitForChild('Head')
local face = head:FindFirstChild('face')
local oldFace =''
if face then oldFace = face.Texture end
humanoid.WalkSpeed = 0
LookGyro.cframe = torso.CFrame - torso.CFrame.p
LookGyro.Parent = torso
local ntable = ThrowTable:Clone()
ntable.CFrame = torso.CFrame+(torso.CFrame.lookVector*4)
ntable.Parent = Workspace
MakeValue('StringValue','aniId',ThrowAnimation,AniScript)
wait(.5)
YellSound:play()
wait(.5)
if face then
face.Texture=ThrowFace
end
local bAVel = Instance.new('BodyAngularVelocity')
bAVel.maxTorque = Vector3.new(math.huge,math.huge,math.huge)
bAVel.angularvelocity = ((torso.CFrame*CFrame.Angles(0,math.pi/2,0)).lookVector*10)
bAVel.Parent = ntable
local bVel = Instance.new('BodyVelocity')
bVel.maxForce = Vector3.new(math.huge,0,math.huge)
bVel.velocity = (torso.CFrame.lookVector*51)
bVel.Parent = ntable
ntable.Touched:connect(function(part)
--print('GotTouched:' .. part.Name)
Spawn(function()
if part.Name == 'Terrain' then return end
if part.Anchored then return end
local hitHumanoid = FindAttachedHumanoid(part)
if hitHumanoid then
--print('HumanoidParent:'..hitHumanoid.Parent.Name)
if hitHumanoid==humanoid then return end
hitHumanoid.PlatformStand =true
end
if part.Size.x*part.Size.y*part.Size.z<=5*9*5 then
part.Velocity = (Vector3.new((math.random()-.5)*2,math.random(),(math.random()-.5)*2).unit)*500
end
wait(3)
print('got past wait')
if hitHumanoid then
print('unplatformstanding')
hitHumanoid.PlatformStand=false
hitHumanoid.Jump = true
end
end)
end)
wait(6)
LookGyro.Parent = nil
humanoid.WalkSpeed = 16
if face then
face.Texture=oldFace
end
ntable.CanCollide = false
game.Debris:AddItem(ntable,5)
ActivateLock = false
end)
A little off topic to the question but still somewhat relevant.
It should be noted when players are given network ownership over parts there is a potential vulnerability. If you give the player network ownership over lets say a kill block, they could teleport the block around on their client to the position of players and kill them (This is because the player has network ownership and the position of the part on the client of the network owner will be replicated to the server.)
BasePart.Position is not replicated across the client/server boundary. Clients can’t teleport bricks, regardless of if they have network ownership, unless they’re changing the physics of the part to achieve teleport-like behaviour. Network ownership is strictly physics, it doesn’t grant any other kind of replication authority.
Correct me if I’m wrong on that, though I remember it being this way.
(Sorry for the late response, took an absolute unit of time to upload clip)
I took the liberty of verifying the what I said[1] through the means of ROBLOX studio. If a player has network ownership over a part and changes its position it then the new position IS replicated to the server (and then to all the clients).
In the example I simulated using an exploit by using the command bar. Player1 is give network ownership of workspace.Test.
As you can see in the video linked below, when Player1 executes workspace.Test.Position = Vector3.new(0, 10, 0) the part’s new position is quickly replicated to Player2's client.
The code is executed multiple times to illustrate this.
TIL not to trust the warning on the page and that Position actually does replicate. Thanks for reaching back and actually providing a video test to back up your statements, something that’s very rare to get when you’re looking for citation or discussing a certain topic and there’s some disagreement.
I don’t know whether it was an oversight on my part or if this has always been the behaviour, but I was so sure about the replication warning and physics stuff. This proves that position falls under the physics pipeline (should’ve known) and it would be possible to move the brick around with network ownership.
You probably won’t want to rely too much on the part itself and instead add a means of verifying the position and contact of the table. You should still be setting network ownership for peak UX and performance, but then you have the concern that clients become authoritative of the table’s position. The server should then, acknowledging this authority, check if the trajectory of the table and the hit is possible rather than trying to force some weird sanitisation of the position.
Network ownership definitely is the cause for the table freezes though.
Again, cheers for the information. Learned something new.
Best way is to handle the collision impulse yourself based on detection of the table hitting a player. I would calculate the energy of the collision based on table mass and velocity, then generate force on the player for some short duration based on the energy.
