Multiverse/Multiverse-NetherPortals

Portals doesnt send players to their linked worlds [1.16.2]

rockrevenchy opened this issue ยท 63 comments

Greetings! I scratched my head for a little over 3 hours now to find anything related to this issue or a solution to it to no avail, so here I am!

I use the snapshot 4.1.1 for both multiverse and mv-netherportal

I have 5 worlds which are really self explanatory: spawn, nether, end, skyblock, spawn_the_end (cant remove it)
no matter how I link my portals, they do not send me anywhere but (after activating Debug) the console gets spammed with this entry bellow upon using the portal but I remain still and dont get sent anywhere
[Multiverse-NetherPortals-Debug]: Finding new teleport location for player RockRevenchy to world nether

This bellow is how my configs are set

bounceback: true
worlds:
  skyblock:
    portalgoesto:
      END: end
      NETHER: nether
  nether:
    portalgoesto:
      NETHER: skyblock
  end:
    portalgoesto:
      END: spawn

Spigot: git-Spigot-379750e-9a9c223 (MC: 1.16.2)
/mv version: https://pastebin.com/Fe3J7vKH (/mv version -b wouldnt give me a link)

also to be noted, the end portal sends me to "spawn_the_end" instead of "end"

I have also tried removing every plugins from my server and leave only multiverse-core and multiverse-netherportal today

I figured the nether portals part, this setting in server.properties has to be like this allow-nether=true
altho the end portal still sends players to the wrong world

There is a similar setting for the end in bukkit.yml called allow-end. Please check it's value and get back to us.

if allow-end is at false, it simply wont send the player anywhere but it does show this in the console
[Multiverse-NetherPortals-Debug]: Finding new teleport location for player RockRevenchy to world end

I am having the same problem. Reverting back to 1.16.1 seems to fix the issue.

So the problem is that in 1.16.2, Minecraft changed the way extra dimensions were handled. Now, the game says that all extra worlds are actually child dimensions of your main world as it appears in server.properties.

Let's call this hypothetical world hub. Every world in 1.16.2 is now a dimension of the hub world. You have the hub's normal dimensions, hub_nether and hub_the_end, but now extra worlds are added too. The internal name for hub is now minecraft:overworld, and a creative world is now internally called minecraft:creative. Because of this, server.properties and bukkit.yml is now enforced for all worlds, when in 1.16.1 didn't.

I'm not too sure Multiverse-NetherPortals could workaround this issue, since Minecraft changed the vanilla way it handles worlds.

But point being that @nicegamer7 and @rockrevenchy are correct. You now must enable allow-end and allow-nether in bukkit.yml and server.properties respectively.

I have the same problem... Mutli-verse nether portals were working fine in 1.16.1. After I updated to 1.16.2 the portals stopped working. Portals in the overworld no longer allowed travel to the nether. If I teleported to the nether and tried a portal back to the overworld, I would wind up in stone most of the time -- I was many blocks off from the target portal in the overworld. A new portal did not manifest, I was just off destintion from where I should have wound up. And again - traveling to the nether doesn't work. In fact, if you try to light an unlit portal, in either the overworld or nether, it fails to light.

Mike_

Right so this issue also effects end portals. On a server I manage, there's the hub world, which is the main world in server.properties and another world called survival_world. The hub has the child worlds hub_nether and hub_the_end. You are in another world called survival_world that has survival_end and survival_nether. If you enter a stronghold portal from survival you end up in hub_the_end despite your config linking survival_world to survival_end. Here's our config.

bounceback: true
worlds:
  survival_world:
    portalgoesto:
      NETHER: survival_nether
      END: survival_end

In addition, if you manage to get to the survival_end via some other means, if you enter the return portal, it tries to send you to survival_end_the_end which ends up sending you to hub_the_end anyway. And in hub_the_end, it just spams you You have no home bed or charged respawn anchor, or it was obstructed everytime you try to enter it and puts you at 0, 67, 0 in the same world.

@shroomdog27 is allow-end enabled?

