thanks @phoenixlzx to test this bug
if admin in vanish status and teleport to other worlds, Essentials will duplicate add player name to ess.vanishedPlayers
when a player join to the server, will can't see this admin even if this admin is unvanish status

EssentialsPlayerListener.java#L237
EssentialsPlayerListener.java#L578
User.java#L718

That's a great observation - I've been wondering what caused unpredictable issues with the vanish functionality, but never found the cause.

@khobbits Just out of interest, what was the reasoning behind having the vanishedPlayers list?

@md678685 Two reasons I think:

It's part of the public API, so other plugins can see who's vanished.

It's used to handle the vanish.see permissions when logging in. Ie when a new player joins the server, he shouldnt see people who are 'vanished', unless he has 'ess.vanish.see'.

Thanks @cyilin for reporting this to EssentialsX. I believe this issue exists in origin Essentials as well.

Some details to reproduce:

1. Create a server, install EssentialsX and multi world management plugin (multiworld/multiverse... etc)
2. Create another world.
3. Issue server command /vanish
4. Teleport to another world.

Result:

You are not vanishing in Essentials, but when you move (anyway to move/teleport) to other players, they can't see you unless you toggle /v twice in front of them - However even toggled vanish status and let others see you, you are still in the list of 'ess.vanishedPlayers', confirmed by our plugin invoking this.

I must ask, why exactly was the vanished players collection not a Set in the first place? Isn't it common sense for it to not contain duplicates, or simply oversight?

I've worked on a very simple solution which simply avoids adding existing usernames to the list. However, I'm considering that we could replace the list with a Set and deprecate the existing getVanishedPlayers, especially considering since there's no reason for plugins to directly mutate the ess.vanishedPlayers list instead of using the appropriate User method.

This should be fixed by #1796.