[Script] Page Navigator

Page Navigator v1.46 This thread is out of date. Please see the  v2.x thread Page navigator simplifies moving your players from map to map and allows them to interact with destinations on the map directly by moving their token to the destination. Player movement between maps regardless of the trigger is controlled by the GM, unless the GM has defined a page or pages as player accessible, or has turned off the player movement restriction. Starting back in v1.4, I've been trying to get token's to be automatically created on the new page (aka teleportation). With v1.43, this functionality is completely live and I have been unable to find any bugs. See below for a complete guide on using the script. Dependencies: This script uses Path Math, Token Collisions (I recommend  v1.3 or later because rectangles are useful), Vector Math, and Matrix Math. You will need to have all of these installed. Please let me know what you think and what you'd like to see changed. Thank you to Stephen for his wonderful utility functions and his help in figuring them out, and as always thank you to Aaron for allowing me to pester him with naive questions about javascript. -Scott C. Gif of teleportation and token removal in action. With many tokens as shown in the gif, it can take awhile. How to use the Script (v1.4): Page Navigator allows you to more easily move your players from page to page. You can utilize the script through API commands or by relying on token collisions to provide a more interactive map for your players. Commands The api command to trigger the script is !nav . The commands that can be passed with !nav are: help — Shows the Help screen pages — Brings up a dialog of all non-archived pages in the Campaign for specifying a page to send players to. The exact behavior is dependent on the next argument, which can be: whole — To move all players to the selected page. current — To move only those players currently in the player ribbon to the selected page. player — To move a specific player(s) to the selected page. This must be followed by at least one token or character id and will move the owners of that token/character to the selected page or will only move the messaging player if the gm has set player control to only themselves. return — If sent by the gm; returns all designated players (via token/character id) to the player ribbon. If sent by a player, returns that player to the player ribbon. config — If sent by the gm; brings up the configuration options. Has no effect if sent by a player. Defining Destinations In order for Page Navigator's token collision functionality to work, you must properly set up the destination tokens. The script looks for the following token properties when determining if a token is a destination or not: Layer — The token must be on the GM layer. Marked as destination — The token must be marked as a destination correctly. The script looks for the flying-flag  status marker by default, but it can be set to look for any status marker or to look for tokens based on name only. Token Name — The name must exactly match the name of whatever page you want it to link to. This includes the player accessible tag you have designated in the configuration options for player pages. Buttons There are several API button dialogs that may be generated while using this script. These are descriptions of what each button will do. Dialog for a token colliding with a destination-token: Whole Party — Will move all players in the game to the player ribbon, and will move the player ribbon to the page described in the dialog. Current Party — Will move the player ribbon to the designated page, but will not affect any players split from the party. Controlling Player(s) — Will move any players set to control the token or its associated character (if it represents a character) to the designated page. Dialog for the pages command: The dialogs that are produced by using !nav pages produce a button for each page that the sender of the message has access to. These buttons will send players to the indicated map based on how pages was called. Access Page Navigator functions differently based on the access allowed by the triggering player. Setting Access — Pages are GM access only by default. To set a page to Player access, simply add the tag that you have selected to the end of the page name. By default the tag is set to .players . Any text after the tag will not be shown in any button labels or dialogs. Example: Test Page - GM only page vs. Test Page.players - player visible page GM Access — If the !nav pages ... command is sent from a GM, all pages are populated as API buttons. The GM receives a whispered movement prompt for all token collision prompted navigation requests. Player Access — If the !nav pages ... command is sent from a player, only those pages flagged as player pages are populated as API buttons. Players only receive a whispered movement prompt when their token collides with a player accessible destination. Config Page Navigator now has several options that you can adjust according to your preferences. Players can move: This button cycles between allowing players to move everyone in the game (default), only those currently in the player ribbon, or only themselves. Players can access all pages: Sets the access state to restricted (default) or open. This defines whether a player can directly access only player pages or all pages respectively. Player page tag: Triggers a roll query prompt to specify what tag you would like to use to mark pages as player accessible Destination tokens marked by: A list of all status markers that can be applied to tokens along with an option for name only . The currently selected one is highlighted in green. Teleport on/off Buttons to set the default characters of each player as well as toggle the removal of tokens on or off. Update Destinations & Pages Triggers the scripts update behavior to update the stored pages and destination-tokens. Use after you have added a page and/or a token linked to a page. Change log: Version 1.47 Removed several lines of code that I used for debugging and developing features. This will remove several extraneous logs in the API dashboard. Was also an incorrect state variable definition that I was using to auto-set a script setting prior to having the control in the config menu; this would not cause a problem for anyone who had previously installed the script, but would cause a crash for new users. Version 1.46 The removal of teleporting tokens can be toggled on/off. Will limit the number of tokens representing a given player controlled character to only those generated by the script (all tokens controlled by players being moved are deleted before new tokens are made). Version 1.44 Minor Bug fix that was causing values stored in the state to be wiped with any update. Should be no changes in functionality.   Version 1.43 Features You can now set a player's default token to "none" which will wipe the memory for that player's settings. Bug Fixes Fixed a bug where the script would crash if there was not enough room for all tokens that were being generated Increased the amount of time the script spends looking for an open square for a given token from 20 seconds to 25 seconds. This probably won't get any longer as it's already closer to the 30 second trigger of the infinite loop detection than is probably wise. The script now stops iterating through characters as soon as it is unable to find enough space for a character's token. A note about interactions with some new scripts: The script stores all of a character's default token information in the state, so if you are using something like  TokenSwapper to modify characters' default tokens on the fly you will have to update PageNavigator's memory before the tokens it creates will reflect the change. My next iteration will probably switch to pulling this information from the characters as it is needed, but that probably won't be for a while as it is going to require rewriting how token generation is handled to accommodate asynch resolution. Version 1.42 No new features, just fixes for the bugs that plagued v1.4. Teleport functionality is now working without crashing the API. I don't know how this was working for me when I released it, but it should all be kosher now. Version 1.4 (BUGGED, only use if you do not plan to turn the token teleport functionality on) New features: !nav pages return can now return all players to the player ribbon by adding whole  to the end of the command. (Only works for the GM) The script now has a teleport option. It is off by default. Turning teleportation on adds an additional section to the configuration menu where you can designate up to 6 default characters for every player in the game from a list of characters that that player controls (characters controlled by 'all' are not included in this list). When teleportation is turned on the script will look for JSON text in the GM notes of the destination tokens on the destination map in this format: { "location":"Descriptive Text", "linkLocation":"Descriptive Text" } "location" - this describes where on the map this destination token is (i.e. Front Entrance) "linkLocation" - this describes where on the destination map the destination token links to (i.e. Front Entrance) In order for a token to be created on the new page, the origin Token's linkLocation text must be the same as the location text of a destination token on the destination map. The script will only work if there is a single match. Once the script has found a match it creates the designated default tokens as specified in the config menu. The script will only create a token in a square if there is a direct path between the square and the landing site that is not blocked by a DL path. The script will respect token size when looking for an open square. I have not tried it with small tokens, but I would assume that it will work with them, although it will probably not pack multiple small tokens into a single square. The script assumes that you are using the default 70px X 70px squares in the page's settings. Using another setting will throw off square alignment, but should not otherwise provide a problem. Version 1.3(Currently in One-Click) Large Update with a lot of changes. Read the changelog and the updated instructions above before upgrading to this version if you are currently using a previous version. msg.selected support enabled - The script will now respond to what you have selected when you trigger any of the !nav pages  commands, assuming you don't enter anything in the 4th argument. (e.g. !nav pages [pages command] [4th argument]) The script now stores the destination tokens and pages in the state rather than finding them with each trigger. Please use the update button in the config dialog to update the stored destinations and pages before using the first time. The tag for defining pages as player accessible is now customizable. It's default is no longer "players" ; it is now .players . This change was due to programming necessities for making it customizable. Any command except for !nav help and !nav pages ... requires gm access. Gm's should not use any of these commands except for !nav config as they are meant to handle the pressing of an API button and have very specific requirements for arguments. WARNING!: If you use these hidden commands, you risk breaking the stored variables and the script. Erroneous chat commands being sent when there were no valid pages or players has been stopped. An error message is now generated instead. There are now error messages if the conditions required by each command are not met. Handling for non-controlled characters/tokens has been added The Help screen now appears if the next argument after !nav was invalid, or if only !nav is entered. - will add handling for further down incorrect arguments in the next beta/release iteration. The Help screen has now been updated to reflect the new capabilities of the beta version. New Commands !nav pages return - If sent by the GM, returns the controlling players of all selected tokens to the player ribbon. If sent by a player, returns that player to the player ribbon if the ribbon is on a player accessible page; sends a request to return to the GM if it is not. !nav config - The script now has several settings that you can modify to customize the navigation behavior: Player Control - Adjust whether players can move the whole party, the current party, or themselves only via the !nav pages commands (the exception is !nav pages return which only allows players to move themselves regardless). Possible Values: Whole Party (Default), Current Party, Themselves only. Access all pages - Toggles whether or not players have access to all campaign pages or not. Possible Values: off (Default), on You can now set how you want your campaign's destination tokens identified. Possible Values: any status marker (Default: flying-flag) or name only Update - Updates the stored destination tokens and pages. Version 0.1.031 Minor update. The help dialog has been adjusted so that it does not present one block of text. Instead specific help topics are available via API button. The handling of page names has been changed so that the "players" tag no longer shows up in buttons and dialogs. Because of this change, the tag must now be at the end of the page name. Any text after the "players" will not show up in buttons or dialogs. Version 0.1.03 Had also not updated the help screen with what buttons are created. Help screen has been updated as shown to the left. Version 0.1.02 Had forgotten to update the help, or this post with changes to the command syntax for the script. There is a new syntax for using !nav pages all. It now uses !nav pages whole instead. Thanks for pointing this out Ziechael. Version 0.1.01 Fixed the issue with splitting the party. The party can now be split as much as you would like in any way you would like. The script now has logic for determining what pages the GM would like players to have access to and which they shouldn't have via looking for "players" (including "") in the page name. The script will whisper formatted API buttons based on whether pages are flagged with "players" or not. Version 0.1.0 All players who control a triggering token will now be separated from the party if the "specific players" button is pressed. There is now a command to manually move players to any nonarchived page. Players are now notified via chat when players are being moved to new pages. Version 0.0.5 Noticed that I had programmed the script so that it would trigger if there was any collision with a destination token during the move. The script will now only trigger if the moved token finishes its move sharing space with the destination token. Version 0.0.4 Release Planned Features - May not happen, but things I'd like to add - Allow tokens to be removed when teleporting allow handling of chat output/API commands to be executed on a move to a specific page/destination EDITED 5/12/16 10:20pm CST: To be more specific that the buttons are whispered to GM only in order to maintain GM control over player exploration. Edited 5/17/16 2353: To show that the multiple specific players functionality mentioned above is completed. (Thanks Paprikacc for pointing out I had neglected updating this part of the post). Edited 6/1/16 1845: Added Version 1.3 to the changelog. Updated the top description to be less rambly. Moved list of edits to the bottom.

