[Help] Reference repeating section id or index from roll output

Hi, I'm looking at ways to handle integrating API behaviours with repeating sections on character sheets. In particular, I'd like an API script to be able to pick up and respond to the output of a Roll button within a repeating section. For it to be useful, however, the API script needs a reliable way of knowing which repeating row generated the output. Is there a way for a roll expression to reference the ID (or current index, that would also work) of the repeating section directly, or do I have to write a sheet worker to dump this value into a hidden field in order to get it output? Cheers, Lucian

Just looking at the msg for a roll, it doesn't seem like there is anything that references the row id of the button pressed... however maybe some logical leaps could be made.  For example on the shaped sheet the character_name is always passed, as well as the title, as well as the roll template type.  So maybe you could use this information to find an attribute (like the name) and pull the rowID out of that name.  It's probably not terribly efficient to do this, but it might work... 

Kevin said: Just looking at the msg for a roll, it doesn't seem like there is anything that references the row id of the button pressed... however maybe some logical leaps could be made.  For example on the shaped sheet the character_name is always passed, as well as the title, as well as the roll template type.  So maybe you could use this information to find an attribute (like the name) and pull the rowID out of that name.  It's probably not terribly efficient to do this, but it might work...  Hey, I don't think that will be good enough. There are no unique attributes on e.g. attacks or spells - there's nothing stopping you having two attacks called "Longbow" or two "Fireball" spells. In that case, there's nothing in the roll output that will allow me to uniquely identify the correct row. Granted it would be odd/unhelpful to have two attacks called the same thing, but if a job's worth doing.... The correct fix for this is to include a hidden field in the output that contains a unique ID. This will involve changing the shaped sheet itself, and I'm currently putting together a pull request to this effect. My question is whether there is a syntax like @{row_id} that will output this for me, or whether I have to go round the houses with a hidden field that I then populate from a sheet worker triggered when a new repeating row is added (sheet workers can definitely access the row ids). Cheers, Lucian

I don't know sheet workers well, but I don't see a problem adding @{row_id} as an additional attribute other than the performance impact of adding a significant number of fields on a large sheet... or in a campaign with a large number of character journals (of course if they also have these attributes). The problem though is you will need to pass this as part of the roll, but not have it displayed as part of the roll template (which may not be much of a problem, but I don't know html/css really at all).

Kevin said: I don't know sheet workers well, but I don't see a problem adding @{row_id} as an additional attribute other than the performance impact of adding a significant number of fields on a large sheet... or in a campaign with a large number of character journals (of course if they also have these attributes). Sure, I already have this working with a sheet worker that populates a hidden attack_id field for attacks. But, as you say, it's an extra field, potentially on most repeating rows on every character sheet, along with a corresponding sheet worker, just to duplicate a value that is already in the Roll20 data model for repeating fields. What I was (very unclearly) asking for, is whether there's a *built-in* syntax for accessing this row id directly from a roll query *without* having to make a custom field for it. I suspect the answer is no, but if it does exist it would be much better than what I'm doing now. The problem though is you will need to pass this as part of the roll, but not have it displayed as part of the roll template (which may not be much of a problem, but I don't know html/css really at all). The part is easy - I already have that working in my modified copy. You just wrap it up in a roll template field and then don't output it in the roll template (and instruct the generic field output thingy at the bottom to ignore it).

It now all makes sense.. You're L H. We'll wait and see what Aaron says.

Kryx said: It now all makes sense.. You're L H. We'll wait and see what Aaron says. Lol, I've only just realised how cryptic my github profile is. Sorry about that! :-)

<a href="http://www.shamasis.net/2009/09/fast-algorithm-to-find-unique-items-in-javascript-array/" rel="nofollow">http://www.shamasis.net/2009/09/fast-algorithm-to-find-unique-items-in-javascript-array/</a> gives a method for finding unique items in an array. I'm sure we could find one for finding unique objects in an array.

Kryx said: <a href="http://www.shamasis.net/2009/09/fast-algorithm-to-find-unique-items-in-javascript-array/" rel="nofollow">http://www.shamasis.net/2009/09/fast-algorithm-to-find-unique-items-in-javascript-array/</a> gives a method for finding unique items in an array. I'm sure we could find one for finding unique objects in an array. I'm not really worried about the speed of searching - it's not that big a list in the first place. The trouble is that I'm not sure there's a reliable unique key for the items in the attacks array without having the ID. You could use the name, but there's no guarantee that people won't have two weapons with the same name. E.g. two daggers, one ranged and one melee. Sure, it would be better if people *don't* do that, but I don't think it would be great for the script to make assumptions about that.

I wasn't suggesting using the name. I was suggesting comparing the whole object, but I guess we don't have the whole object to begin with. Though for specific cases (each sheet) we could piece together a fairly good piece of the pie.

