Severe camera issues in multiplayer using set_look_horizontal, move_to, and set_pos

[jordan4ibanez]

Minetest version

5.5.0 - 2866918f3

OS / Hardware

Operating system: Windows 10
CPU: Ryzen 5600x

GPU model: PowerColor AMD Radeon 5700 XT Red Devil
OpenGL version: 4.6.14742

Summary

When utilizing set_look_horizontal, move_to, and/or set_pos on multiplayer, the camera will attempt to recenter/interpolate itself (a guess) with severe overcorrections to the point where the screen is basically flashing.

This does not occur in a local server.

Here is a video showing what I am trying to explain: https://youtu.be/xlmmKX-6b4g

Steps to reproduce

You can test this using an entity that turns the players look horizontal. Also, simply by utilizing move_to or set_pos to move the player on the X or Z axis on a multiplayer server.

[hecktest]

Manipulating the position definitely shouldn't be affecting the camera.
I should also mention that anything that's an issue on a server is also an issue in singleplayer, there is no technical difference between the two. The camera problem does happen on localhost, barely noticeable but it's there.

[jordan4ibanez]

Manipulating the position definitely shouldn't be affecting the camera.
I should also mention that anything that's an issue on a server is also an issue in singleplayer, there is no technical difference between the two. The camera problem does happen on localhost, barely noticeable but it's there.

1.) Yes, you are correct.
2.) I am uncertain as to why this happens so noticeably on servers. This is very strange behavior and I cannot wrap my mind around it. I did some more testing, with GTA V, Blender, and BeamNG open and it started absolutely flipping out worse than it did in the video due to 20-30 FPS. I am unsure why, but I thought I would just update this with more information.

[Jordach]

From testing, anything related to the server directly updating the camera's position can lead to a cascade of failures, where the server no longer has the exact camera location of the client which has since moved the camera's rotation vector, leading to the server sending from the old position that the client just sent as part of the last step.

Let's say I take the players camera vector and drag my mouse downwards for an infinite period. Every step, the server would be aware that I'm pitching the camera down, but let's say I start adding upwards pitch from the server to the client to outpace the downwards pitch. When the client receives the packet (and this becomes more pronounced with network latency) instead of the position being relative to the user's mouse movement, it snaps to where the server last saw the camera rotated. Causing an effect where the client and server both cannot agree on a recent position of the last steps due to mouse movement being applied, then giving the user camera whiplash because the server has instead forced it to that position due to latency.

[mschuindt]

Tried with high latency and limited CPU, but couldn't reproduce this issue. Does it still apply?

[sfan5]

The root cause hasn't changed, when setting the position the server also always sets the look direction. These need to be separated.

[jordan4ibanez]

Dang, I didn't expect one of my ancient issues to be looked at again. Hello from the future.