Sounds like a fun script!  I'm always happy to help! =D

Very nice! Glad my fancy mathemagicks came in handy. :)

This is a very nice script.  I shall be implementing it this weekend and let you know how it works!

Slight update to the code, new version: 0.0.5

Discovered that the "moving specific players" functionality is not actually working. Each time that a specific player(s) is moved, it overrides the previous 'specificplayerpage' setting; sending everyone else back to the player ribbon. If you are sending multiple players to a specific page (either via having a token controlled by multiple players trigger or via the !nav pages command with multiple targets) it will send all of them correctly, it will however then overwrite all of these the next time you split any player from the party.

Going to be playing around with this at some point soon, can't wait as I've been waiting on something like this (and yet too lazy to learn to do it myself, go figure!). Will let you know any issues I encounter, in a polite and constructive way :) Out of interest, can the script be used by players when a GM is absent? I have a game that is made up of pages relating to a player owned stronghold and want to be able to let them ping from page to page as they want without me having to be there... although that does rely on the API sandbox not needing me to restart it (which is much better these days at least!). Thanks for your work, looking forward to trying this!

Hi Ziechael, It is possible to modify the script to be player activated. I wasn't sure how requested that feature might be, so I didn't worry about it much. I'll look at adding that in the next couple days. It will also require figuring out why splitting the party doesn't work as intended, but that's on the agenda anyways. How would you envision granting access to players?

