Teleport - general purpose teleporting tool : Miscellaneous : Elder Scrolls Online AddOns

(19 Kb)

Download

Updated: 03/13/23 03:18 AM

Add Favorite

Install Help

Compatibility:	Scribes of Fate (8.3.5) Firesong (8.2.5) Lost Depths (8.1.5) High Isle (8.0.0) Ascending Tide (7.3.5) Deadlands (7.2.5) Waking Flame (7.1.5) Blackwood (7.0.5)
Updated:	03/13/23 03:18 AM
Created:	09/15/20 07:26 PM
Monthly downloads:	284
Total downloads:	4,340
Favorites:	2
MD5:
Categories:	Miscellaneous, Homestead, Utility Mods

8.3.5

Teleport - general purpose teleporting tool

Version: 1.0.16

by: Schrodi [More]

Teleport

Teleport is a general purpose teleportation addon. It's main aim is to make teleportation a quick and pleasant experience, very different to what game offers - minutes, if not seconds (!!!) of looking trough menus, icons and lists. Ugh. The only extra feature it offers over in-game menus is teleporting to a specific house of any player. I took some ideas from BeamMeUp as well from Traveller, you may want to check them out before deciding on what to use.

There is no graphical user interface provided, everything is done using a /tp command. If you're not a keyboard person, this is probably where our ways part.

Features

Teleporting to zones for free (using party members / friends / guildies)
Teleporting to houses, other player's houses included (free, duh)
Teleporting to dungeons/arenas/trials (free if any of the party members is already in, paid otherwise)
Teleporting to specific wayshrines (always paid)

I highly suggest reading all the way trough the readme file on github. I am not going to copy-paste the entirety of it here because it's pretty long and the formatting would have to be fixed manually.

Apologies for not updating the addon for a while!

1.0.16

added Bal Sunnar and Scrivener's Hall
removed some old, unused aliases
changed addAlias, delAlias and lstAlias commands to --add, --remove and --list
changed SurveyMaps command to surveymaps
updated readme

1.0.15

added Galen zone (yes, finally applies here as well)
added a new feature - travel to a reset instance rDungeonAlias, similar to previously available nDungeonAlias or vDungeonAlias, ie.
nKA - normal Kyne's Aegis
rCA - reset instance of Coral Aerie
vSS - veteran Sunspire Resets the instance or assumes that instance was already reset by a group leader. This is always a paid teleport. Same as with other paid teleports, you can mitigate the cost by having a wayshrine menu open.

1.0.14

added Earthen Root Enclave and Graven Deep dungeons (finally)
added a new feature - travel to survey map zones from your inventory /tp SurveyMaps - it can be aliased just like any other command

1.0.13

- updated for High Isle
- fixed a minor issue regarding teleporting to zones that prevent fast travel

1.0.12

updated for Deadlands
FINALLY added Rockgrove
and two """new""" dungeons: Red Petal Bastion, The Dread Cellar
@userId in info chat messages is now clickable
removed some uncommon dungeon/arena aliases

1.0.11

updated for Blackwood

1.0.10

added two new dungeons
added the ability to teleport outside of owned houses

1.0.9

improved alphabetical sorting for wayshrines, now the " Wayshrine" suffix is ignored
some internal changes and refactoring that shouldn't affect end-user experience

1.0.8

restored the ability to travel to houses you don't own (preview mode)

1.0.7

changed how wayshrines are handled (restored "wayshrine" suffix in names)
fixed group difficulty settings being read incorrectly at times
added zone aliases
other minor or major improvements not directly visible to the users

1.0.6

improved dungeon difficulty changing for groups
fixed dungeon difficulty changing when not in a group

1.0.5

added "The Reach" to the zones list

1.0.4

fixed an issue with aliases starting with 'n' or 'v' (Vateshran Hollows)

1.0.3

updated for Markarth

1.0.2

fixed pre-defined aliases being broken for trials and dungeons (thanks to my trigger-happy regex replace)

1.0.1

added sanity check for addAlias
minor refactoring, stop leaking global variables all over the place

1.0

initial release

Optional Files (0)

Archived Files (12)

File Name	Version	Size	Uploader	Date
Teleport - general purpose teleporting tool	1.0.13	18kB	Schrodi	06/09/22 08:42 AM
Teleport - general purpose teleporting tool	1.0.12	17kB	Schrodi	12/03/21 06:24 AM
Teleport - general purpose teleporting tool	1.0.11	17kB	Schrodi	07/07/21 01:40 PM
Teleport - general purpose teleporting tool	1.0.10	17kB	Schrodi	03/14/21 05:02 PM
Teleport - general purpose teleporting tool	1.0.9	17kB	Schrodi	02/08/21 01:12 PM
Teleport - general purpose teleporting tool	1.0.8	17kB	Schrodi	12/12/20 03:25 PM
Teleport - general purpose teleporting tool	1.0.6	20kB	Schrodi	11/06/20 04:28 PM
Teleport - general purpose teleporting tool	1.0.5	21kB	Schrodi	11/03/20 07:28 PM
Teleport - general purpose teleporting tool	1.0.4	21kB	Schrodi	11/03/20 09:49 AM
Teleport - general purpose teleporting tool	1.0.2	21kB	Schrodi	09/17/20 05:07 PM
Teleport - general purpose teleporting tool	1.0.1	21kB	Schrodi	09/17/20 06:57 AM
Teleport - general purpose teleporting tool	1.0	20kB		09/15/20 07:26 PM

Comment Options

09/17/20, 04:29 PM

Schrodi

Forum posts: 0

File comments: 4

