[Script] Map Teleporters - Updated w/ Automated Demo Campaign

I posted a version of this script  a year ago but never found a chance to use it in any of my campaigns until just recently. When I went to use it I found the existing implementation wanting, so I redid some of the token/teleporter detection. Got to use it in my campaign this past Saturday and it went great! Players had a lot of fun and much ooo'ing and aww'ing was had. I've updated my gist with the latest version:  MapTeleporters Also I finally did what I talked about doing a year ago, and set up an automated demo campaign using part of the map I used on my campaign. All you need to do is join the campaign, launch the game, and say "!test" in chat, and it'll create a token for you to move around the map and teleport around:  Try it out here!

Wow! 

That's an incredible demo, and a very impressive script.

Wow, very nice script and demo. I think I have some uses for it :)

I was like WOW. I thought of some many things I could do with that script that ranged from hex crawl, dungeon crawl, to urban exploration.

I just tested this out and it's very cool! I can't wait to try it in some of my games!

I am using the old version (which is a fantastic idea, and thank you for it) and I have some issues. My group is using TeamSpeak and I had a player's token that kept automoving back to the teleporter when they would use hit dice (D&D5e), or make a change to hitpoints. I don;t know if its because of TS, and I don't know if this would carry over to your new script or not. My question is: will my existing teleporters still work, ie: is the name-format for the teleport locations the same, or do I need to redo all of them if I use this new script? 

That's pretty darn cool. Nice job!

Kimli said: I am using the old version (which is a fantastic idea, and thank you for it) and I have some issues. My group is using TeamSpeak and I had a player's token that kept automoving back to the teleporter when they would use hit dice (D&D5e), or make a change to hitpoints. I don;t know if its because of TS, and I don't know if this would carry over to your new script or not. My question is: will my existing teleporters still work, ie: is the name-format for the teleport locations the same, or do I need to redo all of them if I use this new script?  Existing teleporters should continue to function perfectly, as I haven't made any changes to the teleporter naming control logic. Only naming related change was I removed the need to use "Teleporter" in the name of every teleporter. It doesn't hurt if you do, it just gives you more options. I'm pretty sure I fixed that bug too! Turned out I wasn't checking whether the token to "teleport" was in the object layer, which meant that if the GMLayer token on another map which was sitting on a teleporter got updated it would try to re-teleport the player. Also, I still have no clue why this was happening, but if you've also been experiencing issues with random map layer elements getting moved to the object layer and teleported around, that is also fixed. Only Object layer tokens can now trigger a teleport.

Pretty neat!  You might want to restrict your teleportation to only when the token is moved, as right now adding a statusmarker or changing the bars will trigger the move, which might cause some confusion if battle ensues before the token moves off the stairs. =D

The Aaron said: Pretty neat!  You might want to restrict your teleportation to only when the token is moved, as right now adding a statusmarker or changing the bars will trigger the move, which might cause some confusion if battle ensues before the token moves off the stairs. =D Didn't realize registering for events like 'change:graphic:left' was a thing. Thanks for the tip! Updating the gist and demo now.

Kimli said: ...I had a player's token that kept automoving back to the teleporter when they would use hit dice (D&D5e), or make a change to hitpoints. Just added another fix suggested by The Aaron . Now you can make changes to hitpoints while standing on the stairs and it won't teleport you back!

Now combat sequences on stairs can be ran up and down and across rooftops. :D

Thanks for the update. I'll be test driving it again soon.. good work and thanks again.

Thanks, FinalFrog, and thanks for backward compatibility. 

So I am having a problem with this script, I have it set up correctly but for some reason the 2 way teleport doesn't work. When moving a player token onto Teleport01A it swaps them to Teleport01B and hides the token correctly on MAP1 but when moving the token off and then back onto Teleport01B which is located on MAP2 it won't toggle them between the maps for whatever reason. Any insight as to why this would occur? Edit: I got it working, I hadn't realized that I had made another Teleport01A token on Map 1 once I deleted it the tokens moved back and forth without issue.

