Add /tpalock feature

[Pangamma]

Feature request

Feature description
A command that allows players to automatically accept or deny teleport requests. Only for teleports going TO that player though. It would be rather jarring if players could constantly summon you without you confirming anything.

Command would be /tpalock [yes/no/accept/deny/prompt]. If no argument is supplied, assume "prompt" has been selected as the argument.
yes/accept = automatically accept teleport requests.
no/deny = automatically deny teleport requests.
prompt/[blank] = follow default behavior of asking a user if they want to accept the request or not.

How the feature is useful
As an admin, I don't mind if players want to quickly teleport to me whenever they want. I don't like the TPO option because it always feels like I am having to brute force my way around the server. I want to allow anyone- even low level users - to quickly teleport to people as long as the targets are willing.

[scmcgowen]

Love it.

[mdcfe]

Thanks for opening a feature request! I definitely see the point of this, as it isn't currently served by /tptoggle or /tpo.

I'm not sure about the naming - perhaps /tparespond or /tpaauto might be more obvious and less confusing to users?

We should add messages to inform players when requests are automatically accepted or denied.

[Pangamma]

On a personal server it has been tpalock for a few years now. It just has a nice ring to it. TPAAuto would be okay, but I would like to keep the tpalock as an alias. That's a good idea 2 ad messages explaining that they were automatically accepted. That makes players want to know how they themselves can automatically accept things

[mdcfe]

I think /tpalock would be too ambiguous for most EssentialsX users even as an alias (you could always add the alias manually in commands.yml). Perhaps /tpauto would be more memorable than /tpaauto?

In addition, I feel we should definitely inform players when they receive a request that's automatically accepted or denied, but should we inform players when they send a request that's handled automatically?

[Pangamma]

In honor of the person who came up with the idea, how about we just put that tpalock alias in there so that I don't have to edit my plugin.yml every single time. I would definitely appreciate that. Also I don't know what other plug-in command would begin with TPA. Already it is not ambiguous. for notifying both parties of an automatic teleport taking place, that just makes good sense. One thing you want to let people know that the feature is there. For the other thing you need to make sure that the person automatically getting teleported to understand why they are automatically accepting or rejecting teleports

[mdcfe]

so that I don't have to edit my plugin.yml every single time

(you could always add the alias manually in commands.yml)

---

One thing you want to let people know that the feature is there. For the other thing you need to make sure that the person automatically getting teleported to understand why they are automatically accepting or rejecting teleports

The issue is that players may not want people to know what their automatic response setting is, as this could be abused by players knowing that they can instantly teleport.

---

Another consideration is that /tptoggle already has the same effect as the proposed /tpauto deny, which when off automatically prevents the player teleporting to the target.

A better implementation of this command could be to have /tpauto on/off. When on, teleport requests would be automatically accepted, and when off, the target will be prompted to accept it (current behaviour). This can then be supplemented with /tptoggle. If /tptoggle is off, then /tpauto will be ignored (as the request is never sent). This solution avoids confusion arising from duplicating the same feature across two separate commands.

In summary:

• /tptoggle on/off stays as-is: controls whether a player can receive teleport requests or not
• /tpauto on/off is added: controls whether received teleport requests are automatically accepted or not

[Pangamma]

Having two separate boolean commands to control a single state value is just confusing. Why would you do that to people? Why would you not just add a second parameter to a single command?

Off/deny/accept. If you are worried about it being ambiguous and confusing with TP toggle, change the off parameter to be named prompt. Or else make it so that TP toggle is a state command and not a Boolean command.

If you're really planning on making it that confusing by using two separate commands that both toggle a Boolean, I would rather you close this feature and not implement it at all because I would rather not confuse my members as I continue to use alternative systems that are already implementing this as suggested in the original post.

[mdcfe]

Having two separate commands for this is confusing.

I would argue that randomly changing the functionality of an existing command is more confusing, as we then have to:

• update documentation (and hope that people don't even think about looking at the original Essentials wiki, the front page result when looking for Essentials documentation)
• write an EssentialsUpgrade migration to run through userdata and update it
• add new permissions to go existing commands

...all of this while having to ensure that:

• existing permissions setups are not broken by the change
• server admins have an opportunity to manually enable it, rather than all users suddenly having access to it
• the EssentialsX API provides deprecated workarounds for the vast majority of plugins that will not update solely for this change

---

I would rather you close this feature and not implement it at all because I would rather not confuse my members as I continue to use alternative systems that are already implementing this as suggested in the original post.

Nothing is there to stop you using your own implementation in your own server, and I'm not trying to do that.

This is a feature request to EssentialsX, a massive open source project with tens of thousands of users. Decisions have to be made in the best interests of everyone, including server admins, players, and the EssentialsX maintainers and support staff, hence I'm exploring various implantations of the concept. There are several reasons:

• to avoid the vast majority of users being confused as to where to find the new feature/why a command that has existed since at least 7½ years ago unexpectedly changed to do something else entirely
• to minimise support burden created people who start complaining about sudden changes to commands (note three years of contention over command confirmations until they were finally changed a few months ago)

You can, as mentioned above, implement this however you want on your server, but EssentialsX has a much broader target audience that we need to account for.

[Pangamma]

Fair enough. Apologies for my brash commentary. Work has had a few parallels to this kind of convo lately. I am going to close this feature and request that it not be added to essentials in the modified state. Thank you.

[mdcfe]

I've reopened this at #2307.