For my initial use case it would literally be a case of moving the player ribbon so that whoever is viewing the stronghold can move to whatever page they want since it is unlikely that there will be more than one person in there at once... and if they are it will be to discuss something about the continued development of their island and happy to view the same page all at once. I was hoping that they would be able to use a macro of !nav pages all to output the buttons for them to move about with, there won't be any tokens on any of these pages (i use the transmogrifier to move them over to the main game in the event of an encounter happening there). In terms of access, it would be a universal thing for my use case but I'm probably somewhat unique lol... sorry. PS. initial testing from a DM perspective: this script is a work of art.

Lol, glad you like it Ziechael. Right now the script only responds to messages sent by the GM, but I can update it so that that can be changed. I think I'll try to figure out a way to identify player accessible pages so that when players do have access to the script they won't just get a listing of all available pages (which could cause some major spoilers depending on how descriptive you are with your page names). This doesn't sound like it'll be needed for your case, but I think it might be a good idea for people that don't have two separate games running for player space and game space. TL;DR: Proposed Changes: Make a use case for player input to the script Design a way to specify what pages players have unfettered access to, and which require GM approval to move to. Fix the party split functionality Anything else that you'd like to see?

As a side note, until I get the script actually updated for these new features, you should be able to change the if statement at line 373 from this: if (msg.type !== "api" || !playerIsGM(msg.playerid)) { return; } to this: if (msg.type !== "api") { return; } to allow players to access the api. I wouldn't suggest doing this in any other situation other than your's where the player pages and game pages are in two separate games.

