CFrame value changing through remote event

Help and Feedback Scripting Support
#1

I have a script on the client:

local cf = CFrame.new(pos,Vector3.new(x,y,z))
print(cf)
game.ReplicatedStorage.remotes.Place:FireServer(cf,"Forcefield")

and on the server:

game.ReplicatedStorage.remotes.Place.OnServerEvent:Connect(function(player,CF,t)
	print(CF)

The problem is that the cframe value is different on the client then it is to the server:

image
image1233Ă—70 14.4 KB

any help in why this is happening is appreciated :slight_smile:

#2

Try sending {CF.ToEulerAnglesXYZ()}, CF.Position and on the server side, to get the CFrame construct it like this:

game.ReplicatedStorage.remotes.Place.OnServerEvent:Connect(function(player,Angle,Position)
	print(CFrame.fromEulerAnglesXYZ(Angle[3], Angle[2], Angle[1])*Position)
end
#3

Tried this and it didn’t work, also tried it one the client.

#4

Is the CFrame different again or what’s the issue

#5

same issue cframe is different, same value as before

#6

This should work:

--Client
local cf = CFrame.new(pos,Vector3.new(x,y,z))
print(cf)
game.ReplicatedStorage.remotes.Place:FireServer({},"Forcefield")

--Server
game.ReplicatedStorage.remotes.Place.OnServerEvent:Connect(function(player,CF,t)
	print(CFrame.new(table.unpack(CF)))
end
#7

still has the exact same behavior, when I tested with a random parts CF it worked though.

#8

I am having trouble reconstructing this problem how are you getting this CFrame

#9

it is coming from a ray that I cast, this is apart of a placement system:

local cframe = CFrame.fromMatrix(
	ray.Position,
	ray.Normal:Cross(humRP.CFrame.RightVector),
	humRP.CFrame.RightVector,
	ray.Normal)*CFrame.Angles(math.rad(90),rotation,0)
#10

Can you try recasting the ray on the server-side

#11

ye but it would be easier to send the cframe other then redoing the whole ray cast

#12

I can’t replicate the issue even with the same value and the same script so sorry I am unable to help

1 Like
#13

It’s prolly some weird precision loss issues, which won’t be noticeable. Afaik roblox serializes values that is passed through remotes and even though lua uses 64 bit double numbers, I think the engine uses 32 bit floats internally so the loss might be coming from small changes while rounding.

#14

Now that I checked again yes I can replicate it and it shows the same thing it is 100% float imprecision float values can’t store anything and has blind spots I think that’s what is causing it

#15

is there a work around? char limit

#16

Well afaik no, although you don’t need a workaround as the precision loss is really minimal and won’t be noticed in game.

#17

well when I test it is very noticeable, I ended up just calculating the cframe different and it worked normally

#18

That’s weird, I’ll try reproducing the issue later in studio

#19

well this was 2 years ago so sorry about that but YES, it is very noticable, at least the rotation is basically totally different, im having the same exact issue when raycasting and then sending the CFrame through so my guess is that it has something to do with the raycasting also?

anyway, dont know if you ever found a fix for this other than just sending it the other way around (which i cant do for the reason that im raycasting on the client off of the player wtich isnt perfectly replicated on the server)

im going to try to find a solution this evening and ill report back if i discover anything

Edit: wait a second i just realized i am also using .fromMatrix to construct the CFrame! … and almost the same way you showed… there must be a roblox bug in that somewhere

1 Like
#20

HAHAHAHA i did it!

There appears to be a roblox bug with the instanciation of the CFrame datatype, by making a part on the client first, setting its CFrame to the calculated CFrame (creating a new instance of the CFrame that the client part… has, owns) and then sending the CFrame of that client part to the server, that works! And then you can just delete the client part.

1 Like