Button rolls on repeating sections

Searching is generally useless, so hear I go: What's the current best way to get and use the "pseudo-attributes" (calling them "pseudo-attributes" because they don't surface beyond the character sheet) of repeating section in a roll button on each row, when calling an API script (or not). Example: <fieldset class="repeating_ranged-weapons"> <div class="sheet-row"> <div class="sheet-item sheet-small sheet-black"> <input type="text" name="attr_ranged-name"/> </div> <!-- more fields --> <div class="sheet-item sheet-nano sheet-black"> <button type='roll' name='roll_ranged-attack' value='!ammo @{character_id} @{repeating_ranged-weapons_???} -1 /em fires a @{ranged-name}! /roll 1d100<[[@{ballisticskill}+@{ranged-difficulty}+@{ranged-attack-type}+@{ranged-aim}]]'></button> </div> </div> <!-- /Ranged Weapon Items --> </fieldset> I cannot "know" the index in the repeating section, or can I? I've seen in other character sheets examples in any of the following formats: @{repeating_ranged-weapons_[number]_ranged-ammo} @{repeating_ranged-weapons_#_ranged-ammo} Examples in other character sheets with attempts do not tie back to Roll20 documentation, but mostly had to go to search (in vain) for where ideas germinated, then chased rabbits down holes, where it seems that most attempts are hacks to surface the pseudo-attribute in a field, but nothing on the why or how in comments (or easily hunted in these forums). What am I doing wrong? Examples and documentation would be helpful.

Those examples are correct. The first repeating item is 0 and each on increments (so the second one is 1, the third one is 2, etc). I hope that helps.

@G V., the indexing of the repeating_ items is not at issue. It's the actual referencing of them as noted. As near as I can tell, "#" doesn't actually expand to anything. And the same may be for [number]. Need more context? I'm starting to think it's the Dev Server or the API Script I'm using or something else hidden in the undocumented arcane of Roll20. I've looked at your work G V. so I know it's solid.

Timothy - sorry, I didn't look at your code close enough... :( **DISCLAIMER** I've never used the API from within a character sheet, so I'm just throwing stuff out there that may or may not work, and that you may or may not have already tried... **END DISCLAIMER** In your example, because the button is inside the fieldset I don't believe you need the index. For example: <fieldset class="repeating_meleeweapons"> <snipped code> <input class="sheet-standard" type="text" name="attr_WeaponType" title="@{repeating_meleeweapons_#_WeaponType}" style='width:115px;'/> <snipped code> <select name="attr_DmgType" title="@{repeating_meleeweapons_#_DmgType}" class="dtype"> <snipped options> </select>+<input class="sheet-modifier" type="number" name="attr_MDmgMod" title="@{repeating_meleeweapons_#_MDmgMod}" value="0" /> <snipped code> <input type="checkbox" name="attr_DmgRaise" title="@{repeating_meleeweapons_#_DmgRaise}" value="6!" /> <snipped code> <button type='roll' name='roll_WeaponTypeRoll' title="@{repeating_meleeweapons_#_WeaponTypeRoll}" value='/em @{character_name} attempts to do damage with a @{WeaponType} and rolls: [[1d@{Strength}![Strength]+1d @{DmgType} + @{MDmgMod} [Weapon Damage]+@{dmgmod}[Damage Modifier]+1d @{DmgRaise} [Bonus Damage]]]!'></button> </fieldset> So, if calling the field from within the fieldset, you shouldn't need to know it (at least that's true for a standard, non-API calling button). So I'm not sure why it would be different. You'll notice the titles, are different, because that's what you would need to do if you were to call the field from some other place. The field that you have bolded, what field is that supposed to be? I'm asking, because I've never really looked at the ammo tracker API script (and that looks like what you're trying to use?). But, just like you don't worry about the the repeating_* for the other fields in the button, is this different somehow? Are you using the Ammo Tracker from The Aaron or from King? It looks like it may be Aaron's script? Have you tried just calling the field normally (i.e. @{ranged-ammo} ), like you do for the other fields? I apologize if that seems condescending, but too many times I've overlooked the obvious (no insult intended).

You cant call the macros that are within repeating sections directly at this time (to the best of my knowledge). You can access attributes. So, if X is the row number of the repeating section (starting from 0) you can access the attributes as normal like this - @{repeating_sectionname_X_attributename} But you CANNOT access a roll within that same section // THIS DOES NOT WORK %{repeating_sectionname_X_macroname}

