Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

Dev API Update 8/22: setDefaultTokenForCharacter(), Fixes for repeating_$n variables, and more!

1471916862

Edited 1471917637
Riley D.
Roll20 Team
Hey everyone, We've just pushed a new update out the API for the Dev Server which provides the following new features: setDefaultTokenForCharacter(characterObj, graphicObj) This is a new function which allows you to use the API to set the default token for a Character. To use it, just pass in a Character object (that you can get with e.g. findObjs() or getObj()) and a Graphic object. It will handle doing all the necessary work to set up the Character's default token to a snapshot of the Graphic object. Note that default tokens are snapshots, not links, so if you change something about the Graphic object and you want to update the default token, you'll need to call this again. Also note that the Graphic object will not be automatically linked to the Character via its "represents" field, so be sure to set that in advance. Fixes for repeating_$n variables Behavior when using repeating_$n variables (for example, repeating_spells_$1_name to get the name of the spell in the second row of a repeating section) should now match the rest of Roll20's behavior. This change applies both to sendChat() calls (which had support for these previously but could possibly not match the correct order), and we have also added support for them when using getAttrByName(). In addition, getAttrByName() is now case-insensitive, as with the rest of variable usage in Roll20. Fix for noarchive: true There was a behavior previously where if you called sendChat() with the noarchive:true flag set, it could result in multiple "chat:message" events being called for the same message. This should now be fixed. In addition to these changes, internally we have a prototype of the code which can run the Sheet Worker scripts from Character Sheets on the API Server. However, I'm thinking it might be best to not turn this on by default for all sheets and scripts, since it's possible existing scripts may not anticipate this new interaction and it could cause issues. So I wanted to get the community's input on what the best way might be to handle that. Right now I'm leaning toward requiring you to set a flag on the API Scripts page that says "Execute sheet worker scripts in the API" or something of that nature. At least until we've thoroughly tested the possible interactions and given script authors time to make sure it won't interfere with their existing scripts. Thoughts?
1471918529
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
I'm looking forward to that noarchive fix. I've been wanting to make the config menus for my scripts noarchive for awhile now.
1471946005
Jakob
Sheet Author
API Scripter
setDefaultTokenForCharacter(characterObj, graphicObj) That makes me happy once it goes live. Even less clicking required to set up a character :). Great thing on the noarchive fix as well, I was really struggling with that when writing e.g. ChatSetAttr and getting all sorts of unexpected errors. Fixes for repeating_$n variables.  That's great! I know it's a separate matter, but is there any chance that you'll make it possible to find repeating attributes by row index via findObj, or at least expose the row index to the API some other way? I had to cook up some hacky solution to make ChatSetAttr accept repeating_$n variables, and it still targets the wrong row when any of the rows have been reordered. Thoughts on sheet worker - API interaction.  How about including it as an option for attribute.set? Script authors can - and must - then choose to run sheet worker scripts when they update attributes deliberately.
1471975458
The Aaron
Pro
API Scripter
This sounds great.  Is there any restriction on the imgsrc for the graphic object which is used to set the default token?
The Aaron said: This sounds great.  Is there any restriction on the imgsrc for the graphic object which is used to set the default token? It doesn't place any additional restriction on it, no. You pass it an existing Graphic object. If the Graphic object is already in the game, it's assumed that either a) you created it using the API with the existing restrictions, or b) it was already in your game because you put it there via the Roll20 interface, so we don't need to re-check it. So I don't think this would open up any avenues to create totally new Graphic objects via the API that don't abide by the current API restrictions, but you can use it with existing Graphic objects even if they don't abide by those restrictions, if that makes sense. If that's not the behavior you're seeing, let me know.
1471987607
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Hmmm, would this open up the possibility of being able to create tokens on the future that don't follow the current api rules if it is stored as a default token?
1471987808
Natha
KS Backer
Sheet Author
API Scripter
Excited about  setDefaultTokenForCharacter !
Jakob said: Thoughts on sheet worker - API interaction.  How about including it as an option for attribute.set? Script authors can - and must - then choose to run sheet worker scripts when they update attributes deliberately. Yeah I kind of like this idea. I suppose it's a bit annoying to have to update every set() call...maybe we could just add a new function called setWithWorker() then it would be a simple find/replace thing if you know you want the functionality. But that way script authors have complete control at a fine-grained level about whether they want to take advantage of the sheet worker script or not. 
1472137332
Lithl
Pro
Sheet Author
API Scripter
Jakob said: Fixes for repeating_$n variables.  That's great! I know it's a separate matter, but is there any chance that you'll make it possible to find repeating attributes by row index via findObj, or at least expose the row index to the API some other way? Have you tried using filterObjs instead of findObjs?
1472138843
Jakob
Sheet Author
API Scripter
Brian said: Jakob said: Fixes for repeating_$n variables.  That's great! I know it's a separate matter, but is there any chance that you'll make it possible to find repeating attributes by row index via findObj, or at least expose the row index to the API some other way? Have you tried using filterObjs instead of findObjs? No, but I don't see how that will help? How can I access a repeating attribute's row index?
1472140290
The Aaron
Pro
API Scripter
It might be nice to have a _rowid on the attributes which are repeating attributes.  Then you could grab an attribute with _$1_ and use it's _rowid to grab all the other attributes in that row with filterObjs().  Really, you could do that now with a bit of string manipulation, but for convenience... 
1472143812