That's all from me... for now >:)

I believe I have fixed the problem with splitting the party using the API. That functionality should work as intended now. Player access vs. GM access is also now enabled. See the OP for details on how to use these. Let me know if it all works as planned.

Not sure if i'm doing it wrong now but '!nav pages all' doesn't seem to be doing anything?

Woops, this is what I get for coding and uploading while having pneumonia. Thought I had updated the help dialog to show that change; due to changes in how the code handles notifying people of what is going on, I changed the syntax. Instead of 'all' use 'whole'. I'll update the script so that the help menu reflects the proper syntax. EDIT: Gist link in OP is updated appropriately 2nd EDIT: Had apparently also not updated the help dialog to reflect some other minor formatting changes that did not affect using the script, but should have been corrected nonetheless. The help dialog and OP are now updated to reflect all changes made.

Works like an absolute dream, you sir are a legend! I have one final tweak that would be considered a luxury and therefore not any more urgent than the next time you add a function and schedule a release (I'm very aware that you are doing all this work pro-bono and as such I feel very demanding... sorry!), when the buttons are generated could they omit the "players" bit ;) On a side note, there may be some test logging still in the code too, getting a lot of info outputting to the console. Sorry... First though, get yourself well and put your computer down!!!

Lol, no need to feel like you're being demanding at all. I may be doing this pro bono, but I'm also doing it because I wanted a script like this. Heck, the way I look at it, I'm just taking advantage of the roll20 API community so I don't have to rely on my own time for testing every possible interaction. Besides, programming while on bed rest and binge-watching netflix is not a horrible day at all. As for your request, do you mean the "players" text that gets put into the button because it's part of the page name now? That is not just you having a problem with it. It's on the docket for planned upgrades, along with a few other things.

That's exactly what i meant yup... glad to know i'm not the only one who is super pedantic out there ;) I have to admit I've spent many a happy sick day working on my game so I can totally see your point, so in the spirit of aiding your recovery... Get back to work!! ;)

Hi there. I was working on my own navigation scripts when I noticed that you had posted yours here. I've noticed that your script only takes ID input for both players and pages and if you feed the API invalid IDs it doesn't spit out any errors. So if you haven't already, I'm working on adding some functions to your scripts to also accept page/player names instead of unreadable IDs. For example instead of using a chat command like: !nav current -Kz89fsdf93k1 // ID of the page "Arabel" You would be able to use this (alongside the first example): !nav current Arabel And it would be a neat functionality to use msg.selected instead of only macro commands for groups of players. !nav selected Arabel Your post also noted that you didn't have a solution for the "multiple people controlling a single token" problem. Here's a snippet that allows you to get a list of all player names and IDs that can control the selected tokens ( using msg.selected ). You can replace msg.selected with any other list of IDs. controllingPlayerId = []; controllingPlayerNames = []; _.each( msg.selected , function(selected){ var token, controlledBy; token = getObj("graphic", selected._id); controlledBy = token.get("controlledby") ? token.get("controlledby") : getObj("character", token.get("represents")).get("controlledby"); _.each(controlledBy.split(","), function(id){ if(id && id !== "all" && !(_.contains(controllingPlayerId, id))) { controllingPlayerId.push(id) } }) }) _.each(controllingPlayerId, function(id){ name = getObj("player", id).get("displayname"); controllingPlayerNames.push(name); })