What I have found is that @G V. is correct. Buttons on a repeating attribute will reference the executing context of that "row." No problem there. Thanks for that excellent reply by the way. @Actoba, your follow up is also a known state in my development. However , i'm starting to realize that as a senior technical lead for a large enterprise financial institution, that I was making assumptions about what is being read, especially in regards to variables as string literals or iterator indexes. No one should have used '#' or 'X' or '[number]' (though the last is closer to what should possibly be used). It would have been better to use '[i]' to describe the internal array index of the repeating section. It's important to note that the subscript or index is never exposed and is not replaced in any use of an attribute reference (especially, where 'X' or '#' appear in discussions!). It's especially harmful for me, someone with experience and a context of development, to see the use of a subscript like syntax, e.g., '[number]', and make the leap of: "Of course, the index is exposed as 'number' and I can get a subscript reference to it in my character sheet repeating rows." This is simply incorrect and a mistake I own. All said, I'm hearing in private messages that an upcoming release will make repeating attributes full fledged citizens, making their use much easier and far more predictable.

...now I am jealous that the voices talk to you and now me. At least, those voices.

@Timothy S - I'm confused. What is the end goal that you are trying to get to here? People refer to the index as X (or #) because by far the most common question posted here is how to reference variables in a repeating section when they are building their own macros and so on. The assumption (and quite correctly I believe) is that the majority of the audience probably are not developers hence the lack of discussions or references to internal mechanisms which we dont really have any insight into anyway. As far as I know the best ways to reference attributes in repeating sections are as follows - Using the API - filterObjs function - <a href="https://wiki.roll20.net/API:Objects#Finding.2FFilt" rel="nofollow">https://wiki.roll20.net/API:Objects#Finding.2FFilt</a>... Within a row of a repeating section itself - &lt;fieldset class="repeating_example"&gt; &lt;input type="text" name="attr_myattribute"/&gt; &lt;button type='roll' name='roll_ExampleRoll' value='This is a test and the value of myattribute in this row (regardless of the index) is - @{myattribute}'&gt;&lt;/button&gt; &lt;/fieldset&gt; Note that there is no need to use an index as the initial scope of the attribute when used like above is the repeating row that generates the request Elsewhere in a macro or character sheet roll - &lt;button type='roll' name='roll_OutsideRepeatingSectionMacro' value='Outside of the repeating section we need to directly reference the specific instance of myattribute we want to get. So if it is the very first row in the example above we would use @{repeating_example_0_myattribute}'&gt;&lt;/button&gt; Note that without API scripting theres no way to derive or otherwise work out which row/index you need. Hope this helps

Well, I finally got working something I'll consider my first Roll20 Character Sheet hack—SRISH, Stone Repeating Index Surfacing Hack—that allows anyone to surface a reference to the index of a repeating row without textareas or other player editing of macros: overload the parsing engine of roll queries (see image). The user is presented with the query dialog, the index (zero-based of course) is provided, and BAM. The above linked image on my WFRP wiki—screencap'd from the Dev server— one will note that the Ammo (Ammo.js v.22 by The Aaron) is decremented as expected, though the system whispers twice (two times). On the P roduction server the action works as well, but the Ammo is not decremented "live." The value is updated, but only closing and opening the sheet will update value of ammo. Here's a sample: &lt;div class="sheet-item sheet-nano sheet-black"&gt; &lt;button type="roll" name="roll_RangedAttack" value=" !ammo @{selected|token_id} repeating_rangedweapons_?{Weapon Index}_RangedAmmo -1 /em fires a @{RangedName}! /roll 1d100&lt;[[@{BallisticSkill}+ (@{RangedAttackRange} + @{RangedHand} + @{RangedDifficulty} + @{RangedAttackType} + @{RangedAim})]]"&gt;&lt;/button&gt; &lt;/div&gt; Opportunity for the Bag of Holding release? Maybe. I would really like to see the indexing of repeating_ sections surface references to the API on Buttons without any Player intervention.

Is accessing rolls in repeating sections possible with the Bag of Holding release? Been looking for info on this, but this was the most I've found.

No change to repeating sections in the UoH as far as i'm aware