Uploads: 4

You define the load order in your addon's manifest txt file, and it's consistent this way, means always will load in the same order for 1 addon!

Now that sounds suprisingly reasonable, I think I could abuse it a little bit but I don't think I'm gonna bother (for now.)

09/17/20, 01:30 PM

Baertram

Super Moderator

Forum posts: 4439

File comments: 5523

Uploads: 77

You define the load order in your addon's manifest txt file, and it's consistent this way, means always will load in the same order for 1 addon!
Loaded from top to bottom, just like the lua code files are read from top to bottom so local variables/functions need to be defined before (on top of) their usage.

Adding other dependencies/addons will change the load order of the addons, but NOT the load order of files defined in these addons txt files!
Within the manifest txt files you can use ## DependsOn or ## OptionalDependsOn: otherAddonName1>=[IntegerVersionOfThisAddon compared to it's manifest ## AddOnVersion tag]
to assure that these other versions/libraries are loaded before your addon.
Their EVENT_ADD_ON_LOADED will be fired before yours then and the game will make ure that other addon/lib's files from these addons/libs manifest txt will also all be loaded before your addon, which depends on it, is loaded.

The load order of addon folders/manifest txt files will start at Z (because of ZOs_ files) and go up to A, respecting all the ## (Optional)DependsOn in all txt files to build a load order in total.
You can use LibDebugLogger and DebugLogViewer addons to show the load order in the DebugLogViewer UI ingame e.g.

Originally Posted by Schrodi

Is the file load order predictable and consistent or do we have any other idea about how the game loads multi-file addons?

Last edited by Baertram : 09/17/20 at 01:32 PM.

09/17/20, 09:29 AM

Schrodi

Forum posts: 0

File comments: 4

Uploads: 4

All variables declared, if not using "local" up infront of them, will be known to the global table _G

Ikr, I just expected that every addon runs in it's own scope/sandbox.

Best practice is to define 1 global variable for your addon, which's name is similar to your addon but at least UNIQUE

In such case it would be the best it's name was exactly the same as addon's name to avoid possible conflicts (and that's what I did in 1.0.1). An addon called Teleport Tool already exists and so does Teleporter.

in the first lua file which is loaded from your manifest txt, and all other files can e.g. use this simple line to reuse the same table contents, or build a new table if it was not existing yet

Is the file load order predictable and consistent or do we have any other idea about how the game loads multi-file addons?

09/17/20, 08:39 AM

Baertram

Super Moderator

Forum posts: 4439

File comments: 5523

Uploads: 77

Originally Posted by Schrodi

Wait, addons are not running in separate contexts? Well, the more I know now. I assumed there's a more refined way of registering my own and calling other addons' public APIs than just leaking global variables all over the place. Eh.

I'll """fix""" it and submit an update, thanks for letting me know about the issue.

All variables declared, if not using "local" up infront of them, will be known to the global table _G, so
if you declare myVar it will be _G["myVar"], or _G.myVar (both are the same).
If you add

Code:

local

they will be declared locally to your context/scope, e.g. at the start of your addon file -> Known to the whole file.
Inside an if ... end / for do ... end/function -> Only inside this if's/for's/function's scope!

Best practice is to define 1 global variable for your addon, which's name is similar to your addon but at least UNIQUE, e.g. Teleport could be reused in many addons so better use something like TeleportTool or TELEPORTTOOL (the variables are case sensitive!).
And then add your functions, tables, variables to it.
Or just use local variables if your addon does not need to expose anything globally.

If your addon got multiple files you can define

Code:

TeleportTool  = {}
local tt = TeleportTool  
tt.variable1 = "Hello world"

in the first lua file which is loaded from your manifest txt, and all other files can e.g. use this simple line to reuse the same table contents, or build a new table if it was not existing yet:

Code:

TeleportTool = TeleportTool  or {}

In your second file you can also access it via a local tt = TeleportTool again and reuse the assigned variable tt.variable1 then, or add new ones.

Or you only build some global API functions within your addon providing the data etc. you want to expose.

Last edited by Baertram : 09/17/20 at 08:43 AM.

09/17/20, 05:44 AM
Schrodi Forum posts: 0 File comments: 4 Uploads: 4	Wait, addons are not running in separate contexts? Well, the more I know now. I assumed there's a more refined way of registering my own and calling other addons' public APIs than just leaking global variables all over the place. Eh. I'll """fix""" it and submit an update, thanks for letting me know about the issue.

09/16/20, 07:49 AM
Baertram Super Moderator Forum posts: 4439 File comments: 5523 Uploads: 77	Correct. Please change the names of the global variables, or add them as local to your addon or add like 1 global table of your addon e.g. TeleportTool = {} and then add the variables to your global table ... TeleportTool.Zones = {} ... and use the variable TeleportTool.Zones, TeleportTool.Players etc. in your addon's scope. Else every other variable called Zones or Players will be overwritten by your global variables, and this is what zelenin said you will "break" other addons (or maybe even ZOs code) by these "leaking global vars". These global variables are only needed though if you want other addons have access to your addon OR if you are using mutiple files in your addon. Else defining them local at the top of your 1 addon file should be enough. Last edited by Baertram : 09/16/20 at 07:50 AM.

09/16/20, 04:35 AM
zelenin Forum posts: 7 File comments: 177 Uploads: 12	Code: Aliases = { } Dungeons = { } Helpers = { } Houses = { } Nodes = {} Players = { } Wayshrines = {} Zones = { } you add these objects with very common names to the global scope. You will break other add-ons that did the same careless thing or wil be broken yourself.

Report this File