[SPIGOT-248] PortalCreateEvent not fired when exit portal is created automatically. Created: 20/Dec/14  Updated: 05/May/19  Resolved: 05/May/19

Status: Resolved
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Arne Assignee: md_5
Resolution: Fixed Votes: 1
Labels: None


 Description   

When a player enters a nether portal with no existing exit portal, a new portal is created automatically but no PortalCreateEvent is sent.
PortalCreateEvent does have a possible CreateReason.OBC_DESTINATION that is described in the docs as "When a portal is created as a destination for an existing portal when using the custom PortalTravelAgent.". This leads me to believe a PortalCreateEvent should be sent in this case.
A PortalCreateEvent is sent, as expected, when a player lights the portal by hand using flint and steel.

Steps to reproduce:

  • Create a plugin that listens for PortalCreateEvents,
    PortalCreateEventListener.java
    class Testplugin extends JavaPlugin implements Listener {
        @EventHandler
        public void onPortalCreate(PortalCreateEvent event) {
            getLogger().info("Portal created!");
        }
        @Override
        public void onEnable() {
            getServer().getPluginManager().registerEvents(this, this);
        }
    
  • Start a server with the plugin installed (and a clean, new world).
  • Connect to the server and create a portal using obsidian and flint and steel. This triggers a PortalCreateEvent correctly, with CreateReason.FIRE.
  • Walk through the portal. This should trigger a new PortalCreateEvent with CreateReason.OBC_DESTINATION as the exit portal in the nether is created automatically, but no event is sent.

I discoved this while trying to find a way to stop portals from automatically forming in specific areas.



 Comments   
Comment by Stuperfied [ 18/Mar/18 ]

Not sure about this but Should PortalTravelAgent.CreatePortal contain a call to PortalCreateEvent with CreateReason.OBC_DESTINATION

 

Update: I ran the test suggested by reporter (Arne ) on a spigot 1.12.2 server and have uploaded the latest.log with the results.

https://pastebin.com/HMUf6RYM

Comment by Ryan Hamshire [ 15/Jan/15 ]

I worked this out in GriefPrevention. Check the github to see how I did it - it's rather expensive because I have to ask the travel agent to find a place for the portal, but it works.

Basically, instead of using PortalCreateEvent, I use PlayerPortalEvent and ask the travel agent to calculate for me where the portal would be. Then I check the block type there - if it's a portal block, then this is an existing portal. If it's not, then it's a new portal and I can choose to cancel the event or not in that case.

I can imagine a better API which would allow me to consider and possibly cancel the event AFTER the portal location had been determined so that I don't have to ask for that calculation to happen on my behalf, but this is good enough considering that players don't go through portals very often, and when they do, idling doesn't cause them to hop back and forth - they have to step out and then back in to trigger another teleportation, and then there's the delay before the teleport actually happens to slow down any would-be server laggers.

Comment by Arne [ 23/Dec/14 ]

Oh, that is weird. That makes me unsure if this even is a bug. But what other purpose can CreateReason have if not this?

I tried working around it (implementing my own TravelAgent), but that means messing with NMS code which I would rather avoid. The problem remains; I have no way of stopping a portal from being created automatically in any world, or affect where it is placed.

Comment by md_5 [ 20/Dec/14 ]

This hasn't existed since Minecraft 1.4!

Comment by md_5 [ 20/Dec/14 ]

Seems CraftBukkit 1.7.10 did not have this either.

Generated at Mon Apr 21 21:19:17 UTC 2025 using Jira 10.3.5#10030005-sha1:190c783f2bd6c69cd5accdb70f97e48812a78d14.