[HELP] different results getAttrByName & chat window recall of repeating row

I'm getting an odd difference occurring when accessing a repeating row table on a character sheet from an API script using getAttrByName, and via ability macros or the chat window, which is causing multiple issues.  I'm fairly new to API creation, so I may be doing something obviously wrong... If I use the following code: for (let i = 0; i < 24; i++) { qty = getAttrByName( targetID, 'repeating_potions_$' + i + '_potionqty' ); mi = getAttrByName( targetID, 'repeating_potions_$' + i + '_potion' ); log('ID: '+targetID+' repeating_potions_$'+i+'_potion: '+qty+' '+mi); }; I get the following results: "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$0_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$1_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$2_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$3_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$4_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$5_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$6_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$7_potion: 0 -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$8_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$9_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$10_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$11_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$12_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$13_potion: 0 -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$14_potion: 0 -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$15_potion: 0 Cube-of-Force" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$16_potion: 0 -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$17_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$18_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$19_potion: 1 Magical-Sword" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$20_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$21_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$22_potion:  -" "ID: -MGOSZ7Pnz1Fn3t1W9Ja repeating_potions_$23_potion:  -" However, if I run the following in an Ability macro: &{template:2Edefault}{{name=test}}{{desc= repeating_potions_$0_potion: @{selected|repeating_potions_$0_potion} repeating_potions_$1_potion: @{selected|repeating_potions_$1_potion} repeating_potions_$2_potion: @{selected|repeating_potions_$2_potion} repeating_potions_$3_potion: @{selected|repeating_potions_$3_potion} repeating_potions_$4_potion: @{selected|repeating_potions_$4_potion} repeating_potions_$5_potion: @{selected|repeating_potions_$5_potion} repeating_potions_$6_potion: @{selected|repeating_potions_$6_potion} repeating_potions_$7_potion: @{selected|repeating_potions_$7_potion} repeating_potions_$8_potion: @{selected|repeating_potions_$8_potion} repeating_potions_$9_potion: @{selected|repeating_potions_$9_potion} repeating_potions_$10_potion: @{selected|repeating_potions_$10_potion} repeating_potions_$11_potion: @{selected|repeating_potions_$11_potion} repeating_potions_$12_potion: @{selected|repeating_potions_$12_potion} repeating_potions_$13_potion: @{selected|repeating_potions_$13_potion} repeating_potions_$14_potion: @{selected|repeating_potions_$14_potion} repeating_potions_$15_potion: @{selected|repeating_potions_$15_potion} repeating_potions_$16_potion: @{selected|repeating_potions_$16_potion} repeating_potions_$17_potion: @{selected|repeating_potions_$17_potion} repeating_potions_$18_potion: @{selected|repeating_potions_$18_potion} repeating_potions_$19_potion: @{selected|repeating_potions_$19_potion} repeating_potions_$20_potion: @{selected|repeating_potions_$20_potion} repeating_potions_$21_potion: @{selected|repeating_potions_$21_potion} repeating_potions_$22_potion: @{selected|repeating_potions_$22_potion} repeating_potions_$23_potion: @{selected|repeating_potions_$23_potion}}} I get the following result in the chat window: test repeating_potions_$0_potion: - repeating_potions_$1_potion: - repeating_potions_$2_potion: Cube-of-Force repeating_potions_$3_potion: - repeating_potions_$4_potion: - repeating_potions_$5_potion: - repeating_potions_$6_potion: Magical-Sword repeating_potions_$7_potion: - repeating_potions_$8_potion: - repeating_potions_$9_potion: - repeating_potions_$10_potion: - repeating_potions_$11_potion: - repeating_potions_$12_potion: - repeating_potions_$13_potion: - repeating_potions_$14_potion: - repeating_potions_$15_potion: - repeating_potions_$16_potion: - repeating_potions_$17_potion: - repeating_potions_$18_potion: - repeating_potions_$19_potion: - repeating_potions_$20_potion: - repeating_potions_$21_potion: - repeating_potions_$22_potion: - repeating_potions_$23_potion: - Why is e.g the Cube of Force at row $15 when recalled from the repeating_potions_$ repeating section via the getAttrByName, and at row $2 when recalled in a macro via @{selected|repeating_potions_$2_potion} from the same character sheet?  I've checked the id and they are definitely the same... Help!