I just read through the script. Very thoroughly documented. Thanks, that helps javascript-challenged folks like myself understand how the API works.

I wasn't able to test this in your demo game, but the previous version of this script did not work well with "large" tokens (tokens 2x2 or larger) has this been addressed?  I absolutely love this script, I just wasn't able to use it in my last campaign because one of my players had a large animal companion, and changes to the token while on a teleporter activated it.

Brusana said: I wasn't able to test this in your demo game, but the previous version of this script did not work well with "large" tokens (tokens 2x2 or larger) has this been addressed?  I absolutely love this script, I just wasn't able to use it in my last campaign because one of my players had a large animal companion, and changes to the token while on a teleporter activated it. For me at least I haven't run into any issues in my testing with Larger tokens besides the fact that it is very easy to trigger the map switch.

Brusana said: I wasn't able to test this in your demo game, but the previous version of this script did not work well with "large" tokens (tokens 2x2 or larger) has this been addressed?  I absolutely love this script, I just wasn't able to use it in my last campaign because one of my players had a large animal companion, and changes to the token while on a teleporter activated it. I didn't have issues with this last weekend. I'll add a token macro to switch token between 2x2 and 1x1 so you can test it out for yourself. Edit: Okay, should be good to test. Say "!big" to change all your tokens to 2x2 and "!small" to change them back to 1x1. I did a quick check and there is one quirk with teleporting 2x2 tokens. For some reason it centers the 2x2 token on the 1x1 destination teleporter, and trying to adjust it will teleport you back. I'll see if I can fix that tonight after I get home from work. Shouldn't be too hard to compute the token's relative offset from the source teleport and preserve that when placing it on the destination teleporter.

FinalFrog said: I did a quick check and there is one quirk with teleporting 2x2 tokens. For some reason it centers the 2x2 token on the 1x1 destination teleporter, and trying to adjust it will teleport you back. I'll see if I can fix that tonight after I get home from work. Shouldn't be too hard to compute the token's relative offset from the source teleport and preserve that when placing it on the destination teleporter. Awesome thank you for looking into that issue.

Gist and demo updated! Tokens larger than 1x1 will preserve their offset on the source token when teleported to a destination token. Just be aware that this doesn't take dynamic lighting movement restrictions into account, so the token may end up stuck in a wall if you're not careful with teleporter placement. To see an example of this move a large token in the demo onto both of the left side teleporters of the Northeast tower of the battlements. If you run into this in the demo just say "!fix" and it will move you back to the center of the map. (this also moves your token to the object layer if you run into an issue I saw earlier where I couldn't see my token) Additionally I've also fixed an issue with the demo where creating more than one character with "!test" would create duplicate tokens that behave weirdly. Now if you say "!test" while you already have a character it will center your character's token and make sure it is visible instead of creating a second character and token. Also, I cleaned up all the characters in the demo since it was getting pretty cluttered. Just run "!test" again to make a new character.

I haven't yet installed this (I usually wait for community feedback to polish a script if I don't have an immediate need), but I do have a question. In your demo campaign, the player always sees their token in the same spot in the window (not scrolled off one of the edges). Do your pages and maps need to be of the same size and in register for this, or does something in the script account for position?

This is very awesome! And timely as I have a multi-level castle with many stairs. Each level is a different page. I imagine, though, only one teleporter token could be in a space? So, for ladders that on a level could go up as well as down, I'd have to offset them?

keithcurtis said: Do your pages and maps need to be of the same size and in register for this, or does something in the script account for position? There's no dependency between the position or page size of the source and destination teleporters. You can link a 2x2 page to a 30x1 page to a 40x40 page and it wouldn't have any problems. In the original version in the campaign I'm running there's actually a working hidden staircase in one of the houses leading down to a dungeon that's slightly smaller than the above-ground map. (I kept it disabled by adding a _ in front of the working teleporter name until the players discovered it). I didn't include it in the demo because my players haven't finished exploring it yet, but I might add it later.

