Add rotation to tp command

[Mabeeck]

Adds optional yaw and pitch parameters to the /tp command.

/tp <playerId> <x> <y> <z> <yaw> <pitch>

Yaw and pitch are expected to be supplied in degrees as that is the unit most users can be expected to be familiar with and will automatically be converted to radians internally.
Yaw and pitch can be relative: /tp @0 ~ ~ ~ ~ ~10

Closes #2403

[Mabeeck]

Hmm, I don't really see any large batches of commits all working on the same issue in the commit-history.
Should I squash these commits or does GitHub have a feature for that?

[Wunka]

Hmm, I don't really see any large batches of commits all working on the same issue in the commit-history.
Should I squash these commits or does GitHub have a feature for that?

The pr commits are squashed on merge automatically

[Wunka]

Else this looks really good. But please rename your pr to something more meaningfull like: "Add rotation to tp command"

[Wunka]

Seems good to me. As a lot of code is pretty much the same to other code I put you into easy to review. Sorry also that you got hit by my command rewrite pr.

[Mabeeck]

Sorry also that you got hit by my command rewrite pr.

No problem, it wasn't that hard to fix my PR. Always making sure never to interfere with anything isn't possible anyways.
I am happy to know that a volunteer as dedicated as you is working on this project.

[IntegratedQuantum]

I think this should wait until after #2414 so we don't need to introduce yet another needless network protocol for random command data.

[Mabeeck]

I think this should wait until after #2414 so we don't need to introduce yet another needless network protocol for random command data.

I think I have the race condition fixed now, as for the issue of network protocols; /tp currently cannot be used to teleport other players, which I find surprising. Since it cannot be used to teleport other players the rotation parameters could be handled locally, however if in the future you intend /tp to teleport other players to you or to a specified location (which I expect to be the case), then the yaw/pitch parameters not working would be counterintuitive and the protocol would need to be added anyways. Alternatively I could bundle the rotation into the existing teleport packet, if you are wondering why I used a separate packet in the first place then you can look at the giant walls of text that are my commit messages.

Besides that I am not sure why you are opposed to this additional UpdateType. It may only be used by one command, but that command is useful and can only be expected to become more useful as Cubyz obtains more content (like command blocks for example) and gains more popularity and modded servers may in the future want to set a players rotation when teleporting into an area (like spawn or a lobby of sorts) as well (imagine if hypixel gave you a random yaw and pitch every time you entered the lobby) and the most significant bloat added by it is the camera mutex, which might have been needed anyways depending on how the clientside implementation would/will go. Again, I can bundle the setRotation packet into the teleport one. The mutex would still have to stay though.

So that was my opinion and the arguments for it. I hope I convinced you that some method for the server to set player rotation is worth it.
If not, well then I'll be forced to close this PR, though I might have a go at a clientside setrotation command once the necessary dependencies exist.

[IntegratedQuantum]

Yeah, right that is a good point. But it still should not be a random network command (which inherintly are not synchronized properly which you already discovered as a race condition).
Also, more importantly, if the server sets your direction to a new value, then the client needs to take care of that in its client-side prediction. e.g. if you get teleported while you try to hit someone, the hit should now be at the new location and in the new direction.

Instead you should use a SyncOperation in sync.zig (see also #1124).

The mutex would still have to stay though.

It would not be needed, since the sync system already has its own mutex, and in the future will handle synchronization by putting everything onto the render thread.