Nested Derived Attributes and Conditionals on these

[RayPrancer]

One of the trickest bits of the setting I've been working on is the Learning trait - it's defined as the lower of Memory (attrMem) or Concentration (attrCon). To make matters worse it can be altered from this base up for 1CP or down giving back 1CP.

Ideally I'd also like it to display indented under the Concentration attribute on the Attributes tab, but appreciate that might be a bit beyond my current level of ability.

I also have two traits that default to Concentration and can be raised and lowered in the same way - Focus and Perception, as well as six other traits of this nature relating to other Attributes.

Perhaps it's best if we start with Focus as the example and expand to cover the more difficult Learning trait later. I think I need to add the code to thing_traits.dat - is this right?
If so will the following code work? It's a non-combat ability. Do I need to add any code elsewhere (apart from the eventual code for displaying it as intended on the Abilities tab)?

<thing
   id=trFocus
   name="Focus"
   compset="trait"
   isunique="yes"
   description="Your ability to concentrate on a single task for an extended period. Defaults to Concentration.">
     <eval value="1" phase="Traits" priority="4000">
      <before name="Derived trtFinal"/>
      <after name="Calc trtFinal"/><![CDATA[
      field[trtBonus].value +=  #trait[attrCon]
      ]]></eval>

Although after typing that out it seems like it's simply a matter of nesting the two different calculations that could be used for Learning inside if statements (one if Memory is less than Concentration, the other if it's equal to or greater than because Concentration should be used if tied).

 

[rob]

I was circling back to spot posts we've missed and found this one. It looks like all of us on this end saw this post as a huge can of worms that would entail a long response - and we all assumed someone else would respond. Oops. That's one of the downsides of group ownership of tasks. Sorry! :-(

I'm going to try answering your post in pieces, with each piece in a separate post. Hopefully, this will keep everything more easily digestible.

 

[rob]

One of the trickest bits of the setting I've been working on is the Learning trait - it's defined as the lower of Memory (attrMem) or Concentration (attrCon). To make matters worse it can be altered from this base up for 1CP or down giving back 1CP.

Defining a trait that is calculated from other traits is easy. And you can use the "minimum" intrinsic function to retrieve the lower of the two other attributes. The detail that will be important is timing the calculation. It needs to be done *after* the other two attributes have been fully tallied, including all adjustments, but *before* the Learning trait is fully tallied.

An excellent example of how to handle this situation is provided within the Savage Worlds data files. Within SW, there are standard traits and derived traits, with the latter being passed on the standard traits (as well as other factors like skills). So the trick is to define a new component for derived traits that allows handling of the special behaviors involved.

If you take a look at the file "thing_traits.dat" within the SW data files, there is a big comment block at the top that describes what's going on. The actual implementations of the derived things are also found there. The walk-through within the Wiki documentation also provides a additional explanation of what's going on and how to set it all up.

 

[rob]

Ideally I'd also like it to display indented under the Concentration attribute on the Attributes tab, but appreciate that might be a bit beyond my current level of ability.

When displaying info to the user, you'll be using tables. These tables have some specific rules about their contents and sizing, which you'll learn as you delve into them. It would be impractical to try and indent the various dependent attributes beneath the primary attributes. You're much better off having a separate table of the derived attributes. Perhaps you can place the derived attributes in a table to the right of the primary attributes, establishing the spacing to visually associate the groups of attributes together for the user.

 

[rob]

I also have two traits that default to Concentration and can be raised and lowered in the same way - Focus and Perception, as well as six other traits of this nature relating to other Attributes.

Traits that are based on other traits like this are simply derived traits. The fact that they can be adjusted is independent of the fact that their values are calculated based on other primary traits. So these will work just like the Learning trait discussed earlier.

The key thing you'll want to do with these derived traits is set them up to possess a linkage (or two) to the trait(s) they derive from. Since you have lots of these derived traits, this will make it easier to define the traits and add new ones as necessary. Don't worry about the linkages at first, but that's something you'll want to switch to once you've got things starting to work.

 

[rob]

Perhaps it's best if we start with Focus as the example and expand to cover the more difficult Learning trait later. I think I need to add the code to thing_traits.dat - is this right?

Exactly correct.

If so will the following code work? It's a non-combat ability. Do I need to add any code elsewhere (apart from the eventual code for displaying it as intended on the Abilities tab)?

<thing
   id=trFocus
   name="Focus"
   compset="trait"
   isunique="yes"
   description="Your ability to concentrate on a single task for an extended period. Defaults to Concentration.">
     <eval value="1" phase="Traits" priority="4000">
      <before name="Derived trtFinal"/>
      <after name="Calc trtFinal"/><![CDATA[
      field[trtBonus].value +=  #trait[attrCon]
      ]]></eval>

The above code should work fine, except for one nasty problem. You're defining the bonus of one trait based on the net adjusted value of another trait. Since all traits are processed in the exact same way, you have a chicken-and-egg problem.

The solution is to setup a separate component and component set to differentiate a "derived" trait from a primary trait. Once you have the derived trait, you can re-calculate values after the primary trait is finalized. This is what's done in the Savage Worlds files that I pointed you to above. It's the only way to eliminate the circular dependency.

Although after typing that out it seems like it's simply a matter of nesting the two different calculations that could be used for Learning inside if statements (one if Memory is less than Concentration, the other if it's equal to or greater than because Concentration should be used if tied).

Yep. It's actually pretty easy. Instead of nesting the calculations, you can use the "minimize" intrinsic function on the two primary traits to get the lowest.