PaprikaCC said: Hi there. I was working on my own navigation scripts when I noticed that you had posted yours here. I've noticed that your script only takes ID input for both players and pages and if you feed the API invalid IDs it doesn't spit out any errors. So if you haven't already, I'm working on adding some functions to your scripts to also accept page/player names instead of unreadable IDs. For example instead of using a chat command like: !nav current -Kz89fsdf93k1 // ID of the page "Arabel" You would be able to use this (alongside the first example): !nav current Arabel And it would be a neat functionality to use msg.selected instead of only macro commands for groups of players. !nav selected Arabel Your post also noted that you didn't have a solution for the "multiple people controlling a single token" problem. Here's a snippet that allows you to get a list of all player names and IDs that can control the selected tokens ( using msg.selected ). You can replace msg.selected with any other list of IDs. controllingPlayerId = []; controllingPlayerNames = []; _.each( msg.selected , function(selected){ var token, controlledBy; token = getObj("graphic", selected._id); controlledBy = token.get("controlledby") ? token.get("controlledby") : getObj("character", token.get("represents")).get("controlledby"); _.each(controlledBy.split(","), function(id){ if(id && id !== "all" && !(_.contains(controllingPlayerId, id))) { controllingPlayerId.push(id) } }) }) _.each(controllingPlayerId, function(id){ name = getObj("player", id).get("displayname"); controllingPlayerNames.push(name); }) Hi Paprika, Thanks for the input. The current version of the script actually has that multiple controllers of a single token solved. It was mostly me being stupid and not thinking ahead, although I haven't yet implemented the msg.selected aspect (one of the many things on the future docket). I like the idea of specifying a name (character or player display-as) to send players around. I'll probably add that to my list of future features. The problem that I can see with it immediately (because I have a related problem in the current script version) is that names (especially player names) tend to be multiple words, which I'm not sure off the top of my head how to deal with perfectly. An imperfect way would be to have it take only the first word of the name and find the best match based on that one word, but of course this would have the problem of not being able to differentiate between Bob D. and Bob A. I wonder if it would be possible to use .split() to split according to an array of found players in the game (or probably more accurately, have the script iterate through the array of single names to see if any of the consecutive entries result in a name match). Hmmm, I'll have to take a look at how some other scripts handle name calls and address this (/Aaron, I may be hitting you up via PM later to talk about this ;D). I'm slowly expanding the features as I think of additional things and hear/see comments like your's and Ziechael's; so keep the critiques coming, they are much appreciated. Sometime next week, I'll post up a proposed updates list for comments. -Scott C.

also Paprika, I was just rereading your post and noticed something that you may not have been aware of. The !nav current, !nav all, and !nav player commands are not supposed to be used by users of the script directly. They are only there for creating the API buttons that the script generates in chat to allow for the GM to approve the change/specify who is being transitioned to the page that is associated with the destination-token that the triggering-token collided with and is currently overlapping. The API commands that users are expected to use via typing into chat or saving in macros are !nav pages [all/current and player+[1 or multiple token_ID's passed via selected|token_id or target|token_id]]. Just thought it might be helpful if you were looking to use or modify some of the script's code in your own navigation scripting.

That makes a lot of sense. I guess that I got mixed up because I didn't read the help menu well enough. Thanks!

NP

I was able to sit down and collect my thoughts on additional features a little sooner than planned. So, here's what I'm thinking about for the next (probably several) updates to Page Navigator. Anyone have any comments or additional ideas? Planned Features (in no particular order or expected completion): Can't believe I didn't already do this, but have a command in !nav pages to return a specific player or group of players to the player ribbon Eliminate the second word of the /w name when an API button dialog is whispered to a player De-clutter the help dialog as it is about two pages long on a high res display Thinking that the various sections will become general descriptions with API buttons for accessing true details about each aspect - Completed Add handling for names (character or player) to be used in !nav pages player Add handling to use all selected tokens when using !nav pages player Filter out the "players" tag that is added to a page in the outputted API buttons and dialogs. Completed Long-Term Features: Identify destination tokens via another method Thinking of doing it via name only and storing them in State This would be updated on GM command and would actually reduce the performance requirements of the script As part of this, allow the GM to determine how they want to mark destination-tokens and perhaps pages. Allow the GM to set player accesses and permissions for who can be moved by a player (the whole party, the current party, players sharing control of the token/character, or only themselves) Pie-In-The-Sky/No-Idea-How-To-Do-It/Know-It's-Not-Currently-Possible: Move the GM via the script (Yeah, the API has no way to do this right now) Triggering the page's playlist options - Don't believe the API has access to this info

Minor update. Reformatted the help screen and took care of Ziechael's request to eliminate the "players" tag from the buttons and dialogs. Also, for this update and future ones, the link to the new script will be at the top of the changelog rather than at the top of the post.

Works beautifully, bravo sir, bravo! Now you need to get this bad boy one-click install enabled ;)

Learning that is scheduled for next week :)

