[Script] EncounterHelper

Encounter Helper

Development GIST: https://gist.github.com/kjaegers/0885fa7d308fdb4b4f82bb4471b96487

YouTube Demonstration: https://youtu.be/tPdyRIcpeVY

Updates

Version 1.1.10 (2020-09-24)

• New button to rename existing encounters. This will pop up a roll query prompt asking for the new name. It will check to see if the new name conflicts with another encounter before performing the rename. Saved data about the tokens in the encounter is preserved across the rename.
• Includes code to facilitate User Options from OneClick install for eventual inclusion there.

Version 1.0.9 (2020-08-21)

• Extensions to the reset functionality. You can now update an encounter (!eh update_reset_info <encountername>) to store or replace its reset data. You can also run a command to update every encounter's (on the page) reset data or reset every encounter on the page.
• Did some localization cleanup... it is far from complete, but should mostly just effect some instance of seeing "Encounter Helper" as the entity sending chat info instead of the localized version. Actual text should be localized almost everywhere.

Version 1.0.8 (2020-08-20)

• Added the ability to reset encounters to a saved state. The state of several (definable) attributes gets stored when the encounter is created, and running "!eh reset <encountername>" will restore those values. Defaults are position, size, bar3 val/max, and status markers. Thanks to MykeMyke for the feature suggestion.
• Corrected a bad column header in the encounter display table. Thanks to Erik M. for pointing out the issue.

Version 1.0.7 (2020-07-27)

• Added localization with four languages (english, french, spanish, and german) based on google translate. There are probably better translations if anyone wants to make suggestions :) To set a language, look for "APILANGUAGE" near the top of the script after the comments section and change the assigned value to one of the available languages.

Version 1.0.6 (2020-07-27)

• Added a configuration menu : !eh configmenu There is currently only one configuration option that lets you toggle on/off rolling for characters if you execute a GroupInitiative call. Note that I can't find a way in Group-Initiative to have it ignore selected tokens, so if you have something selected it will roll that token's initiative regardless of this setting.
• The background for storing and retrieving configuration items - this is internal stuff, but I hope to use what I develop for EncounterHelper for other API scripts in the future.
• The very basic beginnings of support for localization. This is fairly experimental, but right now I have an APILANGUAGE constant at the beginning of the script. I've translated (via our good friend Google Translate) a few phrases used in Encounter Helper into French to try out the system. Most notably configuration options and the output of "!eh create ..." This appears to be working how I intended it, so my next goal is to replace all of the output text in the script with localizable replacement strings.

Version 1.0.5 (2020-07-26)

