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

Expand Messages
  • Frugal
    How does your system handle the common base tags that all Entities can have in PCGen: add, auto, bonus, campaign, changeprof, choose, cskill, ccskill, define,
    Message 1 of 9 , Nov 13, 2003
      How does your system handle the common base tags that all Entities can
      have in PCGen:

      add, auto, bonus, campaign, changeprof, choose, cskill, ccskill, define,
      desc, descispi, dr, key, kit, langauto, move, movea, moveclone,
      name, nameispi, naturalattacks, outputname, pre, region, source, sa,
      spell, spelllevel, sr, type, udam, umult, vfeat, vision, weaponauto

      It is possible to have a natural attacks flag in a skill (PCGen would
      probably never do anything with it, but it is possible).

      Will the XML elements be able to encode all of these elements for any
      Object, or will you restrict it (i.e. skills can only use bonus, pre,
      define, choose, nameispi, name).

      If you are planning to restrict it, what method are you using to determine
      which of the global tags can be in each entity?

      --
      regards,
      Frugal
      -OS Chimp
    • Keith Davies
      ... I have no real intention of restricting anything. As described (long ago) if you want a skill that gives a bonus to attack rolls, a weapon that gives a
      Message 2 of 9 , Nov 13, 2003
        On Thu, Nov 13, 2003 at 11:54:36AM +0000, Frugal wrote:
        > How does your system handle the common base tags that all Entities can
        > have in PCGen:
        >
        > add, auto, bonus, campaign, changeprof, choose, cskill, ccskill,
        > define, desc, descispi, dr, key, kit, langauto, move, movea,
        > moveclone, name, nameispi, naturalattacks, outputname, pre, region,
        > source, sa, spell, spelllevel, sr, type, udam, umult, vfeat, vision,
        > weaponauto
        >
        > It is possible to have a natural attacks flag in a skill (PCGen would
        > probably never do anything with it, but it is possible).
        >
        > Will the XML elements be able to encode all of these elements for any
        > Object, or will you restrict it (i.e. skills can only use bonus, pre,
        > define, choose, nameispi, name).
        >
        > If you are planning to restrict it, what method are you using to
        > determine which of the global tags can be in each entity?

        I have no real intention of restricting anything. As described (long
        ago) if you want a skill that gives a bonus to attack rolls, a weapon
        that gives a bonus to skill checks, whatever, it's not *my* place to say
        you can't. In many cases it makes sense to be able to do so, and for
        the others, I don't see it worth the bother to make it impossible.

        The <effects> element (I think I've seen mention of it) may or may not
        be present in the schema. If present, it could contain any sort of
        effect -- add bonuses, add to known spells, whatever. It wouldn't vary
        by parent element. If not present in the schema, it's a placeholder for
        'anything that can be an effect of this thing'.

        If the current PCGen-XML documentation does not show otherwise, it means
        that either nothing else was found there, or the documentation is not
        complete.

        Obvious global children are:

        <name abbrev />
        <aka /> <!-- aliases, but not the primary name -->
        <desc />
        <description />
        <pre /> <!-- or <prereq /> -->

        global attributes may be on any object and include

        source:*

        source information is handled using attributes, and is inherited from
        parent elements except where overridden. This allows you to define
        source information at the <data> level and have all children share it.

        ispi, isogl

        are both needed? One indicates PI, other indicates OGL; I *think*
        these are exclusive conditions. These attributes may appear on any
        element, not just game objects (<description ispi='yes' /> means that
        the description is PI).

        I want to rework type; it's doing way more than it should have to.


        Keith
        --
        Keith Davies "Your ability to bang your head against
        keith.davies@... reality in the hope that reality will
        crack first is impressive, but futile"
        -- Geoffrey Brent, rec.games.frp.dnd
      • Frugal
        ... That is cool. In fact it is helpfull as we can create an Object base type in the schema for all of the common data and then
        Message 3 of 9 , Nov 14, 2003
          <quote who="Keith Davies">
          > I have no real intention of restricting anything. As described (long
          > ago) if you want a skill that gives a bonus to attack rolls, a weapon
          > that gives a bonus to skill checks, whatever, it's not *my* place to say
          > you can't. In many cases it makes sense to be able to do so, and for
          > the others, I don't see it worth the bother to make it impossible.

          That is cool. In fact it is helpfull as we can create an Object base type
          in the schema for all of the common data and then derive a type for each
          of the concrete object types (feat skill etc).

          --
          regards,
          Frugal
          -OS Chimp
        • Keith Davies
          ... That s pretty much my plan. Keith -- Keith Davies Your ability to bang your head against keith.davies@kjdavies.org reality in the hope
          Message 4 of 9 , Nov 14, 2003
            On Fri, Nov 14, 2003 at 08:51:21AM +0000, Frugal wrote:
            >
            > <quote who="Keith Davies">
            > > I have no real intention of restricting anything. As described
            > > (long ago) if you want a skill that gives a bonus to attack rolls, a
            > > weapon that gives a bonus to skill checks, whatever, it's not *my*
            > > place to say you can't. In many cases it makes sense to be able to
            > > do so, and for the others, I don't see it worth the bother to make
            > > it impossible.
            >
            > That is cool. In fact it is helpfull as we can create an Object base
            > type in the schema for all of the common data and then derive a type
            > for each of the concrete object types (feat skill etc).

            That's pretty much my plan.


            Keith
            --
            Keith Davies "Your ability to bang your head against
            keith.davies@... reality in the hope that reality will
            crack first is impressive, but futile"
            -- Geoffrey Brent, rec.games.frp.dnd
          • Frugal
            ... Trouble is, I can not figure out how to have a concrete type derived from an abstract base type and have the data be unordered
            Message 5 of 9 , Nov 14, 2003
              <quote who="Keith Davies">
              > On Fri, Nov 14, 2003 at 08:51:21AM +0000, Frugal wrote:
              >>
              >> <quote who="Keith Davies">
              >> > I have no real intention of restricting anything. As described
              >> > (long ago) if you want a skill that gives a bonus to attack rolls, a
              >> > weapon that gives a bonus to skill checks, whatever, it's not *my*
              >> > place to say you can't. In many cases it makes sense to be able to
              >> > do so, and for the others, I don't see it worth the bother to make
              >> > it impossible.
              >>
              >> That is cool. In fact it is helpfull as we can create an Object base
              >> type in the schema for all of the common data and then derive a type
              >> for each of the concrete object types (feat skill etc).
              >
              > That's pretty much my plan.

              Trouble is, I can not figure out how to have a concrete type derived from
              an abstract base type and have the data be unordered over all of them.

              But hey, I only just figured out how to use the source: namespace for
              attributes without the parser throwing a hissy fit ;O)

              --
              regards,
              Frugal
              -OS Chimp
            • Keith Davies
              ... That the child elements be unordered was Tir s requirement, not mine. I m all for having the children in specific order. That said, a reasonably simple way
              Message 6 of 9 , Nov 17, 2003
                On Fri, Nov 14, 2003 at 08:08:30PM +0000, Frugal wrote:
                >
                > <quote who="Keith Davies">
                > > On Fri, Nov 14, 2003 at 08:51:21AM +0000, Frugal wrote:
                > >>
                > >> <quote who="Keith Davies">
                > >> > I have no real intention of restricting anything. As described
                > >> > (long ago) if you want a skill that gives a bonus to attack rolls, a
                > >> > weapon that gives a bonus to skill checks, whatever, it's not *my*
                > >> > place to say you can't. In many cases it makes sense to be able to
                > >> > do so, and for the others, I don't see it worth the bother to make
                > >> > it impossible.
                > >>
                > >> That is cool. In fact it is helpfull as we can create an Object base
                > >> type in the schema for all of the common data and then derive a type
                > >> for each of the concrete object types (feat skill etc).
                > >
                > > That's pretty much my plan.
                >
                > Trouble is, I can not figure out how to have a concrete type derived
                > from an abstract base type and have the data be unordered over all of
                > them.

                That the child elements be unordered was Tir's requirement, not mine.
                I'm all for having the children in specific order.

                That said, a reasonably simple way to handle it would be to allow any
                number of them in any order and just keep the last. If the element may
                appear more than once (which I'm trying to avoid, as you know) then cat
                them together as you normally would (all <prereq>s go into the prereqs
                set, etc.). If you find a second... <weight>, say, for an <equip> just
                stomp on the one that was already present.


                Keith
                --
                Keith Davies "Your ability to bang your head against
                keith.davies@... reality in the hope that reality will
                crack first is impressive, but futile"
                -- Geoffrey Brent, rec.games.frp.dnd
              • Keith Davies
                ... Whoops, just remembered that keeping children in the same order for *all* elements can lead to some ugliness -- either children in weird order (one that
                Message 7 of 9 , Nov 17, 2003
                  On Fri, Nov 14, 2003 at 08:08:30PM +0000, Frugal wrote:
                  >
                  > <quote who="Keith Davies">
                  > > On Fri, Nov 14, 2003 at 08:51:21AM +0000, Frugal wrote:
                  > >>
                  > >> <quote who="Keith Davies">
                  > >> > I have no real intention of restricting anything. As described
                  > >> > (long ago) if you want a skill that gives a bonus to attack rolls, a
                  > >> > weapon that gives a bonus to skill checks, whatever, it's not *my*
                  > >> > place to say you can't. In many cases it makes sense to be able to
                  > >> > do so, and for the others, I don't see it worth the bother to make
                  > >> > it impossible.
                  > >>
                  > >> That is cool. In fact it is helpfull as we can create an Object base
                  > >> type in the schema for all of the common data and then derive a type
                  > >> for each of the concrete object types (feat skill etc).
                  > >
                  > > That's pretty much my plan.
                  >
                  > Trouble is, I can not figure out how to have a concrete type derived
                  > from an abstract base type and have the data be unordered over all of
                  > them.

                  Whoops, just remembered that keeping children in the same order for
                  *all* elements can lead to some ugliness -- either children in weird
                  order (one that doesn't make sense for the element) or conflicts.

                  This can be remedied, I think, by establishing a single ordering scheme
                  for all entities; if an entity doesn't contain a particular child
                  element at all, it simply doesn't show up in the list of allowable
                  children. For instance, we might say

                  <!ELEMENT race (name,desc?,description?,prereq?) >
                  <!ELMEENT skill (name,desc?,description?) >

                  Assuming, of course, that <skill> will never have prereqs (which I'm
                  inclined to allow them to have anyway because I figure just about
                  *anything* can be limited by prereqs). As an example, though, I think
                  it's simple enough.


                  Keith
                  --
                  Keith Davies "Your ability to bang your head against
                  keith.davies@... reality in the hope that reality will
                  crack first is impressive, but futile"
                  -- Geoffrey Brent, rec.games.frp.dnd
                • Frugal
                  ... Caveat: I have never tried to write a schema that is anything other than trivial before this. Please feel free to tear this to
                  Message 8 of 9 , Nov 18, 2003
                    <quote who="Keith Davies">
                    >> Trouble is, I can not figure out how to have a concrete type derived
                    >> from an abstract base type and have the data be unordered over all of
                    >> them.
                    >
                    > Whoops, just remembered that keeping children in the same order for
                    > *all* elements can lead to some ugliness -- either children in weird
                    > order (one that doesn't make sense for the element) or conflicts.

                    Caveat: I have never tried to write a schema that is anything other than
                    trivial before this. Please feel free to tear this to pieces. We have the
                    technology, we can rebuild it.

                    What I currently have is something like this:

                    <xs:complexType name="objectType">
                    <xs:all>
                    <xs:element ref="name"/>
                    <xs:element ref="outputName" minOccurs="0"/>
                    <xs:element ref="description" minOccurs="0"/>
                    <xs:element ref="prereq" minOccurs="0"/>
                    <xs:element ref="types" minOccurs="0"/>
                    <xs:element ref="defines" minOccurs="0"/>
                    <xs:element ref="bonuses" minOccurs="0"/>
                    <xs:element ref="autos" minOccurs="0"/>
                    <xs:element ref="specialAbilities" minOccurs="0"/>
                    <xs:element ref="damageReduction" minOccurs="0"/>
                    <xs:element name="classSkills" type="classSkillsType" minOccurs="0"/>
                    <xs:element name="crossClassSkills" type="crossClassSkillsType"
                    minOccurs="0"/>
                    <xs:element ref="vision" minOccurs="0"/>
                    <xs:element ref="add" minOccurs="0"/>
                    </xs:all>
                    <xs:attribute name="id" type="xs:string" use="required"/>
                    <xs:attribute name="ispi" type="xs:boolean" use="optional"/>
                    <xs:attributeGroup ref="source.group"/>
                    </xs:complexType>
                    <xs:complexType name="featType">
                    <xs:complexContent>
                    <xs:extension base="objectType">
                    <xs:all>
                    <xs:element ref="cost" minOccurs="0"/>
                    <xs:element ref="addSpellLevel" minOccurs="0"/>
                    </xs:all>
                    <xs:attribute name="visiblity" type="xs:string" use="optional"/>
                    <xs:attribute name="stacks" type="xs:string" use="optional"/>
                    <xs:attribute name="multiples" type="xs:string" use="optional"/>
                    </xs:extension>
                    </xs:complexContent>
                    </xs:complexType>


                    Which sort of works. You can order the elements in the 'objectType' in any
                    order you wish; you can order the elements in the 'featType' in any order
                    you wish. What you can not do is put any featType child before any
                    objectType child.

                    i.e.

                    <feat id="feat.foo">
                    <types>
                    <type>Fighter</type>
                    <type>General</type>
                    </types>
                    <name>Foo</name>
                    <cost>1</cost>
                    </feat>

                    is fine, but:

                    <feat id="feat.foo">
                    <types>
                    <type>Fighter</type>
                    <type>General</type>
                    </types>
                    <cost>1</cost>
                    <name>Foo</name>
                    </feat>

                    Is not. It will give an "unexpected child element 'name' error".

                    Is it even possible to write a schema that allows the elements from a type
                    and it's base type to mix ?

                    > This can be remedied, I think, by establishing a single ordering scheme
                    > for all entities; if an entity doesn't contain a particular child
                    > element at all, it simply doesn't show up in the list of allowable
                    > children. For instance, we might say
                    >
                    > <!ELEMENT race (name,desc?,description?,prereq?) >
                    > <!ELMEENT skill (name,desc?,description?) >

                    True, but this means that we need to copy the common objectType content
                    into each and every Entity element (and remember to update them all
                    whenever we change something).

                    > Assuming, of course, that <skill> will never have prereqs (which I'm
                    > inclined to allow them to have anyway because I figure just about
                    > *anything* can be limited by prereqs). As an example, though, I think
                    > it's simple enough.

                    As you suspected there are indeed skills that have prereqs on them.

                    "Knowledge (Data World)" has a prereq of 1 level in a particular class.

                    "Pilot" has a prereq of the "Technical Proficiency" feat.

                    --
                    regards,
                    Frugal
                    -OS Chimp
                  • Keith Davies
                    ... I ll have to comment on this later; I m working right now and don t have the time to examine it in sufficient detail. ... Keith -- Keith Davies
                    Message 9 of 9 , Nov 18, 2003
                      On Tue, Nov 18, 2003 at 10:32:52AM +0000, Frugal wrote:
                      >
                      > <quote who="Keith Davies">
                      > >> Trouble is, I can not figure out how to have a concrete type derived
                      > >> from an abstract base type and have the data be unordered over all of
                      > >> them.
                      > >
                      > > Whoops, just remembered that keeping children in the same order for
                      > > *all* elements can lead to some ugliness -- either children in weird
                      > > order (one that doesn't make sense for the element) or conflicts.
                      >
                      > Caveat: I have never tried to write a schema that is anything other
                      > than trivial before this. Please feel free to tear this to pieces. We
                      > have the technology, we can rebuild it.

                      I'll have to comment on this later; I'm working right now and don't have
                      the time to examine it in sufficient detail.

                      > What I currently have is something like this:
                      >
                      > <xs:complexType name="objectType">
                      > <xs:all>


                      Keith
                      --
                      Keith Davies "Your ability to bang your head against
                      keith.davies@... reality in the hope that reality will
                      crack first is impressive, but futile"
                      -- Geoffrey Brent, rec.games.frp.dnd
                    Your message has been successfully submitted and would be delivered to recipients shortly.