Loading ...
Sorry, an error occurred while loading the content.

Examples

Expand Messages
  • Frugal
    After the discussions last week about how to do various things I tried to see just how difficult it was to do various bits and pieces. My aim was to see if we
    Message 1 of 12 , Apr 5, 2004
    • 0 Attachment
      After the discussions last week about how to do various things I tried to
      see just how difficult it was to do various bits and pieces.

      My aim was to see if we can encode the objects in a few constructs. In
      these examples I have used <progression> and <entity> with a primitive
      type of 'variable'.

      Notes:

      - Variable bonuses do not stack unless explicitly stated.

      - I do not know how to allow arbitrary XML inside a tag. i.e. we do not
      care what XML goes inside a <description> tag, just so long as it is
      valid.

      - I have not done any repetition on ranks other than usnig "all" as a
      catch all. We could have something like <rank min="x" max="y"> to indicate
      all ranks between x and y, or put s formula on it with $rank as an
      implicit variable <rank level="floor($rank/3)"> for "every 3 ranks
      starting at level 3"

      - The race and character progessions are basically Keiths.

      - I have decided to encode all of the numeric details of items and their
      effects as variables. This should allow us to alter each aspect more
      easily. The most interesting case in the Monk class, where the damage can
      be encoded as a series of prereqs rather than the current custom tag.

      - Some kind of syntax / methodology needs to be defined for looking up
      choices and inserting the results into another variable. (Weapon Focus).


      <progression id="skill.balance">
      <name>Balance</name>
      <description>Long formatted description of balance skill text from
      SRD</description>
      <source page="Skills1.rtf"></source>
      <attributes>
      <!-- Attributes are constants on an entity that are not numbers -->
      <attribute key="armour.check.applies" value="true"/>
      <attribute key="usable-untrained" value="true" />
      </attributes>
      <types>
      <type>Dexterity</type>
      </types>
      <ranks>
      <rank level="all">
      <!-- All levels give a +1 rank -->
      <effects>
      <variable-bonus targetid="skill.balance.ranks" stacks="true" value="1"/>
      </effects>
      </rank>
      <rank level="1">
      <!-- Level 1 give a stat bonus -->
      <effects>
      <variable-bonus targetid="skill.balance" value="$skill.balance.ranks
      + $skill.balance.ranks.bonus + $skill.balance.stat +
      $skill.balance.misc + $skill.balance.synergy" />
      <variable-bonus targetid="skill.balance.stat" value="$stat.dex.mod" />
      </effects>
      </rank>
      <rank level="5">
      <!-- level 5 gives a synergy bonus to tumble -->
      <effects>
      <variable-bonus targetid="skill.tumble.ranks.synergy" value="2"/>
      </effects>
      </rank>
      </ranks>
      </progression>

      <progression id="skill.survival-underground">
      <name>Survival (Underground)</name>
      <description>Long Desc goes in here</description>
      <source page="SkillsII.rtf"/>
      <attributes>
      <attribute key="exclusive" value="true"/>
      <attribute key="usable-untrained" value="false" />
      </attributes>
      <types>
      <type>Wisdom</type>
      </types>
      <ranks>
      <rank level="all">
      <effects>
      <variable-bonus targetid="skill.survival-underground"
      value="$skill.survival-underground.ranks +
      $skill.survival-underground.ranks.bonus +
      $skill.survival-underground.stat + $skill.survival-underground.misc +
      $skill.survival-underground.synergy" />
      <variable-bonus targetid="skill.survival-underground.ranks" value="1"/>
      </effects>
      </rank>
      <rank level="1">
      <!-- You get to add your suvival ranks to your survival-underground
      ranks, so we need to have
      a separate *.ranks.bonus for each skill so that when we add up
      *.ranks we do not count
      these bonus ranks twice. It will also help for some classes (quint
      monk) that give free ranks -->
      <effects>
      <variable-bonus targetid="skill.survival-underground.stat"
      value="$stat.dex.mod" />
      <variable-bonus targetid="skill.survival-underground.ranks.bonus"
      value="$skill.survival.ranks" />
      </effects>
      </rank>
      </ranks>
      </progression>

      <progression id="skill.ride">
      <name>Ride</name>
      <description>Allows a character ride well.</description>
      <ranks>
      <rank level="all">
      <effects>
      <variable-bonus targetid="skill.ride.ranks" value="1"/>
      </effects>
      </rank>
      <rank level="1">
      <!-- Level 1 give a stat bonus -->
      <effects>
      <variable-bonus targetid="skill.ride" value="$skill.ride.ranks +
      $skill.ride.ranks.bonus + $skill.ride.stat + $skill.ride.misc +
      $skill.ride.synergy" />
      <variable-bonus targetid="skill.ride.stat" value="$stat.dex.mod" />
      </effects>
      </rank>
      </ranks>
      </progression>

      <progression id="race.human">
      <name>Human</name>
      <ranks >
      <rank level="all">
      <effects>
      <variable-bonus targetid="ranks.race.human" value="1"/>
      <add-rank type="characterlevel"/>
      </effects>
      </rank>
      <rank level="1">
      <effects>
      <add-entity type="feat" />
      <variable-bonus targetid="skillpool.multiplier" value="4"/>
      <variable-bonus targetid="skillpool.bonus.characterlevel" value="1"/>
      <variable-bonus targetid="skillpool.extrabonus.characterlevel"
      value="0"/>
      </effects>
      </rank>
      <rank level="2">
      <effects>
      <variable-bonus targetid="skillpool.multiplier" stacks="true"
      value="-3"/>
      </effects>
      </rank>
      </ranks>
      </progression>

      <progression id="characterlevel">
      <ranks>
      <rank level="1">
      <effects>
      <variable-bonus targetid="ranks.characterlevel" value="1"/>
      <variable-bonus targetid="var.featcount"
      value="floor($ranks.characterlevel / 3)"/>
      <add-rank type="class"/>
      </effects>
      </rank>
      </ranks>
      </progression>

      <progression id="class.fighter">
      <name>Fighter</name>
      <description>Bloke with a sword</description>
      <ranks>
      <rank level="1">
      <effects>
      <add-entity type="feats.fighter"/>
      <variable-bonus targetid="ranks.class.fighter" value="1"/>
      <variable-bonus targetid="skillpool.ranks.class.fighter"
      value="2+var.stat.int.mod.taken"/>
      <variable-bonus targetid="var.bab" value="ranks.class.fighter"/>
      <variable-bonus targetid="var.save.reflex.base"
      value="ranks.class.fighter/2"/>
      <variable-bonus targetid="skillpool" replaces="true" value="(2 +
      var.stat.int.mod.taken + skillpool.bonus.characterlevel.taken ) *
      skillpool.multiplier.taken + skillpool.extrabonus.taken"/>
      </effects>
      </rank>
      </ranks>
      </progression>


      <entity id="feat.toughness">
      <name>Toughness</name>
      <description>
      <b>Benefit:</b>You gain +3 hit points.<br />
      <b>Special:</b> A character may gain this feat multiple times. Its
      effects stack.
      </description>
      <attributes>
      <attribute key="allow.multiple" value="true"></attribute>
      </attributes>
      <types>
      <type>feat</type>
      <type>general</type>
      </types>
      <effects>
      <variable-bonus targetid="hitpoints" value="3"/>
      </effects>
      </entity>

      <entity id="feat.power-attack">
      <name>Power Attack</name>
      <types>
      <type>fighter</type>
      <type>feat</type>
      <type>general</type>
      </types>
      </entity>

      <entity id="feat.acrobatic">
      <name>Acrobatic</name>
      <description>See Text</description>
      <source page="Feats.rtf"/>
      <types>
      <type>feat</type>
      <type>general</type>
      </types>
      <effects>
      <variable-bonus targetid="skill.jump.misc" value="2"/>
      <variable-bonus targetid="skill.tumble.misc" value="2"/>
      </effects>
      </entity>

      <entity id="item.dagger">
      <name>Dagger</name>
      <attributes>
      <attribute key="wield" value="light"/>
      <attribute key="default-size" value="m"/>
      </attributes>
      <types>
      <type>item</type>
      <type>weapon</type>
      <type>melee</type>
      <type>finesseable</type>
      <type>ranged</type>
      <type>thrown</type>
      <type>simple</type>
      <type>standard</type>
      <type>piercing</type>
      <type>slashing</type>
      <type>dagger</type>
      </types>
      <effects>
      <variable-bonus targetid="combat.to-hit.dagger.melee"
      value="$combat.to-hit.melee + $combat.to-hit.dagger.melee.prof-penalty"
      stacks="false"/>
      <variable-bonus targetid="combat.to-hit.dagger.melee.prof-penalty"
      value="-4" stacks="false">
      <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
      operand="1"/>
      </variable-bonus>
      <variable-bonus targetid="combat.to-hit.dagger.ranged"
      value="$combat.to-hit.ranged +
      $combat.to-hit.dagger.ranged.prof-penalty" stacks="false"/>
      <variable-bonus targetid="combat.to-hit.dagger.ranged.prof-penalty"
      value="-4" stacks="false">
      <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
      operand="1"/>
      </variable-bonus>
      <variable-bonus targetid="item.dagger.range-increment" value="10"/>
      <variable-bonus targetid="item.dagger.critmult" value="2"/>
      <variable-bonus targetid="item.dagger.critrange" value="2" />
      <variable-bonus targetid="item.dagger.damage.die-size" value="4" />
      <variable-bonus targetid="item.dagger.damage.die-count" value="1"/>
      <variable-bonus targetid="item.dagger.range" value="10"/>
      <variable-bonus targetid="item.dagger.weight" value="1"/>
      <variable-bonus targetid="item.dagger.cost" value="2"/>
      <add-entity refid="eqmod.steel"/>
      </effects>
      </entity>

      <entity id="item.sword-bastard">
      <name>Sword (Bastard)</name>
      <attributes>
      <attribute key="wield" value="bastard"/>
      <attribute key="default-size" value="m"/>
      </attributes>
      <types>
      <type>item</type>
      <type>weapon</type>
      <type>melee</type>
      <type>martial</type>
      <type>exotic</type>
      <type>standard</type>
      <type>slashing</type>
      <type>sword</type>
      </types>
      <effects>
      <variable-bonus targetid="combat.to-hit.sword-bastard.melee"
      value="$combat.to-hit.melee +
      $combat.to-hit.sword-bastard.melee.prof-penalty" stacks="false"/>
      <variable-bonus
      targetid="combat.to-hit.sword-bastard.melee.prof-penalty" value="-4"
      stacks="false">
      <!-- get a -4 penalty if you do not have the bastard sword
      proficiency, or you are wielding it 2 handed with a martial
      proficiency -->
      <prereq kind="mult" operand=">=" operator="1">
      <prereq kind="feat" key="feat.weapon-prof.sword-bastard"
      operator="<" operand="1"/>
      <prereq kind="mult">
      <prereq kind="feat" key="feat.weapon-prof.martial" operator="<"
      operand="1"/>
      <prereq kind="wield" key="2-handed"/>
      </prereq>
      </prereq>
      </variable-bonus>
      <variable-bonus targetid="item.sword-bastard.range-increment" value="10"/>
      <variable-bonus targetid="item.sword-bastard.critmult" value="2"/>
      <variable-bonus targetid="item.sword-bastard.critrange" value="2" />
      <variable-bonus targetid="item.sword-bastard.damage.die-size"
      value="10" />
      <variable-bonus targetid="item.sword-bastard.damage.die-count" value="1"/>
      <variable-bonus targetid="item.sword-bastard.weight" value="10"/>
      <variable-bonus targetid="item.sword-bastard.cost" value="35"/>
      <add-entity refid="eqmod.steel"/>
      </effects>
      </entity>

      <entity id="feat.greater-weapon-focus">
      <name>Greater Weapon Focus</name>
      <description>See Text</description>
      <source page="Feats.rtf"></source>
      <attributes>
      <attribute key="multiples-stack" value="false"></attribute>
      <attribute key="allow-multiple" value="true"></attribute>
      </attributes>
      <types>
      <type>fighter</type>
      <type>feat</type>
      <type>general</type>
      </types>
      <prereq kind="mult">
      <prereq kind="has.entity" key="feat.weapon-focus"/>
      <prereq kind="variable" operator=">=" operand="1"/>
      </prereq>

      <effects>
      <!-- Icky. I have no idea how to set up choice lists
      This is trying to say: you can have a +1 to-hit to any one weapon
      for which you already have weapon focus...
      -->
      <variable-bonus targetid="combat.to-hit.%.melee"
      choice="feat.weapon-focus.%" value="1" stacks="true"/>
      </effects>
      </entity>


      <progression id="class.monk">
      <name abbrev="Mnk">Monk</name>
      <source page="Classes.rtf"/>
      <types>
      <type>class</type>
      <type>base</type>
      <type>pc</type>
      </types>
      <prereq kind="mult" operand="1">
      <prereq kind="alignment" key="lawful.good"/>
      <prereq kind="alignment" key="lawful.neutral"/>
      <prereq kind="alignment" key="lawful.evil"/>
      </prereq>
      <ranks>
      <rank level="1">
      <effects>
      <add-entity refid="sa.literacy"/>
      <add-entity refid="skill.balance"/>
      <add-entity refid="feat.weapon-prof" choice="club"/>
      <add-entity refid="feat.weapon-prof" choice="crossbow-light"/>
      <add-entity refid="feat.weapon-prof" choice="crossbow-heavy"/>
      <add-entity refid="feat.weapon-prof" choice="dagger"/>
      <add-entity refid="feat.weapon-prof" choice="handaxe"/>
      <add-entity refid="feat.weapon-prof" choice="javelin"/>
      <add-entity refid="feat.weapon-prof" choice="kama"/>
      <add-entity refid="feat.weapon-prof" choice="nunchaku"/>
      <add-entity refid="feat.weapon-prof" choice="quarterstaff"/>
      <add-entity refid="feat.weapon-prof" choice="sai"/>
      <add-entity refid="feat.weapon-prof" choice="shuriken"/>
      <add-entity refid="feat.weapon-prof" choice="siangham"/>
      <add-entity refid="feat.weapon-prof" choice="sling"/>
      <add-entity refid="feat.weapon-prof" choice="unarmed-strike"/>


      <variable-bonus targetid="var.flurry-of-blows">1</variable-bonus>
      <variable-bonus targetid="checks.fortitude.base"
      stacks="true">floor($class.monk.ranks/2)+2</variable-bonus>
      <variable-bonus targetid="checks.willpower.base"
      stacks="true">floor($class.monk.ranks/2)+2</variable-bonus>
      <variable-bonus targetid="checks.reflex.base"
      stacks="true">floor($class.monk.ranks/2)+2</variable-bonus>
      <variable-bonus targetid="combat.bab"
      stacks="true">floor($class.monk.ranks*3/4)</variable-bonus>
      <variable-bonus targetid="skillpool" replaces="true">(4 +
      var.stat.int.mod.taken + skillpool.bonus.characterlevel.taken ) *
      skillpool.multiplier.taken +
      skillpool.extrabonus.taken</variable-bonus>

      <!-- If we set up each weapon as a series of variables then we can do
      monk weapon sizes a lot more simply.
      This technique allows up to alter the xdy for unarmed damage where
      ever we like, which we can not do
      at the moment. This will allow for some special feats/classses from
      Oriental Adventures and Quintisential
      Monk -->
      <variable-bonus targetid="item.unarmed-strike.critmult" value="2"/>
      <variable-bonus targetid="item.unarmed-strike.critrange" value="1" />
      <variable-bonus targetid="item.unarmed-strike.damage.die-size"
      value="1"><prereq kind="size" key="f" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-size"
      value="2"><prereq kind="size" key="d" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-size"
      value="3"><prereq kind="size" key="t" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-size"
      value="4"><prereq kind="size" key="s" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-size"
      value="6"><prereq kind="size" key="m" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-size"
      value="8"><prereq kind="size" key="l" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-size"
      value="6"><prereq kind="size" key="h" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-size"
      value="6"><prereq kind="size" key="c" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-size"
      value="6"><prereq kind="size" key="g" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-count"
      value="1"><prereq kind="size" key="f" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-count"
      value="1"><prereq kind="size" key="d" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-count"
      value="1"><prereq kind="size" key="t" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-count"
      value="1"><prereq kind="size" key="s" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-count"
      value="1"><prereq kind="size" key="m" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-count"
      value="1"><prereq kind="size" key="l" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-count"
      value="2"><prereq kind="size" key="h" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-count"
      value="3"><prereq kind="size" key="c" operator="="/></variable-bonus>
      <variable-bonus targetid="item.unarmed-strike.damage.die-count"
      value="4"><prereq kind="size" key="g" operator="="/></variable-bonus>

      </effects>
      </rank>
      </ranks>
      </progression>


      --
      regards,
      Frugal
      -OS Chimp
    • Keith Davies
      ... Looking this over, is this intended as a representation of a cooked form of the data (that is, after it s been loaded, how it might look in the program)?
      Message 2 of 12 , Apr 5, 2004
      • 0 Attachment
        On Mon, Apr 05, 2004 at 02:41:20PM +0100, Frugal wrote:
        >
        > After the discussions last week about how to do various things I tried to
        > see just how difficult it was to do various bits and pieces.
        >
        > My aim was to see if we can encode the objects in a few constructs. In
        > these examples I have used <progression> and <entity> with a primitive
        > type of 'variable'.

        Looking this over, is this intended as a representation of a cooked form
        of the data (that is, after it's been loaded, how it might look in the
        program)? The XML itself could be very much simplified for use in data
        files and a translation between the two forms should not be particularly
        scary... and the XML you've described below would require a fair amount
        of sophistication for data entry.

        If that's the case, and a simpler form can actually be used for the data
        files, then this looks like a fairly reasonable processing structure. I
        do have some questions about particulars that aren't clear to me
        (included inline below), but by and large I think our differences are
        largely style-based.

        > Notes:
        >
        > - Variable bonuses do not stack unless explicitly stated.
        >
        > - I do not know how to allow arbitrary XML inside a tag. i.e. we do not
        > care what XML goes inside a <description> tag, just so long as it is
        > valid.
        >
        > - I have not done any repetition on ranks other than usnig "all" as a
        > catch all. We could have something like <rank min="x" max="y"> to indicate
        > all ranks between x and y, or put s formula on it with $rank as an
        > implicit variable <rank level="floor($rank/3)"> for "every 3 ranks
        > starting at level 3"

        I've hit this one a few times and considered several possibilities.
        Probably the simplest was to put min and max attributes on the effect,
        and a formula that resolves to 'non-zero' on levels it should apply (for
        instance, 'not($level % 3)' would trip on 3, 6, 9, ...).

        > - The race and character progessions are basically Keiths.
        >
        > - I have decided to encode all of the numeric details of items and their
        > effects as variables. This should allow us to alter each aspect more
        > easily. The most interesting case in the Monk class, where the damage can
        > be encoded as a series of prereqs rather than the current custom tag.
        >
        > - Some kind of syntax / methodology needs to be defined for looking up
        > choices and inserting the results into another variable. (Weapon Focus).
        >
        >
        > <progression id="skill.balance">
        > <name>Balance</name>
        > <description>Long formatted description of balance skill text from
        > SRD</description>

        What about a short description, the one-liners as on feats and spells?
        I used the <desc> element to contain those, or 'brief' (in another piece
        of work I'm doing).

        > <source page="Skills1.rtf"></source>

        I had this as a set of attributes (source namespace) on the entity
        rather than a child element; style difference.

        > <attributes>
        > <!-- Attributes are constants on an entity that are not numbers -->
        > <attribute key="armour.check.applies" value="true"/>
        > <attribute key="usable-untrained" value="true" />

        <attribute key='key.ability' value='stat.dex' />

        > </attributes>
        > <types>
        > <type>Dexterity</type>
        > </types>

        Descriptive type used for classification?

        > <ranks>
        > <rank level="all">
        > <!-- All levels give a +1 rank -->
        > <effects>
        > <variable-bonus targetid="skill.balance.ranks" stacks="true" value="1"/>
        > </effects>
        > </rank>
        > <rank level="1">
        > <!-- Level 1 give a stat bonus -->
        > <effects>
        > <variable-bonus targetid="skill.balance" value="$skill.balance.ranks
        > + $skill.balance.ranks.bonus + $skill.balance.stat +
        > $skill.balance.misc + $skill.balance.synergy" />
        > <variable-bonus targetid="skill.balance.stat" value="$stat.dex.mod" />

        statmod($skill.balance.stat) instead, since it doesn't use Dex directly?

        Hmm... no, you're more or less doing that... but it looks like you need
        to be able to process the effects in arbitrary order.

        > </effects>
        > </rank>
        > <rank level="5">
        > <!-- level 5 gives a synergy bonus to tumble -->
        > <effects>
        > <variable-bonus targetid="skill.tumble.ranks.synergy" value="2"/>
        > </effects>
        > </rank>
        > </ranks>
        > </progression>
        >
        > <progression id="skill.survival-underground">
        > <name>Survival (Underground)</name>
        > <description>Long Desc goes in here</description>
        > <source page="SkillsII.rtf"/>
        > <attributes>
        > <attribute key="exclusive" value="true"/>
        > <attribute key="usable-untrained" value="false" />
        > </attributes>
        > <types>
        > <type>Wisdom</type>
        > </types>
        > <ranks>
        > <rank level="all">
        > <effects>
        > <variable-bonus targetid="skill.survival-underground"
        > value="$skill.survival-underground.ranks +
        > $skill.survival-underground.ranks.bonus +
        > $skill.survival-underground.stat + $skill.survival-underground.misc +
        > $skill.survival-underground.synergy" />
        > <variable-bonus targetid="skill.survival-underground.ranks" value="1"/>
        > </effects>
        > </rank>

        You had this in <rank level='1'> in Balance, but in <rank level='all'>
        here. Was that on purpose?

        > <rank level="1">
        > <!-- You get to add your suvival ranks to your survival-underground
        > ranks, so we need to have
        > a separate *.ranks.bonus for each skill so that when we add up
        > *.ranks we do not count
        > these bonus ranks twice. It will also help for some classes (quint
        > monk) that give free ranks -->
        > <effects>
        > <variable-bonus targetid="skill.survival-underground.stat"
        > value="$stat.dex.mod" />
        > <variable-bonus targetid="skill.survival-underground.ranks.bonus"
        > value="$skill.survival.ranks" />
        > </effects>
        > </rank>
        > </ranks>
        > </progression>
        >
        > <progression id="skill.ride">
        > <name>Ride</name>
        > <description>Allows a character ride well.</description>
        > <ranks>
        > <rank level="all">
        > <effects>
        > <variable-bonus targetid="skill.ride.ranks" value="1"/>
        > </effects>
        > </rank>
        > <rank level="1">
        > <!-- Level 1 give a stat bonus -->
        > <effects>
        > <variable-bonus targetid="skill.ride" value="$skill.ride.ranks +
        > $skill.ride.ranks.bonus + $skill.ride.stat + $skill.ride.misc +
        > $skill.ride.synergy" />
        > <variable-bonus targetid="skill.ride.stat" value="$stat.dex.mod" />
        > </effects>
        > </rank>
        > </ranks>
        > </progression>
        >
        > <progression id="race.human">
        > <name>Human</name>
        > <ranks >
        > <rank level="all">
        > <effects>
        > <variable-bonus targetid="ranks.race.human" value="1"/>
        > <add-rank type="characterlevel"/>
        > </effects>
        > </rank>
        > <rank level="1">
        > <effects>
        > <add-entity type="feat" />
        > <variable-bonus targetid="skillpool.multiplier" value="4"/>
        > <variable-bonus targetid="skillpool.bonus.characterlevel" value="1"/>
        > <variable-bonus targetid="skillpool.extrabonus.characterlevel"
        > value="0"/>
        > </effects>
        > </rank>
        > <rank level="2">
        > <effects>
        > <variable-bonus targetid="skillpool.multiplier" stacks="true"
        > value="-3"/>
        > </effects>
        > </rank>
        > </ranks>
        > </progression>
        >
        > <progression id="characterlevel">
        > <ranks>
        > <rank level="1">
        > <effects>
        > <variable-bonus targetid="ranks.characterlevel" value="1"/>
        > <variable-bonus targetid="var.featcount"
        > value="floor($ranks.characterlevel / 3)"/>
        > <add-rank type="class"/>
        > </effects>
        > </rank>
        > </ranks>
        > </progression>
        >
        > <progression id="class.fighter">
        > <name>Fighter</name>
        > <description>Bloke with a sword</description>
        > <ranks>
        > <rank level="1">
        > <effects>
        > <add-entity type="feats.fighter"/>
        > <variable-bonus targetid="ranks.class.fighter" value="1"/>
        > <variable-bonus targetid="skillpool.ranks.class.fighter"
        > value="2+var.stat.int.mod.taken"/>
        > <variable-bonus targetid="var.bab" value="ranks.class.fighter"/>
        > <variable-bonus targetid="var.save.reflex.base"
        > value="ranks.class.fighter/2"/>

        Should be ranks.class.fighter/3, no? And need values for Fort and Will.

        > <variable-bonus targetid="skillpool" replaces="true" value="(2 +
        > var.stat.int.mod.taken + skillpool.bonus.characterlevel.taken ) *
        > skillpool.multiplier.taken + skillpool.extrabonus.taken"/>
        > </effects>
        > </rank>
        > </ranks>
        > </progression>
        >
        >
        > <entity id="feat.toughness">
        > <name>Toughness</name>
        > <description>
        > <b>Benefit:</b>You gain +3 hit points.<br />
        > <b>Special:</b> A character may gain this feat multiple times. Its
        > effects stack.
        > </description>
        > <attributes>
        > <attribute key="allow.multiple" value="true"></attribute>
        > </attributes>
        > <types>
        > <type>feat</type>
        > <type>general</type>
        > </types>
        > <effects>
        > <variable-bonus targetid="hitpoints" value="3"/>
        > </effects>
        > </entity>

        Is it necessary to indicate that the feat stacks? Or is that the
        default?

        > <entity id="feat.power-attack">
        > <name>Power Attack</name>
        > <types>
        > <type>fighter</type>
        > <type>feat</type>
        > <type>general</type>
        > </types>
        > </entity>
        >
        > <entity id="feat.acrobatic">
        > <name>Acrobatic</name>
        > <description>See Text</description>
        > <source page="Feats.rtf"/>
        > <types>
        > <type>feat</type>
        > <type>general</type>
        > </types>
        > <effects>
        > <variable-bonus targetid="skill.jump.misc" value="2"/>
        > <variable-bonus targetid="skill.tumble.misc" value="2"/>
        > </effects>
        > </entity>
        >
        > <entity id="item.dagger">
        > <name>Dagger</name>
        > <attributes>
        > <attribute key="wield" value="light"/>
        > <attribute key="default-size" value="m"/>
        > </attributes>
        > <types>
        > <type>item</type>
        > <type>weapon</type>
        > <type>melee</type>
        > <type>finesseable</type>
        > <type>ranged</type>
        > <type>thrown</type>
        > <type>simple</type>
        > <type>standard</type>
        > <type>piercing</type>
        > <type>slashing</type>
        > <type>dagger</type>
        > </types>
        > <effects>
        > <variable-bonus targetid="combat.to-hit.dagger.melee"
        > value="$combat.to-hit.melee + $combat.to-hit.dagger.melee.prof-penalty"
        > stacks="false"/>
        > <variable-bonus targetid="combat.to-hit.dagger.melee.prof-penalty"
        > value="-4" stacks="false">
        > <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
        > operand="1"/>
        > </variable-bonus>
        > <variable-bonus targetid="combat.to-hit.dagger.ranged"
        > value="$combat.to-hit.ranged +
        > $combat.to-hit.dagger.ranged.prof-penalty" stacks="false"/>
        > <variable-bonus targetid="combat.to-hit.dagger.ranged.prof-penalty"
        > value="-4" stacks="false">
        > <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
        > operand="1"/>
        > </variable-bonus>
        > <variable-bonus targetid="item.dagger.range-increment" value="10"/>
        > <variable-bonus targetid="item.dagger.critmult" value="2"/>
        > <variable-bonus targetid="item.dagger.critrange" value="2" />
        > <variable-bonus targetid="item.dagger.damage.die-size" value="4" />
        > <variable-bonus targetid="item.dagger.damage.die-count" value="1"/>
        > <variable-bonus targetid="item.dagger.range" value="10"/>
        > <variable-bonus targetid="item.dagger.weight" value="1"/>
        > <variable-bonus targetid="item.dagger.cost" value="2"/>
        > <add-entity refid="eqmod.steel"/>
        > </effects>
        > </entity>

        The variable-bonus... does it apply to the entity being described, or to
        the character/entity it is being applied to? With a feat, it looks like
        it gets applied to the character, but with the dagger it... looks like
        it gets applied to the character, but should actually be describing the
        dagger. This is unclear to me.

        Also, 'variable-bonus' looks deceptive. Is it a bonus to the 'real'
        value of the variable (in which case there are rules about how they
        stack, etc.) or is it a direct modification of the real value?

        Is this intended to be an 'intermediate form' (for instance, how it
        might look after being loaded? The XML itself can probably be very much
        simplified and the data translated to this form automatically without a
        lot of scariness from a simpler form, something like

        <equipment id='item.dagger'>
        <name>Dagger</name>
        <types>
        <type>item</type>
        <type>weapon</type>
        <type>melee</type>
        <type>dagger</type>
        <type>standard</type>
        </types>
        <effects /> <!-- how it changes the character goes here -->
        <physical-info size='medium' weight='2' cost='2' />
        <weapon-info>
        <usage light='yes' finesseable='yes' ranged='thrown' />
        <damage roll='1d4' critmult='2' critrange='2'>
        <type>piercing</type>
        <type>slashing</type>
        </damage>
        <ranged range-increment='10' max-increments='5' />
        </weapon-info>
        </equipment>
        <!-- not sure how to indicate that it's made of steel, though your
        '<add-entity refid="eqmod.steel" />' seems likely. I didn't include
        it because it *looks* like it's supposed to be added to the character
        who receives the dagger.

        These types/flags are all described in the <weapon-info /> element below
        and can be extracted at that time from that information.

        <type>finesseable</type>
        <type>ranged</type>
        <type>thrown</type>
        <type>piercing</type>
        <type>slashing</type>

        Proficiency is better determined and indicated by feats and class
        abilities, not the item itself, I think. This may also be subject to
        reclassification in different campaigns.

        <type>simple</type>


        You'll also note that I dropped 'entity' in favor of 'equipment';
        conversion to an 'entity' would be handled on loading (or by cooking the
        data before loading -- run it through a conversion routine that would
        expand it from the simpler form to the form you've described.


        No time to examine bastard sword and GWF; no comment on them at this
        point. I'm leaving them in for now in case I find time later.

        > <entity id="item.sword-bastard">
        > <name>Sword (Bastard)</name>
        > <attributes>
        > <attribute key="wield" value="bastard"/>
        > <attribute key="default-size" value="m"/>
        > </attributes>
        > <types>
        > <type>item</type>
        > <type>weapon</type>
        > <type>melee</type>
        > <type>martial</type>
        > <type>exotic</type>
        > <type>standard</type>
        > <type>slashing</type>
        > <type>sword</type>
        > </types>
        > <effects>
        > <variable-bonus targetid="combat.to-hit.sword-bastard.melee"
        > value="$combat.to-hit.melee +
        > $combat.to-hit.sword-bastard.melee.prof-penalty" stacks="false"/>
        > <variable-bonus
        > targetid="combat.to-hit.sword-bastard.melee.prof-penalty" value="-4"
        > stacks="false">
        > <!-- get a -4 penalty if you do not have the bastard sword
        > proficiency, or you are wielding it 2 handed with a martial
        > proficiency -->
        > <prereq kind="mult" operand=">=" operator="1">
        > <prereq kind="feat" key="feat.weapon-prof.sword-bastard"
        > operator="<" operand="1"/>
        > <prereq kind="mult">
        > <prereq kind="feat" key="feat.weapon-prof.martial" operator="<"
        > operand="1"/>
        > <prereq kind="wield" key="2-handed"/>
        > </prereq>
        > </prereq>
        > </variable-bonus>
        > <variable-bonus targetid="item.sword-bastard.range-increment" value="10"/>
        > <variable-bonus targetid="item.sword-bastard.critmult" value="2"/>
        > <variable-bonus targetid="item.sword-bastard.critrange" value="2" />
        > <variable-bonus targetid="item.sword-bastard.damage.die-size"
        > value="10" />
        > <variable-bonus targetid="item.sword-bastard.damage.die-count" value="1"/>
        > <variable-bonus targetid="item.sword-bastard.weight" value="10"/>
        > <variable-bonus targetid="item.sword-bastard.cost" value="35"/>
        > <add-entity refid="eqmod.steel"/>
        > </effects>
        > </entity>
        >
        > <entity id="feat.greater-weapon-focus">
        > <name>Greater Weapon Focus</name>
        > <description>See Text</description>
        > <source page="Feats.rtf"></source>
        > <attributes>
        > <attribute key="multiples-stack" value="false"></attribute>
        > <attribute key="allow-multiple" value="true"></attribute>
        > </attributes>
        > <types>
        > <type>fighter</type>
        > <type>feat</type>
        > <type>general</type>
        > </types>
        > <prereq kind="mult">
        > <prereq kind="has.entity" key="feat.weapon-focus"/>
        > <prereq kind="variable" operator=">=" operand="1"/>
        > </prereq>
        >
        > <effects>
        > <!-- Icky. I have no idea how to set up choice lists
        > This is trying to say: you can have a +1 to-hit to any one weapon
        > for which you already have weapon focus...
        > -->
        > <variable-bonus targetid="combat.to-hit.%.melee"
        > choice="feat.weapon-focus.%" value="1" stacks="true"/>
        > </effects>
        > </entity>
        >
        >
        > <progression id="class.monk">
        > <name abbrev="Mnk">Monk</name>
        > <source page="Classes.rtf"/>
        > <types>
        > <type>class</type>
        > <type>base</type>
        > <type>pc</type>
        > </types>
        > <prereq kind="mult" operand="1">
        > <prereq kind="alignment" key="lawful.good"/>
        > <prereq kind="alignment" key="lawful.neutral"/>
        > <prereq kind="alignment" key="lawful.evil"/>
        > </prereq>

        I had this as

        <prereq min='1' max='1'>
        <prereq kind='alignment' key='lawful.good' /> <!-- align.lg -->
        <prereq kind='alignment' key='lawful.neutral' /> <!-- align.ln -->
        <prereq kind='alignment' key='lawful.evil' /> <!-- align.le -->
        </prereq>

        Basically, any time they nest, they implicitly form a mult-kind of
        prereq... that's one only one that makes sense. After that you just
        have to indicate how many of the child prereqs must be satisfied.

        > <ranks>
        > <rank level="1">
        > <effects>
        > <add-entity refid="sa.literacy"/>
        > <add-entity refid="skill.balance"/>

        Add 'skill.balance' to the character? As a class skill, you mean? This
        isn't entirely clear to me.

        > <add-entity refid="feat.weapon-prof" choice="club"/>
        > <add-entity refid="feat.weapon-prof" choice="crossbow-light"/>
        > <add-entity refid="feat.weapon-prof" choice="crossbow-heavy"/>
        > <add-entity refid="feat.weapon-prof" choice="dagger"/>
        > <add-entity refid="feat.weapon-prof" choice="handaxe"/>
        > <add-entity refid="feat.weapon-prof" choice="javelin"/>
        > <add-entity refid="feat.weapon-prof" choice="kama"/>
        > <add-entity refid="feat.weapon-prof" choice="nunchaku"/>
        > <add-entity refid="feat.weapon-prof" choice="quarterstaff"/>
        > <add-entity refid="feat.weapon-prof" choice="sai"/>
        > <add-entity refid="feat.weapon-prof" choice="shuriken"/>
        > <add-entity refid="feat.weapon-prof" choice="siangham"/>
        > <add-entity refid="feat.weapon-prof" choice="sling"/>
        > <add-entity refid="feat.weapon-prof" choice="unarmed-strike"/>

        I'd put these in a separate list ('monk weapon proficiencies') outside
        the class and add them later, something like an 'invisible feat' as
        they're currently used.

        > <variable-bonus targetid="var.flurry-of-blows">1</variable-bonus>
        > <variable-bonus targetid="checks.fortitude.base"
        > stacks="true">floor($class.monk.ranks/2)+2</variable-bonus>
        > <variable-bonus targetid="checks.willpower.base"
        > stacks="true">floor($class.monk.ranks/2)+2</variable-bonus>
        > <variable-bonus targetid="checks.reflex.base"
        > stacks="true">floor($class.monk.ranks/2)+2</variable-bonus>
        > <variable-bonus targetid="combat.bab"
        > stacks="true">floor($class.monk.ranks*3/4)</variable-bonus>
        > <variable-bonus targetid="skillpool" replaces="true">(4 +
        > var.stat.int.mod.taken + skillpool.bonus.characterlevel.taken ) *
        > skillpool.multiplier.taken +
        > skillpool.extrabonus.taken</variable-bonus>
        >
        > <!-- If we set up each weapon as a series of variables then we can do
        > monk weapon sizes a lot more simply.
        > This technique allows up to alter the xdy for unarmed damage where
        > ever we like, which we can not do
        > at the moment. This will allow for some special feats/classses from
        > Oriental Adventures and Quintisential
        > Monk -->

        I would instead create a 'monk unarmed combat' progression that lives
        outside the monk class. The monk class adds a rank in that progression
        at each of its own ranks... then other classes can also do the same (a
        monk-based prestige class could then say 'unarmed combat stacks with
        that from monk' very easily). Incidentally, I would do the same with
        spellcasters; each level of wizard adds one level of 'wizard
        spellcasting', which in turn adds 'one level of wizard spells per day';
        each level of sorcerer adds one level of 'sorcerer spellcasting', which
        in turn adds a rank each of 'sorcerer spells per day' and 'sorcerer
        spells known'.

        > <variable-bonus targetid="item.unarmed-strike.critmult" value="2"/>
        > <variable-bonus targetid="item.unarmed-strike.critrange" value="1" />
        > <variable-bonus targetid="item.unarmed-strike.damage.die-size"
        > value="1"><prereq kind="size" key="f" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-size"
        > value="2"><prereq kind="size" key="d" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-size"
        > value="3"><prereq kind="size" key="t" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-size"
        > value="4"><prereq kind="size" key="s" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-size"
        > value="6"><prereq kind="size" key="m" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-size"
        > value="8"><prereq kind="size" key="l" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-size"
        > value="6"><prereq kind="size" key="h" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-size"
        > value="6"><prereq kind="size" key="c" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-size"
        > value="6"><prereq kind="size" key="g" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-count"
        > value="1"><prereq kind="size" key="f" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-count"
        > value="1"><prereq kind="size" key="d" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-count"
        > value="1"><prereq kind="size" key="t" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-count"
        > value="1"><prereq kind="size" key="s" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-count"
        > value="1"><prereq kind="size" key="m" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-count"
        > value="1"><prereq kind="size" key="l" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-count"
        > value="2"><prereq kind="size" key="h" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-count"
        > value="3"><prereq kind="size" key="c" operator="="/></variable-bonus>
        > <variable-bonus targetid="item.unarmed-strike.damage.die-count"
        > value="4"><prereq kind="size" key="g" operator="="/></variable-bonus>
        >
        > </effects>
        > </rank>
        > </ranks>
        > </progression>

        --
        Keith Davies I gave my 2yo daughter a strawberry
        keith.davies@... Naomi: "Strawberry!"
        me: "What do you say?"
        Naomi: "*MY* strawberry!"
      • Steven Bethard
        ... Why does the stat bonus occur at rank 1? Shouldn t it be assigned at rank 0 of a skill (so that a character with no ranks in Balance still gets their stat
        Message 3 of 12 , Apr 5, 2004
        • 0 Attachment
          Some questions (hopefully I'm not repeating anything Keith asked):

          > <rank level="1">
          > <!-- Level 1 give a stat bonus -->
          > <effects>
          > <variable-bonus targetid="skill.balance"
          > value="$skill.balance.ranks +
          > $skill.balance.ranks.bonus +
          > $skill.balance.stat +
          > $skill.balance.misc +
          > $skill.balance.synergy" />
          > <variable-bonus targetid="skill.balance.stat"
          > value="$stat.dex.mod" />
          > </effects>
          > ...
          > </rank>

          Why does the stat bonus occur at rank 1? Shouldn't it be assigned at rank 0
          of a skill (so that a character with no ranks in Balance still gets their
          stat adjustment)?

          > <rank level="5">
          > <!-- level 5 gives a synergy bonus to tumble -->
          > <effects>
          > <variable-bonus targetid="skill.tumble.ranks.synergy"
          > value="2"/>
          > </effects>
          > </rank>

          How do we deal with synergy bonuses for things like Diplomacy? From the
          RSRD:
          "Synergy: If you have 5 or more ranks in Bluff, Knowledge (nobility and
          royalty), or Sense Motive, you get a +2 bonus on Diplomacy checks"
          I read this as a boolean OR, such that if you have 5 ranks in Bluff and 5
          ranks in Sense Motive, you still only get a +2 Synergy bonus to Diplomacy.
          Regardless of whether my reading is right or wrong :), can we support
          something like this?

          > <progression id="race.human">
          > ...
          > <rank level="1">
          > ...
          > <rank level="2">
          > <effects>
          > <variable-bonus targetid="skillpool.multiplier"
          > stacks="true"
          > value="-3"/>
          > </effects>
          > </rank>
          > ...
          > </progression>

          Just to clarify, but this means a player chooses a Race at each level,
          right? I assume this is to make monster levels/classes simpler...

          Also, is there a reason why you used 'value="-3"' here instead of
          'replaces="true" value="1"'?

          > <progression id="race.human">
          > ...
          > <add-entity type="feat" />
          > ...
          > </progression>
          > ...
          > <progression id="characterlevel">
          > ...
          > <add-rank type="class"/>
          > ...
          > </progression>

          Is the assumption with 'type' that any time it selects more than one item
          the user must make a choice? If this is the case, to specify that the user
          gets all the feats of a certain type, we would have to enumerate them all in
          <add-entity />s, which might be annoying for the weapon-proficiency feats...

          > <variable-bonus targetid="combat.to-hit.dagger.melee.prof-penalty"
          > value="-4"
          > stacks="false">
          > <prereq kind="feat"
          > key="feat.weapon-prof.dagger"
          > operator="<"
          > operand="1"/>
          > </variable-bonus>
          > <variable-bonus targetid="combat.to-hit.dagger.ranged"
          > value="$combat.to-hit.ranged +
          > $combat.to-hit.dagger.ranged.prof-penalty"
          > stacks="false"/>

          This reads a little weird to me. Is the prereq for the variable-bonus to
          apply, or not to apply? If it's for it to apply, should the prof-penalty be
          subtracted from the second variable-bonus value instead of added?

          Also, I would be inclined to have at least two types of prereq tags, one for
          entities and one for variables. The operator/operand syntax seems a little
          strange when talking about an entity. I'd prefer something like:
          <entity-prereq key="feat.weapon-prof.dagger" present="true" />
          for entities and:
          <variable-prereq key="skill.balance.stat"
          test="$val > 12 && $val < 15" />
          for variables. I think this approach would be more coherent with the fact
          that we've already defined variable-bonus as separate from add-entity.

          > <prereq kind="wield" key="2-handed"/>

          How do you intend this to be handled? That is, how do we know how to check
          "wield"? I can see how to check entity presence and variable values based
          on the data descriptions so far. Can this be done with "wield" too, or is
          this one of the things we'll have to leave to program logic?

          > <variable-bonus targetid="combat.to-hit.%.melee"
          > choice="feat.weapon-focus.%"
          > value="1"
          > stacks="true"/>

          You're right, this is icky -- we'd really rather the program not have to
          parse ids. I'll have to think about if there's a better way to do this...
          Without parsing ids, we need some way to specify correspondence between
          weapons and their combat values... Hmm...


          Steve
          _____

          You can wordify anything if you just verb it.
          - Bucky Katt, Get Fuzzy
        • Frugal
          ... It is a representation of the cooked XML. When I first came up with a schema that converted the LST data into XML everyone told
          Message 4 of 12 , Apr 6, 2004
          • 0 Attachment
            <quote who="Keith Davies">
            > On Mon, Apr 05, 2004 at 02:41:20PM +0100, Frugal wrote:
            > Looking this over, is this intended as a representation of a cooked form
            > of the data (that is, after it's been loaded, how it might look in the
            > program)? The XML itself could be very much simplified for use in data
            > files and a translation between the two forms should not be particularly
            > scary... and the XML you've described below would require a fair amount
            > of sophistication for data entry.

            It is a representation of the cooked XML.

            When I first came up with a schema that converted the LST data into XML
            everyone told me that we could not possibly use that system as it was too
            system dependent. Are we now saying that the progression, rank, entity
            structures are actually Java structures that we map the high level XML
            onto? Or are we planning to map from high level XML to low level XML to
            java structures? I am getting very confused about what people actually
            want from this project.

            >> - I have not done any repetition on ranks other than usnig "all" as a
            >> catch all. We could have something like <rank min="x" max="y"> to
            >> indicate
            >> all ranks between x and y, or put s formula on it with $rank as an
            >> implicit variable <rank level="floor($rank/3)"> for "every 3 ranks
            >> starting at level 3"
            >
            > I've hit this one a few times and considered several possibilities.
            > Probably the simplest was to put min and max attributes on the effect,
            > and a formula that resolves to 'non-zero' on levels it should apply (for
            > instance, 'not($level % 3)' would trip on 3, 6, 9, ...).

            You are quite correct, not(x) will have far mroe effect than floor(x) ;O)

            If we have a formula we do not need 'min' and 'max'.

            "not($level % 3 == 0) && $level>6 && $level<20"

            >> <progression id="skill.balance">
            >> <name>Balance</name>
            >> <description>Long formatted description of balance skill text from
            >> SRD</description>
            >
            > What about a short description, the one-liners as on feats and spells?
            > I used the <desc> element to contain those, or 'brief' (in another piece
            > of work I'm doing).

            Yeah, that works. Or even nest them:

            <description>
            <brief>One line desc</brief>
            <detailed><h3>Description</h3><p>This is the long desc</p></detailed>

            >> <source page="Skills1.rtf"></source>
            >
            > I had this as a set of attributes (source namespace) on the entity
            > rather than a child element; style difference.

            It really make no difference.

            As a style question (and something I have just never "got"): Why use all
            of the namespaces? None of them make sense without the others so shouldn't
            they all be part of the same thing? Under what circumstances would a
            namespace consisting of nothing but 4 attributes be useful? I can
            understand the use of namespaces with things like Schema, XSLT, XSL-FO as
            they are all encapsulating different things and each can be use
            independently, or in conjunction with each other, but I can not see how
            this works with the PCGen namespaces.

            >> <attributes>
            >> <!-- Attributes are constants on an entity that are not numbers -->
            >> <attribute key="armour.check.applies" value="true"/>
            >> <attribute key="usable-untrained" value="true" />
            >
            > <attribute key='key.ability' value='stat.dex' />
            >
            >> </attributes>
            >> <types>
            >> <type>Dexterity</type>
            >> </types>
            >
            > Descriptive type used for classification?

            I did it this way for a couple of reasons:

            I did not see the point in having a 'key.ability' attribute as the stat
            bonus is explicitly encoded in the effects of the progression.

            I added the <type>Dexterity</type> so that the progression can be searched
            and indexed. If all entities (and progressions) have a series of types
            that describe them then we can search for all entities that have type
            'FEAT' and type 'FIGHTER', or type 'SKILL' and type 'Dexterity'. If we
            have half of this information in object specific attributes then this
            becomes more difficult.

            I have just noticed that all of the skills need <type>Skill</type> added
            to them.

            >> <ranks>
            >> <rank level="all">
            >> <!-- All levels give a +1 rank -->
            >> <effects>
            >> <variable-bonus targetid="skill.balance.ranks" stacks="true"
            >> value="1"/>
            >> </effects>
            >> </rank>
            >> <rank level="1">
            >> <!-- Level 1 give a stat bonus -->
            >> <effects>
            >> <variable-bonus targetid="skill.balance"
            >> value="$skill.balance.ranks
            >> + $skill.balance.ranks.bonus + $skill.balance.stat +
            >> $skill.balance.misc + $skill.balance.synergy" />
            >> <variable-bonus targetid="skill.balance.stat" value="$stat.dex.mod"
            >> />
            >
            > statmod($skill.balance.stat) instead, since it doesn't use Dex directly?

            I did not use this structure as it requires a statmod() function and the
            ability to lookup from $skill.balance.stat to 'stat.dex' and from there to
            an explicit number.

            I would much rather have a series of variables in the character object:

            stat.dex
            stat.dex.mod

            and then a formula:

            <variable-bonus targtrid="stat.dex.mod" value="floor($stat.dex/2)-5"/>

            > Hmm... no, you're more or less doing that... but it looks like you need
            > to be able to process the effects in arbitrary order.

            I am working on the assumption that the client can either set up
            dependencies on the variables and calculate them in order, or the client
            can set up a notification system such that variable 'a' is notified when
            variable 'b' is changed.

            > You had this in <rank level='1'> in Balance, but in <rank level='all'>
            > here. Was that on purpose?

            Nope, completely messed it up ;O)

            I had originally thought about putting the stat modifiers in the first
            rank for skills that were not useable untrained and in 'all' for untrained
            skills. After I sent it out I realised that 'all' was a really stupid
            place to put it, and it should go in the top level <effects> rather than
            under a rank so that if you have 0 ranks you still get the bonus...

            I am now undecided as to wether all the stat bonuses should go under the
            top level <effects>, or if the untraned=no skills should have their stat
            bonus under rank 1...

            >> <variable-bonus targetid="var.save.reflex.base"
            >> value="ranks.class.fighter/2"/>
            >
            > Should be ranks.class.fighter/3, no? And need values for Fort and Will.

            Oh, more than likely. I was doing this off of the top of my head and
            trying to remember the progressions rather than bothering to look them up
            ;O)

            Yes, you are right, Fortitude and Willpower bonuses also need to go in there

            >> <entity id="feat.toughness">
            >> <name>Toughness</name>
            >> <description>
            >> <b>Benefit:</b>You gain +3 hit points.<br />
            >> <b>Special:</b> A character may gain this feat multiple times. Its
            >> effects stack.
            >> </description>
            >> <attributes>
            >> <attribute key="allow.multiple" value="true"></attribute>
            >> </attributes>
            >> <types>
            >> <type>feat</type>
            >> <type>general</type>
            >> </types>
            >> <effects>
            >> <variable-bonus targetid="hitpoints" value="3"/>
            >> </effects>
            >> </entity>
            >
            > Is it necessary to indicate that the feat stacks? Or is that the
            > default?

            You are quite right, I put an 'allows-mutiples' attribute in, but I forgot
            the 'multiples.stack' attribute.

            >> <entity id="item.dagger">
            >> <name>Dagger</name>
            >> <attributes>
            >> <attribute key="wield" value="light"/>
            >> <attribute key="default-size" value="m"/>
            >> </attributes>
            >> <types>
            >> <type>item</type>
            >> <type>weapon</type>
            >> <type>melee</type>
            >> <type>finesseable</type>
            >> <type>ranged</type>
            >> <type>thrown</type>
            >> <type>simple</type>
            >> <type>standard</type>
            >> <type>piercing</type>
            >> <type>slashing</type>
            >> <type>dagger</type>
            >> </types>
            >> <effects>
            >> <variable-bonus targetid="combat.to-hit.dagger.melee"
            >> value="$combat.to-hit.melee + $combat.to-hit.dagger.melee.prof-penalty"
            >> stacks="false"/>
            >> <variable-bonus targetid="combat.to-hit.dagger.melee.prof-penalty"
            >> value="-4" stacks="false">
            >> <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
            >> operand="1"/>
            >> </variable-bonus>
            >> <variable-bonus targetid="combat.to-hit.dagger.ranged"
            >> value="$combat.to-hit.ranged +
            >> $combat.to-hit.dagger.ranged.prof-penalty" stacks="false"/>
            >> <variable-bonus targetid="combat.to-hit.dagger.ranged.prof-penalty"
            >> value="-4" stacks="false">
            >> <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
            >> operand="1"/>
            >> </variable-bonus>
            >> <variable-bonus targetid="item.dagger.range-increment" value="10"/>
            >> <variable-bonus targetid="item.dagger.critmult" value="2"/>
            >> <variable-bonus targetid="item.dagger.critrange" value="2" />
            >> <variable-bonus targetid="item.dagger.damage.die-size" value="4" />
            >> <variable-bonus targetid="item.dagger.damage.die-count" value="1"/>
            >> <variable-bonus targetid="item.dagger.range" value="10"/>
            >> <variable-bonus targetid="item.dagger.weight" value="1"/>
            >> <variable-bonus targetid="item.dagger.cost" value="2"/>
            >> <add-entity refid="eqmod.steel"/>
            >> </effects>
            >> </entity>
            >
            > The variable-bonus... does it apply to the entity being described, or to
            > the character/entity it is being applied to? With a feat, it looks like
            > it gets applied to the character, but with the dagger it... looks like
            > it gets applied to the character, but should actually be describing the
            > dagger. This is unclear to me.

            I am working on everything apliying to the character. I guess it is the
            difference between asking the character "how much damage do you do with a
            dagger" and asking the dagger: "how much damage to you do when weilded by
            the character". this is why all of the variables are prefexed with the
            item id.

            If you wanted to give a feat that increased the damage dice to a d6 rather
            than a d4 you would apply this to the character:

            <variable-bonus targetid="item.dagger.damage.die-size" value="2"
            stacks="true"/>

            or

            <variable-bonus targetid="item.dagger.damage.die-size" value="6"
            stacks="false"/>


            > Also, 'variable-bonus' looks deceptive. Is it a bonus to the 'real'
            > value of the variable (in which case there are rules about how they
            > stack, etc.) or is it a direct modification of the real value?

            It is a modification to the variable. I guess it is badly named, it should
            be named something like: <variable-modification>.

            I would say that the rules on <variable-modification> are:

            - If (there are any modifications that have replaces="true")
            then use the highest one
            else
            Take the highest modification that does not have
            stacks="true" or replaces="true".
            - add all of the modifications that have stacks="true"



            > Is this intended to be an 'intermediate form' (for instance, how it
            > might look after being loaded? The XML itself can probably be very much
            > simplified and the data translated to this form automatically without a
            > lot of scariness from a simpler form, something like
            >
            > <equipment id='item.dagger'>
            > <name>Dagger</name>
            > <types>
            > <type>item</type>
            > <type>weapon</type>
            > <type>melee</type>
            > <type>dagger</type>
            > <type>standard</type>
            > </types>
            > <effects /> <!-- how it changes the character goes here -->
            > <physical-info size='medium' weight='2' cost='2' />
            > <weapon-info>
            > <usage light='yes' finesseable='yes' ranged='thrown' />
            > <damage roll='1d4' critmult='2' critrange='2'>
            > <type>piercing</type>
            > <type>slashing</type>
            > </damage>
            > <ranged range-increment='10' max-increments='5' />
            > </weapon-info>
            > </equipment>

            as I said at the top of this email: I did not do any kind of high level
            XML as everytime I have suggested it over ht epast year someone has shot
            me down.


            > <!-- not sure how to indicate that it's made of steel, though your
            > '<add-entity refid="eqmod.steel" />' seems likely. I didn't include
            > it because it *looks* like it's supposed to be added to the character
            > who receives the dagger.

            This is the part where my "everything applies to the character" system
            falls apart ;O(

            > Proficiency is better determined and indicated by feats and class
            > abilities, not the item itself, I think. This may also be subject to
            > reclassification in different campaigns.
            >
            > <type>simple</type>

            I put the proficiency bonuses in the item because I did not want to go
            down the road of having to lookup bonuses from unrelated things.

            I guess that you can have a dagger.prof variable made up of the highest of
            weaponprof.dagger bonus, weaponprof.martial bonus and weaponprof.dagger
            bonus.

            >> <prereq kind="mult" operand="1">
            >> <prereq kind="alignment" key="lawful.good"/>
            >> <prereq kind="alignment" key="lawful.neutral"/>
            >> <prereq kind="alignment" key="lawful.evil"/>
            >> </prereq>
            >
            > I had this as
            >
            > <prereq min='1' max='1'>
            > <prereq kind='alignment' key='lawful.good' /> <!-- align.lg -->
            > <prereq kind='alignment' key='lawful.neutral' /> <!-- align.ln -->
            > <prereq kind='alignment' key='lawful.evil' /> <!-- align.le -->
            > </prereq>
            >
            > Basically, any time they nest, they implicitly form a mult-kind of
            > prereq... that's one only one that makes sense. After that you just
            > have to indicate how many of the child prereqs must be satisfied.

            I am 'implicit-phobic' I have been bitten by implitic too many times to
            trust it (or anyone else implimentation of it) saying that I missed out
            the 'operator="="' attribute ;O)

            Having used my prereq syntax in the current version of PCGen I know that
            it copes with all cases without needed other syntax.

            >> <ranks>
            >> <rank level="1">
            >> <effects>
            >> <add-entity refid="sa.literacy"/>
            >> <add-entity refid="skill.balance"/>
            >
            > Add 'skill.balance' to the character? As a class skill, you mean? This
            > isn't entirely clear to me.

            Yes. It isn't entirly clear to me now that I reread it. We are back to
            skills being a pain to implement.

            >> <add-entity refid="feat.weapon-prof" choice="club"/>
            >
            > I'd put these in a separate list ('monk weapon proficiencies') outside
            > the class and add them later, something like an 'invisible feat' as
            > they're currently used.

            Again, purely a style issue.

            > I would instead create a 'monk unarmed combat' progression that lives
            > outside the monk class. The monk class adds a rank in that progression
            > at each of its own ranks... then other classes can also do the same (a
            > monk-based prestige class could then say 'unarmed combat stacks with
            > that from monk' very easily).

            After I sent out the email I realised that doing the unarmed combat as a
            progression would be easier.

            the one thing I have not figured out how to do is replace the progression
            with a completely different one. Some of the complex monk classes/feats
            allow you to "use one size larger for unarmed damage", "use 1 size smaller
            for damage", "use this other progression for unarmed damage".

            > Incidentally, I would do the same with
            > spellcasters; each level of wizard adds one level of 'wizard
            > spellcasting', which in turn adds 'one level of wizard spells per day';
            > each level of sorcerer adds one level of 'sorcerer spellcasting', which
            > in turn adds a rank each of 'sorcerer spells per day' and 'sorcerer
            > spells known'.

            That would make spellcasting prestige classes a lot easier.

            --
            regards,
            Frugal
            -OS Chimp
          • Frugal
            ... Ermmm. Good, you passed the test, move along now, nothing to see here ;O) It should be a child of the progression/effects
            Message 5 of 12 , Apr 6, 2004
            • 0 Attachment
              <quote who="Steven Bethard">
              > Some questions (hopefully I'm not repeating anything Keith asked):
              >
              > Why does the stat bonus occur at rank 1? Shouldn't it be assigned at rank
              > 0
              > of a skill (so that a character with no ranks in Balance still gets their
              > stat adjustment)?

              Ermmm. Good, you passed the test, move along now, nothing to see here ;O)

              It should be a child of the progression/effects rather than
              progression/ranks/rank/effects

              > How do we deal with synergy bonuses for things like Diplomacy? From the
              > RSRD:
              > "Synergy: If you have 5 or more ranks in Bluff, Knowledge (nobility and
              > royalty), or Sense Motive, you get a +2 bonus on Diplomacy checks"
              > I read this as a boolean OR, such that if you have 5 ranks in Bluff and 5
              > ranks in Sense Motive, you still only get a +2 Synergy bonus to Diplomacy.
              > Regardless of whether my reading is right or wrong :), can we support
              > something like this?

              Unfortunately the SRD authors did not right everything in pseudocode, if
              they had our life would be a lot easier. I believe that this has been
              FAQed to state that this in fact uses the other english usage of 'or'. You
              get the synergy bonuses for each and every skill with 5 ranks.

              In any case we can handle both cases:

              Do not stack:

              <variable-modification targetid="skill.diplomacy.synergy"
              stacks="false"
              value="2">
              <prereq kind="var" key="skill.bluff.ranks" operand="5" operator=">="/>
              </variable-modification>
              <variable-modification targetid="skill.diplomacy.synergy"
              stacks="false"
              value="2">
              <prereq kind="var" key="skill.sense-motive.ranks" operand="5"
              operator=">="/>
              </variable-modification>

              Do Stack:

              <variable-modification targetid="skill.diplomacy.synergy"
              stacks="true"
              value="2">
              <prereq kind="var" key="skill.bluff.ranks" operand="5" operator=">="/>
              </variable-modification>
              <variable-modification targetid="skill.diplomacy.synergy"
              stacks="true"
              value="2">
              <prereq kind="var" key="skill.sense-motive.ranks" operand="5"
              operator=">="/>
              </variable-modification>


              The only difference is the 'stacks="true"' or 'stacks="false"'.


              > Just to clarify, but this means a player chooses a Race at each level,
              > right? I assume this is to make monster levels/classes simpler...

              Correct.

              > Also, is there a reason why you used 'value="-3"' here instead of
              > 'replaces="true" value="1"'?

              absolutely none, it is just a style thing. I wanted to show that you can
              do things either way.

              >> <progression id="race.human">
              >> ...
              >> <add-entity type="feat" />
              >> ...
              >> </progression>
              >> ...
              >> <progression id="characterlevel">
              >> ...
              >> <add-rank type="class"/>
              >> ...
              >> </progression>
              >
              > Is the assumption with 'type' that any time it selects more than one item
              > the user must make a choice? If this is the case, to specify that the
              > user
              > gets all the feats of a certain type, we would have to enumerate them all
              > in
              > <add-entity />s, which might be annoying for the weapon-proficiency
              > feats...

              The assumption is that with <add-rank type="class"/> the client will look
              for all progressions with a <type>class</type> child element and ask the
              user to choose one. Likewise <add-entity type="feat" /> will look for all
              entitiess with a <type>feat</type>.

              I imagine that <add-entity type="feat,fighter"/> will look for all
              entities with a type of 'feat' && a type of 'fighter'.

              I guess we do need some way to add more than one entity at a time.

              <add-entity type="feat,weapon-prof,martial" count="all"/>

              to add all entities that have the 'feat', 'weapon-prof' and 'martial' types.

              <add-entity type="feat,meta-magic" count="2"/>

              To add any 2 meta-magic feats.

              >> <variable-bonus targetid="combat.to-hit.dagger.melee.prof-penalty"
              >> value="-4"
              >> stacks="false">
              >> <prereq kind="feat"
              >> key="feat.weapon-prof.dagger"
              >> operator="<"
              >> operand="1"/>
              >> </variable-bonus>
              >> <variable-bonus targetid="combat.to-hit.dagger.ranged"
              >> value="$combat.to-hit.ranged +
              >> $combat.to-hit.dagger.ranged.prof-penalty"
              >> stacks="false"/>
              >
              > This reads a little weird to me. Is the prereq for the variable-bonus to
              > apply, or not to apply?

              the prereq says: if you do not have the dagger proficiency then the
              prof-penalty is -4. I now realise that I forgot to put the replaces="true"
              tag in the variable-bonus.

              > If it's for it to apply, should the prof-penalty
              > be
              > subtracted from the second variable-bonus value instead of added?

              No, because the prof-penalty is either '0' or '-4'.

              > How do you intend this to be handled? That is, how do we know how to
              > check
              > "wield"? I can see how to check entity presence and variable values based
              > on the data descriptions so far. Can this be done with "wield" too, or is
              > this one of the things we'll have to leave to program logic?

              All of the prerequisites will need to be done in code, even the variable
              ones.

              --
              regards,
              Frugal
              -OS Chimp
            • Keith Davies
              ... Ah, okay. ... I think rank, entity, and progression are abstractions well-suited to representing RPG information. I think it s a difference in levels of
              Message 6 of 12 , Apr 6, 2004
              • 0 Attachment
                On Tue, Apr 06, 2004 at 11:56:32AM +0100, Frugal wrote:
                >
                > <quote who="Keith Davies">
                > > On Mon, Apr 05, 2004 at 02:41:20PM +0100, Frugal wrote:
                > > Looking this over, is this intended as a representation of a cooked form
                > > of the data (that is, after it's been loaded, how it might look in the
                > > program)? The XML itself could be very much simplified for use in data
                > > files and a translation between the two forms should not be particularly
                > > scary... and the XML you've described below would require a fair amount
                > > of sophistication for data entry.
                >
                > It is a representation of the cooked XML.

                Ah, okay.

                > When I first came up with a schema that converted the LST data into XML
                > everyone told me that we could not possibly use that system as it was too
                > system dependent. Are we now saying that the progression, rank, entity
                > structures are actually Java structures that we map the high level XML
                > onto? Or are we planning to map from high level XML to low level XML to
                > java structures? I am getting very confused about what people actually
                > want from this project.

                I think rank, entity, and progression are abstractions well-suited to
                representing RPG information. I think it's a difference in levels of
                interpretation -- in my XML I say that particular things *are* entities
                or progressions; in your intermediate form they have been rendered *as*
                entities and progressions.

                Does that make sense? I hope so; I was up late last night.

                > > I've hit this one a few times and considered several possibilities.
                > > Probably the simplest was to put min and max attributes on the effect,
                > > and a formula that resolves to 'non-zero' on levels it should apply (for
                > > instance, 'not($level % 3)' would trip on 3, 6, 9, ...).
                >
                > You are quite correct, not(x) will have far mroe effect than floor(x) ;O)
                >
                > If we have a formula we do not need 'min' and 'max'.
                >
                > "not($level % 3 == 0) && $level>6 && $level<20"
                >
                > >> <progression id="skill.balance">
                > >> <name>Balance</name>
                > >> <description>Long formatted description of balance skill text from
                > >> SRD</description>
                > >
                > > What about a short description, the one-liners as on feats and spells?
                > > I used the <desc> element to contain those, or 'brief' (in another piece
                > > of work I'm doing).
                >
                > Yeah, that works. Or even nest them:
                >
                > <description>
                > <brief>One line desc</brief>
                > <detailed><h3>Description</h3><p>This is the long desc</p></detailed>

                Don't embed specific headings in it like this, I think. I can't think
                of *too* many cases where entities will be complex enough to have their
                own headings. The few that do would probably be better off with a more
                generic <h> -- that can be picked up and formatted as needed for
                whatever level it appears at. For instance, if we were dumping
                everything to HTML and each class gets its own page, we might make them
                <h2> (<h3> for nested ones); if they all go on a single page, they might
                be <h3> or <h4> (with corresponding values for nested ones).

                > >> <source page="Skills1.rtf"></source>
                > >
                > > I had this as a set of attributes (source namespace) on the entity
                > > rather than a child element; style difference.
                >
                > It really make no difference.
                >
                > As a style question (and something I have just never "got"): Why use
                > all of the namespaces? None of them make sense without the others so
                > shouldn't they all be part of the same thing? Under what circumstances
                > would a namespace consisting of nothing but 4 attributes be useful? I
                > can understand the use of namespaces with things like Schema, XSLT,
                > XSL-FO as they are all encapsulating different things and each can be
                > use independently, or in conjunction with each other, but I can not
                > see how this works with the PCGen namespaces.

                Different levels of abstraction, plus shared behavior. The meta
                namespace describes the structure of game entities and related
                information. It is used by the engine so it knows how to map the XML to
                the internal representation. A namespace for each rule set makes it
                explicit what rules are being loaded and how to map them -- and clears
                the way to having different games using the same element names (not
                loaded at the same time, probably -- though there'd be nothing making it
                impossible, I think it'd be way more trouble than it's worth). For
                instance, d20 <skill> and Hero <skill> look different, etc. Without
                using namespaces for this, we'll end up with <d20skill> and <heroskill>,
                or some ungodly creation that tries to merge the behavior for both.
                Source has common behavior regardless of game or system; it's not
                metadata (in the sense that it doesn't describe the structure of the
                data being manipulated), but it is data about where entity manipulation
                being read came from. It's not part of d20, it's not part of Hero, but
                it can reasonably be used by both.

                Namespaces are still useful and appropriate IMO, in other words.

                > >> <attributes>
                > >> <!-- Attributes are constants on an entity that are not numbers -->
                > >> <attribute key="armour.check.applies" value="true"/>
                > >> <attribute key="usable-untrained" value="true" />
                > >
                > > <attribute key='key.ability' value='stat.dex' />
                > >
                > >> </attributes>
                > >> <types>
                > >> <type>Dexterity</type>
                > >> </types>
                > >
                > > Descriptive type used for classification?
                >
                > I did it this way for a couple of reasons:
                >
                > I did not see the point in having a 'key.ability' attribute as the stat
                > bonus is explicitly encoded in the effects of the progression.

                We still present it, don't we? While functionally you are correct, I
                think there are expectations that it be easily presented.

                > I added the <type>Dexterity</type> so that the progression can be
                > searched and indexed. If all entities (and progressions) have a series
                > of types that describe them then we can search for all entities that
                > have type 'FEAT' and type 'FIGHTER', or type 'SKILL' and type
                > 'Dexterity'. If we have half of this information in object specific
                > attributes then this becomes more difficult.

                I was really hoping to get away from TYPE, but even so this is a better
                representation than the current concatenated string... and it might not
                be visible in data since this is an internal representation.

                > I have just noticed that all of the skills need <type>Skill</type> added
                > to them.
                >
                > >> <ranks>
                > >> <rank level="all">
                > >> <!-- All levels give a +1 rank -->
                > >> <effects>
                > >> <variable-bonus targetid="skill.balance.ranks" stacks="true"
                > >> value="1"/>
                > >> </effects>
                > >> </rank>
                > >> <rank level="1">
                > >> <!-- Level 1 give a stat bonus -->
                > >> <effects>
                > >> <variable-bonus targetid="skill.balance"
                > >> value="$skill.balance.ranks
                > >> + $skill.balance.ranks.bonus + $skill.balance.stat +
                > >> $skill.balance.misc + $skill.balance.synergy" />
                > >> <variable-bonus targetid="skill.balance.stat" value="$stat.dex.mod"
                > >> />
                > >
                > > statmod($skill.balance.stat) instead, since it doesn't use Dex directly?
                >
                > I did not use this structure as it requires a statmod() function and the
                > ability to lookup from $skill.balance.stat to 'stat.dex' and from there to
                > an explicit number.
                >
                > I would much rather have a series of variables in the character object:
                >
                > stat.dex
                > stat.dex.mod
                >
                > and then a formula:
                >
                > <variable-bonus targtrid="stat.dex.mod" value="floor($stat.dex/2)-5"/>

                That's not a bonus, though, that's a calculation. If it were to be done
                that way, I'd rather see something like

                <variable key='stat.dex' />
                <function key='stat.dex.mod' calc='floor($stat.dex/2)-5' />

                > > Hmm... no, you're more or less doing that... but it looks like you need
                > > to be able to process the effects in arbitrary order.
                >
                > I am working on the assumption that the client can either set up
                > dependencies on the variables and calculate them in order, or the client
                > can set up a notification system such that variable 'a' is notified when
                > variable 'b' is changed.

                That can be done.

                > > You had this in <rank level='1'> in Balance, but in <rank level='all'>
                > > here. Was that on purpose?
                >
                > Nope, completely messed it up ;O)
                >
                > I had originally thought about putting the stat modifiers in the first
                > rank for skills that were not useable untrained and in 'all' for
                > untrained skills. After I sent it out I realised that 'all' was a
                > really stupid place to put it, and it should go in the top level
                > <effects> rather than under a rank so that if you have 0 ranks you
                > still get the bonus...

                I'd figured <effects> would only happen when it got applied. Untrained
                would never see it anyway.

                > I am now undecided as to wether all the stat bonuses should go under
                > the top level <effects>, or if the untraned=no skills should have
                > their stat bonus under rank 1...

                Mmm... I can see why you're doing this for skills -- in order to present
                a character's total bonus to the roll for each skill you need to know
                about both the character and every skill you want the roll bonus for.
                It seems to depart from the normal model, though; feats don't have
                effect unless they're applied to the character, classes don't have
                effect unless they're applied to the character, etc. Making skills
                behave differently here adds complication, I think, that isn't quite
                needed.

                > >> <variable-bonus targetid="var.save.reflex.base"
                > >> value="ranks.class.fighter/2"/>
                > >
                > > Should be ranks.class.fighter/3, no? And need values for Fort and Will.
                >
                > Oh, more than likely. I was doing this off of the top of my head and
                > trying to remember the progressions rather than bothering to look them up
                > ;O)
                >
                > Yes, you are right, Fortitude and Willpower bonuses also need to go in there
                >
                Fair enough; I know I elide things (don't put in all saves, etc.) and
                make mistakes on what I do put in. It's enough to show the structure, I
                just wanted to check.

                > >> <entity id="item.dagger">
                > >> <name>Dagger</name>
                > >> <attributes>
                > >> <attribute key="wield" value="light"/>
                > >> <attribute key="default-size" value="m"/>
                > >> </attributes>
                > >> <types>
                > >> <type>item</type>
                > >> <type>weapon</type>
                > >> <type>melee</type>
                > >> <type>finesseable</type>
                > >> <type>ranged</type>
                > >> <type>thrown</type>
                > >> <type>simple</type>
                > >> <type>standard</type>
                > >> <type>piercing</type>
                > >> <type>slashing</type>
                > >> <type>dagger</type>
                > >> </types>
                > >> <effects>
                > >> <variable-bonus targetid="combat.to-hit.dagger.melee"
                > >> value="$combat.to-hit.melee + $combat.to-hit.dagger.melee.prof-penalty"
                > >> stacks="false"/>
                > >> <variable-bonus targetid="combat.to-hit.dagger.melee.prof-penalty"
                > >> value="-4" stacks="false">
                > >> <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
                > >> operand="1"/>
                > >> </variable-bonus>
                > >> <variable-bonus targetid="combat.to-hit.dagger.ranged"
                > >> value="$combat.to-hit.ranged +
                > >> $combat.to-hit.dagger.ranged.prof-penalty" stacks="false"/>
                > >> <variable-bonus targetid="combat.to-hit.dagger.ranged.prof-penalty"
                > >> value="-4" stacks="false">
                > >> <prereq kind="feat" key="feat.weapon-prof.dagger" operator="<"
                > >> operand="1"/>
                > >> </variable-bonus>
                > >> <variable-bonus targetid="item.dagger.range-increment" value="10"/>
                > >> <variable-bonus targetid="item.dagger.critmult" value="2"/>
                > >> <variable-bonus targetid="item.dagger.critrange" value="2" />
                > >> <variable-bonus targetid="item.dagger.damage.die-size" value="4" />
                > >> <variable-bonus targetid="item.dagger.damage.die-count" value="1"/>
                > >> <variable-bonus targetid="item.dagger.range" value="10"/>
                > >> <variable-bonus targetid="item.dagger.weight" value="1"/>
                > >> <variable-bonus targetid="item.dagger.cost" value="2"/>
                > >> <add-entity refid="eqmod.steel"/>
                > >> </effects>
                > >> </entity>
                > >
                > > The variable-bonus... does it apply to the entity being described, or to
                > > the character/entity it is being applied to? With a feat, it looks like
                > > it gets applied to the character, but with the dagger it... looks like
                > > it gets applied to the character, but should actually be describing the
                > > dagger. This is unclear to me.
                >
                > I am working on everything apliying to the character. I guess it is the
                > difference between asking the character "how much damage do you do with a
                > dagger" and asking the dagger: "how much damage to you do when weilded by
                > the character". this is why all of the variables are prefexed with the
                > item id.

                Best watch this; characters in my design are not particularly 'special';
                the same mechanisms are used for other entities (such as equipment and
                whatnot -- adding an equipmod to a sword is much the same as adding a
                feat to a character).

                If you'll be prefixing the item ID to the variable modified, you'll need
                to parse it out at some point to determine the values. However, I have
                an idea.

                <variable-mod target='self' key='varname' value='n' />

                Hmm... actually, that doesn't make a lot of sense -- why would something
                need to modify itself? Most modifications would implicitly be to what
                the item is applied to... so.

                <variable key='varname' value='n' />

                defines the field (in concrete terms that'd be <cost> or <critmult> or
                whatever)

                <variable-mod key='varname' value='formula' />

                would describe (in part) what happens when you apply the modifier to the
                receiving entity:

                <equipmod id='eqmod.masterwork'>
                <variable-mod key='toHit' value='+1' />
                </equipmod>

                should (in theory) increase the toHit value of the item of equipment it
                is applied to... though in this case it should probably be treated as a
                bonus rather than a modifier.

                Oh, right -- we probably need to be able to piggyback effects, too.
                Adding one entity to another might modify the recipient so it passes an
                effect on to what *it* is applied to.

                > If you wanted to give a feat that increased the damage dice to a d6
                > rather than a d4 you would apply this to the character:
                >
                > <variable-bonus targetid="item.dagger.damage.die-size" value="2"
                > stacks="true"/>
                >
                > or
                >
                > <variable-bonus targetid="item.dagger.damage.die-size" value="6"
                > stacks="false"/>

                how would you increase the damage of a particular dagger, though?
                Create a new 'sharper dagger' entity?

                > > Also, 'variable-bonus' looks deceptive. Is it a bonus to the 'real'
                > > value of the variable (in which case there are rules about how they
                > > stack, etc.) or is it a direct modification of the real value?
                >
                > It is a modification to the variable. I guess it is badly named, it should
                > be named something like: <variable-modification>.
                >
                > I would say that the rules on <variable-modification> are:
                >
                > - If (there are any modifications that have replaces="true")
                > then use the highest one
                > else
                > Take the highest modification that does not have
                > stacks="true" or replaces="true".
                > - add all of the modifications that have stacks="true"
                >
                >
                >
                > > Is this intended to be an 'intermediate form' (for instance, how it
                > > might look after being loaded? The XML itself can probably be very much
                > > simplified and the data translated to this form automatically without a
                > > lot of scariness from a simpler form, something like
                > >
                > > <equipment id='item.dagger'>
                > > <name>Dagger</name>
                > > <types>
                > > <type>item</type>
                > > <type>weapon</type>
                > > <type>melee</type>
                > > <type>dagger</type>
                > > <type>standard</type>
                > > </types>
                > > <effects /> <!-- how it changes the character goes here -->
                > > <physical-info size='medium' weight='2' cost='2' />
                > > <weapon-info>
                > > <usage light='yes' finesseable='yes' ranged='thrown' />
                > > <damage roll='1d4' critmult='2' critrange='2'>
                > > <type>piercing</type>
                > > <type>slashing</type>
                > > </damage>
                > > <ranged range-increment='10' max-increments='5' />
                > > </weapon-info>
                > > </equipment>
                >
                > as I said at the top of this email: I did not do any kind of high level
                > XML as everytime I have suggested it over ht epast year someone has shot
                > me down.
                >
                >
                > > <!-- not sure how to indicate that it's made of steel, though your
                > > '<add-entity refid="eqmod.steel" />' seems likely. I didn't include
                > > it because it *looks* like it's supposed to be added to the character
                > > who receives the dagger.
                >
                > This is the part where my "everything applies to the character" system
                > falls apart ;O(

                I like the use of the steel equipmod, though; this is much better than
                'TYPE: STEEL'.

                How's this: change your targetid attribute to 'key' [which is safer
                anyway; ID should be unique in the system, which means that only a
                single character is being modeled (targetid *is* unique) or it isn't
                (and targetid is lying about this implication]. Give the variable-mod
                (or any other effect) an implicit target of 'the recipient'; this can be
                overridden (target='self') for those cases where you want it to be able
                to apply something (variable modification, equipment modification, etc.)
                to itself instead. So

                <entity id='item.dagger'>
                <!-- name, variable identification and initialization , etc. -->
                <add-entity target='self' refid='eqmod.steel' />
                </entity>

                Or for a truly nifty item:

                <entity id='item.dagger.steelbody'>
                <!-- name, variable identification and initialization , etc. -->
                <add-entity refid='eqmod.steel' />
                <!-- turns wielder into steel, oops... -->
                </entity>

                > > Proficiency is better determined and indicated by feats and class
                > > abilities, not the item itself, I think. This may also be subject to
                > > reclassification in different campaigns.
                > >
                > > <type>simple</type>
                >
                > I put the proficiency bonuses in the item because I did not want to go
                > down the road of having to lookup bonuses from unrelated things.
                >
                > I guess that you can have a dagger.prof variable made up of the highest of
                > weaponprof.dagger bonus, weaponprof.martial bonus and weaponprof.dagger
                > bonus.
                >
                > >> <prereq kind="mult" operand="1">
                > >> <prereq kind="alignment" key="lawful.good"/>
                > >> <prereq kind="alignment" key="lawful.neutral"/>
                > >> <prereq kind="alignment" key="lawful.evil"/>
                > >> </prereq>
                > >
                > > I had this as
                > >
                > > <prereq min='1' max='1'>
                > > <prereq kind='alignment' key='lawful.good' /> <!-- align.lg -->
                > > <prereq kind='alignment' key='lawful.neutral' /> <!-- align.ln -->
                > > <prereq kind='alignment' key='lawful.evil' /> <!-- align.le -->
                > > </prereq>
                > >
                > > Basically, any time they nest, they implicitly form a mult-kind of
                > > prereq... that's one only one that makes sense. After that you just
                > > have to indicate how many of the child prereqs must be satisfied.
                >
                > I am 'implicit-phobic' I have been bitten by implitic too many times to
                > trust it (or anyone else implimentation of it) saying that I missed out
                > the 'operator="="' attribute ;O)

                I'm not generally fond of implicit behavior... though in this case I see
                it as something of an 'explicit implicit' -- it's part of the defined
                behavior. Still, it doesn't *hurt* to say <prereq kind='mult'>, either.

                > Having used my prereq syntax in the current version of PCGen I know that
                > it copes with all cases without needed other syntax.
                >
                > >> <ranks>
                > >> <rank level="1">
                > >> <effects>
                > >> <add-entity refid="sa.literacy"/>
                > >> <add-entity refid="skill.balance"/>
                > >
                > > Add 'skill.balance' to the character? As a class skill, you mean? This
                > > isn't entirely clear to me.
                >
                > Yes. It isn't entirly clear to me now that I reread it. We are back to
                > skills being a pain to implement.

                yep.

                > >> <add-entity refid="feat.weapon-prof" choice="club"/>
                > >
                > > I'd put these in a separate list ('monk weapon proficiencies') outside
                > > the class and add them later, something like an 'invisible feat' as
                > > they're currently used.
                >
                > Again, purely a style issue.
                >
                > > I would instead create a 'monk unarmed combat' progression that lives
                > > outside the monk class. The monk class adds a rank in that progression
                > > at each of its own ranks... then other classes can also do the same (a
                > > monk-based prestige class could then say 'unarmed combat stacks with
                > > that from monk' very easily).
                >
                > After I sent out the email I realised that doing the unarmed combat as a
                > progression would be easier.
                >
                > the one thing I have not figured out how to do is replace the progression
                > with a completely different one. Some of the complex monk classes/feats
                > allow you to "use one size larger for unarmed damage", "use 1 size smaller
                > for damage", "use this other progression for unarmed damage".

                Hmm... this is one of those 'it's easy to design it this way from the
                front' sort of deals, where we make the association *between* the
                character and the class -- in RDBMS terms, something like

                Character
                |
                ^
                CharClass (this contains things like 'effective monk damage size', ick)
                v
                |
                Class

                But I'm not happy with *that*, either.

                It's a damn shame that the monk progressions aren't *quite* size bumps
                (at /n/ level you are treated as /x/ sizes larger than normal)...
                they're *close* in RSRD, IIRC, but not *quite* right. Dammit.

                Hmm... I think I'll note that for my campaign, actually; it'll simplify
                things.

                > > Incidentally, I would do the same with
                > > spellcasters; each level of wizard adds one level of 'wizard
                > > spellcasting', which in turn adds 'one level of wizard spells per day';
                > > each level of sorcerer adds one level of 'sorcerer spellcasting', which
                > > in turn adds a rank each of 'sorcerer spells per day' and 'sorcerer
                > > spells known'.
                >
                > That would make spellcasting prestige classes a lot easier.

                That's why <g>

                --
                Keith Davies I gave my 2yo daughter a strawberry
                keith.davies@... Naomi: "Strawberry!"
                me: "What do you say?"
                Naomi: "*MY* strawberry!"
              • Keith Davies
                ... To be more precise (at least about my design, which I think Frugal was trying to model), each race has or is a progression; the character (or creature)
                Message 7 of 12 , Apr 6, 2004
                • 0 Attachment
                  On Tue, Apr 06, 2004 at 12:34:40PM +0100, Frugal wrote:
                  >
                  > <quote who="Steven Bethard">
                  > > Just to clarify, but this means a player chooses a Race at each level,
                  > > right? I assume this is to make monster levels/classes simpler...
                  >
                  > Correct.

                  To be more precise (at least about my design, which I think Frugal was
                  trying to model), each race has or is a progression; the character (or
                  creature) adds a rank in that progression and it (may) end up adding a
                  class level. Specifically, the race is chosen once, ranks are added
                  many times... he doesn't get to choose a new race at each level (which
                  is how I first read your question).

                  > >> <progression id="race.human">
                  > >> ...
                  > >> <add-entity type="feat" />
                  > >> ...
                  > >> </progression>
                  > >> ...
                  > >> <progression id="characterlevel">
                  > >> ...
                  > >> <add-rank type="class"/>
                  > >> ...
                  > >> </progression>
                  > >
                  > > Is the assumption with 'type' that any time it selects more than one
                  > > item the user must make a choice? If this is the case, to specify
                  > > that the user gets all the feats of a certain type, we would have to
                  > > enumerate them all in <add-entity />s, which might be annoying for
                  > > the weapon-proficiency feats...
                  >
                  > The assumption is that with <add-rank type="class"/> the client will look
                  > for all progressions with a <type>class</type> child element and ask the
                  > user to choose one. Likewise <add-entity type="feat" /> will look for all
                  > entitiess with a <type>feat</type>.
                  >
                  > I imagine that <add-entity type="feat,fighter"/> will look for all
                  > entities with a type of 'feat' && a type of 'fighter'.
                  >
                  > I guess we do need some way to add more than one entity at a time.
                  >
                  > <add-entity type="feat,weapon-prof,martial" count="all"/>
                  >
                  > to add all entities that have the 'feat', 'weapon-prof' and 'martial' types.

                  If you're saying what I think you are here, I suspect it's backward --
                  feats grant proficiency, but they're not the *only* thing that grants
                  proficiency.

                  > <add-entity type="feat,meta-magic" count="2"/>
                  >
                  > To add any 2 meta-magic feats.

                  I think we need to specify some sort of query syntax to deal with this
                  sort of thing... you're working around the edges of one, but we should
                  do something more explicit. 'sides, I'll need it for extracting
                  entities from the system to be written to file.

                  > > How do you intend this to be handled? That is, how do we know how
                  > > to check "wield"? I can see how to check entity presence and
                  > > variable values based on the data descriptions so far. Can this be
                  > > done with "wield" too, or is this one of the things we'll have to
                  > > leave to program logic?
                  >
                  > All of the prerequisites will need to be done in code, even the variable
                  > ones.

                  Described in data, tested in code, you mean?


                  Keith
                  --
                  Keith Davies I gave my 2yo daughter a strawberry
                  keith.davies@... Naomi: "Strawberry!"
                  me: "What do you say?"
                  Naomi: "*MY* strawberry!"
                • Steven Bethard
                  ... My preference is to have one XML standard that looks something like what Frugal s presented. This standard should be as
                  Message 8 of 12 , Apr 6, 2004
                  • 0 Attachment
                    <quote who="Frugal">
                    > Are we now saying that the progression, rank, entity
                    > structures are actually Java structures that we map
                    > the high level XML onto? Or are we planning to map
                    > from high level XML to low level XML to java
                    > structures?

                    My preference is to have one XML standard that looks something like what
                    Frugal's presented. This standard should be as system-independent as
                    possible, and as much as possible should map directly into Java objects. If
                    this standard is still too low-level for people, I think we should allow a
                    higher-level standard that can be mapped to this standard, but I think this
                    step should be completely optional.

                    I've been pushing to keep the one standard as simple as possible, which is
                    why we discussed using just Entities and Effects for a while. I think I'm
                    more or less convinced now that this very general approach won't work for
                    D&D, and that we'll have to move to something that encodes a little more
                    about the system into the code, like what Frugal's done.

                    In general, I'd prefer that we never have elements or attributes named with
                    something specific to one game system, so that we would never have:
                    <progression id="skill.balance" usable-untrained="true" />
                    or:
                    <skill id="balance" usable-untrained="true" />
                    but instead, something like what Frugal's done:
                    <progression id="skill.balance">
                    <attribute key="usable-untrained" value="true" />
                    </progression
                    This may be what Keith already intended, but it's hard for me to tell how
                    the UML diagrams were supposed to translate into XML.


                    Steve
                    _____

                    You can wordify anything if you just verb it.
                    - Bucky Katt, Get Fuzzy
                  • Frugal
                    ... I think it is a fine enough distinction that it will not be relevent. ... I did not mean to imply that we would format the
                    Message 9 of 12 , Apr 7, 2004
                    • 0 Attachment
                      <quote who="Keith Davies">
                      > On Tue, Apr 06, 2004 at 11:56:32AM +0100, Frugal wrote:
                      >
                      > I think rank, entity, and progression are abstractions well-suited to
                      > representing RPG information. I think it's a difference in levels of
                      > interpretation -- in my XML I say that particular things *are* entities
                      > or progressions; in your intermediate form they have been rendered *as*
                      > entities and progressions.

                      I think it is a fine enough distinction that it will not be relevent.

                      >> <description>
                      >> <brief>One line desc</brief>
                      >> <detailed><h3>Description</h3><p>This is the long desc</p></detailed>
                      >
                      > Don't embed specific headings in it like this, I think. I can't think
                      > of *too* many cases where entities will be complex enough to have their
                      > own headings. The few that do would probably be better off with a more
                      > generic <h> -- that can be picked up and formatted as needed for
                      > whatever level it appears at. For instance, if we were dumping
                      > everything to HTML and each class gets its own page, we might make them
                      > <h2> (<h3> for nested ones); if they all go on a single page, they might
                      > be <h3> or <h4> (with corresponding values for nested ones).

                      I did not mean to imply that we would format the descriptions this
                      particular way, I just wanted to say that we can put arbitrary tags inside
                      the detailed description and <h3> was the only tag I could think of ;O)

                      I really must craft my examples with more care from now on. We all seem to
                      be able to infer a great deal of incorrect detail from each others
                      examples ;O)

                      Like you I can not think of any reason to have headings in a description,
                      but I can certainly see a use for lists, emphasis etc.

                      Out of interest what do people thin is the best way to allow an arbitrary
                      set of tags under a <description> tag ?

                      - Explicitly specify which subset of HTML tags we allow?

                      - include the XHTML schema and demand that the nested tags are all in the
                      xhtml: namespace?

                      - Can we even say "allow any valid XML content as a child of this tag and
                      do not validate it against the current schema"? and if we can do we want
                      to?

                      ...

                      Okay that was a bit too low level and detailed for the moment, but it is
                      worth remembering for a later date.



                      >> >> <source page="Skills1.rtf"></source>
                      >> >
                      >> > I had this as a set of attributes (source namespace) on the entity
                      >> > rather than a child element; style difference.
                      >>
                      >> It really make no difference.
                      >>
                      >> As a style question (and something I have just never "got"): Why use
                      >> all of the namespaces? None of them make sense without the others so
                      >> shouldn't they all be part of the same thing? Under what circumstances
                      >> would a namespace consisting of nothing but 4 attributes be useful? I
                      >> can understand the use of namespaces with things like Schema, XSLT,
                      >> XSL-FO as they are all encapsulating different things and each can be
                      >> use independently, or in conjunction with each other, but I can not
                      >> see how this works with the PCGen namespaces.
                      >
                      > Different levels of abstraction, plus shared behavior. The meta
                      > namespace describes the structure of game entities and related
                      > information. It is used by the engine so it knows how to map the XML to
                      > the internal representation. A namespace for each rule set makes it
                      > explicit what rules are being loaded and how to map them -- and clears
                      > the way to having different games using the same element names (not
                      > loaded at the same time, probably -- though there'd be nothing making it
                      > impossible, I think it'd be way more trouble than it's worth). For
                      > instance, d20 <skill> and Hero <skill> look different, etc. Without
                      > using namespaces for this, we'll end up with <d20skill> and <heroskill>,
                      > or some ungodly creation that tries to merge the behavior for both.
                      > Source has common behavior regardless of game or system; it's not
                      > metadata (in the sense that it doesn't describe the structure of the
                      > data being manipulated), but it is data about where entity manipulation
                      > being read came from. It's not part of d20, it's not part of Hero, but
                      > it can reasonably be used by both.

                      So the namespaces aer going to be more use for the "high level" xml, where
                      we can have data from Hero or D20. But when we have homogenised down to
                      the low level impolimentation XML they will not have as much relevance
                      because we will be useing the same set of rules and meta data for
                      everything so we will always be using the same elements.

                      >> I did not see the point in having a 'key.ability' attribute as the stat
                      >> bonus is explicitly encoded in the effects of the progression.
                      >
                      > We still present it, don't we? While functionally you are correct, I
                      > think there are expectations that it be easily presented.

                      Okay, I see where you are coming from on this one and you are quite
                      correct, we need to hold that data in such a way that it can be presented
                      to the user in the interface.

                      >> I added the <type>Dexterity</type> so that the progression can be
                      >> searched and indexed. If all entities (and progressions) have a series
                      >> of types that describe them then we can search for all entities that
                      >> have type 'FEAT' and type 'FIGHTER', or type 'SKILL' and type
                      >> 'Dexterity'. If we have half of this information in object specific
                      >> attributes then this becomes more difficult.
                      >
                      > I was really hoping to get away from TYPE, but even so this is a better
                      > representation than the current concatenated string... and it might not
                      > be visible in data since this is an internal representation.

                      I think we need something like a <type> tag, otherwise the only thing we
                      will have to differentiate a Feat <entity> from an Item <entity> will be
                      the fact that one has an ID that starts with "feat." and the other has an
                      ID that starts with "item.".

                      I think of them as a secondary index field in RDBMS terms. Something that
                      provides useful information about the record, but also allows index
                      searching.

                      > That's not a bonus, though, that's a calculation. If it were to be done
                      > that way, I'd rather see something like
                      >
                      > <variable key='stat.dex' />
                      > <function key='stat.dex.mod' calc='floor($stat.dex/2)-5' />

                      My only issue with calling the operation that gives a value to a variable
                      a function is that in a lot of cases there will be an arbitrary number of
                      functions that apply to the variable and they may or may not stack or
                      replace other functions.

                      As an example you have the following:

                      <variable key="armour_class"/>
                      <variable key="armour_class.armour"/>
                      <variable key="armour_class.stat"/>
                      <variable key="armour_class.deflection"/>
                      <function key="armour_class" calc="$armour_class.armour +
                      armour_class.stat + armour_class.deflection"/>

                      To give a standard Armour class of armour worn + dex_mod + deflection
                      bonus. Howver then the GM creates an item that give an "artifact bonus" to
                      armour class:

                      <variable key="armour_class.artifact"/>
                      <function key="armour_class" calc="$armour_class.artifact" stacks="true"/>

                      So that we can add an extra value on top of the existing value without
                      needing to know about all of the other calculations on the variable.

                      basically we have created a <variable> tag instead of implicitly creating
                      any variable mentioned and renamed <variable-bonus> to <function>. I must
                      confess that I have not been declaring variables in my examples, I really
                      should have been for clarity.

                      I have no problem with this. In some ways it is more descriptive.

                      >> > Hmm... no, you're more or less doing that... but it looks like you
                      >> need
                      >> > to be able to process the effects in arbitrary order.
                      >>
                      >> I am working on the assumption that the client can either set up
                      >> dependencies on the variables and calculate them in order, or the client
                      >> can set up a notification system such that variable 'a' is notified when
                      >> variable 'b' is changed.
                      >
                      > That can be done.

                      The couple of prototype code examples that Steve and I were kicking around
                      at the end of last year did exactly that.

                      >> I had originally thought about putting the stat modifiers in the first
                      >> rank for skills that were not useable untrained and in 'all' for
                      >> untrained skills. After I sent it out I realised that 'all' was a
                      >> really stupid place to put it, and it should go in the top level
                      >> <effects> rather than under a rank so that if you have 0 ranks you
                      >> still get the bonus...
                      >
                      > I'd figured <effects> would only happen when it got applied. Untrained
                      > would never see it anyway.

                      I guess that I was expecting to be able to apply 0 ranks of a progession
                      to a character.

                      So the client could look for all skill entities with the "allow_untrained"
                      attribute and add them to the character with 0 ranks when the character is
                      created

                      >> I am now undecided as to wether all the stat bonuses should go under
                      >> the top level <effects>, or if the untraned=no skills should have
                      >> their stat bonus under rank 1...
                      >
                      > Mmm... I can see why you're doing this for skills -- in order to present
                      > a character's total bonus to the roll for each skill you need to know
                      > about both the character and every skill you want the roll bonus for.
                      > It seems to depart from the normal model, though; feats don't have
                      > effect unless they're applied to the character, classes don't have
                      > effect unless they're applied to the character, etc. Making skills
                      > behave differently here adds complication, I think, that isn't quite
                      > needed.

                      I think we can handle this if we allow a progression to be applied to a
                      character with 0 ranks.

                      > Best watch this; characters in my design are not particularly 'special';
                      > the same mechanisms are used for other entities (such as equipment and
                      > whatnot -- adding an equipmod to a sword is much the same as adding a
                      > feat to a character).
                      >
                      > If you'll be prefixing the item ID to the variable modified, you'll need
                      > to parse it out at some point to determine the values. However, I have
                      > an idea.
                      >
                      > <variable-mod target='self' key='varname' value='n' />
                      >
                      > Hmm... actually, that doesn't make a lot of sense -- why would something
                      > need to modify itself? Most modifications would implicitly be to what
                      > the item is applied to... so.
                      >
                      > <variable key='varname' value='n' />
                      >
                      > defines the field (in concrete terms that'd be <cost> or <critmult> or
                      > whatever)
                      >
                      > <variable-mod key='varname' value='formula' />
                      >
                      > would describe (in part) what happens when you apply the modifier to the
                      > receiving entity:
                      >
                      > <equipmod id='eqmod.masterwork'>
                      > <variable-mod key='toHit' value='+1' />
                      > </equipmod>
                      >
                      > should (in theory) increase the toHit value of the item of equipment it
                      > is applied to... though in this case it should probably be treated as a
                      > bonus rather than a modifier.
                      >
                      > Oh, right -- we probably need to be able to piggyback effects, too.
                      > Adding one entity to another might modify the recipient so it passes an
                      > effect on to what *it* is applied to.

                      So we have a character entity that has a "masterwork dagger" entity that
                      has a "eqmod.masterwork" entity that gives a +1 to toHit

                      <entity id="character">
                      <add-entity idref="item.dagger-masterwork"/>
                      <entities>
                      <variable key="melee_attack"/>
                      </entities>
                      <effects>
                      <!-- give the character a +9 attack from somewhere
                      exactly where is not relevent for this
                      example -->
                      <function key="melee_attack" calc="9"/>
                      </effects>
                      </entity>

                      <entity id="item.dagger-masterwork">
                      <add-entity idref="eqmod.masterwork"/>
                      </entity>

                      <entity id="eqmod.masterwork" >
                      <effects>
                      <function key="toHit_bonus" calc="1" />
                      </effects>
                      </entity>

                      The <function> on the eqmod entity applies the effects to the entity it is
                      applied to (the item entity). So now we have an 'item.dagger-masterwork'
                      with a variable of 'toHit_bonus' that has a function that will return '1'.

                      So how do we go about determining that the attack bonus for the
                      dagger-masterwork is +10 (9+1):

                      <entity id="item.dagger-masterwork">
                      <add-entity idref="eqmod.masterwork"/>
                      <effects>
                      <function key="toHit_melee" calc="$melee_attack + toHit_bonus"/>
                      </effects>
                      </entity>

                      I am sure that we can come up with some better variable names than I have
                      used.

                      So as the item.dagger-masterwork entity needs to ask the parent entity for
                      any variables it does not know (in this case $melee_attack). Do we need to
                      ask the parent for all variables, or just the one we do not know ?

                      How will variables propogate? In the example of a weapon we do not want
                      the character to be affected by the toHit=+1 that the item has, but for
                      bracers of armour we want the armour bonus to affect the character... Do
                      we need a 'propogate="true|false"' attribute of function. If the entitiy
                      is asked for the functions that can affect a variable we only return the
                      ones that have propogate="true". The ones that have propogate="false" are
                      only used for calculations internally for that entity.



                      The other alternative would be for the client to ask "what is the
                      melee_attack for this character entity using this item entity" at which
                      point we need to have the character return a list of propogate="true"
                      functions that affect "toHit" from all child entities (recursively), plus
                      the list of functions that affect "toHit" from the specific item we are
                      interested in that have the 'propogate="false"' attribute.



                      the difference is that in the first case the item is being asked for a
                      variable and has to interrogate its parent entity, and in the second the
                      top level is being asked for the variable and is specifically asked for
                      the internal functions of a specific subentity that the client is
                      interested in.


                      >> If you wanted to give a feat that increased the damage dice to a d6
                      >> rather than a d4 you would apply this to the character:
                      >>
                      >> <variable-bonus targetid="item.dagger.damage.die-size" value="2"
                      >> stacks="true"/>
                      >>
                      >> or
                      >>
                      >> <variable-bonus targetid="item.dagger.damage.die-size" value="6"
                      >> stacks="false"/>
                      >
                      > how would you increase the damage of a particular dagger, though?
                      > Create a new 'sharper dagger' entity?

                      In this scenario you would indeed have to create a new item.dagger_sharper
                      entity. But then again if you apply an eqmod to an item you have created a
                      new item.

                      I consider entities to be immutable. If you add a subentity to an entity
                      you affect all instances of that entity. If you want to add a subentity to
                      only 1 instance of an entity then you copy the entity and give it a new ID
                      and apply the subentity to the copy.

                      > I like the use of the steel equipmod, though; this is much better than
                      > 'TYPE: STEEL'.

                      That is the way that the current LST data sets do it. In the Steel eqmod
                      it adds the TYPE:STEEL. They do it this way so that Admantine eqmod can
                      "REPLACE:STEEL", i.e. any item with the steel eqmod (and hence steel type)
                      will have the steel eqmod removed when the admantine eqmod is applied.

                      > How's this: change your targetid attribute to 'key' [which is safer
                      > anyway; ID should be unique in the system, which means that only a
                      > single character is being modeled (targetid *is* unique) or it isn't
                      > (and targetid is lying about this implication]. Give the variable-mod
                      > (or any other effect) an implicit target of 'the recipient'; this can be
                      > overridden (target='self') for those cases where you want it to be able
                      > to apply something (variable modification, equipment modification, etc.)
                      > to itself instead. So
                      >
                      > <entity id='item.dagger'>
                      > <!-- name, variable identification and initialization , etc. -->
                      > <add-entity target='self' refid='eqmod.steel' />
                      > </entity>
                      >
                      > Or for a truly nifty item:
                      >
                      > <entity id='item.dagger.steelbody'>
                      > <!-- name, variable identification and initialization , etc. -->
                      > <add-entity refid='eqmod.steel' />
                      > <!-- turns wielder into steel, oops... -->
                      > </entity>

                      That works.

                      Variable functions can either propogate or not, and entities can be
                      applied to the containing entity, or the top level entity.

                      So the target attribute has 2 options "self", or "top_level" where "self"
                      is the default (we are more likely to want to apply a subentity to the
                      current entity than the top level one, and this just makes it a bit more
                      explicit).

                      >> I am 'implicit-phobic' I have been bitten by implitic too many times to
                      >> trust it (or anyone else implimentation of it) saying that I missed out
                      >> the 'operator="="' attribute ;O)
                      >
                      > I'm not generally fond of implicit behavior... though in this case I see
                      > it as something of an 'explicit implicit' -- it's part of the defined
                      > behavior. Still, it doesn't *hurt* to say <prereq kind='mult'>, either.

                      Given that this is most likely going to be auto generated from the top
                      level XML I have not problem with demanding a fully explicit syntax.

                      >> the one thing I have not figured out how to do is replace the
                      >> progression
                      >> with a completely different one. Some of the complex monk classes/feats
                      >> allow you to "use one size larger for unarmed damage", "use 1 size
                      >> smaller
                      >> for damage", "use this other progression for unarmed damage".
                      >
                      > Hmm... this is one of those 'it's easy to design it this way from the
                      > front' sort of deals, where we make the association *between* the
                      > character and the class -- in RDBMS terms, something like
                      >
                      > Character
                      > |
                      > ^
                      > CharClass (this contains things like 'effective monk damage size', ick)
                      > v
                      > |
                      > Class
                      >
                      > But I'm not happy with *that*, either.
                      >
                      > It's a damn shame that the monk progressions aren't *quite* size bumps
                      > (at /n/ level you are treated as /x/ sizes larger than normal)...
                      > they're *close* in RSRD, IIRC, but not *quite* right. Dammit.

                      If we have a default progression referenced from the monk class
                      "monk.udam", could we do something like this:

                      Have a new progression "monk.udam.other" and then we have 3 possibilites:

                      1 - Replace the default progression. This is bad because we have then
                      changed the progression for _all_ monks

                      2 - Have some sort of <replaces old="monk.udam" new="monk.udam.other"> tag
                      such that whenever a value is to be looked up from the "monk.udam"
                      progression it is actually looked up in the "monk.udam.other" progression.

                      3 - Have the new progression use the replace="true" flag on all variables
                      and have some mechanism to ensure that you have the same number of ranks
                      in monk.udam.other as in monk.udam <add-rank key="monk.udam.other"
                      ranks="ranks(monk.udam)"/>

                      1 is right out, but what do people think about 2 and 3? They both have
                      their pros and cons.


                      --
                      regards,
                      Frugal
                      -OS Chimp
                    • Frugal
                      ... Once again Frugal s bad examples strike uncertanty in to the hearts of all who look upon them ;O) I had worked it out in my head
                      Message 10 of 12 , Apr 7, 2004
                      • 0 Attachment
                        <quote who="Keith Davies">
                        > On Tue, Apr 06, 2004 at 12:34:40PM +0100, Frugal wrote:
                        >> <quote who="Steven Bethard">
                        >> The assumption is that with <add-rank type="class"/> the client will
                        >> look
                        >> for all progressions with a <type>class</type> child element and ask the
                        >> user to choose one. Likewise <add-entity type="feat" /> will look for
                        >> all
                        >> entitiess with a <type>feat</type>.
                        >>
                        >> I imagine that <add-entity type="feat,fighter"/> will look for all
                        >> entities with a type of 'feat' && a type of 'fighter'.
                        >>
                        >> I guess we do need some way to add more than one entity at a time.
                        >>
                        >> <add-entity type="feat,weapon-prof,martial" count="all"/>
                        >>
                        >> to add all entities that have the 'feat', 'weapon-prof' and 'martial'
                        >> types.
                        >
                        > If you're saying what I think you are here, I suspect it's backward --
                        > feats grant proficiency, but they're not the *only* thing that grants
                        > proficiency.

                        Once again Frugal's bad examples strike uncertanty in to the hearts of all
                        who look upon them ;O)

                        I had worked it out in my head that each weapon proficiency was a feat.
                        You are right, each weapon proficiency is an entity. A feat entity may add
                        one or more weapon prof entities, but class progressions, items etc can
                        all add the weapon prof entity as well.

                        >> <add-entity type="feat,meta-magic" count="2"/>
                        >>
                        >> To add any 2 meta-magic feats.
                        >
                        > I think we need to specify some sort of query syntax to deal with this
                        > sort of thing... you're working around the edges of one, but we should
                        > do something more explicit. 'sides, I'll need it for extracting
                        > entities from the system to be written to file.

                        I keep veering toward and then away from XPath...

                        >> All of the prerequisites will need to be done in code, even the variable
                        >> ones.
                        >
                        > Described in data, tested in code, you mean?

                        Correct.

                        --
                        regards,
                        Frugal
                        -OS Chimp
                      • andargor
                        ... this ... should ... variable ... I ve been lurking for a few days, I find the discussion interesting. I m continuing to experiment with my own approach.
                        Message 11 of 12 , Apr 7, 2004
                        • 0 Attachment
                          --- In pcgen-xml@yahoogroups.com, "Frugal" <frugal@p...> wrote:
                          >
                          > > I think we need to specify some sort of query syntax to deal with
                          this
                          > > sort of thing... you're working around the edges of one, but we
                          should
                          > > do something more explicit. 'sides, I'll need it for extracting
                          > > entities from the system to be written to file.
                          >
                          > I keep veering toward and then away from XPath...
                          >
                          > >> All of the prerequisites will need to be done in code, even the
                          variable
                          > >> ones.
                          > >
                          > > Described in data, tested in code, you mean?
                          >
                          > Correct.
                          >
                          > --
                          > regards,
                          > Frugal
                          > -OS Chimp

                          I've been lurking for a few days, I find the discussion interesting.
                          I'm continuing to experiment with my own approach. BTW, I do use
                          XPath a lot. It's slow in itself, but useful to hash XML data by
                          attributes for example.

                          As for the XML format aspect, it really doesn't matter what the
                          format is. A high-level XML file can easily be XSLT'd down to a low
                          level one.

                          I personally don't like mapping XML to engine-specific objects, but
                          if the XML can be transformed and reused in another engine, I really
                          don't care much.

                          To give you a sense of where I am right now with my own attempt:

                          - XML is of a very high level, similar to Doug's XML proposal in
                          PCGen main (I actually stole it for testing)
                          - Each XML tree is loaded and wrapped into a Javascript object. (ie.:
                          <skill>...</skill> becomes skill.xxx)
                          - I use only one attribute: "id". I hash it against the XML tree
                          (e.g.: skill["Diplomacy"].key_stat)
                          - I have a few API routines to the engine to load XML, print out
                          debugging info, copy/append/delete nodes (reflected in JS objects)
                          - A new PC is a copy of an XML tree template for a character
                          - Skills, feats, levels, etc. are added using object templates. I
                          copy the template and append it to the character
                          - All "common" d20 functions (e.g. calculating ability mods) are in a
                          common d20 JS library (pre-compiled on load, bytecode executed)
                          - I use Javascript code snippets for behavior for custom objects. E.g:

                          <feat id="Alertness">
                          <name>Alertness</name>
                          <method id="OnAdd">
                          <name>OnAdd</name>
                          <file>rsrd/alertness.js</file>
                          </method>
                          <method id="OnRemove">
                          <name>OnAdd</name>
                          <file>rsrd/alertness.js</file>
                          </method>
                          <method id="OnCheck">
                          <name>OnAdd</name>
                          <file>rsrd/alertness.js</file>
                          </method>
                          <method id="OnCalculate">
                          <name>OnAdd</name>
                          <file>rsrd/alertness.js</file>
                          </method>

                          </feat>

                          (it could have different files for each method, or a script directly
                          in this data using <script>)

                          In alertness.js:

                          OnAdd(oPC) { ... }
                          OnRemove(oPC) { ... }
                          OnCheck(oPC) { ... }
                          OnCalculate(oPC) {
                          applyBonus(oPC.skill["Search"].value,2,STACK);
                          applyBonus(oPC.skill["Spot"].value,2,STACK);
                          }

                          The applyBonus function in in the main JS library outside the engine.

                          It's fairly fast, as I compile JS on load and then only chain the
                          compiled functions and execute them.

                          Anyway, just giving you a heads up on what I'm doing.

                          Andargor
                        • (no author)
                          ... Hmmmm... I wonder how we can do things like Weapon Focus like this (I am ignoring for the moment the choice side of Wepon Focus and
                          Message 12 of 12 , Apr 7, 2004
                          • 0 Attachment
                            <quote who="Frugal">
                            > So as the item.dagger-masterwork entity needs to ask the parent entity for
                            > any variables it does not know (in this case $melee_attack). Do we need to
                            > ask the parent for all variables, or just the one we do not know ?
                            >
                            > How will variables propogate? In the example of a weapon we do not want
                            > the character to be affected by the toHit=+1 that the item has, but for
                            > bracers of armour we want the armour bonus to affect the character... Do
                            > we need a 'propogate="true|false"' attribute of function. If the entitiy
                            > is asked for the functions that can affect a variable we only return the
                            > ones that have propogate="true". The ones that have propogate="false" are
                            > only used for calculations internally for that entity.
                            >
                            > The other alternative would be for the client to ask "what is the
                            > melee_attack for this character entity using this item entity" at which
                            > point we need to have the character return a list of propogate="true"
                            > functions that affect "toHit" from all child entities (recursively), plus
                            > the list of functions that affect "toHit" from the specific item we are
                            > interested in that have the 'propogate="false"' attribute.
                            >
                            >
                            >
                            > the difference is that in the first case the item is being asked for a
                            > variable and has to interrogate its parent entity, and in the second the
                            > top level is being asked for the variable and is specifically asked for
                            > the internal functions of a specific subentity that the client is
                            > interested in.

                            Hmmmm... I wonder how we can do things like Weapon Focus like this (I am
                            ignoring for the moment the choice side of Wepon Focus and concentrate on
                            the +1 to a certain type of weapon issue).

                            Weapon Focus gives the character a +1 untyped bonus to hit with a specific
                            weapon type eg. dagger.

                            The current LST syntax gives:

                            CHOOSE:WEAPONPROFS|SpellCaster.Ray|ADD.Grapple|LIST
                            BONUS:WEAPONPROF=%LIST|TOHIT|1

                            And then in the code to determine what the total to-hit bonus for a dagger
                            is the code gets the to-hit from the dagger, and then add a whole bunch of
                            modifiers one of which is WEAPONPROF=DAGGER|TOHIT|1

                            Is this acceptable for us? Do we want to say
                            - get the variable from the item.
                            - For each type in the item get any bonuses from the character for that item

                            i.e. we get the varible 'toHit' from the item.dagger. Then get all of the
                            bonuses from the character for each <type> the particular item has :
                            toHit.dagger
                            toHit.melee
                            toHit.simple
                            toHit.martial
                            toHit.steel
                            etc.

                            This should also allow us to do something like create a feat "Sharp Blade"
                            that gives the character 2d4 with a dagger rather than 1d4:

                            <entity id="feat.sharp_blade">
                            <effects>
                            <function key="die_count.dagger" calc="2" replaces="true"/>
                            </effects>
                            </entity>

                            So when we ask for the die count for a particular dagger we will get:

                            <variable key="die_count" value="1" />

                            From the dagger item and

                            <function key="die_count.dagger" calc="2" replaces="true" />

                            From the character (and its sub entities) due to that fact that the item
                            has the "dagger" type and so we know to search for functions that look
                            like "die_count.dagger".

                            Yey! Something we can not do in the existing system ;O)

                            --
                            regards,
                            Frugal
                            -OS Chimp
                          Your message has been successfully submitted and would be delivered to recipients shortly.