Hmm. That looks like a bug with getAttrByName, but it could just be undefined behavior. I don't remember getAttrByName ever working with indexed rowids, but I rarely use it except for autocalc fields. If you look at my Ammo script, it has a function for resolving row order, which is a pretty obnoxious task. 

The Aaron said: Hmm. That looks like a bug with getAttrByName, but it could just be undefined behavior. I don't remember getAttrByName ever working with indexed rowids, but I rarely use it except for autocalc fields. If you look at my Ammo script, it has a function for resolving row order, which is a pretty obnoxious task.  Thanks for that!  Your attrLookup() worked a treat!  So that's the end of getAttrByName() for me... do you think I should report what I found as a bug?

That's a good question.  I'll look back through the release information and see if it's supposed to be supported, then I can ping the devs about it directly with a reproduction script.

Ok, I've reproduced the issue, created a reproduction script and instructions, and passed it on to the devs.

The Aaron said: Ok, I've reproduced the issue, created a reproduction script and instructions, and passed it on to the devs. Now I'm getting the same problem even using your attrLookup() from the ammo script!  When I've got the time, I'll create the same type of demo as I did for getAttrByName.  The issue is occurring on the repeating_weaponProfs_$n table on the 2E sheet.  @{selected|repeating_weaponprofs_$6_specialist} returns 1 (correct), but attrLookup( charCS, 'repeating_weaponprofs_$6_specialist', false ) returns 'undefined'.  It seems that any index above $6 also returns 'undefined' from attrLookup(), but is fine using @{selected|...}.  This table has been created only by using the [Add++] button on the 2E character sheet.  !setAttr has not been used at all.

Hmm. They announce a change to Repeating rows in the roundtable last week. I wonder if it broke the _reporder_ field. See:&nbsp; <a href="https://www.twitch.tv/videos/824846067?t=1h3m30s" rel="nofollow">https://www.twitch.tv/videos/824846067?t=1h3m30s</a>

Hmm.&nbsp; I just tested this and I'm getting identical results to what I got last week.&nbsp; attrLookup() is working for me, but getAttrByName is out of order.

OK.&nbsp; I'll investigate some more and produce a script to reproduce the issue - watch this space.&nbsp; It might be specific to non-standard repeating tables - e.g. on the 2E sheet where the first row is a field, and subsequent ones are repeating_table_$n_field.&nbsp; Those tables do seem to be having the majority of issues. I've found a workaround for now, but it is a poor fix and makes things inflexible, so I'd like to find a solution.

