EssentialsX

EssentialsX

2M Downloads

world-change-fly-reset does not detect end portal use

AntZaro opened this issue ยท 5 comments

commented

Type of bug

Other unexpected behaviour

/ess dump all output

https://essentialsx.net/dump.html?id=d465bff2d09749e38e04c45d7fda99cd

Error log (if applicable)

No response

Bug description

When a player goes to the end using a portal instead of teleporting or warping there, their /fly status is not reset. This allows them to fly in the end when we do not wish to allow that (fly permission is negated in the end).

Steps to reproduce

  1. Set world-change-fly-reset: true in settings.yml
  2. Set a warp in the end
  3. Have a player use the warp to enter the end, their /fly should turn off (as expected)
  4. Have a player use a portal to enter the end, their /fly status should be unaffected (unexpected)

Expected behaviour

We would expect the player entering the end via a portal would have their /fly reset since they are entering a different world, just as they do with /tp or /warp.

Actual behaviour

The player entering the end via a portal does not have their /fly reset and is able to fly around the end despite the permission being negated in that world due to the status remaining on from the overworld or nether.

Additional Information

If this is expected behavior than I apologize. It just struck me as something unexpected based on how I interpreted that setting.

commented

Confirmed this is occurring, it's also happening for the Nether portal too.

commented

Turns out I was wrong. The behaviour explained of warping disabling flight but walking through a portal not is indeed occurring but I have realised that is actually working as intended (sort of). The option world-change-fly-reset being enabled only disables flight for players who do not have the permission essentials.fly when changing worlds.

With that being said, teleporting to a different world whether by warping or by portal should result in the same outcome (remain in flight when having essentials.fly and losing flight otherwise). What is actually occurring though is that warping to a different world always disables flight regardless of if the player has the permission essentials.fly whereas the same is not occurring when entering a different world via a portal.

Unsure if I should create a new issue for this bug or just use this issue? @AntZaro thoughts?

commented

Oh okay, interesting point. My interpretation was that this setting should reset your fly when switching worlds regardless of the permissions. That is why I negated essentials.fly in world_the_end for our players. So when they go to the end, it's reset, and they can no longer do /fly to turn it back on again in that world. But switching back to the overworld or nether would then allow them to /fly again.

Basically, I didn't see it as the setting doesn't apply to those with the permission. But those with the permission in said world would be able to turn it on again after it's reset upon switching.

Not sure if what you are saying would then be a feature request, requesting that this setting check for a permission and not apply to those players.

commented

Sorry, I'll try to clarify.

I did some testing without having the permission essentials.fly and found that it does indeed disable flight when going through a portal as well as when warping to a different world. When I gave myself permission (op), then my flight was only being disabled when I warp but not when going through a portal.

For some reason, warping to a different world will disable flight regardless of conditions. At first glance this doesn't appear to be caused by Essentials but rather by either Spigot/Paper or Vanilla Minecraft. I need to do more testing to find the root cause however.

commented

looking at what the setting is supposed to be doing, @zp4rker is right. code link
there is a check to see if they're in creative, spectator and see if they have essentials.fly, and if all of those conditions are false, then flight is reset.
i think this was a misunderstanding of what the config boolean was supposed to do, and quite honestly i would have assumed the same without looking into it. works as intended.