Hi there,

I'm setting up a bungee network with your portal plugin, and I was hoping to use an alias /hub linking to /portal warp hubportal, hubportal being an inaccessible hidden portal so players could be sent back to the hub spawn on the hub server using /hub.
However, using the command sends the player to where they last were on the server, most likely being the respective portal, which isn't exactly what I'm searching for.

I was wondering if this was a bug or if this feature could be added?

Thanks, Silicon

Changing back to the old method with a backup. Though the current one works despite the bungee API doesn't really support it because of a description so I am adding a solid way to ensure future-proofing it in case changes occur.

Future-proofing change will come in the next update.

@sekwah41 This issue seems to still be present?

Would it be possible for the feature to be added where if there is no destination specified, just the bungee server, that it would send the player to their last destination. But if you specify a destination then it overrides the last known position and sends them to the destination position?

Hi again,

So I have added the plugin to the bungee proxy, so now it's on every server in the network. I have cleared all portals and destinations and created a 'spawn' destination on the hub server, and a hubportal portal with tags bungee:hub destination:spawn in one of the other servers. Flying through this portal still sends me to my last known location in the hub server and not the hub's 'spawn' destination. Is there anything else I could do to fix this or is this a bug?

Thanks again, and sorry for the bother. Trying to find a portal plugin that sends a player to a set location in another server seems to be a nightmare and this is the only plugin I've found that has this feature.

Are you using bungee or a branch of bungee? I know there are some builds that arn't exactly bungee that are strange. I will have to take a closer look at this but I don't have the time today. As long as the destination exists on the target server and also the plugin is on the target server just listing the bungee and the name of a valid desti (caps and all i believe) on the other server should trigger it.

If this exact setup isnt working could you check the console for any logs?

That feature was actually added two updates ago. Just specify a desti: that exists on the target server as long as you used bungee: and not a command.

I set up a portal that would be out of reach to players and tested it both by going through it and using the /portal warp command. The portal was set up using /portal create name:hubportal bungee:hub desti:hubspawn. I had previously set up the hubspawn destination on the hub server but the portal still sends the player to their last location on the hub server.

oh forgot you need to put the plugin on the bungee too so it can communicate with the other server

Ahhh that's where I'm going wrong! I'll try that and test it asap! I'll close the ticket if that fixes it.

I believe I'm using the official BungeeCord from md_5, I've hosted many spigot servers in the past but this is my first multi server network with BungeeCord so I'm not an expert on it yet, this is definitely a learning experience. There was something that struck me as a bit odd that may shed some light, when placed into the Bungee proxy server, the plugin is loaded and reports as loaded from the console but no configuration is generated. I'm not sure if the integrated BungeeCord version of the plugin requires config or not so I'm not sure if this is normal, but if it is please let me know.

As for the server specific console, other than the enabling on restart which seemed successful, I can't find any errors at all from the plugin.

Thanks for looking into this for me, this plugin is my best bet at a ready-for-players portal system.

the bungeecord version just acts to bounce packets to the other server with a delay. it doesnt have a config. Do you mind uploading the portal.yml file for the server the portal is on and the destination.yml file for the server it is being sent to?

Also which version of advanced portals are you using? (probably should have been an earlier question tbh)

Sure! Here's the configs. And I'm using 0.4.0 Snapshot.

### portals.yml (Node 3 'creative') :-
hubportal:
  world: spawn
  triggerblock: NETHER_PORTAL
  destination: spawn
  bungee: hub
  pos1:
    X: -15
    Y: 93
    Z: 37
  pos2:
    X: -15
    Y: 88
    Z: 32

### destinations.yml (Node 1 'hub') :-
spawn:
  world: world
  pos:
    X: 0.5
    Y: 101.0
    Z: 72.5
    pitch: 0.038091235
    yaw: 179.97615

not sure, that looks like it should work... ill give it a look if i get some time tomorrow

That's great, thank you.

Sorry it seems the fix that someone pushed actually broke it in the last update. I will have to alter it to trigger the sending at the right time. They just made an artificial delay that doesn't seem to properly trigger though I sorta blindly trusted them as they originally added the support for this feature that worked as well as i was busy.

No worries! Glad I could bring your attention to it. Thanks for all your help with it, could you let me know when the bug is fixed so I can download the newer version?

Actually testing it, it works fine xD Ive just realise why its an issue because someone just had a completely seperate issue for the same reason. You need to have ip-forwarding enabled and the servers need to have bungee enabled in their spigot.yml files so that their uuid's are not their offline uuid's. The code shouldn't be using the uuids but rather the player the packet was sent on so that was an oversight in the code.

Does this mean it's a setup issue and not a code issue? I have ip-forwarding on and bungee enabled on all servers, but I've also been having a few errors with luck perms about uuid being the players actual uuid and not a fake one, so there might be an issue with that. If you're sure it's not a code issue I'll make sure to look into the uuid problem further, I hadn't so far as the permissions were still working fine.

It is a code issue which was missed due to how the testing server was setup i assume. I have made a fix

This file should contain the fix
Bungee desti fix.zip

Hello again, thanks for the previous fix. Unfortunately, although that has fixed the bug with the wrong player being teleported, the teleport now only happens on the first attempt. Any others by any other player causes them to be put back to their last position.

If it would help, I can invite you to the network I am attempting to build so you can test on multiple servers with multiple players?

Thanks again, and I am so sorry!

Sure, are you on my discord?

No, could you send me a link? I'll invite you to mine as well so I can introduce you to the current staff so they know why you're there (The server is still in dev so no players are allowed on)

https://discord.gg/fAJ3xJg here ya go

Thanks! And here's mine: https://discord.gg/4EXrY84