Edited 1472143943
Jakob
Sheet Author
API Scripter
The Aaron said: It might be nice to have a _rowid on the attributes which are repeating attributes.  Then you could grab an attribute with _$1_ and use it's _rowid to grab all the other attributes in that row with filterObjs().  Really, you could do that now with a bit of string manipulation, but for convenience...  If I'm not mistaken, you currently can't do it with string manipulation... sure, once I have an attribute, I can get its rowid, but I can't find out which one is $1 in the first place. What would be really useful here is a variant of getAttrByName that returns the object and not its value.
1472152114
The Aaron
Pro
API Scripter
Ah, I missed that this is only for the 2 functions sendChat() and getAttrByName().  bummer.
1472244652
Lithl
Pro
Sheet Author
API Scripter
Jakob said: Brian said: Jakob said: Fixes for repeating_$n variables.  That's great! I know it's a separate matter, but is there any chance that you'll make it possible to find repeating attributes by row index via findObj, or at least expose the row index to the API some other way? Have you tried using filterObjs instead of findObjs? No, but I don't see how that will help? How can I access a repeating attribute's row index? I believe the return value of filterObjs (although now that I think about it, this would apply to findObjs too) will be ordered by the order of attribute creation. So if the result array only contains a single attribute from each row in a repeating section that has not been reordered, the index into the array will be the row index as well.
1472248252