• Added a block near the top of the code to allow customization of the appearance of the tables an buttons output by Encounter Helper. If you come up with something that looks nice, please post your CSS so I can replace mine... I'm not a UI designer by any means.
• Similarly, you can set the text that is displayed on the buttons. Right now, they default to "S", "H", "D" and an emoji red X.
• Expanded GroupInitiative integration slightly... If GroupInitiative is installed, the encounter list will now include a button (defaults to look like a D6) to roll initiative for the tokens in the encounter (so you don't have to show the encounter to roll initiative for the critters).

Version 1.0.4 (2020-07-23)

• If you have GroupInitiative installed, when you Show and encounter you will get a button to run GroupInitiative on the tokens from that encounter.

Version 1.0.3 (2020-07-23)

• Prevent non-GMs from running !em commands. They wouldn't see anything anyway, but now they can't do it at all.

Version 1.0.2 (2020-07-23)

• Reworked the way the page/token system is handled. Now, when you want to have encounters on a page, create a token on that page named "Encounter Token" (you can rename your existing tokens - nothing in the way encounters are stored has changed). The new command "!eh pagelist" will display a list of all pages with "Encounter Token" tokens on them, and from there you can activate a page. This removes the tie to page names, and the reliance on the player ribbon. Additinally, parenthesis are now supported in encounter names (the chat server was considering parens as the end of the button command link). The encounter list (!eh l) now lists the active page at the top of the table as a reminder.

Version 1.0.1 (2020-07-23)

• As suggested by GiGs, added a means to redefine the columns shown on the "D" table to support any game/sheet.

Introduction

I've been prepping for a new campaign, and while setting up encounters on my pages I thought it would be nice to have a system where I could mass move tokens between layers without switching back and forth, etc. That was the genesis of this new script.

With Encounter Helper, you can define groups of tokens (Encounters) that you can easily move between layers. There are a few other handy options as well. Check the YouTube video above for a demonstration, but here are the particulars:

Requirements

On any page you want to define encounters, you'll need to create a token and give it a very specific name. That name is "Encounter Token" (case sensitive). Encounters for each page will be stored using the notes field on this token. It can be hidden on the GM layer, etc. Graphic and size are not important.

Once in Roll20, enter the command "!eh pagelist" to list all pages with "Encounter Token" tokens on them and select a page to become active. All Encounter Helper work will now be done on the active page. Run !eh pagelist again to select a different page.

Finally, the details/display function will display a table of all of the tokens in the encounter. By default it displays the value of Bar 3 (cur/max) and the npc_ac attribute, but these are customizable by editing the "const columns" line near the top of the script (after the comments) so it can support any game/sheet.

Commands

Encounter Helper only has one defined command (!eh) but that command has several options. They are:

!eh list

    Probably the command you will use most often. I created a macro bar button for this command because I use it all the time. It displays a list of all of the encounters on the page with buttons to manipulate them.

  The  buttons associated with the list are:

    S - Show the encounter. Move all of the tokens to the Token layer

    H - Hide the encounter. Move all of the tokens to the GM layer.

    D - Details/Display. Show all of the tokens associated with the encounter and some stats about them.

    X - Delete the encounter. Does not impact the tokens. Only removes the encounter from the encounter list.

  All of the buttons above are simply API calls to !eh and its other operations.

!eh create <encounter name>

    Highlight a group of tokens and use the create operation to define and encounter. The name is case sensitive, but since most of the time you will be using the output of !eh list to manipulate encounters, you will almost never have to type it again. Tip: I usually name my encounters starting with a room number, as they are output in the list in alphabetical order, so this makes encounters associated with rooms easy to find.

The rest of the commands can be typed into the chat window, but it is usually much easier to access them via the !eh list buttons. The remaining commands are listed below.

!eh pagelist

    Shows a list of pages that have "Encounter Tokens" tokens on them and allows you to activate the page you want to work on. All further activity will be relative to that page unless you activate a different page.

!eh show <encounter name>

    This is the command run by the "S" button from the list.

!eh hide <encounter name>

    This is the command run by the "H" button from the list.

!eh display <encounter name>

    This is the command run by the "D" button from the list. The output looks something like this:

!eh remove <encounter name>

    This is command run by the "X" button from the list.

Notes

Feedback, bug reports, or suggestions for improvement are welcome.

That looks very handy for D&D players. A feature suggestion:

Have a config setting to include more labels (3 maybe, one for each token bar), and have the option to use or not use each one. Then this script can be used by players of any system.

GiGs said:

That looks very handy for D&D players. A feature suggestion:

Have a config setting to include more labels (3 maybe, one for each token bar), and have the option to use or not use each one. Then this script can be used by players of any system.

Done. You can now define the columns as to what they will contain. As a side effect, it is no longer limited to two (other than name) columns. Currently it is done by editing a line in the script, but eventually I'll have commands to set the values or allow them to be configured via the oneclick install  screen.

Wow, this is filling a need I didn't even realize I had until just now! :) Looks great. I will definitely check this script out.

Kurt J. said:

GiGs said:

That looks very handy for D&D players. A feature suggestion:

Have a config setting to include more labels (3 maybe, one for each token bar), and have the option to use or not use each one. Then this script can be used by players of any system.

Done. You can now define the columns as to what they will contain. As a side effect, it is no longer limited to two (other than name) columns. Currently it is done by editing a line in the script, but eventually I'll have commands to set the values or allow them to be configured via the oneclick install  screen.

That's great. It seems like a very useful script.

Just played around with the script. It works great! I think it will be particularly useful for me when I run random encounters on a page. A few notes:

It seems that the script doesn't like parentheses in encounter names. Tried it and got some weird behavior where the encounter wouldn't display the creature list using the menu button, and show/hide wouldn't work from the menu button (though it did running the command normally). Deleting the encounter with parentheses in the title didn't work using the menu button either. Encounters without parentheses in the title seemed to work fine.

If I change the page name after creating the encounter token and generating encounters, can I simply update the token name and have everything work fine? Or must the page name remain static? If the latter, it's a bit of an issue for me, since I use MapChange and therefore prepend [Hidden] to most maps until it's time for my players to see them, at which point I remove [Hidden] from the title.

I really wish there were some way to not have the script tied to the player ribbon, though I know you mentioned the API limitation that forces you to rely on it. 

Kurt J. said:

Encounters are tracked per-page via this token, and the current page is the page the player ribbon is on. The API has a limitation that there is currently no way to determine/set the page that the GM is looking at, so the player ribbon is key.

The last question made me look against this. Is there a a reason you need to know which page the GM is looking at?

Cant you instead detect the page the control token is on, and use that? 

Jay R. said:

Just played around with the script. It works great! I think it will be particularly useful for me when I run random encounters on a page. A few notes:

It seems that the script doesn't like parentheses in encounter names. Tried it and got some weird behavior where the encounter wouldn't display the creature list using the menu button, and show/hide wouldn't work from the menu button (though it did running the command normally). Deleting the encounter with parentheses in the title didn't work using the menu button either. Encounters without parentheses in the title seemed to work fine.

If I change the page name after creating the encounter token and generating encounters, can I simply update the token name and have everything work fine? Or must the page name remain static? If the latter, it's a bit of an issue for me, since I use MapChange and therefore prepend [Hidden] to most maps until it's time for my players to see them, at which point I remove [Hidden] from the title.

I really wish there were some way to not have the script tied to the player ribbon, though I know you mentioned the API limitation that forces you to rely on it. 

You can rename the page as long as you rename the token... Everything should work fine after that.

One alternative to the player ribbon dependency might be to have a command that would list all of the appropriately named tokens and ask you which one you are working on - that information could be used instead of detecting the current ribbon page each time. I'll put some thought into that.

GiGs said:

Kurt J. said:

Encounters are tracked per-page via this token, and the current page is the page the player ribbon is on. The API has a limitation that there is currently no way to determine/set the page that the GM is looking at, so the player ribbon is key.

The last question made me look against this. Is there a a reason you need to know which page the GM is looking at?

Cant you instead detect the page the control token is on, and use that? 

Each page has its own control token, since it is possible to have encounters with the same name on different pages. Jay R.'s comments above have me thinking about some alternatives, though... It might make more sense to have an !eh command that sets the page you want to work on, and looks for a token named "Encounter Token" on that page instead of having the tokens named for pages. That way it doesn't matter where the player ribbon is... any time you started working on an area you would just need to set your encounter page.

I'll experiment a bit.

That does sound like a better approach.

Looking forward to the next version already! :)