I've finished a large overhaul of the script. Before I declare it fully published, I'd like to get some feedback on it. The Beta version can be found  here . I've tried every circumstance I can think of and it is stable. Version 1.1Beta: Changelog: msg.selected support enabled - The script will now respond to what you have selected when you trigger any of the !nav pages commands, assuming you don't enter anything in the 4th argument. (e.g.  !nav pages [pages command] [4th argument]) The script now stores the destination tokens and pages in the state rather than finding them with each trigger. Please use the update button in the config dialog to update the stored destinations and pages before using the first time. New Commands !nav pages return  - If sent by the GM, returns the controlling players of all selected tokens to the player ribbon. If sent by a player, returns that player to the player ribbon if the ribbon is on a player accessible page; sends a request to return to the GM if it is not. !nav config  - The script now has several settings that you can modify to customize the navigation behavior: Player Control - Adjust whether players can move the whole party, the current party, or themselves only via the !nav pages commands (the exception is !nav pages return which only allows players to move themselves regardless). Possible Values: Whole Party (Default), Current Party, Themselves only. Access all pages - Toggles whether or not players have access to all campaign pages or not. Possible Values: off (Default), on You can now set how you want your campaign's destination tokens identified. Possible Values: any status marker (Default: flying-flag) or name only Update - Updates the stored destination tokens and pages. The live version of the script (the one linked to in the OP) should be getting merged into the API repository (and one-click install) on the next merge day; assuming I did it correctly of course. So, let's see if anything breaks out in the wild. -Scott

Before everything, I just want to say thanks for the script and your work :D I've been playing around with your script and found a few things that others might run into (or maybe I'm just paranoid that my players will exploit the commands). I have two bugs, four suggestions and one request. Bug one : Line 997 to 1000 has the 'not enough commands' message showing up with the "!nav character" command instead of "!nav pages". Bug two : The "!nav pages player" command always breaks the script when you have selected a token that does not represent a character in the journal (eg. An NPC that is currently following the PCs, or a vehicle). Whether or not the token is controlled by players in the "controlledby" field does not stop the script from breaking, and it also breaks when using @{target|target|token_id}. Request one : I would like to request that you pop up a help menu if the second argument doesn't match any of the existing commands (eg. If I type "!nav sdfsd", the help menu appears). It's helped me out so much when navigating other scripts like TokenLock and GroupInitiative when I had no idea (or just forgot) what the commands were. Four (minor) suggestions: First, players can directly access the setControl and setAccess commands and break the chat boxes so you can't toggle between them. You can manually enter "!nav setControl open" and give yourself the ability to manipulate whomever you want to as a player. Could you set those to gm only access? Second, It might help to clarify on the Defining Destinations help tab that the status marker is set by default to "flying-flag" instead of stating that it must always be that way. Third, I suggest that "!nav help" only displays the 'commands help' bit to players. The rest shouldn't be accessible to players. And fourth, the API sends chat commands even if you don't select any players (perhaps accidentally). Perhaps that could be changed so that a chat message is sent that warns the GM that nobody has been selected.

PaprikaCC said: Bug one : Line 997 to 1000 has the 'not enough commands' message showing up with the "!nav character" command instead of "!nav pages". Ah, this is left over code from one of my attempts to handle character Id's (that I never actually wrote, just made the scaffold for the planned handling). I wound up designing !nav pages player to function whether the ID submitted was a token id, character id, or some combination of them for multiple ids instead. I'll be deleting these lines in the next run. Bug two : The "!nav pages player" command always breaks the script when you have selected a token that does not represent a character in the journal (eg. An NPC that is currently following the PCs, or a vehicle). Whether or not the token is controlled by players in the "controlledby" field does not stop the script from breaking, and it also breaks when using @{target|target|token_id}. Hmm, I'll have to take a look at this. It's supposed to function as long as someone controls the token (either through the token's controlledby attribute, or through the represented character's). Somewhat related, I'll need to add in an error message for when someone inevitably selects/targets/specifies a token or character that no one controls. Request one : I would like to request that you pop up a help menu if the second argument doesn't match any of the existing commands (eg. If I type "!nav sdfsd", the help menu appears). It's helped me out so much when navigating other scripts like TokenLock and GroupInitiative when I had no idea (or just forgot) what the commands were. I can handle this easily enough, as a side-note, it should bring up the help screen with just !nav  as well. Four (minor) suggestions: First, players can directly access the setControl and setAccess commands and break the chat boxes so you can't toggle between them. You can manually enter "!nav setControl open" and give yourself the ability to manipulate whomever you want to as a player. Could you set those to gm only access? Ah, yes, you've reminded me that there were supposed to be lock-outs in there so that anything but !nav help and !nav pages ... were inaccessible to anyone but the GM (trusting that the GM would not use the cases meant for handling the buttons only). Second, It might help to clarify on the Defining Destinations help tab that the status marker is set by default to "flying-flag" instead of stating that it must always be that way Derp, I need to update the whole help menu to reflect the changes in the script. Third, I suggest that "!nav help" only displays the 'commands help' bit to players. The rest shouldn't be accessible to players. Easily done, and a good idea. And fourth, the API sends chat commands even if you don't select any players (perhaps accidentally). Perhaps that could be changed so that a chat message is sent that warns the GM that nobody has been selected. Ah, no, that was not by design. There were supposed to be error messages for cases like that, but I apparently deleted or made them not triggerable when I rewrote the script. Great feedback Paprika. I'll get these implemented sometime over the next week. Also, as a side note regarding your question about handling names instead of IDs; I don't think I'm going to implement this functionality in the script as finding an object by name is so inexact. As a work around to mimic this functionality, you can use @{character_name|character_id} to get the same behavior. -Scott

