Sheetworkers; test non-repeating attribute from within repeating scope

Basic question, so please excuse my js ignorance. I want to do "stuff" to a repeating attribute only IF the non-repeating attribute is ===1.  While I'm in a block of sheetworkers code that's working within a repeating section;  do I need to nest a getAttrs function within the repeating scope of my code?  If so, how do I use that value outside the getAttrs?  Is that possible? Sorry for a rather generic non-coded example. On my phone. ;-( TIA

wherever you do the getAttrs in your worker, just add the outer attribute as well. Then you can grab its value easily. If you don't already have a getAttrs, you'll need to add one, but you need to add it in such a way that it is not inside a loop (and if you are using getSectionIDs, it does need to be inside that scope). If you post the code for your repeating section, I'd be able to show how to add it, but it should be a very simple addition.

I'm always grateful for your assistance GiGs.  Thanks ;-) Of course I'm doing some work on the PF Community sheet which doesn't fit the "typical" mold when dealing with the sheetworkers since the sheet uses a "modular" handling for development that are section/function specific ( src folder on github ) .  Often times, one module calls functions from another module which makes it a little harder for novices(me) to follow exactly what is happening in the code.  I'm working within the PFSpells.js "module".  Currently, the sheet allows you to generate a spell attack from a spell for attack/damage based spells.  Many users have requested a method to execute the linked spell from within the attack's chat output.  So, I've added a method that does that and it seems to work fine.  ;-) BUT, I know some people may not want to include a link to the spell from the associated attack, so I've added a sheet option to toggle the this feature. Here's a sub-section of PFSpells.js (see the bold comment/code near the bottom) where I've added an option that adds a link to execute the spell when you create a spell attack.  This seems to work as expected. Now need to include a conditional check using a checkbox located outside repeating_spells <input type="checkbox" name="attr_toggle_spell_include_link" value="1" checked /> I think I just need to grab the value of "toggle_spell_include_link" to test.  Maybe something like; ... var testSpellOption = parseInt(v["toggle_spell_include_link"]);     if (testSpellOption===1) {   <run code to include a link in the spell attack> } ... I don't seem to have a problem grabbing any attributes from within repeating_spell.  It appears that spellPrefix(see code below) somehow knows this section of code is within repeating_spells, but I'm not sure how that works...?  I don't see anything directly that assigns repeating_spells to spellPrefix...   Since I'm working within repeating_spells, how can I grab the value of toggle_spell_include_link? Thanks /* ******************************** REPEATING SPELL FUNCTIONS ********************************** */ function setAttackEntryVals (spellPrefix,weaponPrefix,v,setter,noName){ var notes="",attackType=""; setter = setter||{}; try { TAS.debug("UPDATING SPELL ATTACK: "+spellPrefix,v); attackType=PFUtils.findAbilityInString(v[spellPrefix + "spell-attack-type"]); if (v[spellPrefix + "name"]) { if (!noName) { setter[weaponPrefix + "name"] = v[spellPrefix + "name"]; } setter[weaponPrefix + "source-spell-name"] = v[spellPrefix + "name"]; } if (attackType) { setter[weaponPrefix + "attack-type"] = v[spellPrefix + "spell-attack-type"]; if ((/CMB/i).test(attackType)) { setter[weaponPrefix + "vs"] = "cmd"; } else { setter[weaponPrefix + "vs"] = "touch"; } } if (v[spellPrefix+"range_numeric"]){ setter[weaponPrefix + "range"]=v[spellPrefix+"range_numeric"]; } if (v[spellPrefix+"range"] && v[spellPrefix+"range_pick"]==="see_text" ){ notes += "Range: " + v[spellPrefix+"range"]; } if (v[spellPrefix +"damage-macro-text"]){ setter[weaponPrefix+"precision_dmg_macro"] = v[spellPrefix+"damage-macro-text"]; if(attackType){ setter[weaponPrefix+"critical_dmg_macro"] = v[spellPrefix+"damage-macro-text"]; } } if (v[spellPrefix+ "damage-type"]){ setter[weaponPrefix+"precision_dmg_type"] = v[spellPrefix+"damage-type"]; if(attackType){ setter[weaponPrefix+"critical_dmg_type"] = v[spellPrefix+"damage-type"]; } } if (v[spellPrefix+"save"] ){ notes += "\n**Save:** " + v[spellPrefix + "save"]; if ( !(/none/).test(v[spellPrefix+"save"])){ notes += " **DC:** " + v[spellPrefix+"savedc"] } } if ( v[spellPrefix+"sr"]){ if (notes) { notes += "";} notes += "\n**Spell Resistance:** " + v[spellPrefix + "sr"]; } // include a link in the weapon notes to execute the spell from chat if (v[spellPrefix + "name"]) { if (notes) { notes += ""; } notes += "\n**Cast Spell:** [" + v[spellPrefix + "name"] + "]" + "(~@{character_name}|" + spellPrefix + "roll)"; } // end of link code if (notes){ setter[weaponPrefix+"notes"]=notes; } } catch (err){ TAS.error("PFSpells.setAttackEntryVals",err); } finally { return setter; } }

I'm sorry, I don't feel comfortabl4e trying to untangle all that. I think I'd need a top to bottom understanding of the whole set of modules to understand how it all fits together to know how to make adjustments to it. What I would recommend is completely abandoning that modular approach. But you can't because way it processes the sheet workers creates an obfuscated mess that you cant work with. So someone would first need to change the way sheet workers are processed to generates useful output. Then you could dump the whole set of modular files and have a single file that anyone could contribute to updating.

Also, if you abandon the sheet, and make it clear that it is abandoned and no-one is working on it any more, but link to the source files, then someone who understands the structure may be motivated to step in. That isnt likely to happen while the sheet is still being maintained.

I know we've discussed the pitfalls of developing in a propriety environment, and more specifically in regards to the Pathfinder Community sheet. More than a handful of people have been scared off once they look at how the sheetworkers have been designed.  I just have a hard time turning my back on the sheet since I feel it's still one of best sheets on roll20.  As always, thanks for your advice GiGs.