Jay R. said:

Looking forward to the next version already! :)

I updated to v 1.0.2 to include these changes. No more tie to the player ribbon or page names. Existing tokens can just be renamed to "Encounter Token" and keep their encounters.

Also, the chat server clobbering parenthesis has been allowed for and they should now work in encounter names.

that was quick!

Kurt J. said:

Jay R. said:

Looking forward to the next version already! :)

I updated to v 1.0.2 to include these changes. No more tie to the player ribbon or page names. Existing tokens can just be renamed to "Encounter Token" and keep their encounters.

Also, the chat server clobbering parenthesis has been allowed for and they should now work in encounter names.

Whoa, that was fast! Thank you. Will test this out tonight.

Getting the above error on installing your latest API change

Might have been me making a mistake copying it accross as its working now...sorry

Giulio M. said:

Getting the above error on installing your latest API change

Updated the GIST to fix this... I couldn't get it to happen by just installing it, but if I typed "!eh" without any options I got that behavior. I added a couple of checks to prevent it.

 I typed !eh without any command ....sorry :P

Anyway this is really good and so glad you made it available to us...Thanks :)

New version works great! The flexibility of designating an active page without the Player ribbon is everything I wanted. Thank you, Kurt! As a sidenote, I'm wondering if the new setup allows one to show or hide tokens on a page when you're not even on it yourself. It's fine if you can't, but it would be kinda neat if you could trigger that activity from the Chat menu.