As I suspected in another issue, it seems this was a Spigot bug (https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/commits/9aafdc9a782861665917c8f8490e9cf4eb7fd062). Try again with a new build of Spigot or Paper Build 146 (or newer) and let us know the results!

I was having this same issue on Paper 144. I updated to Paper 150 and it looks like it's fixed.

Now on paper 150
it works only if both allow-nether=true and allow-end: true
in server.properties and bukkit.yml
it'll send players to the right worlds then
but it unfortunately leads to a world list like this
screenshot 705
(note, only end, nether, skyblock and spawn are needed)

Can confirm that without allow-nether and allow-end set to true, the nether portals don't work. Not sure if this is a spigot, papermc, or MV issue, though I'll try to investigate a bit further.

I can confirm if both are false I do not get sent anywhere and I remain still inside the portal (both for the end and nether)
I can also get a recent version of spigot alone

This is a change in Spigot behavior, nothing MV can do about it.

@nicegamer7 Can you help me understand what change caused this?

In 1.16.1, mvnp seemed to ignore the allow-nether flag altogether. From what I can piece together, it seems like the portal event may no longer be firing when this is false in 1.16.2 unless I'm mistaken. If so, is this something we should report as a bug to Spigot, or would you happen to know if this was intentional?

I tried to find some change logs but all I could find were md_5's commit messages which weren't the most detailed or easy to follow.

Okay, so updating to paper 152 still has the broken return portal once you're in the end, but going to the end from a multiworld now sets it correctly.

@leviem1 I'm unsure if the behaviour is intentional, but it is as you said, the event doesn't fire when the options are disabled. I guess you can ask in the Spigot Discord server and see if anyone knows.

@shroomdog27 have you followed this: Multiverse/Multiverse-Core#2160 (comment)?

@nicegamer7 Did that just now and it still doesn't work. Here are our config files.

Funny thing, it works for me on the latest build of paper 1.16.2 and mv dev builds. Maybe try not have any mv-np links as <worldname> and <worldname>_nether and <worldname>_the_end should link by default.

I have a (nether) world call "Nether" and a (normal) world called "Darklands" and I want a one-way link through netherportals from the "Nether" to "darklands". Running paper 168 (just downloaded right now) and the dev builds of MV. Is it supposed to work if I enable allow_nether? How do I prevent other worlds then from having working nether portals? I don't have a world_nether world to my main world though. If I enable "allow_nether" in the server.properties, this world is created but I do not want that. Even when I do so, the portals between the abovementioned worlds do not work.

When #163 is merged, you'll be able to disable portals in a world by linking the world to itself.

Is anyone still experiencing this on the latest release of MV?

It works with players, but items and entities are still a little buggy - when you throw an item not an end portal it appears at 0,0 instead of the obsidian platform.

Is anyone still experiencing this on the latest release of MV?

im having this issue with latest MV and MVNP build in paper 1.16.3

Please provide the link given by /mvv -p.

Please provide the link given by /mvv -p.

here https://j.mp/37Dx8rU

So I understand that nether portals in world are supposed to go to nether, but don't? Is that correct?

Yes, nothing happen when entering the portal.

I have tried to link world to world_nether but it also doing nothing. Allow-nether and allow-end also was settted to true.

Can you provide the output in the console after running /mv debug 3 and entering a portal?

Here is it:

[01:49:57 INFO]: [Multiverse-Core-Debug] EnforceAccess is OFF. Player was allowed in world_nether
[01:49:57 INFO]: [Multiverse-NetherPortals-Debug] Finding new teleport location for player fakhrads to world world_nether
[01:49:57 INFO]: [Multiverse-NetherPortals-Debug] Player 'fakhrads' was allowed to go to 'world_nether' because enforceaccess is off.
[01:49:57 INFO]: [Multiverse-NetherPortals-Debug] TravelAgent not available for PlayerPortalEvent for fakhrads
[01:49:57 INFO]: [Multiverse-Core-Debug] EnforceAccess is OFF. Player was allowed in world_nether
[01:49:57 INFO]: [Multiverse-NetherPortals-Debug] Finding new teleport location for player fakhrads to world world_nether
[01:49:57 INFO]: [Multiverse-Core-Debug] Player 'fakhrads' was allowed to go to 'world_nether' because enforceaccess is off.
[01:49:57 INFO]: [Multiverse-Core-Debug] TravelAgent not available for PlayerPortalEvent for fakhrads