OK, I've done some more investigation &amp; recreated the issue with attrLookup() &amp; getAttrbyName().&nbsp; I'm using the "repeating_weaponprofs_$" table from the ADnD 2E character sheet (because that's the area I'm trying to build an API around at the moment).&nbsp; Here are the worked issues. The following macro: /w gm weapprofname: @{selected|weapprofname}.&nbsp; specialist: @{selected|specialist} /w gm repeating_weaponprofs_$0_weapprofname: @{selected|repeating_weaponprofs_$0_weapprofname}. repeating_weponprofs_$0_specialist: @{selected|repeating_weaponprofs_$0_specialist} /w gm repeating_weaponprofs_$1_weapprofname: @{selected|repeating_weaponprofs_$1_weapprofname}. repeating_weponprofs_$1_specialist: @{selected|repeating_weaponprofs_$1_specialist} /w gm repeating_weaponprofs_$2_weapprofname: @{selected|repeating_weaponprofs_$2_weapprofname}. repeating_weponprofs_$2_specialist: @{selected|repeating_weaponprofs_$2_specialist} /w gm repeating_weaponprofs_$3_weapprofname: @{selected|repeating_weaponprofs_$3_weapprofname}. repeating_weponprofs_$3_specialist: @{selected|repeating_weaponprofs_$3_specialist} /w gm repeating_weaponprofs_$4_weapprofname: @{selected|repeating_weaponprofs_$4_weapprofname}. repeating_weponprofs_$4_specialist: @{selected|repeating_weaponprofs_$4_specialist} /w gm repeating_weaponprofs_$5_weapprofname: @{selected|repeating_weaponprofs_$5_weapprofname}. repeating_weponprofs_$5_specialist: @{selected|repeating_weaponprofs_$5_specialist} /w gm repeating_weaponprofs_$6_weapprofname: @{selected|repeating_weaponprofs_$6_weapprofname}. repeating_weponprofs_$6_specialist: @{selected|repeating_weaponprofs_$6_specialist} /w gm repeating_weaponprofs_$7_weapprofname: @{selected|repeating_weaponprofs_$7_weapprofname}. repeating_weponprofs_$7_specialist: @{selected|repeating_weaponprofs_$7_specialist} /w gm repeating_weaponprofs_$8_weapprofname: @{selected|repeating_weaponprofs_$8_weapprofname}. repeating_weponprofs_$8_specialist: @{selected|repeating_weaponprofs_$8_specialist} /w gm repeating_weaponprofs_$9_weapprofname: @{selected|repeating_weaponprofs_$9_weapprofname}. repeating_weponprofs_$9_specialist: @{selected|repeating_weaponprofs_$9_specialist} /w gm repeating_weaponprofs_$10_weapprofname: @{selected|repeating_weaponprofs_$10_weapprofname}. repeating_weponprofs_$10_specialist: @{selected|repeating_weaponprofs_$10_specialist} Creates the following output: (To GM): &nbsp;weapprofname: Scimitar. specialist: 0 (To GM): &nbsp;repeating_weaponprofs_$0_weapprofname: Horse Bow. repeating_weponprofs_$0_specialist: 1 (To GM): &nbsp;repeating_weaponprofs_$1_weapprofname: Scimitar. repeating_weponprofs_$1_specialist: 0 (To GM): &nbsp;repeating_weaponprofs_$2_weapprofname: Horse Bow. repeating_weponprofs_$2_specialist: 1 (To GM): &nbsp;repeating_weaponprofs_$3_weapprofname: Broadsword. repeating_weponprofs_$3_specialist: 0 (To GM): &nbsp;repeating_weaponprofs_$4_weapprofname: Horse Bow. repeating_weponprofs_$4_specialist: 1 (To GM): &nbsp;repeating_weaponprofs_$5_weapprofname: Broadsword. repeating_weponprofs_$5_specialist: 0 (To GM): &nbsp;repeating_weaponprofs_$6_weapprofname: Horse Bow. repeating_weponprofs_$6_specialist: 1 (To GM): &nbsp;repeating_weaponprofs_$7_weapprofname: Bastardsword. repeating_weponprofs_$7_specialist: 0 (To GM): &nbsp;repeating_weaponprofs_$8_weapprofname: Horse Bow. repeating_weponprofs_$8_specialist: 1 (To GM): &nbsp;repeating_weaponprofs_$9_weapprofname: Bastardsword. repeating_weponprofs_$9_specialist: 0 (To GM): &nbsp;repeating_weaponprofs_$10_weapprofname: Horse Bow. repeating_weponprofs_$10_specialist: 1 which is what I am expecting.&nbsp; However, the following API code: for (let i=-1; i&lt;(sheetTypes.sheetType*2); i++) { if (i==-1) { repProfs_special = 'specialist'; repProfs_name = 'weapprofname'; } else { repProfs_special = 'repeating_weaponprofs_$' + i + '_specialist'; repProfs_name = 'repeating_weaponprofs_$' + i + '_weapprofname'; } if (_.isUndefined(nameObj = attrLookup( charCS, repProfs_name, false ))) { &nbsp; &nbsp; name1 = undefined; } else { &nbsp; &nbsp; name1 = nameObj.get('current'); }; name2 = getAttrByName( charCS.id, repProfs_name ); if (_.isUndefined(specialObj = attrLookup( charCS, repProfs_special, false ))) { &nbsp; &nbsp; special1 = undefined; } else { &nbsp; &nbsp; special1 = specialObj.get('current'); }; special2 = getAttrByName( charCS.id, repProfs_special ); log( repProfs_name + ' from attrLookup: ' + name1 + ', from getAttrByName: ' + name2 + '.&nbsp; ' + repProfs_special + ' from attrLookup: ' + special1 + ', from getAttrByNme: ' + special2 ); } produces the following log entries on the console "weapprofname from attrLookup: Scimitar, from getAttrByName: Scimitar.&nbsp; specialist from attrLookup: undefined, from getAttrByNme: 0" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$0_weapprofname from attrLookup: Horse Bow, from getAttrByName: Horse Bow.&nbsp; repeating_weaponprofs_$0_specialist from attrLookup: 1, from getAttrByNme: 1" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$1_weapprofname from attrLookup: Scimitar, from getAttrByName: Scimitar.&nbsp; repeating_weaponprofs_$1_specialist from attrLookup: 1, from getAttrByNme: 0" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$2_weapprofname from attrLookup: Horse Bow, from getAttrByName: Horse Bow.&nbsp; repeating_weaponprofs_$2_specialist from attrLookup: 1, from getAttrByNme: 1" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$3_weapprofname from attrLookup: Broadsword, from getAttrByName: Horse Bow.&nbsp; repeating_weaponprofs_$3_specialist from attrLookup: 1, from getAttrByNme: 1" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$4_weapprofname from attrLookup: Horse Bow, from getAttrByName: Broadsword.&nbsp; repeating_weaponprofs_$4_specialist from attrLookup: 1, from getAttrByNme: 0" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$5_weapprofname from attrLookup: Broadsword, from getAttrByName: Broadsword.&nbsp; repeating_weaponprofs_$5_specialist from attrLookup: 1, from getAttrByNme: 0" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$6_weapprofname from attrLookup: Horse Bow, from getAttrByName: Bastardsword.&nbsp; repeating_weaponprofs_$6_specialist from attrLookup: undefined, from getAttrByNme: 0" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$7_weapprofname from attrLookup: Bastardsword, from getAttrByName: Horse Bow.&nbsp; repeating_weaponprofs_$7_specialist from attrLookup: undefined, from getAttrByNme: 1" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$8_weapprofname from attrLookup: Horse Bow, from getAttrByName: Bastardsword.&nbsp; repeating_weaponprofs_$8_specialist from attrLookup: undefined, from getAttrByNme: 0" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$9_weapprofname from attrLookup: Bastardsword, from getAttrByName: Horse Bow.&nbsp; repeating_weaponprofs_$9_specialist from attrLookup: undefined, from getAttrByNme: 1" "Foudn a pre-defined key order!" "Foudn a pre-defined key order!" "repeating_weaponprofs_$10_weapprofname from attrLookup: Horse Bow, from getAttrByName: -.&nbsp; repeating_weaponprofs_$10_specialist from attrLookup: undefined, from getAttrByNme: 0" (The "Foudn a pre-defined key order!" is coming from getAttrByName() calls) So, attrLookup() is finding the wrong value for "specialist" repeating field (either "undefined" or 1), although it is finding the right value for "weapprofname".&nbsp; As usual, getAttrByName() is getting mixed up.&nbsp; I'd appreciate any possible alternative solutions?

