[FEATURE] Universal tpll

[george112n]

Formerly implemented as "sledgehammer", which may remain it's published name, universal tpll will take over the tpll functionality across the network.

It's main feature is to automatically switch a player to a different build server when they perform a tpll command taking them outside the bounds of their current build-server. When they connect to the required build-server, the tpll teleportation would be performed. Thus contributing to the BTE Centralised Feel epic. Another benefit of automatic build-server switching is the reduction of empty chunk generation outside of server bounds on servers who do not have any restrictions on chunk generation.

Automatic build-server switching process would also occur when a player crosses the border between the bounds of two build-servers.

[george112n]

Discussed yesterday were two possible solutions to this.

1. Database events: When a tpll command is run, if a server switch is required the tpll coordinates along with the UUID of the player and the destination server would be stored in the DB. The player would then be switched server. On connection to the server, a PlayerJoin event would be triggered and the DB would be queried for any entries matching the player and destination server. If there are any entries, the teleportation event will occur and the entry will be removed from the database.

An API system was suggested to increase the security of this method. Keeping coordinates in a DB may compromise user privacy and security if unwarranted access to the database was gained.

2. Plugin messaging channels. A message would be sent to the destination server which the destination server will hold in a list. (Potentially a map with key=uuid and value=coordinates). The player would then be switched server and when the PlayerJoin event is triggered, the plugin will query the list, perform the command and remove the teleportation from the list.

Option 2 was considered to be the best option due to the security concerns arising from the database method. We currently do not have ample resources to create an API system.

[george112n]

Further to this, the database solution mentioned here wouldn't work because you couldn't access the database without leaking the credentials. So it's not even an option.

[lokerhp]

Another option wpuld be to add a redis pub/sub in between, this would work as follow

• player A wants to switch from A to B
• A sends a pub message containing the dest server, uid and coords. Server B recidves this and st9res it in memory sending a ACK.
• when A recieves the ACK it sends a bungee send message

The redis could be ipwhitelisted to participating servers their ip

[Nudelsuppe42]

Another option wpuld be to add a redis pub/sub in between, this would work as follow

• player A wants to switch from A to B
• A sends a pub message containing the dest server, uid and coords. Server B recidves this and st9res it in memory sending a ACK.
• when A recieves the ACK it sends a bungee send message

The redis could be ipwhitelisted to participating servers their ip

This is basically what Bungeecord messaging does, besides the acknowledgement. Which i dont think is that important, we could always send a response bcmsg if needed. Overcomplicating this is also not really a good option,s since there is a build-in way of doing it and we dont need a redis server.

[george112n]

I will also add some rerouting of some common typos of /tpll

[george112n]

Universal tpll is complete. This issue will remain open so that supplementary additions changes made before release can be recorded and/or discussed.

[george112n]

Feature add: Make sure it maintains the yaw and pitch of the player. Send yaw and pitch with the message