CommandHelper

CommandHelper

46.5k Downloads

player_portal_travel @e['to'] not accurate.

LadyCailinBot opened this issue ยท 4 comments

commented

CMDHELPER-2961 - Reported by VergilPrime

The 'to' event data I believe is pre-search for a portal and not after a portal is found. Because of this I cannot protect a region from a player portalling in.

commented

Comment by PseudoKnight

I'm pretty sure that's just the way the bukkit event works.

commented

Comment by PseudoKnight

WorldGuard now protects portal creation. After it checks if a portal exists, it creates a selection within the creationradius and checking all the regions that intersect it. If any of them are unbuildable for that player, it cancels.

I can't give the location of a new portal without adding a new event. However, I can make this event find and return the existing portal location for nether portals. Then if it has to create one, it'd return null.

commented

Comment by wizjany

yea this is a limitation of the event design. because someone could set a custom PortalTravelAgent, the actual location of the portal isn't known until after the event lifecycle. so WorldGuard just does best-protection guessing and checks the entire possible radius of the destination. as Pseudoknight said though, you can see if a portal already exists or if one would be created (but if it is, you can't pinpoint where).

edit: for reference https://github.com/sk89q/WorldGuard/blob/6.2/worldguard-legacy/src/main/java/com/sk89q/worldguard/bukkit/listener/WorldGuardPlayerListener.java#L400-L440

commented

Out-dated issue, and as of 1.14 not even fixable using the travel agent anymore (if we had wanted to). Best people can do, depending on their need, is adjust the radiuses, set creationallowed to false, or handle the player_teleport event.