Yeah... that doesn't help much :/

If anyone has a reliable way to reproduce this issue on a fresh install of 1.16.3, please let us know. However, I will note that I think this is a Spigot bug.

when I tried it on a fresh install paper 1.16.3, the issue is not appear.
Maybe my other plugin or old MV config.

I have found the cause. It's from other plugin. not from the spigot/paper bug or MV bug.
Thanks for helping me sir.

Can you tell us what plugin is it? Also it will be good if I you know why that plugin is causing such a behaviour ๐Ÿ˜€

It's very easy to produce this issue.

Make a fresh 1.16.3 server with MV and MVNP.

/mv create testnether nether
/mv create testend end

/mvnp link nether world testnether
/mvnp link nether testnether world

/mvnp link end world testend
/mvnp link end testend world

Stop server.

set
allow-end: false
in bukkit.yml

set
allow-nether: false
in server.props

Start it and portals won't work, setting the two above settings back to true works fine.

Many servers including mine don't use the vanilla nether/end and make our own with MV and link them, it makes things cleaner and easier to manage especially if we have multiple worlds not the 3 vanilla/normal ones. With this bug its impossible to have custom nether/end worlds without also having the default "world_nether" and "world_the_end" worlds at least made and loaded.
It wouldn't actually be a problem for any of us if only the two worlds weren't actually made and loaded even with allow-end and allow-nether enabled, if anything it would make way more sense.

Can you tell us what plugin is it? Also it will be good if I you know why that plugin is causing such a behaviour ๐Ÿ˜€

It's caused by CMI config. I upgraded my server from 1.15 to 1.16 without reconfiguring the plugin config.

Thanks @HexedHero and @fakhrads. allow-nether and allow-end directly instruct the server to fire the portal events. Having the plugin continue to function normally while these are off is not possible as of 1.16. Additionally, the default worlds are not created by Multiverse, but the server, and are also outside of MV's control.

With that said, I'll be closing this issue in about two days unless someone continues to experience this issue with these settings enabled.

Server owner with NO coding experience here- If I'm reading this correctly, we need to update to 1.16.3 to fix the issue of an End portal not generating in an End world?

