[Community Request] Bugs/Missing Feature Parity/Desired Features -- help me build a list!

Hi Community!

I'm working on building a list of all the bugs, parity issues, and Missing Features for Mods.

Note: This is strictly about Mod (API) Scripts, not anything else on the site.

Here's my definition of these:

Bugs

This is something that is clearly broken about the implementation.  It's something that should work, but doesn't.  Here's some examples:

• Created Text Objects don't have width and height set correctly.  When a Mod script creates a text object, both properties are set to 0.
• msg.selected is blank if @{target|...} is used on the call.  If you supply information with a @{target} call, the msg.selected object is not populated.

Parity Issues

This is where functionality exists for the Player, but doesn't exist for Mod scripts.  Here's some examples:

• Access to Animation States.  A Player can play or pause an animated graphic, but the API does not have access to this.
• Access to folders in the journal.  The GM can sort items into folders and create folders, the API cannot.

Missing Features

These are things it would be reasonable to expect Mod scripts to have access to, but that they don't currently.  Here's some examples:

• A way to get the currently configured character sheet.  This would allow tailoring scripts to sheets, and detecting incompatibilities, etc.
• And event when pings happen.  This would give a nice interface for scripts that want to target a location, say for moving a token, or placing an effect, etc.

Try to keep one per post. 

• If you're posting a Bug, try to give reproduction steps, or a reproduction script, or a link to a bug post somewhere. 
• If you're posting a Missing Feature, try to include some examples of how you'd use it.

Thanks for the help!

I tried looking for this feature and couldn't find it.  I built a map using purchased tokens.  I would like to convert the completed map into an image to speed up the processing and lower the data footprint.  Is that feature available or possible? 

That wouldn't be part of a Mod (API) Script, that would be a general feature request.  You should look in the Suggestions and idea threads for something that matches and upvote it, probably this one: https://app.roll20.net/forum/post/1406171/slug%7D#post-2845827

Missing feature: access to images that are loaded in a game but not in a player’s art library.

This may be intentional on Roll20’s part, but Mod scripts do not have access to images that are loaded from modules or add-ons; they can only manipulate images that have been uploaded by a player. It’s a frequent question regarding image usage with scripts. 

Missing feature: copy scripts between games. 

Either with the Transmogrifier or when copying a game. 

I'm no longer a Pro but when I was, I remember wishing there was a field on the 'chat:message' message object revealing the current page id of the chat sender.

BUG: playCardToTable() crashes the API for User Library images.

From Aaron's post here: https://app.roll20.net/forum/post/7583610/slug%7D#post-7595323

Jarren: Thanks, I've recorded those two.

Jim: I'll make a note on that.  You can get the page id with some finagling (I've got a function that makes it pretty easy), but it couldn't hurt to have that information on the msg object innately.

Pat: Thanks for that, I found the repro script I wrote for that as well.

Missing/suggested feature

A modal UI <div> which floats over the canvas which scripts have indirect access to - just an absolute/fixed div with a high z-index to act as a container.

Roll20 writes a controller that takes custom events to request a modal to pop up, so Roll20 remains in control of:

    - the modal's outer frame, to match styling with iframes and provide control buttons in the top right

    - max number of modals open at once

    - max/default size of modals

Script authors just need to send a config object. Ideally, we'd want to be able to receive data back from the modals, so some form of whitelisted elements for use in the body would be needed, and a method of returning any inputs.

A few preset buttons for the footer wouldn't go astray, either - boolean returns for yes/no, 'ok' functionality for submitting filled forms.... that probably covers 99% of use cases.

A couple of examples:

// if (arg === 'help') ....
requestModal({
  title: 'Token Mod Help',
  id: 'tokenModHelp',
  buttons: [{
    label: 'Got it!',
    action: 'close'
  }],
  content: `<h3>tokenMod Help</h3> .... etc etc`
});

