FloorHandler.RpcRequestChangeFloor always changes the floor of the local player about submerged HOT 15 OPEN

This is indeed a bug with the code, however since the request change floor RPC is sent on the player physics, trying to teleport other players would result in an anticheat disconnect on official servers. I could move it to a shipstatus RPC to keep compatibility with officials if needed.

Since I'm on vacation now I won't be able to update the mod, but In the meantime, you can get the host to run SubmarinePlayerFloorSystem.Instance.ChangePlayerFloorState(Player.PlayerId, upperDeckIsTargetFloor); via a custom RPC

from submerged.

RegisterFloorOverride should be called on the same frame as RpcRequestChangeFloor

Apart from that what you said does work yes, but it comes with the problem that it will still look jittery for other players (not for the local player though)

from submerged.

I tried to fix the problem in the way you suggested, but I had a new problem where it would move to an unexpected place (inside a wall, etc.) for a split second.
I believe this is probably caused by processing lag because I am moving the player with PlayerControl.NetTransform.SnapTo after changing the floor.

Is it possible to add a patch to PlayerControl.NetTransform.SnapTo on the submerged side and have the snap and floor change processed almost simultaneously for specific coordinates?

from submerged.

You're not really meant to send RpcRequestChangeFloor for other clients. Instead what you should do is make a custom RPC to update the floor state from the host.

from submerged.

OK, I understand.
Is it possible to patch the PlayerControl.NetTransform.SnapTo above? I found this issue because I tried to teleport the player on a different floor with PlayerControl.NetTransform.SnapTo, so a patch would solve this issue completely.

from submerged.

Have you found a workaround for this? Do you still want me to make any changes to Submerged?

from submerged.

I wish the layer saved in FloorHandler would be updated when the layer is moved using PlayerControl.NetTransform.SnapTo.

from submerged.

You mean RpcSnapTo?

from submerged.

I'd be happy to have both, because my mod calls SnapTo bypassing RpcSnapTo to avoid banning.

from submerged.

If you want to avoid the jitter on client side you can also call FloorHandler.RegisterFloorOverride to temporarily change the floor LOCALLY for the local player

from submerged.

Is that to be used in combination with SubmarinePlayerFloorSystem.Instance.ChangePlayerFloorState(Player.PlayerId, upperDeckIsTargetFloor);, which you previously told us about?

from submerged.

No, it's used in combination with RpcRequestChangeFloor.

This is how the button for going up and down floors as a ghost works, it sends an RpcRequestChangeFloor but it doesn't wait for an answer, instead it does a RegisterFloorOverride to make the transition instant.

That means you can run RpcSnapTo, RpcRequestChangeFloor and RegisterFloorOverride together to make the transition seamless for the local player.

The fact that you use SnapTo on multiple clients might make that work differently though. Other clients might receive the SnapTo before or after the floor system update, so it will look weird for them.
The whole point of the floor system is that it's host authoritative so patching SnapTo on our side to change the floor as well would be extremely weird to implement.

This is an extremely intricate problem, I'm not sure how the other role mods were able to work around it.

from submerged.

Is this how I should handle Player A moving Player B up the layers?

1. call PlayerControl(B).NetTransform.RpcSnapTo(with Player A client)
2. call RpcRequestChangeFloor with (Player B client on after the SnapTo process)
3. call RegisterFloorOverride with (Player B client on after the RpcRequestChangeFloor process)

from submerged.

Submerged wasn't really built with teleporting in mind. Best I can do is add an RPC that the host responds to, to teleport a player and change their floor at the same time. This does mean however that it will be delayed for other players, as it needs to be host-authoritative

from submerged.

Thank you, I have confirmed that with local player there is no jittering

from submerged.