Reports of visibility issues.
mbax opened this issue · 24 comments
I think this occurs after changing worlds. I use Multiverse, and there have been numerous times I've been visible after that. If you would like to test specific circumstances, I'm game. You can hit me back here, or check me out on the server librosecretorum.mine.nu
Still happening on my server, this time without a multiverse tp, just normal tp to a player and then "Oh hi TheLecturer!".... embarrassing....
My server start up log here
http://pastebin.com/1P18pbJG
Ok, so that's a spigot server. Is anyone getting this on CraftBukkit? Just curious, not pointing blame.
Latest Bukkit versions, since 1-2 months ago, seem to present instability
or packet sync issues.
Silent chest, for instance. You open the chest, but even it cancelling the
event, for a split of second everyone around can see the chest opening
animation. Then instantly the chest appears closed again. Lag perhaps? But
for that to happen even with heavy server/client lag, the animation packets
would have been sent prior to the event conclusion, when the final
cancelled state would prevent that, right?
Can't that be related to the invisibility failure somehow?
By the way, we run the BungeeCord layer plus Spigot here. Sounds improbable
but it could have some guilt on that unexpected behavior. Is anyone without
BungeeCord having the same ghost animations?
On 13 Sep 2013 01:47, "conflictxinside" [email protected] wrote:
I'm using CB and having the same problem.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/478#issuecomment-24372904
.
Invisibility very unreliable now, I am spotted literally every time I go on my server - looks like some players can see me in the tab list...?
2013-09-16 16:35:52 [INFO] Players: BOWBOWJJRR, MinerHollyG, ProperCaleb, rocklock9, [HIDDEN]TheLecturer, Watmoo
2013-09-16 16:36:20 [INFO] [Purple Belt] rocklock9: lec
2013-09-16 16:36:27 [INFO] Players: BOWBOWJJRR, MinerHollyG, ProperCaleb, rocklock9, [HIDDEN]TheLecturer, Watmoo
2013-09-16 16:36:37 [INFO] [Green Belt] BOWBOWJJRR: lec isnt even online at the moment
2013-09-16 16:36:43 [INFO] [Purple Belt] rocklock9: he is
2013-09-16 16:36:48 [INFO] [Purple Belt] rocklock9: do tab
Tab list visibility is, as far as I can tell, a result of people using BungeeCord with the tab list setting to GLOBAL_PING.
Still struggling to reproduce reports of visibility going wonky.
Also experiencing this. Seems to be primarily on world change. Unvanish then revanish does work.
There's nobody assigned because it's just me handling reports for the most part. I've been unable to reproduce this issue on my own. After the 1.7 update comes out, I'd like to work with someone to test this out.
I've experience it as well, so if you need someone to help test, I'd be more than happy to.
mbaxter asked me to set up a generic bukkit server with just VNP installed to see if we could reproduce the issue in a bare bones environment. I did, but no one seemed to have 15 minutes to help bug test this plugin that we all benefit from. I'm happy to reopen the dev server for that if we had maybe 5 - 10 people that could hop on in the same time frame.
It would involve nothing more then just a simple verizon commercial test.
"Can you see me now? Good."
"Can you see me now? Good."
"Can you see me now? Good."
Yep, let me know when & where, I will join if I am able (job and family permitting !)
Would probably be good for folks to list their availability. We will schedule something for then. My availability is open any time until november 25 2013.
Any update on this bug? I notice it says "No one assigned" at the top...?
Just as a "keep alive" on this thread, I'm still getting the issue (see below) - have updated to 3.18.5.
2013-11-22 17:31:35 [INFO] Players: Creepercrammer, FluffyFishAD, PLOPPLUPE, ppmc2004, Shimmer_Sasha, skwisher542, smosh9000, taddeo12345, [HIDDEN]TheLecturer
2013-11-22 17:31:38 [INFO] [Purple Belt] Creepercrammer: lec
2013-11-22 17:31:48 [INFO] [Purple Belt] Creepercrammer: hi lec
2013-11-22 17:32:06 [INFO] [1st Dan Black Belt Donator] taddeo12345: lec is not on
2013-11-22 17:32:08 [INFO] Players: Creepercrammer, FluffyFishAD, PLOPPLUPE, ppmc2004, Shimmer_Sasha, skwisher542, smosh9000, taddeo12345, [HIDDEN]TheLecturer
2013-11-22 17:32:16 [INFO] [Purple Belt] Creepercrammer: yeds he is i see him
I was physically near "Creepercrammer" so it seems my avatar was visible but not showing up in the TAB list.
Thanks.
Any updates on this? I'm still getting caught by a great number of players.
New dev build - http://ci.kitteh.org/job/VanishNoPacket/
If you are still having this issue, please try it out
I am having the same issue with visibility on my server. I tried using the new dev build, and results are the same. I'm not really having any issues with showing on lists, but showing to players. It seems that you vanish to all players that are online, but people who log on after you vanish, or re-log after you vanish can see you. I had two of my accounts online and when I vanished on one, I vanished on my other accounts screen. After I re-logged on my non-op account I could see the vanished account even though it is invisible on all lists/player count on server ping.
Still having issues and it's embarrassing to say the least. My staff/me being "hidden" and then having the players say "HI ADMIN!!". Since this has been happening since 1.7.2 has been released, never happened before there so you might want to check for changes from 1.6.4>1.7.2 that caused this issue for everyone.
So far only a set amount of players are able to see you online and others are not able to. This can happen on login. Not sure if any world switching/teleportation method disrupts it either.
Hi @mbax,
We have a plugin we wrote called ModMode that is similar in principle to Duties. It keeps staff's "moderator-mode" inventories separate from their player inventories and keeps them vanished and invulnerable when they do moderation tasks. If also changes permission groups (from "Moderators" to "ModMode") to give moderators the additional privileges they need to do moderation tasks, and reverses that group change when they go back to just playing the game. The ModMode group includes vanish.see and vanish.vanish permissions.
We use the VanishNoPacket API and we've been having the problem that when moderators first go into ModMode they can't see other vanished staff until they relog. Also, if they then leave ModMode, they can still see other vanished staff.
I was wondering if you could take a quick look at the relevant lines of code in our plugin just to make sure that we're not misusing the VanishNoPacket API in some way? I've tried several different permutations and work arounds in this code, but my suspicion is now that VanishNoPacket is in some way confused by the permission group changes.
Most relevant line would be:
https://github.com/NerdNu/ModMode/blob/master/src/nu/nerd/modmode/ModMode.java#L480
Which is a call to:
https://github.com/NerdNu/ModMode/blob/master/src/nu/nerd/modmode/ModMode.java#L239
We'd be ever so grateful.
@totemo you can toggle the player's permissions (toggleables are not actively refreshed based on perm node mid-game) by calling the toggle method in VanishPerms
@mbax Thank you very much for taking the time. That was the solution.
I've chosen to implement a fix based on calling VanishPerms.userQuit(player). It works. It is the lowest maintenance risk in terms of number of lines of code and the potential for additional permissions to be added in the future. However, it does carry the risk that userQuit() will at some point be changed to do something more than just invalidating cached permissions.
Two things I wonder: would there be merit in adding a VanishPerms.invalidateCachedPermissions(Player) method, decoupled from userQuit() (but called by it)? And is it really necessary to cache these permissions? I can't see that it would give a major performance boost over a well written permissions plugin, and it is a potential pitfall in any situation where player permissions can change.
All of the toggleable features in VNP have a perm node for defining if you can toggle it and a perm node for defining the initial state on login. That initial state is cached (until changed by command or plugin), as the perm node was just defining what the initial state of the toggle is at time of login.