Since Portals can run commands on activation, I wanted to see if I could make a portal that fires off /back to return to the previous destination that which one took a portal from. Currently it just places your somewhere around your arrival point, not at the departure point.

example scenario:

• One central destination, that is used as a destination for many other portals around the world, named 'Nexus'.
• Use a portal from, say, the 'CoolCity' portal.
• At 'Nexus', there is a portal that has no destination set, but does run command /back
• Take that portal which runs /back, and end up at the 'CoolCity' portal.

This scenario would be to work from coming from any portal to 'Nexus' - doesn't have to be 'CoolCity'.

Now, using /back specifically might not be the easiest since that relies on another plugin and AP appears to not use /tp like that under the hood (which is why this isn't working right now). Possibly a bespoke implementation for AP that's like /portals back, which puts you at your last portal departure...

This might also be tough due to the fact that the portal themselves and destinations are different, so a /portals back would, if I understand correctly, need to know the destination nearest from where you departed, since a portal location doesn't necessarily mean a 'destination' as defined by the plugin is at that portal.

Overall, I think it would be neat to allow something like this!

I could look to add the x y z and world names as command tags. The issue is that /tp does not support world changing. Otherwise for /back I would need to support storing the last location someone left from which wouldnt be wise as it would be just about to enter a portal.

If /portals back was implemented id be best off making it so that you are teleported back at a full 180 and moved forwards slightly so that you are not in the portal. (or opposite angle from your moving so that its more accurate).

For now I can do a quick build which will support %x %y and %z or @x @y and @z to make what you are asking for possible, how does that sound?

That %x %y and %z would be calculated from the block you were prior to moving through a portal? So, that would probably mean one would be either in the portal or one block adjacent to the portal, right?

Your idea for a potential /portals back sounds like the easiest on the user end. Perhaps an optional per-portal attribute made through use of /portals select then maybe something like /portals setback that denotes the /portals back position (which is then kept somewhere in memory and updated everytime a user passes through a portal)? Essentially a coupled portal-specific destination... though that all sounds like it might be over complicating it.

How about a return flag to define a destination? Or the location a slight bit back if not supported? Though what happens if someone is in that area after a server restart or rejoining the server and the only portals are /back portals? User temp data is removed on restart or player rejoin.

So for example, /portals create desti:desti1 name:thename triggerblock:water return:desti2 ? So, whenever a player enters that portal, they go to desti1, but the plugins assigns some temp user data of desti2 to go to if that user was to run something like /portals return (if we're going with that word choice) - that sounds pretty reasonable, though sort of clunky (as it offloads the work to the player, defining a destination at the portal when that behavior isn't enforced by the plugin, though it might be a worth the hoop jumping if one wants this functionality).

As for restart/rejoin - I feel like it can't be a huge deal, if only somewhat inconvenient for a player who was really hoping to return from hence they came after a logout/login or restart - though I guess you could make the data less temporary by assigning a return flag destination to a uuid and storing that in a file?

Additionally, I didn't consider this before since all players on the server I run have access to /back just for convenience, but a /portals back|return could be abused by those wanting an easy tp to a destination that they wouldn't otherwise have - so... we're straying into out-of-scope territory, but perhaps allow portals to grant a temporary permission to run said command? It would likely be another flag, /portals create tempperm:advancedportals.return command:"portals return" desti:location1 return:location -- though I suppose one could just do command:"^portals return".

Ill have a think this is a big feature request to store perma data and everything as the whole point of this plugin is to be lightweight and only store temp data other than the portal and destination storage. I would probably prefer to make this an addon or how like essentials does it where they include loads of jars into 1 zip so you can remove functions.

Additional notes: The point of the advanced portals was solely to create a tag system to make it simpler to customise the aspects of how the portals work with features where performance stays consistent how matter how long the server is alive for. Imagine how large files would be for any larger servers if I enabled that by default? (Hence the idea to do it as an addon)

I mean, with that all said - I still feel as though it's not a big deal that players won't have access to /portals return info upon logging back in - it seems like it would be okay to sever that connection, that it only works if you didn't logout between taking a portal and wanting to return through it.

Soley because it goes against how ive developed it so far thats why id do it as an addon.

I have started adding more features like this though due to the size and not just being a basic tag I will leave this for now but flag it as a possible addon