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

Re: [pcgen-xml] Re:

Expand Messages
  • Keith Davies
    ... I think many of the points you ve mentioned in your post are being addressed -- hopefully reasonably and correctly -- in the work I ve been doing. I think
    Message 1 of 35 , May 6, 2002
    • 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?

      I think many of the points you've mentioned in your post are being
      addressed -- hopefully reasonably and correctly -- in the work I've been
      doing.

      I think it'd take more time than I have right now to respond intelligently
      and with specific examples, but I'll try to do it tonight, or if I hit a
      slow spot at work today.


      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, 2002
      • 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.