Ignoring rotation from vanilla packet `ClientboundPlayerPositionPacket` about shouldersurfing HOT 4 CLOSED

Thanks for reporting. While working on some major refactorings lately (see 7128310), I also came across this issue. I wanted to correctly set the camera rotations after a teleport command. Unfortunately, this the problem is a bit more nuanced, as ClientPacketListener.handleMovePlayer is invoked in the following scenarios:

• Teleport/Ender pearl
• Dimension change
• Mount/Dismount

When in Shoulder Surfing perspective, the camera rotations should not reset when teleporting (or using an ender pearl) or (dis-)mounting, as it can be very disorienting. It is also not always possible to distinguish those cases.

As a possible fix, you could use the new Shoulder Surfing API and set the camera rotations manually, if thats possible in your case:

ShoulderSurfing.getInstance().getCamera().setXRot(xRot);
ShoulderSurfing.getInstance().getCamera().setYRot(yRot);

Note that this API has not been released yet. It will be available for Shoulder Surfing 4.0.0+. For now, you would need to access the implemention directly:

ShoulderRenderer.getInstance().setCameraXRot(xRot);
ShoulderRenderer.getInstance().setCameraYRot(yRot);

from shouldersurfing.

Thank you for the feedback.

As far as I can see after some investigation, I don't think using the API would feasible in my case. I sent a vanilla packet (by invoking vanilla teleport function) handled by vanilla client code.
Sending a custom packet would be possible to adjust the camera angle additionally, however the position and custom angle adjusting packets would not be fully synchronized, likely resulting multiple camera adjustments under a short time.

I understand your concerns your regarding disorienting camera adjustments, and absolutely commend that 🫡, still I think it would be most optimal if Shoulder Surfing would handle the rotation inside the packet.
So I have the following recommendations:

1. If rotation data in the packet is only present at teleport cases (not at dismounting), adjusting the camera unconditionally will not cause districation (imo), since the position of the camera is changed by the teleport any way.
2. If rotation is always passed by the server (so we cannot ever distinguish), how about adjusting camera rotation if the difference between current and received angles is larger than a certain (configurable) value (for example 20 degrees).

What do you think?

from shouldersurfing.

I implemented it now by checking for rotation changes. I also did this in initial experiments last week, but there I injected into some other teleport function which caused many issues. The only caveat now is that it also resets the camera rotations when changing dimensions, but I'm fine with that. Let me know if it works for your use case!

from shouldersurfing.

Hello!
I tested the topmost commit of 1.20.1 branch. The few scenarios I was able to test it worked perfectly, including shadow step. :)

caveat now is that it also resets the camera rotations when changing

I believe instead of a caveat this is actually the correct behavior.

Thank you for the cooperation!

from shouldersurfing.