Ok, let's see how this one does.  Beta 2 now uploaded. Beta 2 Changelog: There are now error messages if the conditions required by each command are not met. Any command except for !nav help  and !nav pages ...  requires gm access. Gm's should not use any of these commands except for !nav config  as they are meant to handle the pressing of an API button and have very specific requirements for arguments. WARNING!: If you use these hidden commands, you risk breaking the stored variables and the script. The Help screen now appears if the next argument after !nav was invalid, or if only !nav is entered. - will add handling for further down incorrect arguments in the next beta/release iteration. Erroneous chat commands being sent when there were no valid pages or players has been stopped. An error message is now generated instead. The Help screen has now been updated to reflect the new capabilities of the beta version. Handling for non-controlled characters/tokens has been added Known Issues: If the GM is one of the controlling players of a token/character that collides with a destination-token and the page that that token links to is a player accessible page, the GM receives two "who is traveling with them" prompts. - Will fix this in the next iteration of the beta.

Version 1.3 released. See the  OP  for details. This is a large update with a lot of changes.

When I install this script form the API library the console throws the following error. No such file or directory @ rb_sysopen - /home/symbly/www/d20-app/apiscripts/Page Navigator/1.3/PageNavigator.js any ideas?

Hi Jason, Sorry to hear that. I'll take a look today during some downtime at work. Scott

Hi again Jason, I've looked at it and it looks like when I updated to 1.3, PageNavigator got renamed from a .js file to a straight .txt file. I've sent in a new pull request for it to be merged, but that could be a week or more (maybe almost a month) before the next merge day. You can copy/paste the script in the old-fashioned way from my fork of the repository  here , if you would like. Page Navigator doesn't require a one-click install for any of it's features to work, so you'll have the same functionality doing this as you would using one-click. Let me know what you think and if you have any additional feature requests, Scott

Scott, Wow, that was fast!  Thanks for the solution.  I'll install the scrip the old fasioned way and give it a whirl!

I aim to please, plus not much else to do while I'm waiting on incubations.

The script from the repository works fine.  Thanks again! Jason

:)

Update v1.4 is up in my  gist.  Use the version on the  roll20 repository . New feature: The script now has a teleport option. It is off by default. Turning teleportation on adds an additional section to the configuration menu where you can designate up to 6 default characters for every player in the game from a list of characters that that player controls (characters controlled by 'all' are not included in this list). When teleportation is turned on the script will look for JSON text in the GM notes of the destination tokens on the destination map in this format: { "location":"Descriptive Text", "linkLocation":"Descriptive Text" } "location" - this describes where on the map this destination token is "linkLocation" - this describes where on the destination map the destination token links to In order for a token to be created on the new page, the origin Token's linkLocation text must be the same as the location text of a destination token on the destination map. The script will only work if there is a single match. Once the script has found a match it creates the default token for each of the characters designated in the config menu. I'll put the update in for merge to the repository and for one-click in a day or two. Let me know if you find any bugs or ideas for improved functionality. The script currently does not delete tokens from maps when teleporting tokens as I couldn't think of a good way to give users control over what tokens were deleted and what were kept. If this is functionality that is requested, I'll see what I can do. -Scott

Slight tweak to the code as I wasn't satisfied with some of the odd formations that could result from the script respecting DL paths. The script now looks for open squares outside of the landing zone in a different way that results in a more compact formation of newly created tokens. Code is still in the v1.4 gist.