Kryx said: I wasn't suggesting using the name. I was suggesting comparing the whole object, but I guess we don't have the whole object to begin with. Though for specific cases (each sheet) we could piece together a fairly good piece of the pie. Ah ok. As a back-end developer by training, I guess it seems *really* hacky to me to be kludging together a surrogate composite key out of a random selection of properties that happen to be supplied for display purposes, when there's a perfectly good primary key that could be used instead. It's just frustrating that we can't get access to that primary key without dancing round the houses with extra attributes. There really needs to be a magic @{row_id} attribute that is available from within repeating sections for this purpose, it would make things a lot simpler :-(

It would be great if we could just get a pseudo attribute with the row id in it. &nbsp;Short of that, I've got two thoughts: Add a hidden field to hold the row_id and populate it when the row is initially created (which might mean you keep having to check if it's set). &nbsp;Note, the names of fields must be unique across all repeating groups, so the name couldn't simply be row_id, it would need to be something like weapon_row_id, or inventory_row_id, etc. In the API, inject the id into the commands themselves. &nbsp;My (years old) UsePower script does this. &nbsp;On change of ability, it checks to see if there is a !use-power command in it and updates or adds the&nbsp;ability's&nbsp;id. &nbsp;You'd need to validate this on API restart (can't be sure things weren't added when the API was stopped) and on attribute changes.

Ah ^%&*?£$ it. I just discovered that it's&nbsp; even uglier than I'd thought. I'm beginning to think I might give up on this particular line of thinking until Roll20 iron out a few more of the wrinkles here. Edit: I've realised I can work round it with {caseInsensitive:true}, so it's still possible to do it the way I was intending. Still want a pseudo-attribute though!

The Aaron said: It would be great if we could just get a pseudo attribute with the row id in it. &nbsp;Short of that, I've got two thoughts: Add a hidden field to hold the row_id and populate it when the row is initially created (which might mean you keep having to check if it's set). &nbsp;Note, the names of fields must be unique across all repeating groups, so the name couldn't simply be row_id, it would need to be something like weapon_row_id, or inventory_row_id, etc. In the API, inject the id into the commands themselves. &nbsp;My (years old) UsePower script does this. &nbsp;On change of ability, it checks to see if there is a !use-power command in it and updates or adds the&nbsp;ability's&nbsp;id. &nbsp;You'd need to validate this on API restart (can't be sure things weren't added when the API was stopped) and on attribute changes. My discovery of the brokenness of getSectionIDs notwithstanding, I thought I'd post something I said to Kryx elsewhere on my thoughts of the relative merits of the two approaches: I do think it's worth considering the wider question of how you can design the sheet for API extensibility. When we build dynamic HTML pages, we start with a good base of semantic markup with little or no direct reference to the JS embedded within it, and then apply the JS afterwards to add extended behaviours for user agents that support it. That keeps the markup and the JS loosely coupled. In the same way, it strikes me as more elegant to have character sheets that output the core information as "semantic markup" in the form of roll template fields (with the roll template itself acting as the CSS, effectively), and then have scripts (if present) selectively process the information that is output to provide extended behaviours. The alternative is to fill up the semantic space of the character attributes with api calls shoe-horned into freeform text fields, which seems much "hackier" to me than including a hidden row id in the output. When you start to think of the roll output as not just a display format, but also a messaging interface to any API scripts that might want to act on the information, I think the inclusion of what is essentially a primary key onto a relevant data table, seems a lot more reasonable. Obviously I have less visibility than probably either you or he do of possible future developments at Roll20, so maybe this is moot, but it does seem to me to be a discussion worth having. Character sheets are a basic feature of Roll20, available to all, so they obviously can't depend on API features. On the other hand, I think that it would be unfortunate if those who want to use the power of the API end up having to basically throw away much of the value of the character sheets and start again - as tends to happen with things like PowerCards, for example (great though that script is). Coming up with some best practice on how to make character sheets extensible by the API would seem like a good idea for everyone. I have no doubt that better minds than mine have chewed all this over before, but I'm not aware of whatever conclusions they may have come to, and would certainly be interested in hearing if there are already some good ideas bubbling away somewhere... Edit: Also:&nbsp;<a href="https://app.roll20.net/forum/post/3051585/provide-a-pseudo-attribute-at-%7Brow-id%7D-for-repeating-sections/" rel="nofollow">https://app.roll20.net/forum/post/3051585/provide-a-pseudo-attribute-at-%7Brow-id%7D-for-repeating-sections/</a>

I just want to say that I gave an official +1 to your feature request. We really need something like that.&nbsp; That having been said, I was going to suggest something similar to Aaron's first suggestion above. A few dozen lines of code can probalby simulate this.

Chris D. said: I just want to say that I gave an official +1 to your feature request. We really need something like that.&nbsp; That having been said, I was going to suggest something similar to Aaron's first suggestion above. A few dozen lines of code can probalby simulate this. That's my vote for the time being as well. I've written something like this for the specific case in question but Kryx and I were just discussing whether there was a less ugly way of implementing it...

And like I said, there really should be a less ugly way of implementing it.&nbsp; I have little doubt that in a few days/weeks/months there will be a less ugly way of implementing it. So we can ether just ignore it for now, or code arond it and pull the extra code out again when the more general case is fixed.&nbsp;