// if (arg === 'settings')
requestModal({
  title: 'Token Mod Config',
  id: 'tokenModConfig',
  buttons: [
    {
      label: 'OK',
      action: 'submit',
      target: '#tokenModConfig'
    },
    {
      label: 'Cancel',
      action: 'close'
    }
  ],
  content: `
    <h3>tokenMod Config</h3>
    <form id="tokenModConfig">
      <span>Allow players to use ids: </span>
      <input type="checkbox" name="allow-ids" />
    </form>
    .... etc etc`
});

on('modal:response', (response) => {
  if (response.id === 'tokenModConfig') {
    const newConfig = response.data;
    // Do things with new settings
  }
});

Script authors have made the best of an ugly situation with chat-bar menus, but it's a pretty poor solution for 2022.

Thanks Oosh, added!

BUG (long lasting) : The update of the visions to be able to use some other scripts (observer, etc...). I know that bug is a legend and soooooo longlasting, but i thought it could be good to give a shoot at it again.

Thank you sir for this initiative

Perhaps a feature that would provide a notice or alert to GM when a script has crashed, failed to load or a player tries to use an action button or command for an API script that isn't there/working/loaded?

Have been in games myself but also read other peoples comments that rolls are not working and there is a lot of confusion as to why, when it turns out the script for some reason didn't load properly. Perhaps it needs a way to silence the alerts, or prevent multiple alerts of same kind to spam the alerting method, e.g. GM chat. 

Lionel: Thanks for the reminder, I've put it on the list.

Richard: Thanks, that's a great feature idea, I've put it on the list.

!setattr --charid @{selected|character_id} --armorother4_mod|?{mod|0}

!token-mod --set bar1_value|?{mod|0}

Vince: I'd say that counts! I'll add it to my list. 

Vince: I verified and added that bug with reproduction steps to my list.  I also adjusted TokenMod to handle this situation natively: https://app.roll20.net/forum/permalink/11047338/

Thanks Aaron.  setWithWorker() was introduced 5 years ago, I just assumed it would have already been implemented in most Mods by this point.

The fix in TokenMod is a workaround. There is no .setWithWork() for anything but attribute objects. To make it work, TokenMod now detects if a change is happening on a bar that is linked, then changes the linked attribute instead. 

Not sure if this is on you list but would like the ability to control animations in the api., i.e Start/Stop/Reset/Loop.  This would work well for door or chests for instance, where a player picks thee lock and it opens,  Graphic animation can be played, DoorKnocker activated to handle the4 Dynamic Lighting and an appropriate sound played.  Trying to do this currently takes a lot of mouse clicks and does not produce a smooth result.

Thanks Aaron

That is a good suggestion, and don't worry Andy, I've got it on the list!

Aaron, if you are still collecting these, there seems to be some odd behavior with setting attributes via the API that have not been set to non-default values through the UI first. I've run into this on a couple of different sheets, but one example I can think if right away is Global * Modifiers in the 5E sheet. If a player creates one and never manually toggles it on, setting the global_attack_active_flag (or whatever type, like global_save, global_damage, global_ac, etc) via obj.set doesn't seem to do anything. After the player has turned it on and back off, it works normally even between sessions.

I've also seen cases since the delayed character loading was introduced where an API or macro trying to access an ability on a character sheet that hasn't been opened in the UI yet acts like the ability doesn't exist. It doesn't seem to trigger the game to fully load the character, so the API can't find these resources.

The Aaron, you have to push Roll20 to get more granular in their categorizing of APIs.  Right now there's too many broad strokes, so individual API issues won't really make this list.  

Go to Roll20 and find the major APIs being used, other than yours because yours are always being used, and include them in the list.  Your approach is too broad based.  Start with the big ones, then narrow down from there.  

And if general architecture issues are reported, then great.  That will be broad based and not api specific.  Otherwise focus on big fish and then move down the food chain.  

Is there a suggestion in there, Victor? I don't actually understand what you're saying. Are you suggesting that individual user scripts need to be fixed by Roll 20?

Or do you mean the actual API needs more granularity, the sandbox layer functions our scripts use to communicate with firebase, like findObjs()?

I'm not quite following...

I think the idea is that the categories in the One Click need to be more granular.

