When a person changes worlds, a "TransportTicket" is created. It builds it based on the config and what triggers transport. These things can be acted upon:

• Departing from a world
• Arriving to a world
• Usage of a Multiverse Portal
• Departing an environment
• Arriving in an environment
• Departing from a WorldGuard region
• Arriving in a WorldGuard region
• Joining the server
• Respawning

I just realized I never actually tested the environment functionality yet, so YMMV for that. These are the actions it can take in those cases:

• LASTLOCATION - Take player to the last saved location on that world
• DISABLED - Do nothing
• SPAWN - Take the player to that world's spawn
• RANDOM - Take the player to a random spot in the world
• LOCATION - Take the player to a specific location

Now there is almost always going to be multiple triggers that apply to a given transportation. To determine precedence, trigger criteria has a "weight". Heavier weights sink to the bottom and get chosen last, thus being the end result. There is a default value for each trigger, these are the values:

0: Departing world
1: Arriving on world
2: Joining the server
3: Respawning
4: Departing environment
5: Arriving in environment
6: Departing a WG region
7: Arriving in a WG region
8: Use of an MV portal

So let's say a person is /MVTP'ing from "world" to "world_nether" and they are standing in a "spawn" WG region. Let's also assume this is their config:

These are the triggers that will get read in the aforementioned scenario, with the weights from the chart above:

Departing world, "world" - 0
Arriving world, "world_nether" - 1
Departing environment, "overworld" - 4
Arriving environment, "nether" - 5
Departing WG region, "spawn" - 6

So judging from that, the trigger rule for departing spawn is what will take precedence. Now what if you really want to be sure the rule for arriving in a nether takes place? You set the weight manually:

Now its weight exceeds that of the WG rule, so it now has precedence. Every trigger rule requires an action and can have its weight optionally set. The actions for random and location have other options as well. For random, you can specify a low/high range for the X and Z randomization. Y customization is irrelevent; it just lands you on the top most block. You can skip any of the values. If you do, it defaults to -20000 through 20000. So if you set X low of 500 and do not set an X high, the range for X is 500 through -20000. Be sure you do not flip flop them; if you put X low -30000 and X high 0, it will not work. For location trigger, you just need a serialized Location object. See the config example above for demos of the layout. Once the GUI config is implemented, you'll be able to just set that from the command but for now you can just copy and paste from this example to get the layout.

Some triggers have a "__global" group that can be used if you don't want to specify individual world settings. __global is recognized in the following config sections:

behavior.wgregion.__global.arriving
behavior.wgregion.__global.departing
behavior.world.__global.arriving
behavior.world.__global.departing
behavior.mvportal.__global
config.teleport-safety.unsafe-materials.__global

Other config information in the general section:

config.plugin-active
If this is false, the plugin will not do anything

config.random
This is a global random range setting. If you set this, any individual random TP will use these range values. If you leave this out, it defaults to -20k through 20k for X and Z.

config.teleport-safety.unsafe-materials.__global
This is a list of unsafe materials so when it random TPs, it will not choose a location that lands on/in those. Use Spigot standard material names ( https://hub.spigotmc.org/javadocs/spigot/org/bukkit/Material.html). Global is used for all worlds

config.teleport-safety.unsafe-materials.(world)
This is a list specific to a world. If a world has a safety list, it will use *only* the world's list. So if you want items from the global, include them in the world specific list as well.

config.teleport-safety.max-attempts
This limits how many tries it will make to find a safe block before it gives up

config.time-thresholds
These values determine how long the disabling of a save/load takes. Like when you do a blocked command, it puts the user into a map and when the command is ran, if the user is still in the map, it turns off LastLocation for this teleport. The time config is so that servers that are laggy can be given more of a window with which to provide the functionality. Leave these default unless you have problems where you block /warp or something and yet you still end up LastLocation'd and cannot figure out why.

config.blocked-commands
Pretty self explanatory. Any commands in here will not trigger LastLocation. Useful for potentially world changing things like warp, home, etc.

As of version 3.0, the only command is /ll reload which will reload the config. Permission node lastlocation.reload

I had my version 3 rewrite tabled for a few months. When I went to work on it today, I couldn't remember what the hell I was doing, lol. I ended up just deleting it all and starting over fresh. Worked out as I had a better way to handle weights, but since the code is all fresh and new I only tested it so far for an hour or so as I keep making tweaks. So I strongly suggest you first use this on a staging/test server to ensure it will work in your environment. Use at your own risk, I make no guarantees about it. It works for me, but that hardly means it'll be good for everyone.

To ensure I see your requests for help, please use the discussion tab if you need help. Don't pepper my profile or make posts in the wild on the forum. Thanks.