Jay R. said:

New version works great! The flexibility of designating an active page without the Player ribbon is everything I wanted. Thank you, Kurt! As a sidenote, I'm wondering if the new setup allows one to show or hide tokens on a page when you're not even on it yourself. It's fine if you can't, but it would be kinda neat if you could trigger that activity from the Chat menu.

Sure does... neither your page or the player ribbon impact where you can show/hide tokens from.

Also, there is a minor new update (1.0.3) that checks to make sure the player using the commands is a GM :) It wouldn't matter TOO much since all the output is whispered to the GM so players would never know the encounter names, etc. but now it will warn you if your players try to run !eh commands.

Kurt J. said:

Jay R. said:

New version works great! The flexibility of designating an active page without the Player ribbon is everything I wanted. Thank you, Kurt! As a sidenote, I'm wondering if the new setup allows one to show or hide tokens on a page when you're not even on it yourself. It's fine if you can't, but it would be kinda neat if you could trigger that activity from the Chat menu.

Sure does... neither your page or the player ribbon impact where you can show/hide tokens from.

Also, there is a minor new update (1.0.3) that checks to make sure the player using the commands is a GM :) It wouldn't matter TOO much since all the output is whispered to the GM so players would never know the encounter names, etc. but now it will warn you if your players try to run !eh commands.

Rocking! Thank you for this script, sir. I'll be using it a ton in my sessions from now on.

I will get in like a dirty shirt with a feature request for the future: the ability to integrate with TheAaron's Group Initiative script. Would be flat-out amazing if one could trigger initiative rolls for a group all at once, or when moving an encounter group from hidden to visible, especially in cases when the tokens in that encounter group were spread out and not easily selectable. I have no idea if that's even possible or not, but I thought I'd put it out there. :)

Jay R. said:

Kurt J. said:

Jay R. said:

New version works great! The flexibility of designating an active page without the Player ribbon is everything I wanted. Thank you, Kurt! As a sidenote, I'm wondering if the new setup allows one to show or hide tokens on a page when you're not even on it yourself. It's fine if you can't, but it would be kinda neat if you could trigger that activity from the Chat menu.

Sure does... neither your page or the player ribbon impact where you can show/hide tokens from.

Also, there is a minor new update (1.0.3) that checks to make sure the player using the commands is a GM :) It wouldn't matter TOO much since all the output is whispered to the GM so players would never know the encounter names, etc. but now it will warn you if your players try to run !eh commands.

Rocking! Thank you for this script, sir. I'll be using it a ton in my sessions from now on.

I will get in like a dirty shirt with a feature request for the future: the ability to integrate with TheAaron's Group Initiative script. Would be flat-out amazing if one could trigger initiative rolls for a group all at once, or when moving an encounter group from hidden to visible, especially in cases when the tokens in that encounter group were spread out and not easily selectable. I have no idea if that's even possible or not, but I thought I'd put it out there. :)

1.0.4 is up... with GroupInitiative integration if you have it installed. It isn't quite as elegant as I'd like - I can't get GroupInitiative to take my command when the API runs it, but what happens now is that if you have GroupInitiative installed when you "S"how an encounter, it will let you know the encounter was shown and have a button to click to run Group-Init on the tokens in the encounter.

Kurt J. said:

Jay R. said:

