Vanish mode is trying to be two things, so make it two things.

[Moosfet]

Feature description

This is related to feature request #3880 "Show join and quit messages when a player vanishes."

Vanish is trying to achieve two separate and partially conflicting goals:

1. Allow a staff to investigate misbehaving players while appearing to be offline.

2. Allow a staff to investigate misbehaving players while appearing to be elsewhere doing something else.

These two goals have many common requirements, but they also have some conflicting requirements, and presently some of the conflicts are resolved in the config file, and the feature suggestion above is an attempt to resolve another of the conflicts, but again only in the config file.

So one has to choose whether they want a server that allows for the first case or the second case, because they can't configure it to have both. This is workable if staff are almost always offline, or almost always online, but when it's a mix of both, then about half of the time, when vanish is used, it comes with big clues to the players that someone is using it: Either a staff who has been online for hours suddenly goes offline, or a staff who has been offline for hours suddenly comes online.

Imagine if /vanish was actually two commands:

/disconnect [on|off] aims to solve the first goal above, appearing to be offline. /remoteview [on|off] aims to solve the second goal, appearing to be somewhere else.

The differences are:

1. /disconnect requires fake quit/join messages when using the command. /remoteview requires silence when using the command.

2. /disconnect requires removing the player from the player list. /remoteview requires leaving the player in the player list.

3. /disconnect requires blocking private messages. /remoteview requires allowing them.

4. /disconnect requires the player to not appear anywhere on the server. /remoteview requires that they appear to still be wherever they were when they began remote viewing. (This includes where they appear on maps.)

5. /disconnect probably shouldn't allow sending chat messages at all. /remoteview should allow them, as it may be necessary to chat with players to keep up the illusion that /remoteview isn't being used.

6. /disconnect requires AFK messages to be disabled. /remoteview is a bit more complicated: If the player is already AFK, then using /remoteview shouldn't trigger the "Player is no longer AFK" message, nor should any moving around on the server and using commands while remote viewing, as we don't want to clue players in to the fact that a staff is now active. However, if the staff decides to send a chat message, then the AFK status must end, so that the staff doesn't appear to have sent a chat while AFK. Also, optionally, it may be nice if, after the usual AFK time-out period, "Player is now AFK" is announced, since, from the perspective of other players, the staff player hasn't been moving or doing anything, and so they appear to have gone AFK, and the AFK message should reflect that. However, even without this feature, the staff can just type /afk if they want to fake going AFK, as long as continuing to use /remoteview doesn't cause the status to go away.

They need not actually be separate commands though, and I would argue that they probably shouldn't be simply to avoid player confusion and questions about what happens when a player is in one mode already but uses the command to enter the other mode, and especially if they've used both and disable one, are they still in the other mode? Realistically, there's no reason to use /remoteview if you're not already online, and there's no reason to use /disconnect unless you're going to actually disconnect afterwards and the mode persists when you reconnect.

So instead, here's my proposal for a /vanish that just always does the right thing:

1. Players with permission to use /vanish always join in what I dubbed /disconnect mode. The server can send the player chunks and sign them up to receive chat messages, but it delays adding them to everyone's player list and announcing that they have joined the game.

2. When the player wishes to be visible, they can use /vanish off, and the server will complete the other join tasks that it posponed in step 1, thus creating the first real connect message, rather than having to create any fake ones. The one thing it does need to do a second time is return them to their original position before they began wandering around while invisible so that anyone who saw them leave can see them join in exactly the location they left in.

3. When the player wishes to be invisible again, they can use /vanish on which will now implement what I dubbed /remoteview mode, and so it need not do anything like remove the player from the player list nor create any fake quit messages, as the goal is to pretend that the player isn't doing anything they weren't already doing.

4. When the player wishes to be visible again, they can use /vanish off which now simply disables the /remoteview mode, and again returns the player to where they were when they used /vanish on.

5. If the player wishes to appear to go offline into vanish mode, they can simply actually go offline, which will generate a real disconnect message, and then reconnect, at which time they will be in /disconnect mode again, with their reconnect unannounced and their addition to the player list delayed.

How the feature is useful

The problem with how vanish presently works comes down to this:

1. Staff who are offline need to be able to pretend to still be offline when investigating player activity, so that misbehaving players aren't alerted. If staff are only ever offline, then fake join/quit messages combined with enabling hide-displayname-in-vanish can accomplish this, but...

2. Staff who are online need to be able to pretend to still be online, but not investigating anyone, when investigating player activity, so that misbehaving players aren't alerted. Having no fake join/quit messages combined with disabling hide-displayname-in-vanish can accomplish this, but these are the settings opposite to what we need for the first case.

If you have both situations on your server, you really need both of those features and many others to be sometimes enabled and sometimes be disabled. So merely having them as options in the config file isn't sufficient. It needs to be possible to choose the needed options without restarting the server.