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

RE: [pcgen-xml] Examples

Expand Messages
  • Steven Bethard
    ... My preference is to have one XML standard that looks something like what Frugal s presented. This standard should be as
    Message 1 of 12 , Apr 6 9:36 AM
    • 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 2 of 12 , Apr 7 2:56 AM
      • 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 3 of 12 , Apr 7 3:02 AM
        • 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 4 of 12 , Apr 7 6:27 AM
          • 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 5 of 12 , Apr 7 8:07 AM
            • 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.