Edited 1472248659
Jakob
Sheet Author
API Scripter
Brian said: Jakob said: *snip* I believe the return value of filterObjs (although now that I think about it, this would apply to findObjs too) will be ordered by the order of attribute creation. So if the result array only contains a single attribute from each row in a repeating section that has not been reordered, the index into the array will be the row index as well. That's true, and with filtering and string manipulation you can find a list of all section rowids for a given type of repeating section (I've had to do this in ChatSetAttr), in order of creation. But that's i) hacky, ii) as you said, does not know about reordering. Not an ideal state of affairs.
1472403109
Lucian
Pro
API Scripter
Wow, lots of good stuff here! Especially pleased about the prospect of sheet worker interaction from the API. I'd have a preference for a solution that doesn't involve users having to select something - I think that this should be something that script authors determine - so the new parameter/method option is attractive. Have you given any thought to the synchronisation issues that this might create (I don't know enough about how it will work to know if it's a real problem)?  In particular, I'm concerned that script authors may find themselves plagued with bizarre race conditions if the sheet workers execute asynchronously with no form of completion callback. I guess this is going to be particularly challenging because the sheet workers can trigger each other in chains, and reliable behaviour will only be achievable if script authors can be sure that all dependent updates have triggered before they take decisions based on the state of the character attributes. Is there any way that the code that executes the sheetworkers on the API server can e.g. replace the setAttrs method with one that keeps track of all the dependent updates that are generated, so that a final "everything that you triggered is finished" callback can be made. It's giving me a headache just thinking about how to ask the question in a meaningful way, which doesn't seem like a good sign - I'm guessing this will be hard :-( Here's hoping that you've already got a simple and elegant solution to the problem and I'm worrying unnecessarily! Cheers,
1472405350
Kryx
Pro
Sheet Author
API Scripter
How are sheetworkers on the API server any different from before? What impact will putting them on the API server have? I'm wary of requiring users to check a box as it's another thing that can go wrong. It seems you'd want the better option (interaction with API) to be the default, but perhaps I'm naive to the issues that this could cause (potentially outlined by Lucian above?)
1472409573
The Aaron
Pro
API Scripter
@Lucian, it sounds like you're worried about the API Sheet Worker making changes and triggering changes in a Player's Sheet Workers instance?   I don't think that's a concern based on my understanding of the architecture involved.  I believe that each location a Sheet Worker runs acts as a Sandbox and only reacts to changes it is making, finally communicating the state up to the Firebase instance, which fans out updates to each location the sheet exists.  The Firebase updates don't cause Sheet Workers to run but can cause API events to occur.  At that point, the API might make some changes that then cause the API's Sheet Worker Sandbox to make changes, but those would not cause other Sheet Worker Sandboxes to trigger.
1472416217
Lucian
Pro
API Scripter
@Aaron, sorry I obviously wasn't clear. What I'm talking about is the API being able to read consistent state from a character in a sequence like this: API changes e.g. DEX attribute Sheet workers fire and update values (which may trigger other sheet workers in turn) API reads e.g. AC I'd like to be able to be confident that I can read the AC value that is consistent with the DEX value I've just set, but this will require me to have some notification that all of the sheet workers have finished executing. Otherwise I'm going to have some horrible race conditions where behaviour is dependent on which part of the code executes faster :-(
1472425687
The Aaron
Pro
API Scripter
Ah, makes sense.
It is asynchronous (just like the sheetworker operates on the client-side). Basically the way it works is exactly the same as on the client, only the thing "triggering" the worker to run is the API instead of a player. But I think trying to keep it consistent makes the most sense. That said, I think there might be somewhat of a way I can offer a callback that would support what you're wanting. Since the worker communicates with the main thread via messaging, it should be as simple as just keeping track of the messages going back-and-forth between them and waiting a reasonable amount of time (probably like 100ms) until the messages have stopped firing, at which point it's safe to assume whatever the sheet worker was going to do is done. It would be pretty "dumb" in the sense that it wouldn't be able to keep track of "the specific messaging regarding the DEX attribute changing is finished", rather just "all messaging is finished", but that should allow you to be "sure" that whatever changes were going to happen because you changed that variable have indeed finished. I am hoping to have the beta version of this out the door sometime next week, after we make it through the Storm King's launch madness.
1472821742

Edited 1472821781
Lucian
Pro
API Scripter
Riley D. said: It is asynchronous (just like the sheetworker operates on the client-side). Basically the way it works is exactly the same as on the client, only the thing "triggering" the worker to run is the API instead of a player. But I think trying to keep it consistent makes the most sense. Oh yeah, I agree completely. I think making it synchronous would be weird in the context of the rest of the system even if it were credible to implement it that way. That said, I think there might be somewhat of a way I can offer a callback that would support what you're wanting. Since the worker communicates with the main thread via messaging, it should be as simple as just keeping track of the messages going back-and-forth between them and waiting a reasonable amount of time (probably like 100ms) until the messages have stopped firing, at which point it's safe to assume whatever the sheet worker was going to do is done. It would be pretty "dumb" in the sense that it wouldn't be able to keep track of "the specific messaging regarding the DEX attribute changing is finished", rather just "all messaging is finished", but that should allow you to be "sure" that whatever changes were going to happen because you changed that variable have indeed finished. That sounds like it would do the job. For my current purposes I don't think the "crudeness" will matter too much, since at worst it will just mean I will end up waiting for some unrelated updates to happen before  I take action. Doing anything more sophisticated than this would seem to require some sort of proper transactional separation which seems implausible under the current architecture! Thanks for looking into this - will be amazing if you can get this to work well, will solve *so* many headaches!
1472865824

Edited 1472865871
getAttrByName seems to still be giving me trouble with repeating fields. I have the following two lines included in an api script: sendChat("", "NAME: @{"+charName+"|repeating_weapon_$0_name}"); sendChat("", "NAME: "+getAttrByName(getChar(charName).get("_id"),"repeating_weapon_$0_name")); getChar is a function I wrote (which I've tested and verified) that returns a character object when passed its name. Of the two sendChat lines, the first works, but the second does not. To be doubly sure, I've also confirmed that the second line works if I modify the getAttrByName call to refer to a non-repeating field. Am I missing something/misusing getAttrByName here?
1472902224
Jakob
Sheet Author
API Scripter
Just to be sure nathan, is this on the dev server? I believe this isn't live yet.
Ah -- no, this is on the standard server. I didn't realize this was only on dev at the moment (but now I see it in the very first post on this page... ah, well). Any idea when this might transition to the main server?
nathan said: Ah -- no, this is on the standard server. I didn't realize this was only on dev at the moment (but now I see it in the very first post on this page... ah, well). Any idea when this might transition to the main server? Within the next week or two, most likely. At this point I'm just trying to see if I have time to get the Sheet Worker stuff out the door with this push or if I'm going to push this stuff out and then do the Sheet Worker stuff in the next one.
Awesome -- thank you. Looking forward to it!
1474054305
Jakob
Sheet Author
API Scripter
setDefaultTokenForCharacter seems to be live now. Awesome! Is the noarchive:true fix also supposed to be live? Because I tested it out in a fit of enthusiasm, and the error still seems to occur.
Jakob said: setDefaultTokenForCharacter seems to be live now. Awesome! Is the noarchive:true fix also supposed to be live? Because I tested it out in a fit of enthusiasm, and the error still seems to occur. Should be live now.
1475775592

Edited 1475776811
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
So, there's still something funky with {noarchive:true}. I've started switching my scripts' menus and help outputs over to noarchive:true, and I'm noticing an intermittent bug. I haven't been able to chase it down to a simplest trigger case, but here's what I've go so far. Occassionally, when the API sends a noarchive message, I get one of my menus output about 5 seconds later. The menu that is output is from the last api command that I entered and is not related to the message that the script just sent. The fact that it is extremely intermittent is what has me stumped. EDIT: I think (emphasis on think) that it only happens if I don't clear the chat archive between sessions (or restarting the sandbox).
1477407075
Laurent
Pro
Sheet Author
API Scripter
I have an issue with repeating fields : var crit = getAttrByName(attackingCharacter, "repeating_armes_$0_armecrit"); raises the following error message: "Error: No attribute or sheet field found for character_id -KUECiT_f0zF8xYzaMPO named repeating_armes_-kuecsrijjdkhgtx3pgw_armecrit" (no error with non repeating fields, such as replacing the line with var crit = getAttrByName(attackingCharacter, "DV");) Any idea how the $0 gets transformed into something like the character id?
1477407467
The Aaron
Pro
API Scripter
$0 is expanded to the RowID of the first entry in the repeating field.  If you look at the source of the character in question you can find that -kuecsrijjdkhgtx3pgw and see it is the RowID of the first entry in repeating_armes.
1477408171
Laurent
Pro
Sheet Author
API Scripter
The error message just means that the attribute is not found, then. But when I copy paste the same attribute name in the chat @{character|repeating_armes_$0_armecrit}, I do get a value. In fact, the error seems to be there only when the value for the attribute is the default. Shouldn't default values be returned by getAttrByName? It seems to be the case for non repeating attributes...
1477491135

Edited 1477491552
Riley D.
Roll20 Team
Scott C. said: So, there's still something funky with {noarchive:true}. I've started switching my scripts' menus and help outputs over to noarchive:true, and I'm noticing an intermittent bug. I haven't been able to chase it down to a simplest trigger case, but here's what I've go so far. Occassionally, when the API sends a noarchive message, I get one of my menus output about 5 seconds later. The menu that is output is from the last api command that I entered and is not related to the message that the script just sent. The fact that it is extremely intermittent is what has me stumped. EDIT: I think (emphasis on think) that it only happens if I don't clear the chat archive between sessions (or restarting the sandbox). Are you saying you're seeing this repeated message in the client? I think the previous bug might have been related to seeing repeated API messages via events in the API... Looking at the client-side code, I'm not really sure how this could happen. Once we've heard a chat message, we store it by its unique ID. Then if we hear about the message with the same ID again, all we try to do is update the existing message that's already being displayed. So I'm not sure how you could end up with the same message repeated multiple times unless it was being sent multiple times from the API. Can you inspect the chat log in the browser and see if the ID is the same between the two messages? You should see a data-messageid attribute for each message. If they're the same, then something is wrong with our code that shouldn't allow multiple messages through. If they're different, then your API script is actually sending the same message multiple times (e.g. multiple calls to sendChat() ).
1477491350

Edited 1477491377
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Yes, It repeats a previous sendChat, which also triggers a repeated message event in the API.
Scott C. said: Yes, It repeats a previous sendChat, which also triggers a repeated message event in the API. (Sorry, I just updated my post with some more info. Take a look at that when you get a chance. Thanks! )
1477492126

Edited 1477492935
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
I'll go in and put the noarchive:true back into the appropriate sendChat's in my script and check, but I don't think it is my code sending the message multiple times as adding noarchive:true was the only change to the code that I made to get this behavior. EDIT: Apparently I was actually thinking ahead for once and simply commented out the noarchive:true additions to my sendChats, so I was able to replicate it more quickly than I thought. The message ID's of the two messages are different, so it's not just repeating the same message. It also is not the code of my script resending these messages tho because if I remove the {noarchive:true} call in the sendChats, the messages don't repeat.
Scott C. said: I'll go in and put the noarchive:true back into the appropriate sendChat's in my script and check, but I don't think it is my code sending the message multiple times as adding noarchive:true was the only change to the code that I made to get this behavior. Okay, well, let me know what you find out :-) Basically I guess the two things I need to know are: 1) Is the chat message that you're seeing a different ID than the other one showing up, and 2) If that's so, what's the code that's sending the message?
1477492978
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Sorry, apparently editing at the same time you are posting. I'm working on a simplest code to replicate right now.
Laurent M. said: I have an issue with repeating fields : var crit = getAttrByName(attackingCharacter, "repeating_armes_$0_armecrit"); raises the following error message: "Error: No attribute or sheet field found for character_id -KUECiT_f0zF8xYzaMPO named repeating_armes_-kuecsrijjdkhgtx3pgw_armecrit" (no error with non repeating fields, such as replacing the line with var crit = getAttrByName(attackingCharacter, "DV");) Any idea how the $0 gets transformed into something like the character id? I think this should be fixed on Dev. getSheetDefaultValue() should now return the correct value for repeating section rows. That's what getAttrByName() uses if it can't find the existing value so it should fix your issue as well. Let me know if that worked.
1477494334

Edited 1477494635
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Ok, so, I think I've figured out the trigger for it (which also means I've got a simplest code) and there are some changes to what I said above. If I send a noarchive message during the sandbox spin up (such as a message on(ready)) it can then trigger the error. In the below code, if I load up the script the message in on(ready) is sent. I can send archived or not archived messages just fine at this point. If I reload the sandbox though, the message in on(ready) is sent again and then the chat also sends the API chat command message for the last chat triggered noarchive message which then triggers the associated noarchive message to be sent again (which of course results in a new message id). At this point, any noarchive message sent by the API will result in this behavior. var BaseScript = BaseScript || (function() {     'use strict';     var HandleInput = function(msg_orig) {     var msg = _.clone(msg_orig), args;         log('&{template:'+msg.rolltemplate+'}'+msg.content);         log(msg);         if (msg.type !== 'api' || !playerIsGM(msg.playerid)){                 return;         } if(_.has(msg,'inlinerolls')){//calculates inline rolls msg.content = _.chain(msg.inlinerolls) .reduce(function(m,v,k){ m['$[['+k+']]']=v.results.total || 0; return m; },{}) .reduce(function(m,v,k){ return m.replace(k,v); },msg.content) .value(); }          args = msg.content.split(/\s+/);//splits the message contents into discrete arguments switch(args[0]) {             case '!naFalse':                 sendChat('BaseScript','This message is stored in the chat log (noarchive:false)');                 break;             case '!naTrue1':                 sendChat('BaseScript','This message is not stored in the chat log (noarchive:true)',null,{noarchive:true});                 break;             case '!naTrue2':                 sendChat('BaseScript','**This message is also not stored in the chat log (noarchive:true)**',null,{noarchive:true});                 break; } },          RegisterEventHandlers = function() {         on('chat:message', HandleInput);     };          return {     RegisterEventHandlers: RegisterEventHandlers };      }()); on("ready",function(){     'use strict';     sendChat('BaseScript','***This message was sent from on(ready) (noarchive:true)***',null,{noarchive:true});     BaseScript.RegisterEventHandlers(); }); Let me know if you need anything else and I apologize for not noticing that it was actually receiving the API command for the associated messages before, probably would have made troubleshooting easier. TL;DR:Steps to recreate: Save the above script on(ready) message will be sent trigger one of the noarchive messages via the chat commands reload the API sandbox on(ready) message will be sent wait a second or two API receives the chat command that you sent to trigger a noarchive message before the sandbox reloaded triggered noarchive message is sent If you only trigger non-archived messages with api commands, the behavior does not show up
No worries, thanks for the test case, makes it a lot easier to figure out the problem. I'll take a look at this later today and get back to you with what I find out.
So just to make sure I understand this, to trigger the error I load up the script, then send "!naTrue1", then I restart the sandbox, and then I should see the message from naTrue1 repeated again?
1477500058
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Hmm, I was just going to say yes, but I went and tested it in a fresh game first. It seems like you may need to send 2+ chat commands that trigger a noarchive message before restarting the sandbox to see the issue. Never noticed that before.
Scott C. said: Hmm, I was just going to say yes, but I went and tested it in a fresh game first. It seems like you may need to send 2+ chat commands that trigger a noarchive message before restarting the sandbox to see the issue. Never noticed that before. Here's a weird question for you -- after you send the chat command that generates the noarchive: true command, try restarting the sandbox within a second or two and see if it happens. Then try doing it again but wait at least 10 seconds to restart the sandbox. Does that make any difference?
1477509109
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Doesn't seem to have any effect. The chat command still gets repeated. Did some more testing while I was trying the above and it isn't the last API command that gets repeated. It's the last chat message that is at least two back but will go as far back as 6 messages (the earliest of these is what is repeated). If the repeated message is an api command and that command results in a noarchive:true message being generated, that message is output to chat and generates a chat event in the API log. If the repeated message is normal chat input (e.g. text) or an api command that results in a noarchive:false message, a chat event is logged in the API but the message is not output to chat (even though it is logged as if it had been). I'm thinking that the actual repeated api command and/or normal chat input message that gets logged (but not output to chat) might have the same message id as the original message, so the chat parser knows not to output it, but for some reason the API doesn't know to disregard it which results in the API trying to respond to the command even though it's not a valid message; no idea why this would prevent the API from outputting the message when it is noarchive:false (or just not declared) but not when it is norachive:true. Not sure if any of that makes sense, but I'm happy to try and clear it up if you have questions. Also, in case it's something about my account/games, the game name that I have been testing this in is Fresh API environment.
1477567023
Laurent
Pro
Sheet Author
API Scripter
Riley D. said: Laurent M. said: I have an issue with repeating fields : var crit = getAttrByName(attackingCharacter, "repeating_armes_$0_armecrit"); raises the following error message: "Error: No attribute or sheet field found for character_id -KUECiT_f0zF8xYzaMPO named repeating_armes_-kuecsrijjdkhgtx3pgw_armecrit" (no error with non repeating fields, such as replacing the line with var crit = getAttrByName(attackingCharacter, "DV");) I think this should be fixed on Dev. getSheetDefaultValue() should now return the correct value for repeating section rows. That's what getAttrByName() uses if it can't find the existing value so it should fix your issue as well. Let me know if that worked. I just tried out, and I get the same error message. In addition, just after the error message, I get SyntaxError: Expected "(", ".", "[", "abs(", "ceil(", "d", "floor(", "round(", "t", "{", [ |\t], [+|\-] or [0-9] but "u" found.undefined Don't know if that's related, or if my script just doesn't work on Dev...
1477574501
The Aaron
Pro
API Scripter
Laurent M. said: SyntaxError: Expected "(", ".", "[", "abs(", "ceil(", "d", "floor(", "round(", "t", "{", [ |\t], [+|\-] or [0-9] but "u" found.undefined Don't know if that's related, or if my script just doesn't work on Dev... That SyntaxError error is likely just a result of a bad value going to a roll somewhere.  Possibly even the word "undefined" since the character it found was "u".
1477577171

Edited 1477577381
Riley D.
Roll20 Team
Laurent M. said: Riley D. said: Laurent M. said: I have an issue with repeating fields : var crit = getAttrByName(attackingCharacter, "repeating_armes_$0_armecrit"); raises the following error message: "Error: No attribute or sheet field found for character_id -KUECiT_f0zF8xYzaMPO named repeating_armes_-kuecsrijjdkhgtx3pgw_armecrit" (no error with non repeating fields, such as replacing the line with&nbsp;var crit = getAttrByName(attackingCharacter, "DV");) I think this should be fixed on Dev. getSheetDefaultValue() should now return the correct value for repeating section rows. That's what getAttrByName() uses if it can't find the existing value so it should fix your issue as well. Let me know if that worked. I just tried out, and I get the same error message. In addition, just after the error message, I get SyntaxError: Expected "(", ".", "[", "abs(", "ceil(", "d", "floor(", "round(", "t", "{", [ |\t], [+|\-] or [0-9] but "u" found.undefined Don't know if that's related, or if my script just doesn't work on Dev... Do you have a test case to reproduce it?&nbsp; Here's what I'm currently doing to test it: 1) Create a new blank game using the 5E OGL character sheet. 2) Create at least one character in the new game. 3) Use the following API script:&nbsp; <a href="https://gist.github.com/rileydutton/846db7771e1ca6" rel="nofollow">https://gist.github.com/rileydutton/846db7771e1ca6</a>... My output log is: Spinning up new sandbox... "Found webworker script" "Abjuration" "ERROR: You tried to use the repeating section row at index 0 for repeating_spell-cantrip, but there doesn't seem to be a row at that index." "Abjuration" Note that I didn't actually add a row to the spell-cantrip repeating section which is why that error is showing up but it still returns a default value anyway. That test case definitely wasn't working before so it was an issue but it is working now so that's why I think it's fixed. If you can give me a test case where it's not working then I'll take a look. Thanks!
Also, I believe that getSheetDefaultValue (and getAttrByName) will return undefined when it doesn't find a matching value to use so that's probably what's throwing the roll error as Aaron pointed out.
1477658029
Laurent
Pro
Sheet Author
API Scripter
Just copied again my game and it's script on Dev, but nothing seems to work today on Dev. Even standard scripts don't display anything in the console... I'll try again in a few days.