Long story short, our End glitched. The dragon wouldn't respawn. We reset the end, and then the return portal vanished and would not regenerate, even when my admin deleted the region and forced it to regen.
We ended up generating a new end world and deleting the old one. Dragon was defeated... and no new portal generated.
The little portals that are supposed to take players to the outer islands in the End are also not working, in either of our two End worlds.
In our second End world, the return portal spits out at the nether portal at Spawn. Or, apparently, whatever nether portal the player last used. (We're experimenting with it now.)

So now what? We're using MultiVerse Core, Inventories, and NetherPortals.
I've checked and "allow end world" and "allow nether world" are enabled as mentioned above.

MultiVerse has been updated to the latest version. We're in 1.16.1.
Will updating to 1.16.3 fix this?

@ShirubaKame can you send to output of /mvversion -p.

Hopefully I've done this right. My admin issued the command in-game, and the log returned this:

[12:12:12] [Server thread/INFO]: o_oHerobrine issued server command: /mvversion -p
[12:12:12] [Server thread/INFO]: [Multiverse-Inventories] Multiverse-Inventories Version: 3.0.0-b459
[12:12:12] [Server thread/INFO]: [Multiverse-Inventories] First Run: true
[12:12:12] [Server thread/INFO]: [Multiverse-Inventories] Using Bypass: false
[12:12:12] [Server thread/INFO]: [Multiverse-Inventories] Default Ungrouped Worlds: false
[12:12:12] [Server thread/INFO]: [Multiverse-Inventories] Using GameMode Profiles: false
[12:12:12] [Server thread/INFO]: [Multiverse-Inventories] === Groups ===
[12:12:12] [Server thread/INFO]: [Multiverse-Inventories] default: {Worlds: [32618hrupdate, 32618hrupdate_nether, 32618hrupdate_the_end, restend], Shares: [hit_points, economy, food_level, saturation, exhaustion, xp, total_xp, lvl, inventory_contents, armor_contents, bed_spawn, maximum_air, remaining_air, fall_distance, fire_ticks, potion_effects, last_location, ender_chest, off_hand]}
[12:12:12] [Server thread/INFO]: [Multiverse-Inventories] HerosQuest: {Worlds: [herosquest, herosquest_theend, hqnether_nether, herosquest_nether], Shares: [hit_points, economy, food_level, saturation, exhaustion, xp, total_xp, lvl, inventory_contents, armor_contents, bed_spawn, maximum_air, remaining_air, fall_distance, fire_ticks, potion_effects, last_location, ender_chest, off_hand]}
[12:12:12] [Server thread/ERROR]: Could not pass event MVVersionEvent to Multiverse-NetherPortals v4.2.1-b786
org.bukkit.event.EventException: null
at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:319) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at org.bukkit.plugin.SimplePluginManager.fireEvent(SimplePluginManager.java:589) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:576) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at com.onarandombox.MultiverseCore.commands.VersionCommand.runCommand(VersionCommand.java:153) ~[?:?]
at com.onarandombox.commandhandler.CommandHandler.checkAndRunCommand(CommandHandler.java:296) ~[?:?]
at com.onarandombox.commandhandler.CommandHandler.processFoundCommands(CommandHandler.java:143) ~[?:?]
at com.onarandombox.commandhandler.CommandHandler.locateAndRunCommand(CommandHandler.java:93) ~[?:?]
at com.onarandombox.MultiverseCore.MultiverseCore.onCommand(MultiverseCore.java:910) ~[?:?]
at org.bukkit.command.PluginCommand.execute(PluginCommand.java:45) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:149) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at org.bukkit.craftbukkit.v1_16_R1.CraftServer.dispatchCommand(CraftServer.java:755) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.PlayerConnection.handleCommand(PlayerConnection.java:1703) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.PlayerConnection.a(PlayerConnection.java:1546) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.PacketPlayInChat.a(PacketPlayInChat.java:47) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.PacketPlayInChat.a(PacketPlayInChat.java:1) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.PlayerConnectionUtils.lambda$0(PlayerConnectionUtils.java:19) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.TickTask.run(SourceFile:18) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.IAsyncTaskHandler.executeTask(SourceFile:144) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.IAsyncTaskHandlerReentrant.executeTask(SourceFile:23) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.IAsyncTaskHandler.executeNext(SourceFile:118) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.MinecraftServer.aZ(MinecraftServer.java:943) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.MinecraftServer.executeNext(MinecraftServer.java:936) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.IAsyncTaskHandler.executeAll(SourceFile:103) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.MinecraftServer.sleepForTick(MinecraftServer.java:919) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.MinecraftServer.v(MinecraftServer.java:852) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at net.minecraft.server.v1_16_R1.MinecraftServer.lambda$0(MinecraftServer.java:164) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_262]
Caused by: java.lang.NoSuchMethodError: com.onarandombox.MultiverseCore.event.MVVersionEvent.putDetailedVersionInfo(Ljava/lang/String;Ljava/io/File;)V
at com.onarandombox.MultiverseNetherPortals.listeners.MVNPCoreListener.versionEvent(MVNPCoreListener.java:40) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_262]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_262]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_262]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_262]
at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:315) ~[spigot_1.16.1.jar:git-Spigot-0287a20-7560f5f]
... 27 more
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] Multiverse-Core Version: 4.1.0-b775
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] Bukkit Version: git-Spigot-0287a20-7560f5f (MC: 1.16.1)
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] Loaded Worlds: [{"MVWorld@1137872791":{"Gen":"null","Type":"NORMAL","Env":"NORMAL","Name":"HerosQuest"}}, {"MVWorld@12011269":{"Gen":"null","Type":"NORMAL","Env":"THE_END","Name":"HerosQuest_theend"}}, {"MVWorld@2122078272":{"Gen":"null","Type":"NORMAL","Env":"THE_END","Name":"RestEnd"}}, {"MVWorld@15965831":{"Gen":"null","Type":"NORMAL","Env":"THE_END","Name":"32618HRUpdate_the_end"}}, {"MVWorld@1468663609":{"Gen":"null","Type":"NORMAL","Env":"NETHER","Name":"HerosQuest_Nether"}}, {"MVWorld@1841298850":{"Gen":"null","Type":"NORMAL","Env":"NORMAL","Name":"32618HRUpdate"}}, {"MVWorld@1897731597":{"Gen":"null","Type":"NORMAL","Env":"NETHER","Name":"32618HRUpdate_nether"}}]
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] Multiverse Plugins Loaded: 2
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] Economy being used: Essentials Economy
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] Permissions Plugin: Bukkit Permissions (SuperPerms)
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] Dumping Config Values: (version 2.9)
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] messagecooldown: 5000
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] teleportcooldown: 1000
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] worldnameprefix: true
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] worldnameprefixFormat: [%world%]%chat%
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] enforceaccess: false
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] displaypermerrors: true
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] teleportintercept: true
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] firstspawnoverride: true
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] firstspawnworld: 32618HRUpdate
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] debug: 0
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Core] Special Code: FRN002
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Inventories] Multiverse-Inventories Version: 3.0.0-b459
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Inventories] First Run: true
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Inventories] Using Bypass: false
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Inventories] Default Ungrouped Worlds: false
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Inventories] Using GameMode Profiles: false
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Inventories] === Groups ===
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Inventories] default: {Worlds: [32618hrupdate, 32618hrupdate_nether, 32618hrupdate_the_end, restend], Shares: [hit_points, economy, food_level, saturation, exhaustion, xp, total_xp, lvl, inventory_contents, armor_contents, bed_spawn, maximum_air, remaining_air, fall_distance, fire_ticks, potion_effects, last_location, ender_chest, off_hand]}
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-Inventories] HerosQuest: {Worlds: [herosquest, herosquest_theend, hqnether_nether, herosquest_nether], Shares: [hit_points, economy, food_level, saturation, exhaustion, xp, total_xp, lvl, inventory_contents, armor_contents, bed_spawn, maximum_air, remaining_air, fall_distance, fire_ticks, potion_effects, last_location, ender_chest, off_hand]}
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] Multiverse-NetherPortals Version: 4.2.1-b786
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] Nether Prefix:
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] Nether Suffix: _nether
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] End Prefix:
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] End Suffix: _the_end
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] Nether Links: {HerosQuest=HerosQuest_Nether, HerosQuest_Nether=HerosQuest, HQNether_nether=HerosQuest}
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] End Links: {HerosQuest=HerosQuest_theend, HerosQuest_theend=HerosQuest, RestEnd=32618HRUpdate, 32618HRUpdate_the_end=32618HRUpdate, 32618HRUpdate=RestEnd}
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] Bounceback: true
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] Teleport Entities: true
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] Send Disabled Portal Message: true
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] Send No Destination Message: true
[12:12:12] [Server thread/INFO]: [Multiverse-Core] [Multiverse-NetherPortals] Special Code: FRN001