Doug E. said: I imagine, though, only one teleporter token could be in a space? So, for ladders that on a level could go up as well as down, I'd have to offset them? Yeah, that would be kinda tricky. Best solution I can think of to connect three stories with only a 1 square teleporter on each would be to name them something like Teleport03A ,Teleport03B, and Teleport03C so that there's a one directional loop across all three floors. It would be a little weird if you wanted it to represent stories like in the demo because you'd go F1->F2->F3->F1->etc. If you didn't mind having to manage the teleporters a little you could do something like name the F1 teleporter "Down_Ladder02A", the F2 teleporter "_Ladder02B", and the F3 teleporter "Up_Ladder0A". Then you could manually switch the F2 teleporter from a down/up ladder at the player's request by changing the name between "Down_Ladder02B" and "Up_Ladder02B".

Could you have a teleporter that takes the player to a ladder or stair graphic (on same page or elsewhere) with an "Up" teleporter at the top and a "Down" teleporter at the bottom? Or logic in the teleporter that prompts the player for up or down for some tokens? Instead of going 01 > 02 > 03, if a character steps onto a median value (02), the script could prompt for up or down.

keithcurtis said: Could you have a teleporter that takes the player to a ladder or stair graphic (on same page or elsewhere) with an "Up" teleporter at the top and a "Down" teleporter at the bottom? Or logic in the teleporter that prompts the player for up or down for some tokens? Instead of going 01 > 02 > 03, if a character steps onto a median value (02), the script could prompt for up or down. You just earned yourself a place in the script's credits! I think this a great idea even for one-way teleporters so the player doesn't automatically get teleported unless they actually want to teleport. Just search for all the teleporters overlapping the player's token and give them a choice of which to use (plus the option of none). I'll leave the current functionality as default for backwards compatibility's sake and offer the Prompt Mode as an config option alternative.

Woot! "This is the kind of spontaneous publicity that makes people!"

Awesome that the prompt option will be implemented, I have a question since I haven't had time to test it out. Say we re-use a teleport for example we have maps 1, 2, 3 have teleport tokens named 01A, B, C respectively. If we make maps 4, 5, 6 with that same naming convention of 01A, B, C what would the script choose? The newer tokens first or would it just not work since there are multiple copies of that same naming convention?

I have been pondering a question. Would it be possible to setup the teleporters to send the tokens to a random selection. Say you have 6 maps that are similar and you want the PCs to be randomly shifted between the pages. The idea is for a maze exploration game I'm thinking about making.

Ziaphas Zain said: Awesome that the prompt option will be implemented, I have a question since I haven't had time to test it out. Say we re-use a teleport for example we have maps 1, 2, 3 have teleport tokens named 01A, B, C respectively. If we make maps 4, 5, 6 with that same naming convention of 01A, B, C what would the script choose? The newer tokens first or would it just not work since there are multiple copies of that same naming convention? I'd say the behavior is undefined right now. The script would select the first matching destination teleporter in the list returned by the findObj API function. The Roll20 API documentation doesn't specify how the order of that list is determined.

Pat S. said: I have been pondering a question. Would it be possible to setup the teleporters to send the tokens to a random selection. Say you have 6 maps that are similar and you want the PCs to be randomly shifted between the pages. The idea is for a maze exploration game I'm thinking about making. Interesting. Right now only the letters A through L are valid letters for a teleporter, so it wouldn't break compatibility to add R as a special case. Since it's random and doesn't need to have a deterministic order you wouldn't need to specify the number of teleporters. I'll add it to my to-do list of features. Implementation will probably be to have teleporters ending with "00R" search for and pick a random teleporter with the same name (filtering out itself of course).

Thinking about the Prompt Mode some more, right now the only identifier for teleporters is their name, which due to the limitations of the implementation is not very immersive. If the prompt is going to be visible to players I should provide a way for users to specify a player friendly name for teleporters. Right now my plan for that is to check the current bar 1 value of the teleporter. If it's non-empty I'll refer to it by that name in the prompt, otherwise I'll refer to it by the default teleporter name. That way you can make a teleporter named "RandomTeleport00R" show up for players as "Mysterious Rune".

