FloorHandler.RpcRequestChangeFloor always changes the floor of the local player

[yukieiji]

Describe the bug
FloorHandler.RpcRequestChangeFloor always changes the floor of local player

To Reproduce
Steps to reproduce the behavior:

1. Player A using FloorHandler.RpcRequestChangeFloor(Player B's) to force Player B to change the floor
2. Player A's floor is changed.

Expected behavior
Player B's floor will be changed.

Screenshots
If applicable, add screenshots to help explain your problem.

Version (please complete the following information):

• Among Us: 2023.07.14
• Submerged: 2023.08.02

Log file
None

Additional context
Some mods require forcing a player to teleport, so another player should be able to change another player's floor.

[Alexejhero]

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

[yukieiji]

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?

[Alexejhero]

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.

[yukieiji]

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.

[Alexejhero]

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

[yukieiji]

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

[Alexejhero]

You mean RpcSnapTo?

[yukieiji]

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

[Alexejhero]

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

[yukieiji]

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

[Alexejhero]

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.

[yukieiji]

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)

[Alexejhero]

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)

[Alexejhero]

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

[yukieiji]

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