update your mc version to 1.16.3 and all mv version to the latest, you have outdated mv plugin causing errors. /mvversion -p should give you a link.

The world 32618HRUpdate_the_end shouldn't still be showing up. That's the world we removed (or tried to) from the group because it was glitching. The new End world is RestEnd.

The worlds should be grouped as follows:
32618HRUpdate (overworld)
32618HRUpdate_Nether
RestEnd_the_end

and
HerosQuest (overworld)
HerosQuest_Nether
HerosQuest_theend

The naming doesn't seem right on a couple of these, I'm not sure if that's affecting things too?
We would've renamed the default world (32618HRUpdate) to "HerosRest" for better clarity, but the name of the file was generated into our PEX and we don't like to make any changes to that because it breaks on a thought.

update your mc version to 1.16.3 and all mv version to the latest, you have outdated mv plugin causing errors. /mvversion -p should give you a link.

We need to do that anyway so yes, that's a good idea. Will that fix things automatically upon restarting, or do we need to regenerate the End worlds to fix the portals? We don't have any huge builds in the End so it's no big deal to just regen or replace the files.

EDITING rather than adding another post-
Updated everything to 1.16.3.

The portals that take players to the outer islands now appear to work properly.

The return portal in the default/main end world- the RestEnd- has not generated.
The return portal in the second world remains glitched (half is missing) and when a player jumps in to the remaining part it simply spits them back out and says "your home bed was missing or obstructed."