Kurt J. said:

Jay R. said:

New version works great! The flexibility of designating an active page without the Player ribbon is everything I wanted. Thank you, Kurt! As a sidenote, I'm wondering if the new setup allows one to show or hide tokens on a page when you're not even on it yourself. It's fine if you can't, but it would be kinda neat if you could trigger that activity from the Chat menu.

Sure does... neither your page or the player ribbon impact where you can show/hide tokens from.

Also, there is a minor new update (1.0.3) that checks to make sure the player using the commands is a GM :) It wouldn't matter TOO much since all the output is whispered to the GM so players would never know the encounter names, etc. but now it will warn you if your players try to run !eh commands.

Rocking! Thank you for this script, sir. I'll be using it a ton in my sessions from now on.

I will get in like a dirty shirt with a feature request for the future: the ability to integrate with TheAaron's Group Initiative script. Would be flat-out amazing if one could trigger initiative rolls for a group all at once, or when moving an encounter group from hidden to visible, especially in cases when the tokens in that encounter group were spread out and not easily selectable. I have no idea if that's even possible or not, but I thought I'd put it out there. :)

1.0.4 is up... with GroupInitiative integration if you have it installed. It isn't quite as elegant as I'd like - I can't get GroupInitiative to take my command when the API runs it, but what happens now is that if you have GroupInitiative installed when you "S"how an encounter, it will let you know the encounter was shown and have a button to click to run Group-Init on the tokens in the encounter.

Can't wait to try this out!

I played around with 1.0.4 last night -- works phenomenally! I love that clicking Show will trigger the Group-Init option even if your encounter group is already visible. So the option is available whether or not the monsters in an encounter group start visible, hidden, or a mix of both. 

This is going to save me a ton of time during sessions. Thank you again!

This is absolutely fantastic!

Kurt, is there a way to change the style or sub in roll templates by messing around with the code? Similar to what you posted for Interactive Map Companion?

Jay R. said:

Kurt, is there a way to change the style or sub in roll templates by messing around with the code? Similar to what you posted for Interactive Map Companion?

There isn't at the moment, but after looking at how some other folks do the chat buttons, I'm going to rework what I have and will include a section where you an edit the CSS to style the output. Mine will probably be ugly... I'm not a UI guy, so if anyone comes up with a good set of styles I'd be happy to incorporate them as the default. I'm working my way through the code on both EncounteHelper and Interact Map Companion... EH should probably be done today.

As a side effect, you can customize what the buttons say unde this new system (Show, Hide, etc...) the language can be changed, they an be replaced with emojis, etc.

Looking forward to it!

Jay R. said:

Looking forward to it!

Version 1.0.5 is up. In addition to customizing the CSS and button text, I also added a button for GroupInit from the encounter list, so you don't even need to show them now to roll group-init for them. Of course, the button won't show if GroupInit isn't installed/enabled.

Hey.-

I don't know if it has been recommended before, but could it be possible to add a field with the players' token-ids so that they could be included in the encounter's group-init function?. Probably a query or a toggle button could make you able to incluide or not the players in encounters. Or a new button (like a D6 with a 'P' overlay) to signify roll the group-init with the PC's and Encounter's TokenID's together.

One can achieve a similar effect by just adding an encounter with the PC's id's in it (or including the PC's in every single encounter along with the enemies), but the proposed way would be much more straight-forward, since there would be no 'delay' in the group-init (and some API's like CombatMaster/Tracker start combat immediately with the first chunk of group-inits).

Nice API altogether!!

Kurt J. said:

Jay R. said:

Looking forward to it!

Version 1.0.5 is up. In addition to customizing the CSS and button text, I also added a button for GroupInit from the encounter list, so you don't even need to show them now to roll group-init for them. Of course, the button won't show if GroupInit isn't installed/enabled.

Looks great so far! I've adjusted the font size and played around with the background color for the cell, to help my failing eyesight. :)

This just gets better thanks

Juan C. said:

Hey.-