Kurt, I'm going to need to try and get some concrete reproductions of those to add them to my list, but I think they're something good to track down.

The Aaron said:

Kurt, I'm going to need to try and get some concrete reproductions of those to add them to my list, but I think they're something good to track down.

For the second one (late loading issue), this works every time for me to reproduce. Doesn't even need the API:

1. Launch a game
2. Add a new character to the game (I called mine MacroTest)
3. On the MacroTest character, make an ability. I called mine "Say-Hello" that just has the word "Hello" in it.
4. In the chat window, get the character id of the character (ie, @{MacroTest|character_id})
5. Create a button to run the ability ([Test](~-NCCU4eSfwLr4hPrTBsC|Say-Hello)) using the character ID from #4 above
6. Clicking this button will work fine.
7. Exit the game with all players
8. Launch the game
9. Recreate the button exactly as above (ie, [Test](~-NCCU4eSfwLr4hPrTBsC|Say-Hello) in chat)
10. Clicking this button will report "No ability was found for %{-NCCU4eSfwLr4hPrTBsC|Say-Hello}"
11. Open the character sheet for MacroTest
12. Click the already existing button in chat or make a new one... now it works fine

I'll put together a simple API example for the other issue, but the one above happens to me reliably. Interestingly when trying to recreate this I noticed that if I use the character name to create the button, it works ([Test](~MacroTest|Say-Hello) and the by-id buttons work after that as well, so it seems the use of the name to look up abilities triggers the character to load into the game, but going by ID does not.

Here's a parity issue, particularly in the 5e OGL sheet:

If you have whisper/advantage toggle enabled (wtype and rtype attributes respectively, which you can set), you can change the whisper toggle between public/gm and the advantage toggle between advantage/normal/disadvantage. This state cannot be set through the API.

