Event Part.NetworkOwnerChanged

[Baumz]

oh, here are the controls

Mouse and Keyboard controls:
Left Click = gas
Right Click = brake
Move mouse Left and right = steer
A and D = Straf
W and S = Tilt (when airborne)
Spacebar = Boost
T = Give Boost (for testing)
R = reset Ship
P = back to Menu

Gamepad controls:
RT = gas
LT = brake
Left Joystick = Steer
Right Joystick = Straf/Tilt
LB = Boost
X = Give Boost (for testing)
Select = Reset ship
Start = go back to menu

Tablet Controls:
Touch/Hold bottom right corner = gas
Touch/Hold bottom left corner = brake
Rotate Device = Steer
Slide gas finger = Straf/Tilt
Tap middle left = Boost
Tap top right = give boost
Double tap bottom middle = reset ship
Swipe down from middle top = go to menu

Although the steering for Mobile is currently not working.

Also it helps to hold down W so that the ship tries to stay on the ground.

Heres me reproducing it on this track:

Although I also find the back side of the first hill to be equal likelihood of happening too.

[Khanovich]

Finally got a repro. Okay, I think I know what is going on. For some reason your high-speed collision with the wall causes the part to explode/teleport due to an over-constraint problem (not quite sure yet). When this part teleports, it seems to teleport in the negative direction (below -500) where the kill plane logic takes place.

Kill Plane logic

• Detect that I am below kill plane.
• Set my ownership to server to verify.
• Server receives ownership and deletes you if you are below the kill plane.

What happens in your game

• Collision causes crazy teleport below kill plane.
• Set ownership of ship to server.
• Server receives ownership but never gets a position update from the client, so it uses the last position that it verified.
• Once the server is owner it sends you an update about how the ship is still on the track.

You need to somehow prevent that crazy 90 degree collision. And I gotta figure out why it teleports you.

Side-note: I appreciate another Blue Stahli and Celldweller fan, but be careful with copyrighted music

If you listen to the Changed event of the Part, there is actually an unscriptable internal property that you could possibly use to detect this.

local function onChanged(property)
	if property == "NetworkOwnershipRuleBool" then
		local isAuto = part:GetNetworkOwnershipAuto()
		if isAuto then
			print("The server is automating the Network Ownership of",part)
		else
			print("The Network Ownership of",part,"is being manually overridden.")
		end
		print("Current Owner:",part:GetNetworkOwner())
	end
end
--
part.Changed:connect(onChanged)

Please tell me you guys aren’t using NetworkOwnershipRuleBool in normal non-debugging logic. The only reason that property name exists is because we found a bug in some replication code that prevented me from adding a new Enum value so I replicated it as a Boolean to prevent Xbox code form going weird even when running an older version. I’m going to switch it back to Enum replication soon and the name NetworkOwnershipRuleBool is going to be invalid.

[Baumz]

Thank-you for your time on this. Do you think possibly setting a bad CFrame to the BodyGyro could be causing the Ship to say flip out and teleport to negative infinity, thus being killed by the Plane? Also I have the killing Plane set to the lowest possible value -50000, so my guess it has to do with the BodyGyro.

Edit: Oh also I am using Legacy Physics if that changes anything.

Also it doesn’t have to be a a >80 degree angle for it to occur, it is just easily producible at steeper angles (example is the second Video I posted, which is like about 60 degree angle).

This is the Code I use to decide the rotation:

[code] --norm is the upwards direction of the Surface, detected using Rays from below the Ship.
local ny = norm.unit
local o = ship.Main.CFrame.p
local ncc = ship.Main.CFrame:vectorToObjectSpace(ny)
–local nzo = Vector3.new(0,-ncc.z,ncc.y)
–local nxo = Vector3.new(ncc.y,-ncc.x,0)
local nzo = Vector3.new(0,-ncc.z,ncc.y).unit
local nxo = ncc:Cross(nzo)
local nz = ship.Main.CFrame:vectorToWorldSpace(nzo)
local nx = ship.Main.CFrame:vectorToWorldSpace(nxo)
M.gyro = CFrame.new(o.x,o.y,o.z,nx.x,ny.x,nz.x,nx.y,ny.y,nz.y,nx.z,ny.z,nz.z)

-- much code later
ship.Main.BodyGyro.cframe = M.gyro * CFrame.fromEulerAnglesXYZ(0,steering/30,0)
-- where steering ranges from like -70 to 70

[/code]

[Khanovich]

Are you doing anything to make sure that the rotation matrix is orthonormal? You’re doing a lot of cross products to generate a very custom rotation matrix.

If the bases are not orthonormal, and the determinant != 1, bad things can happen.

[Maximum_ADHD]

Nah I’m not, I just found it by accident while I was testing some stuff.

You guys should maybe fix that bug. Sometimes internal properties are exposed through Instance.Changed

I’ve discovered several secret properties, such as

• BasePart.DraggingV1
• Humanoid.Health_XML
• Humanoid.JumpReplicate
• FormFactorPart.formFactorRaw

[Baumz]

I’m pretty sure I figured it out, somehow my BodyGyro’s CFrame was being set to NANx12. I use 2 different Ray’s to to determine how the Ship should orient itself, one pointing below the ship, the other pointing straight ahead (to detect sharp hills). Some how the 2 normals returned by the rays were opposite of each other, and so my equation to find a normal between the two normals (so as to make a smooth transition from normal 1 to normal 2) was canceling out to 0,0,0. So in my above code I posted, ny would be nan nan nan therefor M.gyro would be NANx12, which when set to a BodyGyro causes the ship to be flung to negative infinity.

[Khanovich]

NAN would do it. Oh god the NANs.

[acreol]

This would be very useful still in scenarios where we are applying forces/constraints which we could calculate on any client/server (because it would be more efficient to distribute the load than have one machine calculate everything)

For example I have these item drops which are right now only owned by the server
https://streamable.com/e806r