Code is now in Final 1.4 state. Submitted to One-click. I'd like to add the ability to remove tokens from the previous page when teleportation is enabled. Any users have ideas on how they'd like to see that happen?

I am working with this script trying to get ot to work but it keeps crashing here is the error...anyone have any thoughts as to why?

Hi Randall, I'm sorry to hear you're having problems with the script. Could you copy and paste the text of the error as text? I can't quite make out the details of the error, and I'll need that to troubleshoot the issue. -Scott

Hi Randall, I opened your pic of the error on a different computer and the resolution came out correctly. The error doesn't appear to reference anything in the script, which doesn't mean it isn't the script causing it, but I'll need some more information to figure out what is going on. Do you get this error as soon as you try to start-up your api sandbox, after a certain script command, or after moving a token, or is it random/some other trigger? What other scripts do you have installed? How did you install Page Navigator (one-click vs. copy paste from github)? If you pasted from github or one of the links in the OP, what version are you using? Have you used a previous version of the script that worked correctly? I think that covers it for now. Scott

I can't get the above error to generate using v1.4 of the script. If anyone else gets the error, could you post or pm the details of the situation that brought it about?

I don't know exactly how to duplicate it, but if you add checks for _.isUndefined(destination) at lines 878, 895, and 921, you should be able to catch when it happens. Here are some ways that it looks like it could happen: !nav-pages  called as: !nav-pages [who] [speaker id] Looks like it will cause the issue as args[3] will be undefined when it calls movePartyFromDialog(). !nav called as: !nav current [speaker id] Looks like it will cause the issue as args[3] will be undefined when it calls moveCurrentParty(). !nav called as: !nav whole [speaker] Looks like it will cause the issue as args[3] will be undefined when it calls moveCurrentParty().

If you have been having the issue that Randall described above, please do an install from the one-click repository, or re copy and paste from the version 1.4 links. I had linked to my gist rather than my fork of the repository and so there was some incomplete code in the link. If the problem persists let me know, and I'll try to figure a solution. Thanks to Aaron for making me realize I had different code on the repository and my gist.

I'm getting the following error and I feel like I have followed the instructions perfectly. Although I'm sure there is something I ended up missing. I have tried both the one-click and copy and paste from the repository.  I get this error when moving a token on a marker and then selecting any option that appears in chat. SyntaxError: Unexpected token } SyntaxError: Unexpected token } at Object.parse (native) at movePlayer (apiscript.js:11009:19) at handleInput (apiscript.js:11729:33) at eval (eval at <anonymous> (/home/node/d20-api-server/api.js:105:34), <anonymous>:65:16) at Object.publish (eval at <anonymous> (/home/node/d20-api-server/api.js:105:34), <anonymous>:70:8) at /home/node/d20-api-server/api.js:1200:12 at /home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:560 at hc (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:39:147) at Kd (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:546) at Id.Mb (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:489) at Ld.Mb (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:94:425) Any guidance would be greatly appreciated. Thank you!

Hi Korb, I apologize for the inconvenience. Could you disable all other scripts except for the scripts required for page navigator and see if the error still pops up? This looks like something that could happen due to an unanticipated concatenation of the scripts together. Once I'm back at my computer I'll also double-check that I didn't somehow introduce an extra }. EDIT: Also, what other scripts do you have installed? EDIT2: I don't get any error when loading the one-click version (which I use in my live game). I'm guessing this is a problem with one or more scripts not ending themselves properly. Let me know what happens when you try loading just PageNavigator and its dependencies.

I noticed where the one error was, looks like in your main top post under the v4 changes you have  { "location":"Descriptive Text", "linkLocation":"Descriptive Text", } with the comma at the end. So I have gone ahead and removed all scripts except for Vector Math, MatrixMath, Path Math, Token Collisions, and Page Navigator. I get the following error only when selecting an option after I collide with the setup teleport token. I am able to do "!nav pages player" and use the menu to push my player(myself) to the selected page. SyntaxError: Unexpected end of input SyntaxError: Unexpected end of input at Object.parse (native) at movePlayer (apiscript.js:3068:19) at handleInput (apiscript.js:3788:33) at eval (eval at <anonymous> (/home/node/d20-api-server/api.js:105:34), <anonymous>:65:16) at Object.publish (eval at <anonymous> (/home/node/d20-api-server/api.js:105:34), <anonymous>:70:8) at /home/node/d20-api-server/api.js:1200:12 at /home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:560 at hc (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:39:147) at Kd (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:546) at Id.Mb (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:489) at Ld.Mb (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:94:425) Thank again!