When you say "cannot be set through the api" do you mean it's a missing feature of the script (not what I'm collecting) or a missing capability of the Mod Sandbox (what I'm looking for)?

Liam said:

Here's a parity issue, particularly in the 5e OGL sheet:

If you have whisper/advantage toggle enabled (wtype and rtype attributes respectively, which you can set), you can change the whisper toggle between public/gm and the advantage toggle between advantage/normal/disadvantage. This state cannot be set through the API.

The advantage toggle state and whisper toggle state can be set through the API, as they are simply sheetworker created attributes on the 5E sheet.  

When you change the 'Roll Queries' setting on the Character Sheet tab (clicking on the small 'Cog' icon), you get 4 choices, which each update the 'rtype' attribute:

Always Roll Advantage

{{always=1}} {{r2=[[@{d20}

Advantage Toggle

@{advantagetoggle}

Query Advantage

@{queryadvantage}

Never Roll Advantage 

{{normal=1}} {{r2=[[0d20

The Advantage Toggle changes the 'advantagetoggle' attribute to look like this:

Advantage

{{query=1}} {{advantage=1}} {{r2=[[@{d20}

Normal

{{query=1}} {{normal=1}} {{r2=[[0d20

Disadvantage

{{query=1}} {{disadvantage=1}} {{r2=[[@{d20}

The 'queryadvantage' attribute looks like this:

{{query=1}} ?{Advantage?|Normal Roll,&#123&#123normal=1&#125&#125 &#123&#123r2=[[0d20|Advantage,&#123&#123advantage=1&#125&#125 &#123&#123r2=[[@{d20}|Disadvantage,&#123&#123disadvantage=1&#125&#125 &#123&#123r2=[[@{d20}}

The whisper settings are similar. When you change the 'Roll Queries' setting on the Character Sheet tab , you get 4 choices, which each update the 'wtype' attribute:

@{whispertoggle}

?{Whisper?|Public Roll,|Whisper Roll,/w gm }

/w gm 

The 'whispertoggle' attribute looks like this:

/w gm 

So if you were going to use ChatSetAttr to set the Whisper setting to Toggle, and also wanted to set the specific toggle setting to Whisper, you'd have to set 'wtype' to @{whispertoggle} and 'whispertoggle' to /w gm .

If you want to use ChatSetAttr to set the Roll setting to Toggle, and the specific toggle setting to Advantage, you'd have to set the 'rtype' to @{advantagetoggle} and 'advantagetoggle' to {{query=1}} {{advantage=1}} {{r2=[[@{d20}.

Kurt J. said:

The Aaron said:

Kurt, I'm going to need to try and get some concrete reproductions of those to add them to my list, but I think they're something good to track down.

For the second one (late loading issue), this works every time for me to reproduce. Doesn't even need the API:

1. Launch a game
2. Add a new character to the game (I called mine MacroTest)
3. On the MacroTest character, make an ability. I called mine "Say-Hello" that just has the word "Hello" in it.
4. In the chat window, get the character id of the character (ie, @{MacroTest|character_id})
5. Create a button to run the ability ([Test](~-NCCU4eSfwLr4hPrTBsC|Say-Hello)) using the character ID from #4 above
6. Clicking this button will work fine.
7. Exit the game with all players
8. Launch the game
9. Recreate the button exactly as above (ie, [Test](~-NCCU4eSfwLr4hPrTBsC|Say-Hello) in chat)
10. Clicking this button will report "No ability was found for %{-NCCU4eSfwLr4hPrTBsC|Say-Hello}"
11. Open the character sheet for MacroTest
12. Click the already existing button in chat or make a new one... now it works fine

I'll put together a simple API example for the other issue, but the one above happens to me reliably. Interestingly when trying to recreate this I noticed that if I use the character name to create the button, it works ([Test](~MacroTest|Say-Hello) and the by-id buttons work after that as well, so it seems the use of the name to look up abilities triggers the character to load into the game, but going by ID does not.

Confirmed. The character has to be opened at least once for that construction to work. Name, yes. ID, no.

Kurt J. said:

Interestingly when trying to recreate this I noticed that if I use the character name to create the button, it works

That may be somewhat my fault...  I reported this while lazy loading was still on the dev server.  At that time, none of my macro sheets worked without opening the sheet to the Attributes & Abilities tab (it had to be that tab at the time).  I reported it fixed after they made a change, but I always use the sheet name the macro comes from when constructing my chat menus, so I never caught that other forms of constructing the menus weren't working.

Using the ID does work without opening the character first on a character Ability. It appears to be Collections macros and macros just entered into chat that have this issue. In most cases, code that refers to a specific character by ID is better suited to be an Ability (there are exceptions), so the problem probably doesn't affect too many people. Especially weighed against the exceptional advantage granted by Lazy Loading.

From someone who's a long time coder taking a look at the API for the first time, my biggest request would be for the documentation to be updated to be de-obfuscated and made legible at a glance.  Giving the function header by itself so you can see at a glance what parameters are passed into it, then the description for each parameter separate to that would be quite helpful.

As an example of some fairly hard to read documentation, the createObj() global function has this in it:

TYPE(String) The type of Roll20 object to create. Only 'graphic', 'text', 'path', 'character', 'ability', 'attribute', 'handout', 'rollabletable', 'tableitem', and 'macro' may be created.ATTRIBUTES(Object) The initial values to use for the Roll20 object's properties.

Particularly confusing from a programmer's perspective is the baffling lack of space after fullstops in the sentences, leading to "created.ATTRIBUTES(Object)" looking, at a glance, like something to do with calling the ATTRIBUTES function of the 'created' object with the 'Object' parameter passed to it.

Where are you quoting that from? That does not look like the wording of the Wiki or the Help Center.

Yeah, no idea where you're pulling that documentation from, but the wiki is definitely the best place to look. The Help Center text is mostly ripped straight from the wiki, but it looks worse. As Keith said, neither of those sources match what you've quoted.

It looks like a raw text rip of the wiki's function documentation page, with all the formatting ripped out. Without the formatting and new lines, it would indeed be very difficult to parse. Hopefully there isn't a wiki or help center page with the unformatted content on it.

Parity Issue: ability to set the alpha channel (transparency) for colors

It is possible to set the alpha for a color on tokens manually (e.g. the token's aura), but this is not available to Mod scripts