Is specialist an Autocalc Field?

Not as far as I am aware.&nbsp; It is a flag field (a tick box) so can only return 0 or 1.

I've found more issues on the repeating_potions_$ table.&nbsp; Using AttrLookup(), it returns a 'potion' field (the name of the potion) from one row, and the 'potionqty' (how many charges) from another different row for the same index!&nbsp; Using @{selected|repeating_potions_$n_potion} and @{selected|repeating_potions_$n_potionqty} from a macro is fine, however.&nbsp; The problem is inconsistent - some character sheets it is fine, and others not.&nbsp; I've not yet figured out what is different, and I'm a novice programmer in Java, HTML &amp; CSS at the best of times (more used to Z80 and 6502 assembler - I used to write games back in the 1980's: every heard of the Sinclair Spectrum and Commodore64 game "Valhalla"?). I'm going to have to give up converting my extensive macro library to Javascript APIs because I use access to repeating rows on the 2E character sheet a lot (weapons, weapon proficiency, spells, magic items, powers, equipment) and there is no reliable way to query them in an API script.&nbsp; Ordinary attributes are fine, but repeating rows are a nightmare.&nbsp; This is a pain, as the macros are getting large, complicated, and slow.&nbsp; I don't know if the problem is Roll20, the Javascript, or the 2E character sheet, but I'm getting bugs I can't fix, and I want my players to enjoy the game, not get odd results all over the place...