I don't know if it has been recommended before, but could it be possible to add a field with the players' token-ids so that they could be included in the encounter's group-init function?. Probably a query or a toggle button could make you able to incluide or not the players in encounters. Or a new button (like a D6 with a 'P' overlay) to signify roll the group-init with the PC's and Encounter's TokenID's together.

One can achieve a similar effect by just adding an encounter with the PC's id's in it (or including the PC's in every single encounter along with the enemies), but the proposed way would be much more straight-forward, since there would be no 'delay' in the group-init (and some API's like CombatMaster/Tracker start combat immediately with the first chunk of group-inits).

Nice API altogether!!

Interesting request. I'm curious to see what Kurt says. For myself, I prefer to let my players roll their own initiative (via a token action button), for two reasons. One, players like to do it. :) Two, rolling through the sheet takes into account any unique mods a given player might have -- for example, an item that grants advantage on initiative. To my knowledge, group-init doesn't check for those states on the character sheet. 

Jay R. said:

Juan C. said:

Hey.-

I don't know if it has been recommended before, but could it be possible to add a field with the players' token-ids so that they could be included in the encounter's group-init function?. Probably a query or a toggle button could make you able to incluide or not the players in encounters. Or a new button (like a D6 with a 'P' overlay) to signify roll the group-init with the PC's and Encounter's TokenID's together.

One can achieve a similar effect by just adding an encounter with the PC's id's in it (or including the PC's in every single encounter along with the enemies), but the proposed way would be much more straight-forward, since there would be no 'delay' in the group-init (and some API's like CombatMaster/Tracker start combat immediately with the first chunk of group-inits).

Nice API altogether!!

Interesting request. I'm curious to see what Kurt says. For myself, I prefer to let my players roll their own initiative (via a token action button), for two reasons. One, players like to do it. :) Two, rolling through the sheet takes into account any unique mods a given player might have -- for example, an item that grants advantage on initiative. To my knowledge, group-init doesn't check for those states on the character sheet. 

I've started working on implementing this as an option - of course, that means I need a way to store and retrieve option settings, so that work needs to be done on the backend first. The storage/retrieval system is more or less complete, but I've made things a little more complicated up front in the way I define my configuration settings so that I can support localization and extension down the road - and the ability to reuse everything in other API scripts - so what ends up looking like a simple on/off switch from the UI standpoint is a bit more complicated.