Thoughts?

ONE LAST EDIT
After updating ALL our plugins, and updating to 1.16.3, deleting and recreating both End worlds, re-linking the end portals, now the only problem is that the HerosQuest_theend world return portal dumps players at the Heros Rest spawn.
It's a minor issue on our server, as there's a warp back to the Hero's Quest spawn.

Thanks so much for the assistance. If anyone has ideas for fixing that minor glitch in the portal link, that'd be great.

Paril commented

Not sure if related, but the issue I'm having with the 1.16.4 versions now is that the portals work when the server starts, but after a few hours they won't send anybody anywhere.

The plugin reports, as above, that it is finding a location in the nether/overworld to put them, and that they are allowed in the world because allowenforce is false, but no teleportation happens.

We have no other plugins that prevent events (apart from GP, but it doesn't prevent nether travel) that would cause this one.

Anyone still having this issue? Please note you need to set both allow-nether in server.properties and allow-end in bukkit.yml totrue.

Anyone still having this issue? Please note you need to set both allow-nether in server.properties and allow-end in bukkit.yml totrue.

Our portals are still behaving as I described above, dumping players at the original overworld spawn. Minor issue for us, but that's how they function.

We've done both those, setting the allow nether and allow end to true.

I believe you might be running into Multiverse/Multiverse-Core#2160. If the suggestion there fixes your problem, then this issue can be closed.

On the latest build and version of paper. I have a survival world linked to the world_nether and the main world (called world) is a lobby. When I enter a nether portal it takes me back to the lobby world. Can confirm it is Multiverse causing this issue because when I disable it the portals work

@AirKetchPLAYZ can you use the latest dev builds from http://ci.onarandombox.com/view/Multiverse/ and send the output of mv version -p

I'm passing this on to my admin, he knows more than I do about it. We're still having the problems though I know he updated the build. We'll try with this latest build.

@AirKetchPLAYZ can you use the latest dev builds from http://ci.onarandombox.com/view/Multiverse/ and send the output of mv version -p

https://paste.gg/p/anonymous/2854f332dbde4e16a238c0c0f8c833b7

It'll be the weekend likely before we can get down to serious testing. My admin works in payroll and tax season is rough. :) Thanks for the assist!

@AirKetchPLAYZ can you use the latest dev builds from http://ci.onarandombox.com/view/Multiverse/ and send the output of mv version -p

https://paste.gg/p/anonymous/2854f332dbde4e16a238c0c0f8c833b7

Hi, can you try without mv-inventories, or with a new test server with only mv-core and mv-netherportals if you can.

@AirKetchPLAYZ Try the latest dev build of Multiverse-Inventories, as a bug that affects last_location was fixed. It may help in this situation.

https://ci.onarandombox.com/job/Multiverse-Inventories/

So is this problem fixable without having to use world_nether world_the_end ?

No. As of 1.16, the default nether and end are required for portals to work correctly.

Closing this since we haven't heard any reports of this still being an issue. Thanks to everyone who participated.