You could also use the GM Notes section, which would allow for styled text, or for players clever about formatting, macros, API buttons or graphic links.

Honestly the naming scheme was a bit of a hold over from Teleporter Without Movement Tracker which I essentially just squashed with MapChange to create the original implementation of this script. It would break compatibility but I wouldn't mind doing a refactor at some point and move all the values controling the linking and looping behavior of teleporters into the current/max bar values, the aura value, and/or GM Notes as keithcurtis suggested.

Quick question: I noticed that for me the teleporter token gets clustered with the player token that teleport from it and after one or two players used a teleporter it got way trickier to activate it if it even activated. After moving the player token away from the teleporter token on the gm layer it worked like a charm again. Am I the only one that is experiencing this? And how would that be solvable?

Some odd behavior I noticed in testing. Currently, all PCs in my campaign are controlled by the player and a dummy account called "Camera" that I use for recording video of the game. The Camera account controls all PCs so that the video shows everything that is being seen. When a such token representing a character steps on a teleporter, the token goes to the GM layer, but the "camera" player's view stays on that map. As I'm typing, I realize that there might not be a good solution for this. The camera needs to follow the current player, not just the one who last teleported. Hmm. The script works great. I'm not sure I can use it in play, though.

Philip E. said: Quick question: I noticed that for me the teleporter token gets clustered with the player token that teleport from it and after one or two players used a teleporter it got way trickier to activate it if it even activated. After moving the player token away from the teleporter token on the gm layer it worked like a charm again. Am I the only one that is experiencing this? And how would that be solvable? Haven't experienced that problem myself, but I'll look through the teleporter finding code. I can probably improve the detection algorithm a little to improve reliability of detecting collisions between tokens and teleporters.

keithcurtis said: Some odd behavior I noticed in testing. Currently, all PCs in my campaign are controlled by the player and a dummy account called "Camera" that I use for recording video of the game. The Camera account controls all PCs so that the video shows everything that is being seen. When a such token representing a character steps on a teleporter, the token goes to the GM layer, but the "camera" player's view stays on that map. As I'm typing, I realize that there might not be a good solution for this. The camera needs to follow the current player, not just the one who last teleported. Hmm. The script works great. I'm not sure I can use it in play, though. I might be able to make some modifications to help, but I'll need a little more info. What players control the character representing the Camera? Right now the script assumes that each token represents a character controlled by only one player, so it grabs the first player in the list of controlling players and runs with it. If the camera only needs to be controllable by the Camera player account, try and remove all other controlling accounts on it's character. If the camera needs to be controlled by all players but you only want the camera player to be moved to another page, then I could make a tweak where a player id can be specified in the GM Notes of a token so that when the token is teleported it moved that player instead of the first one in the list of controlling players.

Thanks for the offer, but I think the concept itself is unworkable for recording. If Bobby the Barbarian were to go upstairs, and the recording followed him, I would need to switch back to Hank the Ranger in the basement on his turn, but only for his turn. And then if there is a goblin in the basement and a goblin in the attic, but both act on the same round, I would have to switch manually anyway. I might use it for teleporting within a single map, since I often shift ping to pull the camera anyway. For what it's worth, if you come up with a brilliant solution, sometimes I have used "All Players" for any PC, or Player + my dummy account, named "Camera". The Aaron teased me once because I forgot I was logged in that way and posted on the forum as "Camera".

keithcurtis said: The Aaron teased me once because I forgot I was logged in that way and posted on the forum as "Camera".

