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

Re: [pcgen-xml] Re:

Expand Messages
  • Keith Davies
    ... With the feat. This minimizes the changes needed when adding a new feat that adjusts a skill -- such as Blooded from the FRCS (+2 Initiative, +2 Spot
    Message 1 of 35 , May 6 1:25 PM
    • 0 Attachment
      On Mon, May 06, 2002 at 05:11:03PM -0000, dajacques wrote:
      > --- In pcgen-xml@y..., "Scott Boland" <sboland@t...> wrote:
      > >
      > > I'd suggest that each element of a character add it's own contributions
      > > without storing the total results.
      > >
      >
      > This is another problem that I've been grappling with: do you put the
      > modifiers with the trait that is doing the modifying or do you put the
      > modifier with the trait that is being modified?
      >
      > For example, should the +2 Listen bonus from the Alertness feat be
      > noted with Alertness or with Listen?

      With the feat. This minimizes the changes needed when adding a new feat
      that adjusts a skill -- such as "Blooded" from the FRCS (+2 Initiative,
      +2 Spot IIRC) doesn't require that we change the skill description,
      minimizing impact. It also means we don't need to worry about having
      bogus references (the Alertness skill pointing to a non-existent feat)
      when a file isn't loaded (I might have Spot but not Blooded, but I'm
      unlikely to have Blooded but not Spot). So,


      <feat id="feat.alertness">
      <!-- <prereqs> don't apply to this one -->
      <effect>
      <skill-bonus skill-id="skill.listen" bonus="+2"/>
      <skill-bonus skill-id="skill.spot" bonus="+2"/>
      </effect>
      </feat>

      >
      > There has to be some part of the data model that says having the
      > Alertness feat gives you a +2 bonus on Listen skill checks. This is
      > what I would call an effect. The Alertness feat has a set of effects
      > on its possessor. This effect, and any other effect, could easily
      > be stored with the Alertness feat like the previous post suggested..
      >
      > <feat>
      > <add id="phb.skill.listen" value="2"/>
      > </feat>
      >
      > I like this setup, but I don't like including it as part of the
      > character. I would rather see all of these effects drawn off into
      > different schemas for these different portions of the SRD. They turn
      > into a rules database that is used when creating or modifying a
      > character, but are not necessary for any particular instance of a
      > character because all of the effects have been taken into account by
      > enhancing the character with the effect.

      Each skill, feat, etc. will have its own description. This description
      will not be embedded in <character>. The <character> will have entries
      that point to it (under my current schema, it tracks the points/ranks
      allocated to the skill at each level, in order to make it possible to
      roll back). So,

      <skill id="skill.listen">
      <name>Listen</name>
      </skill>

      <skill id="skill.spot">
      <name>Spot</name>
      </skill>

      <feat id="feat.alertness">
      <name>Alertness</name>
      <effect>
      <skill-bonus skill-id="skill.listen" bonus="+2"/>
      <skill-bonus skill-id="skill.spot" bonus="+2"/>
      </effect>
      </feat>

      <feat id="feat.skill-focus" multiple="yes" stackable="no">
      <name>Skill Focus</name>
      <effect>
      <skill-bonus choose="skill-list.any" bonus="+3"/>
      </effect>
      </feat>

      <character id="character.shade">
      <name>Shade</name>
      <race race-id="race.human">
      <feat feat-id="feat.skill-focus" subfeat-id="skill.spot"/>
      </race>
      <stats>
      <stat stat-id="stat.str" value="14"/>
      <stat stat-id="stat.dex" value="18"/>
      <stat stat-id="stat.con" value="13"/>
      <stat stat-id="stat.int" value="11"/>
      <stat stat-id="stat.wis" value="15"/>
      <stat stat-id="stat.cha" value="8"/>
      </stats>
      <levels>
      <level level="1" class-id="class.ranger">
      <skill skill-id="skill.listen" ranks="4"/>
      <skill skill-id="skill.spot" ranks="4"/>
      <feat feat-id="feat.alertness"/>
      </level>
      </levels>
      </character>


      Will produce a first-level ranger with Listen and Spot scores of +8 and
      +11.

      I'm not entirely happy with the choose syntax for skill focus. It'll
      work, but will require that either all skills get added to a list (which
      would get really old, fast) or there are pseudo-lists that contain all
      elements of a particular type (which isn't that bad, actually, and could
      be useful).

      Right now 'choose' is used to indicate a selection made by the user from
      a constrained list (such as the feats a fighter or wizard may take as
      bonus feats); that works just fine and I'm satisfied with it. It's when
      anything of a particular type may be chosen that I'm not... although the
      pseudo-lists aren't necessarily a bad solution. Suggestions or
      comments?

      > I do not know what shape this rules database would take. It might be
      > possible to accomplish this with a set of schemas and transformations.
      >
      > An additional benefit of this method is that it reduces the amount of
      > replicated XML immensely. I understand that XML can be rather bulky
      > and the validating parser would ensure that all the duplicate XML is
      > still valid. I may be short-sighted for being averse to voluminous
      > schema and instance documents.

      Nope, one of the goals of this project is to devise a normalized data
      model -- each piece of information should only be presented once, partly
      to reduce the amount data loaded, but mostly to prevent ambiguities
      between definitions. Something defined once may be incorrect, but it
      won't be ambiguous.

      Once we've got the normalized forms produced, it's relatively easy and
      straight-forward to build the denormalized forms (such as output for
      character sheets, OpenRPG, etc).

      > Perhaps my view is less useful to pcgen because I haven't focused on
      > character creation. I thought this was outside the bounds of the d20
      > licensing.

      eh? I'm not sure I understand.

      > > I think there should be some kind of recursive effect where each layer of a
      > > character description can add maximums, penalties, or bonuses to
      > > stats/skills/feats/etc. Determining the actual current value would then be
      > > a matter of walking the tree. A side benefit would be making it possible to
      > > easily display just how the current value is arrived at. For overriding
      > > elements of a template, we could assign priorities as well. So the the hit
      > > dice of a rogue is d6 by default, but some unusual race could use a higher
      > > priority to change this to d8 or d4. A template with an even higher
      > > priority could then change it yet again. Make sense?
      >
      > I continue to be torn on the issue because I see some value in what
      > you present and representing a character as a unit made of distinct,
      > and interchangeable, building blocks holds some appeal. I would still
      > think you could accomplish this using a rules based approach, even if
      > the lines around those building blocks become less clear from a visual
      > perspective.

      I like the priorities idea, although I haven't decided how to bolt it on
      yet; I'll leave it for later.

      The data as stored by PCGen will maintain normalization and separation.
      It is not possible to guess the 'optimal denormalized form' of the data
      at this point, so I won't try. To be honest, I'm not a whole bunch
      happy with denormalizing data unless it's necessary, so I'll leave it to
      those that use the data to decide how they want to do it. It'll be easy
      to denormalize, but normalizing denormalized ('abnormal'?) data is
      harder. Let's make it easy for people who want to use the data later.

      > > Also, I see a need to make a lot of the xml elements more generic. For
      > > example, descriptions are needed by characters, items, classes, feats, etc
      > > etc. It would make sense to create a generic description element that is
      > > used as a sub element of all the different objects without having a
      > > different element used in each one.
      > >
      > > Common elements I can see: descriptions, modifiers, identifiers,
      > > tables/charts, file links .. Maybe some others.
      >
      > I agree with this, but I think it can be difficult to achieve. Modifier
      > is one that I immediately ran into. From a schema perspective, you use
      > Types for validation, so a Skill Modifier is different than an Ability
      > Modifier because they are legal in different places in the instance.
      > They could be derived from the same type. The Skill Modifier needs to
      > identify what skill is modified, and the value of that skill is limited
      > to the set of skills available, so the Skill Modifier needs to be Type'd.
      > If you encapsulate generic Modifiers into other Type'd containers for
      > validation it starts to get ugly. I could be missing something though.

      It depends at least in part on context. I want to make it possible for
      any effect to appear at (almost) any time -- if something can provide
      any kind of bonus (or penalty), it can provide *any* bonus or penalty.
      I don't mind having templates granting feats, or feats granting skills,
      weapons granting feats or skill boni, or templates, or anything. I want
      this part as flexible as possible.

      That said, I think certain items may have sections limiting what they
      grant the boni *to*. For instance, a <weapon> may have <bonus> section,
      and a <wielder-bonus> section -- the first affects the weapon itself,
      the second the wielder. This would make it possible to have a sword
      with +10 skill bonus to Spellcraft that gives a +5 skill bonus to the
      wielder.

      Doesn't make sense for a sword to give a bonus to Spellcraft? Don't
      care. Not my problem... and it will become my problem if I don't allow
      it. So, it's allowed.


      Keith
      --
      Keith Davies
      kjdavies@...

      DM : You search the storeroom and find a barrel marked 'elf pudding'.
      Random: Elven pudding! Wonderful stuff. Gimme!
      Dolarn: We're in a goblin lair and it says 'elf pudding'. I wouldn't.
      Random: What?! You mean... <hyuuuurfff>
    • rvanwees
      ... contributions ... the modifiers with the trait that is doing the modifying or do you put the modifier with the trait that is being modified? ... noted with
      Message 35 of 35 , May 23 3:27 PM
      • 0 Attachment
        --- In pcgen-xml@y..., "dajacques" <dajacques@y...> wrote:
        > --- In pcgen-xml@y..., "Scott Boland" <sboland@t...> wrote:
        > >
        > > I'd suggest that each element of a character add it's own
        contributions
        > > without storing the total results.
        > >
        >
        > This is another problem that I've been grappling with: do you put
        the modifiers with the trait that is doing the modifying or do you
        put the modifier with the trait that is being modified?
        >
        > For example, should the +2 Listen bonus from the Alertness feat be
        noted with Alertness or with Listen?
        >
        > There has to be some part of the data model that says having the
        Alertness feat gives you a +2 bonus on Listen skill checks. This is
        what I would call an effect. The Alertness feat has a set of effects
        on its possessor. This effect, and any other effect, could easily be
        stored with the Alertness feat like the previous post suggested..
        >
        > <feat>
        > <add id="phb.skill.listen" value="2"/>
        > </feat>
        >
        > I like this setup, but I don't like including it as part of the
        character. I would rather see all of these effects drawn off into
        different schemas for these different portions of the SRD. They turn
        into a rules database that is used when creating or modifying a
        character, but are not necessary for any particular instance of a
        character because all of the effects have been taken into account by
        enhancing the character with the effect.
        >
        > I do not know what shape this rules database would take. It might
        be possible to accomplish this with a set of schemas and
        transformations.
        >
        > An additional benefit of this method is that it reduces the amount
        of replicated XML immensely. I understand that XML can be rather
        bulky and the validating parser would ensure that all the duplicate
        XML is still valid. I may be short-sighted for being averse to
        voluminous schema and instance documents.
        >
        > Perhaps my view is less useful to pcgen because I haven't focused
        on character creation. I thought this was outside the bounds of the
        d20 licensing.
        >
        > >
        > > I think there should be some kind of recursive effect where each
        layer of a
        > > character description can add maximums, penalties, or bonuses to
        > > stats/skills/feats/etc. Determining the actual current value
        would then be
        > > a matter of walking the tree. A side benefit would be making it
        possible to
        > > easily display just how the current value is arrived at. For
        overriding
        > > elements of a template, we could assign priorities as well. So
        the the hit
        > > dice of a rogue is d6 by default, but some unusual race could use
        a higher
        > > priority to change this to d8 or d4. A template with an even
        higher
        > > priority could then change it yet again. Make sense?
        > >
        >
        > I continue to be torn on the issue because I see some value in what
        you present and representing a character as a unit made of distinct,
        and interchangeable, building blocks holds some appeal. I would
        still think you could accomplish this using a rules based approach,
        even if the lines around those building blocks become less clear from
        a visual perspective.
        >
        > >
        > > Also, I see a need to make a lot of the xml elements more
        generic. For
        > > example, descriptions are needed by characters, items, classes,
        feats, etc
        > > etc. It would make sense to create a generic description element
        that is
        > > used as a sub element of all the different objects without having
        a
        > > different element used in each one.
        > >
        > > Common elements I can see: descriptions, modifiers, identifiers,
        > > tables/charts, file links .. Maybe some others.
        >
        > I agree with this, but I think it can be difficult to achieve.
        Modifier is one that I immediately ran into. From a schema
        perspective, you use Types for validation, so a Skill Modifier is
        different than an Ability Modifier because they are legal in
        different places in the instance. They could be derived from the
        same type. The Skill Modifier needs to identify what skill is
        modified, and the value of that skill is limited to the set of skills
        available, so the Skill Modifier needs to be Type'd. If you
        encapsulate generic Modifiers into other Type'd containers for
        validation it starts to get ugly. I could be missing something
        though.
        >
        > >
        > > Comments?
        > >
        > > -- Scott B

        Having gone through this thread, It seems to me that the format Keith
        proposed is a combination of status and action logging (where action
        is represented by (for instance) each <level> element and status
        being the computational result of parsing all <level> elements).

        This may not cause problems if you use a SAX parser, as you would
        have to parse them all, but it will be a lengthy process each time
        you load a character from file.
        If this format is proposed only for allowing to 'de-level' a
        character, should we not try and separate status and actions? That
        would a) make the xml more legible, b) will allow for easier XML
        transformation (i.e. character sheets), c) will seriously ease
        character parser coding efforts.

        On rules: I think this would be good way to go. I started my own
        project at the 'character set-up and modification' end, using a rule
        engine and character XML. Below is a sample of the rule format I use.

        <d20rule ID="DND3-01" name="Dwarf Racial modifiers" type="execute"
        ruleset="DND3" version="2.0" group="race" group_priority="1"
        priority="1" note="Notes go here">
        <conditions>
        <condition element="appearance" attribute="race"
        value="Dwarf" eval=""/>
        </conditions>
        <actions>
        <action type="set" element="con" attribute="bonus"
        value="" eval="d.find('con', 'bonus') + 2"/>
        <action type="set" element="cha" attribute="bonus"
        value="" eval="d.find('cha', 'bonus') - 2"/>
        <action type="set" element="appearance"
        attribute="size" value="Medium" eval=""/>
        <action type="set" element="speed" attribute="base"
        value="20" eval=""/>
        <action type="add"
        element="abilities|special_ability" attribute="name"
        value="Darkvision" eval=""/>
        <action type="add"
        element="abilities|special_ability" attribute="name"
        value="Stonecunning" eval=""/>
        <action type="set" element="languages"
        attribute="automatic" value="Common and Dwarven" eval=""/>
        <action type="set" element="languages"
        attribute="bonus" value="Giant, Gnome, Goblin, Orc, Terran and
        Undercommon" eval=""/>
        <action type="set" element="classes"
        attribute="favored_class" value="Fighter" eval=""/>
        </actions>
        <reverse>
        <action type="set" element="con" attribute="bonus"
        value="" eval="d.find('con', 'bonus') - 2"/>
        <action type="set" element="cha" attribute="bonus"
        value="" eval="d.find('cha', 'bonus') + 2"/>
        <action type="remove element"
        element="special_ability" attribute="name" value="Darkvision"
        eval=""/>
        <action type="remove element"
        element="special_ability" attribute="name" value="Stonecunning"
        eval=""/>
        <action type="set" element="languages"
        attribute="automatic" value="''" eval=""/>
        <action type="set" element="languages"
        attribute="bonus" value="''" eval=""/>
        <action type="set" element="classes"
        attribute="favored_class" value="''" eval=""/>
        </reverse>
        </d20rule>

        (man, does this look horrible in message preview :-( )

        The setup is specific to the engine I built, and it relies on the
        Jython parser for the 'eval' attributes. However, it allows me to
        make any change at any moment, and the engine will do the
        corresponding calculations for me. I use the same rule format for
        classes, skills and feats. It allows for adding|deleting|updating any
        element or attribute in the XML.

        I can't extrapolate on d20 licensing issues using rules, as one
        would 'merely' be applying the rules provided in the SRD inside
        application code, not 'telling people how to build a character'.
        Wiser men than me would have to answer this one.

        Rob.
      Your message has been successfully submitted and would be delivered to recipients shortly.