TravelPortals

TravelPortals

70.9k Downloads

No Portal Found

Craigdb opened this issue · 11 comments

commented

I was trying your portal plugin as a replacement for runecraft teleporters. Using Spigot for MC 1.13.1
I can create a portal and it reports back OK - the yml file shows a portal and co-ords etc correctly (mind you, when I make another one the old one breaks and the yml only shows 1 portal but with the new coords.) Once created I use the '/portal name test' command but it reports back:

No portal found! (You must be within one block of the portal.)

Obviously, I made sure I was within one block, even tested inside the water area. Similar message when using /portal info. Any suggestions for this appreciated,

commented

The possible reasons why this occurred should now be fixed as far as I can tell:

  • Not close enough to portal - Try looking into the portal instead of standing in it as that might lead to better results (56a2047)
  • Fixed a but where two portals at the same location would override each other, that way a portal that had a way could be overwritten by another one without the name (could happen due to how old saving/importing works) (145472d works around that case)
  • Portal storage doesn't use name to identify portals anymore so that multiple non-named portals can exist (f307384)

If this is still happening for someone then please comment here or open a new issue with some more information (ideally your config and storage file(s))

commented

Found another bug that could lead to this issue which is fixed with 826212c: The radius search basically used the wrong coordinates after the loop was completed once.

commented

Sorry for the lack of reply; I'm having a hard time finding time for this plugin right now. I can reproduce the problem - something seems quite off. I'm not quite sure what is causing this yet though.

Spigot version: git-Spigot-f6a273b-7
a2f486 (MC: 1.13.1) (Implementing API version 1.13.1-R0.1-SNAPSHOT)
Minecraft client version: 1.13.1
Travelportals version: TravelPortals 2.4 (1.13 dev build 9)

I was also able to reproduce it with the Craftbukkit jar: git-Bukkit-7a2f486 ( MC: 1.13.1) (Implementing API version 1.13.1-R0.1-SNAPSHOT)

The game seems to only ever recognize the most recently created portal (As Craigdb noted) - if I create a portal then break a block on it, I get the portal destroyed message. If I create two portals, I can break the first one without a message, but the second one breaks as expected. (However, I can't use any of the portal commands no matter where I am in relation to the portal.)

It is also reproducible going back to 1.13 with spigot git-Spigot-fe3ab0d-1 62bda9 (MC: 1.13) (Implementing API version 1.13-R0.1-SNAPSHOT)

Afraid I don't have any suggested workaround beyond sticking with an older build for now.

commented

It looks like there are a few separate problems here:

  1. Due to storing portals using their name as a key, you can only have one nameless portal on a server at a time. (I was able to "fix" this by temporarily hacking the getName() function on WarpLocation to set a unique name if there isn't one. Not a real fix, though...) This by itself would be annoying, but not huge, but the second problem is
  2. We're no longer recognizing when the player steps into a portal.
  3. There is a typo in the default config file - one of the items is BIRCH_DOOR, and that comma causes a failure to load configuration. I'm not sure exactly how, but this prevented the PortalUseTask main method from firing (and probably also did something with playerMove)

I'm still digging into the cause behind that second issue.

commented

I think I've found it! The problem seems to be here:

https://github.com/cppchriscpp/TravelPortals/blob/master/src/main/java/net/cpprograms/minecraft/TravelPortals/storage/PortalStorage.java#L79

This currently reads

        String portalName = portalLocations.get(location.getWorld() + "," + location.getBlockX() + "," + location.getBlockY() + "," + location.getBlockZ());

I think this should read:

        String portalName = portalLocations.get(location.getWorld().getName() + "," + location.getBlockX() + "," + location.getBlockY() + "," + location.getBlockZ());

The problem seems to be that we're looking up portals based on something other than the world name. (Perhaps the World class used to have a getString() that returned its name, and now doesn't? I didn't look...)

I'm not going to be able to put anything together tonight, and tomorrow's unfortunately completely booked. I'll try to get something out for this soon though.

commented

I got a fix to this together. It's going to take a little longer to get an official release out, but for now I've attached a new jar that should solve the problems you described. (Please reply back if it doesn't!)

The official fix is in pr #21

TravelPortals_2.4_fixes.zip

commented

@Craigdb, please try whether or not it is fixed in the latest development build.

commented
commented

I realized I forgot to mention a couple important details:

First, any portals created with first 1.13 version are still broken; they need to be broken and re-created. (You can just drain the water then place a redstone torch again to do this.) Sorry about that!

Second, the jar on bukkitdev isn't updated yet. I want to do a little more cleanup before I release it more publicly. (See discussion in #21 if you're curious) The link in the comment above is the only one that works for 1.13 right now.

Hopefully that's all there is to it. I just re-downloaded it and tested it with the default configuration, and at least that case seems to be working ok. If you continue to have problems, could I ask you to share your config.yml file?

commented
commented