Quick update: I identified the problem keithcurtis was having with gmlayer player tokens interfering with teleports. Turns out I was essentially grabbing the first overlapping token in the gmlayer, seeing if it had a coresponding destination teleporter, then returning! Apparently it works so long as the teleporters were added to the page before the tokens being teleported. I have a fix but looping through the overlapping tokens required a little restructuring of the code. I took the opportunity to add better logging and comments, plus a couple of other minor features which arose from the restructuring: 1. The collisions check detects if any part of the token and source teleporter overlap. Previously tokens would only teleport if their center overlapped with the source teleporter. 2. The improved collision detection now means that teleporters larger than 1x1 will function like you'd expect, so long as the source and destination are the same size. 3. "But won't I be teleported if I move my token within a teleporter larger than 1x1?" you ask. Not any more! Now the script checks the token's 'lastmove' value and only triggers a teleport if the token's previous position did not overlap the teleporter. 4. As part of the fix for the bug keithcurtis reported I now loop through all the overlapping gmlayer tokens with a name and check to see if there is a valid destination on a page with a corresponding token. 5. Changed handling of characters controlled by more than one player to be more consistent (previously it basically picked the first thing in the listi and ran with it). If all the players control a token and it is teleported to another page the players will be united onto the destination page. If more than one player controls a token then all controlling players will be moved to the destination page. I still need to test these changes and may need to make some adjustments to the collision check for maps which use hexes, but I'll leave you with some interesting potential applications of these changes: * Connecting 2 square wide hallways with matched 2x1 teleporters * Creating single teleporter which splits the party by teleporting different players to different maps (Use same destination name on multiple pages and place player tokens only on the maps to which you want the teleporter to take them) * Allow tokens significantly larger than teleporter to use it reliably (ex. 3x3 token and 1x1 teleporters) * Elevator encounters where players can move around inside of elevator without being teleported back. * Reliable and accurate teleportation if grid is disable

Curious - is there a way I can set a teleporter to only work upon a password? When the player steps on the teleporter tile, a pop up window would open and if they put in the correct phrase, it will teleport them.

I had hacked this same script a while back to add combinations based on token status markers:&nbsp; <a href="https://app.roll20.net/forum/post/6195307/script-u" rel="nofollow">https://app.roll20.net/forum/post/6195307/script-u</a>...

The Aaron said: I had hacked this same script a while back to add combinations based on token status markers:&nbsp; <a href="https://app.roll20.net/forum/post/6195307/script-u" rel="nofollow">https://app.roll20.net/forum/post/6195307/script-u</a>... That's awesome! Hadn't seen that before.

Feel free to lift any changes you want out of there. =D

Question, I know your documentation states that the numbers, example Teleport02, expect 2 tokens in the chain. Now I have a map that I have set up for intra map teleporting for the different levels. I have been trying to get it to work correctly, and since it is a circular staircase that separates the levels. I have A being the bottom level marker and have the tokens in ascending order, B,C,D,E,F,G,H. The problem I am running into at this point is two fold. First is that H will not go back down to G, and if I set the token chain to 08 it will just cycle down to A. Second is that I can't for the life of me get the chain to work properly even if I set it to Teleport02, A and B work without issue and will teleport solely in between them. Those after them is where it gets weird C to D Teleport works only one way, and going back onto D teleports to E, same applies to the following letters as well any ideas? Edit: This all started as me not wanting to make 5+ maps for the separate levels for this thing so I don't know if that influences this or not.

It appears the implementation is A&gt;B&gt;C&gt;A. So, the chain cannot go C&gt;B&gt;A. This is the experience I have had. I have a circular stairwell that is 1X1 (it could just as well be a ladder). I believe some prompting logic is in the works to handle up vs down.

Doug E. said: It appears the implementation is A&gt;B&gt;C&gt;A. So, the chain cannot go C&gt;B&gt;A. This is the experience I have had. I have a circular stairwell that is 1X1 (it could just as well be a ladder). I believe some prompting logic is in the works to handle up vs down. That makes sense I was hoping that wasn't the case, at least I can work around it for the time being.

I'm having a small problem with the inter-map teleporter.&nbsp; The player token moves from map1 to map2 fine, but going from 2 back to 1, the players token never moves back from the gm layer back down to the object layer. EDIT:&nbsp; Figured out the issue was something to do with my Map1.&nbsp; Not sure what...but deleted that and remade it....things work fine.&nbsp; Thanks again for this!