That said, here is my assumption for this feature (I don't use GroupInitiative, though I may start for my NPCs now)... If the players were to be included my plan was to include rolling initiative for any tokens on the page where the encounter is located that:

• Represent a character
• Are not "controlledby" noone
• Are not "controlledby" all

Meaning a player would need to have a token on the same map as the encounter in order to be included in the initiative roll. Even if a player had multiple tokens (multiple characters, summoned entities, etc.) they would get their own initiative rolls. I think that would make it as generic as possible without adding a lot of required setup.

This would be controlled by a configuration toggle that currently defaults to off, so players wouldn't be included in Group-Init calls unless you turn it on.

Kurt J. said:

Jay R. said:

Juan C. said:

Hey.-

I don't know if it has been recommended before, but could it be possible to add a field with the players' token-ids so that they could be included in the encounter's group-init function?. Probably a query or a toggle button could make you able to incluide or not the players in encounters. Or a new button (like a D6 with a 'P' overlay) to signify roll the group-init with the PC's and Encounter's TokenID's together.

One can achieve a similar effect by just adding an encounter with the PC's id's in it (or including the PC's in every single encounter along with the enemies), but the proposed way would be much more straight-forward, since there would be no 'delay' in the group-init (and some API's like CombatMaster/Tracker start combat immediately with the first chunk of group-inits).

Nice API altogether!!

Interesting request. I'm curious to see what Kurt says. For myself, I prefer to let my players roll their own initiative (via a token action button), for two reasons. One, players like to do it. :) Two, rolling through the sheet takes into account any unique mods a given player might have -- for example, an item that grants advantage on initiative. To my knowledge, group-init doesn't check for those states on the character sheet. 

I've started working on implementing this as an option - of course, that means I need a way to store and retrieve option settings, so that work needs to be done on the backend first. The storage/retrieval system is more or less complete, but I've made things a little more complicated up front in the way I define my configuration settings so that I can support localization and extension down the road - and the ability to reuse everything in other API scripts - so what ends up looking like a simple on/off switch from the UI standpoint is a bit more complicated.

That said, here is my assumption for this feature (I don't use GroupInitiative, though I may start for my NPCs now)... If the players were to be included my plan was to include rolling initiative for any tokens on the page where the encounter is located that:

• Represent a character
• Are not "controlledby" noone
• Are not "controlledby" all

Meaning a player would need to have a token on the same map as the encounter in order to be included in the initiative roll. Even if a player had multiple tokens (multiple characters, summoned entities, etc.) they would get their own initiative rolls. I think that would make it as generic as possible without adding a lot of required setup.

This would be controlled by a configuration toggle that currently defaults to off, so players wouldn't be included in Group-Init calls unless you turn it on.

Sounds reasonable. I especially like being able to do this with summoned creatures controlled by the players. 

Support for including players in Group-Init rolls is in. This entailed building out my configuration setting system that will hopefully become a standard across my scripts (speedier development, yay!)

The command "!eh configmenu" will list the configuration menu with (currently) a single item you can toggle on and off.

The rules mentioned above are how it determines what player tokens to include, but essentially they:

• Have to be on the active encounter page
• Have to represent a character
• The represented character has to be controlled by one or more players, but not "All Players".

All of that really only takes a few lines of code, but most of the changes in 1.0.6 are to support parameter storage and localization. You can change the APILANGUAGE setting in the script to "french" to see some google-translated text in some places. This isn't completed yet but the framework is there, so it is just a matter of going through and putting in the text. At some point, Google translate is going to be less than stellar for this so if native speakers want to give me some text suggestions, I'm all for it.

Given the number of posts I get in the PowerCards thread from folks whose main language isn't English, I like the idea of supporting multiple languages. When I get EncounterHelper to the point where I feel it can be up on OneClick, selecting a language should be as easy as picking off of a dropdown menu.

Wow, that was quick. Very nice!!

I told myself I was going to stop working on this for a while, but I ended up back at the PC... Version 1.0.7 is up with the localization system completed and basic (google translate) translations for French, Spanish, and German.

Languages are easy to add - and I assume the translations are not the best options - so I'm open to suggestions for updating them.

Looking forward to trying this out!

This looks really good! In terms of additional functionality, might it be nice to see a "set 1st positions" and "reset encounter"? I know a lot of people simply copy a game once it's all set up, but if you had to reset on the same map that would be invaluable (e.g. for your random encounter map use case). The reset could be potentially be a dialogue option from your current X command? Set 1st positions (Or "Record encounter start state" or any similar) should probably have an "Are you sure?" interlock to prevent frustrating errors.

Loving this script. 

One super minor thing: When I click on details for an encounter, the header of the table has some odd formatting:

Certainly nothing breaking. :)

MykeMyke said:

This looks really good! In terms of additional functionality, might it be nice to see a "set 1st positions" and "reset encounter"? I know a lot of people simply copy a game once it's all set up, but if you had to reset on the same map that would be invaluable (e.g. for your random encounter map use case). The reset could be potentially be a dialogue option from your current X command? Set 1st positions (Or "Record encounter start state" or any similar) should probably have an "Are you sure?" interlock to prevent frustrating errors.

That's a pretty interesting idea... I'll see if there is a way I can come up with to make that work.

Erik M. said:

Loving this script. 

One super minor thing: When I click on details for an encounter, the header of the table has some odd formatting:

Certainly nothing breaking. :)

Oops ;) I missed that when I converted how I was building output strings. I'll get an update out over the weekend.

Version 1.0.8 has been uploaded

I have updated the development GIST with the latest version of Encounter Helper. In this version:

- Corrected the bad column header in the !eh display command pointed out by Erik M.

- Implemented the ability to reset encounters, based on the suggestion by MykeMyke. This works as follows:

• Any existing encounters will be unchanged/unharmed by this version upgrade. The will simply not be able to use the reset unless they are recreated.
• When an encounter is created, a set of values will be stored along with each token's ID. These include (by default): left, top, width, height, bar3_value, bar3_max, statusmarkers. The values that are saved are configurable in the script.
• A new command : !eh reset <encounter name> reads the values from the encounter list for each token and replaces them.
• The !eh list now contains a button (a hammer and wrench) to reset the encounter. Clicking this button will supply a confirmation button you must click to actually reset the encounter.
• NOTE: The reset feature cannot restore deleted tokens, but they won't cause the script problems.

As always, feedback and suggestions are welcome!

Wow, thanks, Kurt!

Jay R. said:

Wow, thanks, Kurt!

It is kinda neat seeing the tokens slide back into their places, damage healed, and status markers removed or re-added :)

Version 1.0.9 has been released

This version adds to the reset featuers in 1.0.8 by including the following shanges:

• Added the "!eh update_reset_info <encountername>" command. Will update the named encounter's reset data with the current data from the encounter's tokens.
• Added the "!eh update_all_reset_info" command, which will run update_reset_info for every encounter on the page. This is a quick method for updating existing encounters and saving reset data for them.
• Added the "!eh reset_all_encounters" command, which will run !eh reset for every encounter on the page.
• Added a "show page options" button to the encounter list that will produce a new menu with additional buttons that impact all of the encounters on the page. These are currently "Update all Rest Info" and "Reset All Encounters". Additional buttons may appear in this list over time.

Amazing! Thanks for taking the feedback on board.

Bug report - Parentheses in Encounter Names works for the individual actions, but not the Reset All Encounters button - reports action taken in chat but does not correctly execute.

Feature request - Ability to record the current layer as part of the Reset Data initialisation, and restore as normal. This might be as simple as me not knowing the parameter to specify as part of "resetValues" :-)

Feature request - Add a page-wide option to create a "Master Encounter" from all encounters already in the script; this is just to avoid mistakes for complex encounters and basically facilitate group init when you want to roll all at the same time, but have some on the Token layer and some on the GM layer.

Feature request - Pause / Exclude specific encounters from page wide actions. Toggle on the encounter bar in !eh list. This would be useful for adjustments to an encounter's strength while still maintaining the simplistic workflow.

MykeMyke said:

Bug report - Parentheses in Encounter Names works for the individual actions, but not the Reset All Encounters button - reports action taken in chat but does not correctly execute.

Feature request - Ability to record the current layer as part of the Reset Data initialisation, and restore as normal. This might be as simple as me not knowing the parameter to specify as part of "resetValues" :-)

Feature request - Add a page-wide option to create a "Master Encounter" from all encounters already in the script; this is just to avoid mistakes for complex encounters and basically facilitate group init when you want to roll all at the same time, but have some on the Token layer and some on the GM layer.

Feature request - Pause / Exclude specific encounters from page wide actions. Toggle on the encounter bar in !eh list. This would be useful for adjustments to an encounter's strength while still maintaining the simplistic workflow.

Parenthesis : I should have this fixed for the next release... Parenthesis in notes/chat are weird, and I was double-translating them. I need to test the fix a bit, but it should be straightforward.

Layer : If you add "layer" to resetValues that should do it. Of course, you'll need to update the encounter data to store the layer before it can be reset. Where you add it in the list won't matter - the names of the stored fields are saved with their values, so ordering isn't important.

Last Two : I'll need to ponder how these would work/be implemented :) 

Getting some strange behaviour after resetting an encounter when attempting to select affected tokens. They sometimes have an offset and clicking where they are seems to "zone" to selecting a different token. I haven't been able to isolate what takes it back to normal behaviour, but it does seem to snap back somehow.