Can an "eachpick" item in a "foreach pick" loop recognize itself as the parent?

[EightBitz]

Can an "eachpick" item in a "foreach pick" loop recognize itself as the parent?

I have a question about a FATE Core script I'm writing, but the question is centered around scripting rather than FATE Core, so it makes more sense to me to post it here.

Question: If I include a "foreach pick" loop in an eval script for a stunt, where one of the results will be the parent stunt of the script, is there a way to identify if a particular "eachpick" instance is that same parent stunt?


Context: I have a stunt that offers a refresh bonus, is not unique, and allows multiple ranks. A hero can have five different instances of this stunt, each with its own bonus value. However, according to the rules I'm implementing, only the highest bonus value should apply. The stunt is called "The Catch", so for instance, if a hero has:

The Catch @ 5 pts.
The Catch @ 3 pts.
The Catch @ 1 pt.
The Catch @ 5 pts.

Only 5 points should be applied. I've written the following script which seems to be working so far, but I had to fudge things a bit at the end. In the case above, there are four instances of The Catch. So when I tell the script to find the highest value (5 pts.), and add only the 5 pts, it's doing that four times. Collectively, I end up with 20 pts. instead of 5.

I compensated for this by dividing the highest bonus by the number of instances. With the example above, that gives me 5/4 for each script. But since there are four scripts doing this, I end up with a total of 5.

If there was a way, as I ran through the foreach loop, where every time I found a higher bonus than before, I could query whether or not that bonus belongs to the immediate parent of the script, then I could have only that instance apply its bonus, and I wouldn't have to divide to compensate.


Here's my current script:

~ Declare variables
var thisbonus as number
var highbonus as number
var catches as number

~ Refund the refresh bonus of this instance of The Catch.
herofield[acRefrBase].value -= field[stNumber].value

~ Initialize variables
highbonus = 0
catches = 0

~ Cycle through each instance of The Catch
~ Find the highest, single bonus value from all instances.
~ Count the number of instances.
foreach pick in hero from Stunt where "thingid.pwrCatch"
   thisbonus = eachpick.field[stNumber].value
   if (thisbonus > highbonus) then
      highbonus = thisbonus
   endif
   catches += 1
nexteach

~ Apply only the highest bonus value.
~ Since this script runs on all instances, compensate by
~    dividing the highest bonus value by the number of instances.
~    (This is the part that feels awkward)
herofield[acRefrBase].value += (highbonus / catches)

 

[Mathias]

The uniqindex is a number assigned to each item added to a character, as it's added. The exact number will change from day to day as you use this character, but for the purpose of recognizing a specific copy of a specific thing, it's handy.

if (isroot <> 0) then
  if (root.uniqindex = eachpick.uniqindex) then

root takes you to the pick that bootstrapped this pick. Important: Make sure the pick running this script is NOT unique, or root will not work. Use User-Once if the user should only be allowed to select it once.

 

[Fuzzy]

I think the way this is more often done (multiple picks of the same item combining to a single ability), for example, pathfinder's implementation of sneak attack, is that the script is run on the first copy of the item, and collects info from all the others. only that first item is 'active' doing anything, but the properties of them all can be used for it. At least in pathfinder:

doneif (tagis[Helper.FirstCopy] = 0)

will exit the script if this isn't the first pick of a given thing.

 

[EightBitz]

So, neither of these worked exactly as described, but I was able to extrapolate a working solution.

This:

if (isroot <> 0) then
  if (root.uniqindex = eachpick.uniqindex) then

Yielded no results. Even when I put debug statements in there, I got nothing. So it was just skipping over that code.

This

doneif (tagis[Helper.FirstCopy] = 0)

Told me that the tag 'Helper.FirstCopy' is not defined.

So I ended up using this, which seems to work:

var thisbonus as number
var highbonus as number
var catches as number
var rootishigh as number

herofield[acRefrBase].value -= field[stNumber].value
highbonus = 0
catches = 0
rootishigh = 0
foreach pick in hero from Stunt where "thingid.pwrCatch"
   ~ debug eachpick.uniqindex
   thisbonus = eachpick.field[stNumber].value
   if (thisbonus > highbonus) then
      highbonus = thisbonus

      if (uniqindex = eachpick.uniqindex) then
         rootishigh = 1
      else
         rootishigh = 0
      endif

   endif
nexteach


if (rootishigh = 1) then
   herofield[acRefrBase].value += highbonus
endif

 

[Mathias]

Variables are already set to 0 when created, so unless you need a reminder of their values, you don't need to set them before the foreach.

 

[EightBitz]

Variables are already set to 0 when created, so unless you need a reminder of their values, you don't need to set them before the foreach.

I know. It's just a tendency I have from other scripting languages and programming languages. It's helped me far more than it's hurt me. And many a time, I've been burned by not explicitly setting variables to zero.

It may not be necessary here, but it makes me feel warm and fuzzy inside.

 

[ShadowChemosh]

I know. It's just a tendency I have from other scripting languages and programming languages. It's helped me far more than it's hurt me. And many a time, I've been burned by not explicitly setting variables to zero.

It may not be necessary here, but it makes me feel warm and fuzzy inside.

I have learned HL is consistent in setting initial values to 0 and text fields to blanks. But I agree when I first started I would often initialize fields before using for exactly the same reason's you said EightBitz.