Hmm.&nbsp; That's really weird.&nbsp; I'm going to have to try and duplicate this problem. That's neat about the video game!&nbsp; I also did a stent in the game industry , though most of what I worked on never got released.&nbsp; I did work on the path planning in the engine that powers Starwars Knights of the Old Republic online and The Elder Scrolls Online. =D

OK, I've played around a bit and found that the issue is related to the initialisation of attributes in the repeating tables.&nbsp; e.g. for the 'specialist' flag in the repeating_weaponprofs table, if the _$3_specialist has been ticked (so set to 1), but _$0_specialist, _$1_specialist, &amp; _$2_specialist have never been ticked, using attrLookup() to read repeating_weaponprofs_$3_specialist will go wrong (return 'undefined' or perhaps the value from a different row).&nbsp; If I then tick and then untick the $0, $1, $2 specialist flags the $3 flag is returned correctly.&nbsp; I assume the $0, $1 &amp; $2 specialist attributes are not created until they are used.&nbsp; This means there are lots of tables where this issue might occur. the _reporder_ might also be an issue.&nbsp; For the repeating_potions table issue I believe I had reordered one or two of the rows, which means _reporder_ would have been used.&nbsp; So I completely deleted the table, and recreated it using the [+Add] button on the sheet to add rows, ensuring I put a value in each attribute in each row of the table and didn't reorder the table rows.&nbsp; attrLookup() then worked fine.

I've confirmed that attrLookup() is not picking up default values for table fields in repeating rows, at least in the AD&amp;D 2E sheet.&nbsp; This happens on the flag fields in the Weapon Proficiency table (e.g. specialist &nbsp;and ' mastery' ), and also on the critical hit threshold field in the weapons table (' crit-threshold' ) - also perhaps elsewhere, but I've not checked yet.&nbsp; If the player overtypes the default value with an actual value (e.g. typing '20' over the default value of '20' in the crit-threshold &nbsp;field of any weapon row), the value is then picked up, but only with an index equalling the number of overtyped fields in rows above it.&nbsp; So if rows 2, 4, and 6 have their crit_threshold &nbsp;fields overtyped, attrLookup() on rows $0, $1, &amp; $2 would return valid objects with current values of 20 and all other indexes return undefined .&nbsp; But the rest of the values in the rows are returned in indexes $0, $2, &amp; $4 as they should be, causing all sorts of issues. Any chance of a fix?&nbsp; In the mean time, I'm going through all my PC, NPC and Monster sheets overtyping default values in critical fields...