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

Re: Examples

Expand Messages
  • 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 1 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
      > > sort of thing... you're working around the edges of one, but we
      > > 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
      > >> 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">
      <method id="OnAdd">
      <method id="OnRemove">
      <method id="OnCheck">
      <method id="OnCalculate">


      (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) {

      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.

    • (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 2 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:


        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 :

        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">
        <function key="die_count.dagger" calc="2" replaces="true"/>

        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)

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