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

How goes it?

Expand Messages
  • Steven Bethard
    So I started this weekend looking at the most recent pcgen-xml messages and decided they really weren t going to make any sense without context. 842 messages
    Message 1 of 21 , Jan 14, 2004
    View Source
    • 0 Attachment
      So I started this weekend looking at the most recent pcgen-xml messages and
      decided they really weren't going to make any sense without context. 842
      messages later, I think I'm up to date. ;)

      It was a touching story - I almost cried when the good schema got shelved!
      ;) It had enormous potential to allow PCGen to truly be a multi-system
      character generator. Are there plans to pick this work back up?

      As I understand it right now, Frugal's put together a LST -> XML converter,
      where the output is the interrim XML, right? Where do we stand on an XML ->
      [PCGen internal data structures] converter? It seemed to me that PCGen
      still reads in exclusively LST files - is this correct?


      I'm really interested in helping out around here - I've got a couple of
      years teaching Java, and decent experience with Java and XML (god forbid, I
      even like XSD!), and I've already volunteered to help on some of the
      code-monkey side of things too, where I'm especially interested in
      restructuring the model to help accommodate for things like your XML model
      here.

      So is there anything I can do to help?

      Steve
      _____

      You can wordify anything if you just verb it.
      - Bucky Katt, Get Fuzzy
    • Keith Davies
      ... My gods. *I* wouldn t want to go through the entire history. Good work. ... Oh. Hell. Yes. I ll be making an announcement here in a couple days. ... erm,
      Message 2 of 21 , Jan 14, 2004
      View Source
      • 0 Attachment
        On Wed, Jan 14, 2004 at 10:50:20PM -0700, Steven Bethard wrote:
        > So I started this weekend looking at the most recent pcgen-xml
        > messages and decided they really weren't going to make any sense
        > without context. 842 messages later, I think I'm up to date. ;)

        My gods. *I* wouldn't want to go through the entire history. Good
        work.

        > It was a touching story - I almost cried when the good schema got
        > shelved! ;) It had enormous potential to allow PCGen to truly be a
        > multi-system character generator. Are there plans to pick this work
        > back up?

        Oh. Hell. Yes.

        I'll be making an announcement here in a couple days.

        > As I understand it right now, Frugal's put together a LST -> XML
        > converter, where the output is the interrim XML, right? Where do we
        > stand on an XML -> [PCGen internal data structures] converter? It
        > seemed to me that PCGen still reads in exclusively LST files - is this
        > correct?

        erm, no useful comment here. I need to talk to Frugal.

        > I'm really interested in helping out around here - I've got a couple
        > of years teaching Java, and decent experience with Java and XML (god
        > forbid, I even like XSD!),

        Medic!

        > and I've already volunteered to help on some of the code-monkey side
        > of things too, where I'm especially interested in restructuring the
        > model to help accommodate for things like your XML model here.
        >
        > So is there anything I can do to help?

        Yep. See the announcement in a couple days.


        Keith
        --
        Keith Davies I gave my 2yo daughter a strawberry
        keith.davies@... Naomi: "Strawberry!"
        me: "What do you say?"
        Naomi: "*MY* strawberry!"
      • Frugal
        ... I do not think that PCGen can cope with being a generic character generator. It was created specificly for D&D and has had a
        Message 3 of 21 , Jan 15, 2004
        View Source
        • 0 Attachment
          <quote who="Steven Bethard">
          > It was a touching story - I almost cried when the good schema got shelved!
          > ;) It had enormous potential to allow PCGen to truly be a multi-system
          > character generator. Are there plans to pick this work back up?

          I do not think that PCGen can cope with being a generic character
          generator. It was created specificly for D&D and has had a whole load of
          stuff bolted onto it, each new bit rests unstably on the rather specific
          foundations.

          To make PCGen a generic character editor it would be quicker to rewrite
          the whole thing from scratch than to try and make the base of PCGen
          generic.

          > As I understand it right now, Frugal's put together a LST -> XML
          > converter,
          > where the output is the interrim XML, right? Where do we stand on an XML
          > ->
          > [PCGen internal data structures] converter? It seemed to me that PCGen
          > still reads in exclusively LST files - is this correct?

          I wrote a converter to parse LST and spit out XML according to a schema
          for PCGen. However people do not want a schema for PCGen, they want a
          generic roleplaying character schema. So it was all a waste of time really
          ;O)

          PCGen does not have a hope in hell of parsing XML at any point in the near
          future. Too much of the data parsing is done in pcgen.core rather than
          pcgen.persistence. It will be hundreds of man hours of work to refactor
          all of this out. No one seems particually interested in doing it as there
          is no immediate benefit.

          the only way an XML persistence layer would work at the moment is to
          convert the XML to LST in the persistence layer and insert the appropriate
          bits of LST into the PObjects.

          At the moment I have stopped dealing with the XML side of things (because
          refactoring _must_ come before XML, and because I do not fully understand
          Keith's XML layer) and started to refactor PCGen to move persistence to
          the persistence layer. Keith: you will probably notice that the new
          Prerequiste object looks strangely like the <prereq> tag in my schema ;O)

          --
          regards,
          Frugal
          -OS Chimp
        • bediviere@hotmail.com
          ... Yeah, I had this feeling too. I guess my question was, is PCGen working towards /using files/ that could cope with generic
          Message 4 of 21 , Jan 15, 2004
          View Source
          • 0 Attachment
            <quote who="Frugal">
            > I do not think that PCGen can cope with being a generic character
            > generator. It was created specificly for D&D and has had a whole
            > load of stuff bolted onto it, each new bit rests unstably on the
            > rather specific foundations.
            </quote>

            Yeah, I had this feeling too. I guess my question was, is PCGen
            working towards /using files/ that could cope with generic character
            creation? Even if PCGen doesn't support generic character creation,
            if the data format has the potential to, this is an enormous step
            forward.

            <quote who="Frugal">
            > To make PCGen a generic character editor it would be quicker to
            > rewrite the whole thing from scratch than to try and make the base
            > of PCGen generic.
            </quote>

            Funny, I'd been thinking this too. I was almost considering taking a
            stab at this in my copius amounts of free time - if only I had such
            a thing. ;)

            <quote who="Frugal">
            > PCGen does not have a hope in hell of parsing XML at any point in
            > the near future. Too much of the data parsing is done in
            > pcgen.core rather than pcgen.persistence. It will be hundreds of
            > man hours of work to refactor all of this out. No one seems
            > particually interested in doing it as there is no immediate
            > benefit.
            </quote>

            Ooooh! Pick me! Pick me! ;) This is actually primarily what I'd be
            interested in doing, so once I get caught up on the current code
            base, I'd be glad to help here however I can.


            Steve
            _____

            You can wordify anything if you just verb it.
            - Bucky Katt, Get Fuzzy
          • Scott Ellsworth
            ... I do not think so - we are going to have to convert the LST files somehow, and my experience has been that the very best way to do that is to first move
            Message 5 of 21 , Jan 15, 2004
            View Source
            • 0 Attachment
              On Jan 15, 2004, at 12:46 AM, Frugal wrote:

              > <quote who="Steven Bethard">
              >
              >> As I understand it right now, Frugal's put together a LST -> XML
              >> converter,
              >> where the output is the interrim XML, right? Where do we stand on an
              >> XML
              >> ->
              >> [PCGen internal data structures] converter? It seemed to me that
              >> PCGen
              >> still reads in exclusively LST files - is this correct?
              >
              > I wrote a converter to parse LST and spit out XML according to a schema
              > for PCGen. However people do not want a schema for PCGen, they want a
              > generic roleplaying character schema. So it was all a waste of time
              > really
              > ;O)

              I do not think so - we are going to have to convert the LST files
              somehow, and my experience has been that the very best way to do that
              is to first move weird flat files to weird xml, then to improve the
              XML. If you try to do both at once, it usually ends up being a really
              tough project that never gets finished.

              > PCGen does not have a hope in hell of parsing XML at any point in the
              > near
              > future. Too much of the data parsing is done in pcgen.core rather than
              > pcgen.persistence. It will be hundreds of man hours of work to refactor
              > all of this out. No one seems particually interested in doing it as
              > there
              > is no immediate benefit.

              There is a lot of immediate benefit. The biggest single flaw in
              PCGen's design right now is how we do the data parsing. By not having
              a good object model, we commit ourselves to zillions of
              StringTokenizers, plus a format that cannot easily be validated.
              Further, we end up setting things using Magic Strings (tm) rather than
              object properties.

              I keep profiling the app, and discovering things that need to be fixed,
              but I have not had the time to do the fixes. You have done a lot more
              good by pushing the refactoring - my hat is off to you.

              > the only way an XML persistence layer would work at the moment is to
              > convert the XML to LST in the persistence layer and insert the
              > appropriate
              > bits of LST into the PObjects.

              Yep - that would suck, suck, suck. Far better to get the persistence
              layer right, and then start an xml conversion.

              > At the moment I have stopped dealing with the XML side of things
              > (because
              > refactoring _must_ come before XML, and because I do not fully
              > understand
              > Keith's XML layer) and started to refactor PCGen to move persistence to
              > the persistence layer. Keith: you will probably notice that the new
              > Prerequiste object looks strangely like the <prereq> tag in my schema
              > ;O)

              Agreed - once it is localized to one package, we can actually unit
              test. (For example, we can do something like:

              load

              CLASS:Cleric HD:8 TYPE:Base.PC ABB:Clr SOURCEPAGE:ClassesI.rtf
              LANGAUTO:Literacy LANGBONUS:Abyssal,Celestial,Infernal BONUS:
              CHECKS|BASE.Fortitude,BASE.Willpower|CL/2+2 BONUS:
              CHECKS|BASE.Reflex|CL/3 BONUS:COMBAT|BAB|CL*3/4|TYPE=Base.REPLACE
              BONUS:DOMAIN|NUMBER|2

              and load

              <class name="Cleric" hitdice="8" type="Base.PC" abbreviation="Clr">
              <sourcepage>ClassesI.rtf</sourcepage>
              <languages>
              <language type="auto" id="language.literacy" />
              </language type="auto" id="language.abyssal" />
              </language type="auto" id="language.celestial" />
              </language type="auto" id="language.infernal" />
              </languages>
              <saves>
              <save type="good" id="save.fortitude"/>
              <save type="good" id="save.will"/>
              <save type="bad" id="save.reflex"/>
              </saves>
              <base-attack-bonus type="average" />
              <bonuses>
              <bonus type="domains" name="number" expression="+2"/>
              </bonuses>
              </class>

              And then compare that the resulting data structures are exactly the
              same. Thus - fewer data problems coming from formatting or unknown
              tags.

              Heck - as long as we are dreaming, someone could engineer a
              database-backed persistence layer as well, without touching anything
              outside persistence. This has never been a good idea before, but might
              be reasonable now.

              Scott
            • Frugal
              ... I have discovered an equaly ugly flaw in the model. There is no separation between the data layer and the implementation
              Message 6 of 21 , Jan 19, 2004
              View Source
              • 0 Attachment
                <quote who="Scott Ellsworth">
                > There is a lot of immediate benefit. The biggest single flaw in
                > PCGen's design right now is how we do the data parsing. By not having
                > a good object model, we commit ourselves to zillions of
                > StringTokenizers, plus a format that cannot easily be validated.
                > Further, we end up setting things using Magic Strings (tm) rather than
                > object properties.

                I have discovered an equaly ugly flaw in the model. There is no separation
                between the data layer and the implementation layer. This may or may not
                cause a problem with the XML transformation, it will depend how it is
                done.

                For instance when you add a class to a character it looks to see if the
                character already has a level in that class, if it does not then it finds
                the global instance of the class. Then it takes a clone() of the global
                class and inserts it into the Character class list.

                The reason it does this is so that it it can store the number of levels a
                character has in the class, the number of HP for each level and a few
                other things.

                So if you have 10 Rogue characters open in PCGen you will have 11 copies
                of the Rogue PCClass (original + 10 clones), each having a separate copy
                of the 123 fields in PCClass...

                So I thought to myself I shall try to refactor this out. So I created a
                mapping class from Character to Class so there was somewhere to store
                level count, HP etc.

                Then I discovered that not only does PCClass store a whole load of
                implementation details, but so does PObject. Anything that gives a spell
                to a character (i.e. gaining a level of Sorceror) will put a new set of
                Spell Objects in the PCClass object.

                It gets worse. On the abilities tab you can add and remove a special
                ability. It does this by directly adding and removing the SA from the
                clone of the PCClass...


                Plus there is the problem of what do you do with the variable code. are
                you going to be happy having things like "CL=Cleric" in your xml code,
                because that is how it is handled internally, or are you going to
                translate it from a slightly nicer XML format into a format PCGen can
                handle?

                --
                regards,
                Frugal
                -OS Chimp
              • Frugal
                ... So does this mean you have finished your schema ? As an aside I was having a look at your schema on the Wiki. It seems as though
                Message 7 of 21 , Jan 19, 2004
                View Source
                • 0 Attachment
                  <quote who="Keith Davies">
                  > I'll be making an announcement here in a couple days.

                  So does this mean you have finished your schema ?

                  As an aside I was having a look at your schema on the Wiki. It seems as
                  though you haev based Ranks/Progression on HitDice. Surely HitDice are an
                  effect of Ranks/Progression not the other way around...

                  As a concrete example: Savage Species defines the 20 character levels of
                  progression for an Astral Deva, which is only a 12HD creature, so some
                  levels do not get HD, and some levels do not get Skills.

                  Does your system cope with this kind of progression? It might be unusual
                  and strange for D&D, but it might be very common in some other system.

                  --
                  regards,
                  Frugal
                  -OS Chimp
                • Keith Davies
                  ... Ouch. ... As far as I m concerned, things like CL=Cleric will be broken out into XML in a (hopefully) meaningful matter. The XML largely ignores PCGen s
                  Message 8 of 21 , Jan 19, 2004
                  View Source
                  • 0 Attachment
                    On Mon, Jan 19, 2004 at 09:21:13AM +0000, Frugal wrote:
                    >
                    > So if you have 10 Rogue characters open in PCGen you will have 11 copies
                    > of the Rogue PCClass (original + 10 clones), each having a separate copy
                    > of the 123 fields in PCClass...

                    Ouch.

                    > Plus there is the problem of what do you do with the variable code. are
                    > you going to be happy having things like "CL=Cleric" in your xml code,
                    > because that is how it is handled internally, or are you going to
                    > translate it from a slightly nicer XML format into a format PCGen can
                    > handle?

                    As far as I'm concerned, things like 'CL=Cleric' will be broken out into
                    XML in a (hopefully) meaningful matter. The XML largely ignores PCGen's
                    internal formatting and handling; mapping from XML to the internal
                    format is expected to be handled largely in the Producer-Consumer
                    framework (mostly in the Consumer, of course). It may be that the data
                    design in XML (which is based on relationships in the data rather than
                    the program) may suit the program better and replace the internal
                    structure in PCGen, but that would be down the road and not my decision.


                    Keith
                    --
                    Keith Davies I gave my 2yo daughter a strawberry
                    keith.davies@... Naomi: "Strawberry!"
                    me: "What do you say?"
                    Naomi: "*MY* strawberry!"
                  • Keith Davies
                    ... Not *entirely*, I still need to fill in bonuses and effects. The framework, though, looks pretty solid. ... It s a bit of both, depending how you do it.
                    Message 9 of 21 , Jan 19, 2004
                    View Source
                    • 0 Attachment
                      On Mon, Jan 19, 2004 at 09:57:55AM +0000, Frugal wrote:
                      > <quote who="Keith Davies">
                      > > I'll be making an announcement here in a couple days.
                      >
                      > So does this mean you have finished your schema ?

                      Not *entirely*, I still need to fill in bonuses and effects. The
                      framework, though, looks pretty solid.

                      > As an aside I was having a look at your schema on the Wiki. It seems
                      > as though you haev based Ranks/Progression on HitDice. Surely HitDice
                      > are an effect of Ranks/Progression not the other way around...

                      It's a bit of both, depending how you do it. Theoretically 'one level
                      == one Hit Die', which is fairly reasonable for everything *except*
                      monsters with level adjustment being used as PCs. Until that point it
                      was fine -- that a dragon HD is worth more than a humanoid HD doesn't
                      much matter for our purposes. Classes illustrate the simple case, so
                      I'll describe that here; races are below because they're a more complex
                      case (and it was a better place to answer because that's where you
                      asked).

                      A class is a simpler case because it's defined as granting a hit die at
                      each level (Rank). As such, granting a hit die is indeed a function of
                      level, implemented as a recurring effect (that happens at each level;
                      other recurring effects might happen only on odd levels, levels not
                      divisible by 10, whatever).

                      Whew, it looked for a moment that making Rank an Entity made sense
                      because then we could use the prereq mechanism to govern when recurring
                      effects. Got out of it because we can change prereq checks to go
                      against an Item rather than Entity, which is safer than introducing
                      Entities stored within other Entities.

                      Anyway, the recurring effect means that at each rank one hit die worth
                      of hit points is added (other recurring effects increase BAB, base
                      saves, etc.). These recurring effects might be defined in the class
                      specification at the meta level or in each class using references to
                      common elements.

                      If the recurring effects are built into the class specification they
                      would refer to a property of the class ('at each rank add to hit points
                      the result of rolling a die of the size indicated by hit_die_size'); if
                      not done this way (which frankly I prefer, since it makes it easier to
                      override at different levels -- only used by Dragon Disciple IIRC, or
                      possibly through feats) it allows different die sizes or even skipping
                      if desired.

                      In the simple case, though, for a class adding hit dice is a function of
                      level.

                      > As a concrete example: Savage Species defines the 20 character levels
                      > of progression for an Astral Deva, which is only a 12HD creature, so
                      > some levels do not get HD, and some levels do not get Skills.
                      >
                      > Does your system cope with this kind of progression? It might be
                      > unusual and strange for D&D, but it might be very common in some other
                      > system.

                      Yes, it can.

                      For a 'simple' monster type ('not Savage Species') it's easier because
                      it's safe to assume that each hit die marks a stage in the progression.
                      Savage Species breaks that assumption in order to spread out the level
                      adjustment (and other effects) to keep it balanced at each 'monster
                      level'. For simple monsters this isn't necessary, and each rank can add
                      a whole hit die. For that matter, a monster (such as your Astral Deva)
                      might be defined as getting 12HD at first rank, then each rank after
                      that follows its normal progression (either HD based or 'by class').

                      The 'not simple' way of doing things (from SS) you can define the
                      creature as a progression that adds hit dice (and other effects) at
                      various levels as suggested by SS (this would not, IMO, but
                      automatable).

                      Now, here's the *really* messed thing. It's cool, but it's messed. For
                      fairly obvious reasons, I think we want to keep the 'base version' (the
                      'simple monster' described above) to always start at rank 1. Astral
                      Deva starts with 12HD, etc. However, you may want a pre-base version
                      that supports the monster levels as described in SS. Astral Deva has 20
                      'levels' (PC-style), right? We have an apparent conflict -- Astral
                      Deva, viewed as a 'level for level match for PC classes', has some 20
                      ranks, and viewed the other (the common way) has one (before further
                      advancement). As the 'simple form' is the common case, we want it to be
                      as simple as possible, right?

                      As the 'pre-base' versions get implemented, you can...

                      ...define the first rank of the simple version in terms of the other.
                      Specifically, you can say in the first rank of Astral Deva 'add enough
                      ranks in the 'Astral Deva Prebase' progression to make me a 12HD Astral
                      Deva'.

                      Well, not in English, but you get my drift. 'Astral Deva' shows up in
                      the list and is readily accessible (you don't have to remember that it
                      starts as a 12HD creature) or as a 'racial class' that eventually builds
                      up to the 12HD version... and the definitions would be compatible --
                      starting as a pre-base Astral Deva doesn't require reconstruction after
                      the creature reaches his normal base.

                      This shows up more in dragons. It's possible to define the base
                      progression (Red Dragon), then define the age-specific ones in terms of
                      it. For instance, selecting 'Dragon, Red, Young Adult' can
                      automatically advance the creature the right number of ranks in 'Dragon,
                      Red', and can advance within the Young Adult progression. When the end
                      is reached the creature can no longer advance as a Young Adult, but as
                      an Adult (new progression). The effect of the /n/th rank in Red Dragon
                      might change the descriptive text (from 'Young Adult Red Dragon' to
                      'Adult Red Dragon'). Or the creature can be specified as a /n/ HD red
                      dragon (that is, /n/ Rank) and everything gets set up appropriately.

                      Messed, but cool.


                      Keith
                      --
                      Keith Davies I gave my 2yo daughter a strawberry
                      keith.davies@... Naomi: "Strawberry!"
                      me: "What do you say?"
                      Naomi: "*MY* strawberry!"
                    • CC Noram Carstensen James
                      Keith, That sounds like a lot of extra work. If I m pulling out a basic Deva, I ve got the MM. If I m loading one in PCGen there is at least an even chance I
                      Message 10 of 21 , Jan 19, 2004
                      View Source
                      • 0 Attachment
                        Keith,

                        That sounds like a lot of extra work. If I'm pulling out a basic Deva,
                        I've got the MM. If I'm loading one in PCGen there is at least an even
                        chance I want to customize it. Having two separate ways - one that has
                        a full deva as "rank 1" and a separate that builds it from the ground up
                        means two sets of data to maintain. Much messier.

                        We have classes (that add a HD and various other things), racial classes
                        (that sometimes add a HD), templates (that rarely add a HD), and Level
                        Adjustments (that never add a HD). HD, ECL, and CR are only loosely
                        related, there is no conflict between a "20 level" Deva, a "12 HD + 8
                        Level Adjustment" Deva and a "CR 14" Deva. The cognitive dissonance is
                        only if you get stuck in "level = HD = CR".

                        Cheers,
                        Jim
                      • Keith Davies
                        ... It is more work, in that you would need both definitions available. However, if both *are* available, it means *less* work because you can base on
                        Message 11 of 21 , Jan 19, 2004
                        View Source
                        • 0 Attachment
                          On Mon, Jan 19, 2004 at 05:52:21PM -0500, CC Noram Carstensen James wrote:
                          > Keith,
                          >
                          > That sounds like a lot of extra work. If I'm pulling out a basic
                          > Deva, I've got the MM. If I'm loading one in PCGen there is at least
                          > an even chance I want to customize it. Having two separate ways - one
                          > that has a full deva as "rank 1" and a separate that builds it from
                          > the ground up means two sets of data to maintain. Much messier.

                          It is more work, in that you would need both definitions available.
                          However, if both *are* available, it means *less* work because you can
                          base on definition on the other -- for a 'base Astral Deva', there is
                          only one definition. You only have to dig out the other one if want to
                          create an 'immature' one.

                          If this leads to a messier system, blame Savage Species. Things were
                          much easier before that showed up.

                          I didn't do a very good job of describing it, though, I'll cop to that.

                          > We have classes (that add a HD and various other things), racial
                          > classes (that sometimes add a HD), templates (that rarely add a HD),
                          > and Level Adjustments (that never add a HD). HD, ECL, and CR are only
                          > loosely related, there is no conflict between a "20 level" Deva, a "12
                          > HD + 8 Level Adjustment" Deva and a "CR 14" Deva. The cognitive
                          > dissonance is only if you get stuck in "level = HD = CR".

                          I'm not particularly fixated on that, I just don't want to have to
                          remember how many HD a 'base' Astral Deva has. By defining one in terms
                          of the other, you don't need to. 'Astral Deva' starts with the 'normal'
                          (MM) definition. That the other is defined in terms of the
                          'constructed' one doesn't matter to me at this point, and I don't need
                          to know how it got there. That we can define progressions in terms of
                          each other, even putting breakpoints in them (like with dragons) is a
                          convenience. I don't want to have to remember what HD range a Young
                          Adult Red Dragon has, I want to be able to just find and select it. And
                          advance it, and if I try to advance it out of its range, allow the
                          system to handle the transition nicely.


                          Keith
                          --
                          Keith Davies I gave my 2yo daughter a strawberry
                          keith.davies@... Naomi: "Strawberry!"
                          me: "What do you say?"
                          Naomi: "*MY* strawberry!"
                        • Keith Davies
                          ... Yep. That s why I tried to design a framework that will help move us away from that -- start partitioning the code a bit more. ... Probably. Doesn t mean
                          Message 12 of 21 , Jan 19, 2004
                          View Source
                          • 0 Attachment
                            On Thu, Jan 15, 2004 at 08:46:18AM +0000, Frugal wrote:
                            > <quote who="Steven Bethard">
                            > > It was a touching story - I almost cried when the good schema got
                            > > shelved! ;) It had enormous potential to allow PCGen to truly be a
                            > > multi-system character generator. Are there plans to pick this work
                            > > back up?
                            >
                            > I do not think that PCGen can cope with being a generic character
                            > generator. It was created specificly for D&D and has had a whole load
                            > of stuff bolted onto it, each new bit rests unstably on the rather
                            > specific foundations.

                            Yep. That's why I tried to design a framework that will help move us
                            away from that -- start partitioning the code a bit more.

                            > To make PCGen a generic character editor it would be quicker to rewrite
                            > the whole thing from scratch than to try and make the base of PCGen
                            > generic.

                            Probably. Doesn't mean we have to constrain what the data can do just
                            because the program can't deal with it <g>

                            > > As I understand it right now, Frugal's put together a LST -> XML
                            > > converter, where the output is the interrim XML, right? Where do we
                            > > stand on an XML -> [PCGen internal data structures] converter? It
                            > > seemed to me that PCGen still reads in exclusively LST files - is
                            > > this correct?
                            >
                            > I wrote a converter to parse LST and spit out XML according to a
                            > schema for PCGen. However people do not want a schema for PCGen, they
                            > want a generic roleplaying character schema. So it was all a waste of
                            > time really ;O)

                            Not entirely, as it does demonstrate that it can be done.

                            > PCGen does not have a hope in hell of parsing XML at any point in the
                            > near future. Too much of the data parsing is done in pcgen.core rather
                            > than pcgen.persistence. It will be hundreds of man hours of work to
                            > refactor all of this out. No one seems particually interested in doing
                            > it as there is no immediate benefit.

                            Probably true, sadly. It'll still need to be done, though. I thought
                            Bryan had it on the list of Things to Be Done.

                            > the only way an XML persistence layer would work at the moment is to
                            > convert the XML to LST in the persistence layer and insert the
                            > appropriate bits of LST into the PObjects.

                            yep. Which (hopefully) wouldn't be too difficult in the framework I've
                            devised.

                            > At the moment I have stopped dealing with the XML side of things
                            > (because refactoring _must_ come before XML, and because I do not
                            > fully understand Keith's XML layer)

                            ask away! If it's not clear, I'm not describing it well enough.

                            > and started to refactor PCGen to move persistence to the persistence
                            > layer.

                            I blinked a couple times here. That sentence looks weird. <g>

                            > Keith: you will probably notice that the new Prerequiste object looks
                            > strangely like the <prereq> tag in my schema ;O)

                            Yeah, I did notice that.


                            Keith
                            --
                            Keith Davies I gave my 2yo daughter a strawberry
                            keith.davies@... Naomi: "Strawberry!"
                            me: "What do you say?"
                            Naomi: "*MY* strawberry!"
                          • Frugal
                            ... Erm... Yes it does. This is supposed to be a new data model for PCGen. If PCGen can not use the data in the data model then the
                            Message 13 of 21 , Jan 20, 2004
                            View Source
                            • 0 Attachment
                              <quote who="Keith Davies">
                              > On Thu, Jan 15, 2004 at 08:46:18AM +0000, Frugal wrote:
                              >> To make PCGen a generic character editor it would be quicker to rewrite
                              >> the whole thing from scratch than to try and make the base of PCGen
                              >> generic.
                              >
                              > Probably. Doesn't mean we have to constrain what the data can do just
                              > because the program can't deal with it <g>

                              Erm... Yes it does. This is supposed to be a new data model for PCGen. If
                              PCGen can not use the data in the data model then the data model is
                              useless.

                              If this is supposed to be a generic data model for D&D, or a generic model
                              for an arbitrary RPG then the majority of PCGen will need to be rewritten
                              to the extent that it will effectivly become a new program.

                              >> I wrote a converter to parse LST and spit out XML according to a
                              >> schema for PCGen. However people do not want a schema for PCGen, they
                              >> want a generic roleplaying character schema. So it was all a waste of
                              >> time really ;O)
                              >
                              > Not entirely, as it does demonstrate that it can be done.

                              All it demonstrateed was the the PCGen specific syntax can be reformatted
                              into a slightly different form. I did not add/remove/change any data, all
                              I did was put it in some xml elements.

                              >> PCGen does not have a hope in hell of parsing XML at any point in the
                              >> near future. Too much of the data parsing is done in pcgen.core rather
                              >> than pcgen.persistence. It will be hundreds of man hours of work to
                              >> refactor all of this out. No one seems particually interested in doing
                              >> it as there is no immediate benefit.
                              >
                              > Probably true, sadly. It'll still need to be done, though. I thought
                              > Bryan had it on the list of Things to Be Done.

                              There are items in the "list of things to do" from 2001. Don't hold your
                              breath. PCGen is a community effort, which means that people will only do
                              what they find interesting. changing the code base without any change in
                              interface or functionality is way down on most peoples list of things they
                              wish to do. It is only sick and twisted individuals like me who see the
                              horrors in the code and start twitching that will make these changes.

                              >> the only way an XML persistence layer would work at the moment is to
                              >> convert the XML to LST in the persistence layer and insert the
                              >> appropriate bits of LST into the PObjects.
                              >
                              > yep. Which (hopefully) wouldn't be too difficult in the framework I've
                              > devised.
                              >
                              >> At the moment I have stopped dealing with the XML side of things
                              >> (because refactoring _must_ come before XML, and because I do not
                              >> fully understand Keith's XML layer)
                              >
                              > ask away! If it's not clear, I'm not describing it well enough.

                              What I would really like to see is some concrete examples. You and Steve
                              have been having a wonderful discussion about Ranks and Progressions and
                              all kinds of Airy-Fairy ideas, but I am an old fasioned kind of guy and I
                              need to see some examples to prove that the high levels ideas are actually
                              practical. And ideally the XML examples converted into LST so that it can
                              be seen how the new concepts will map onto the existing structure


                              Has anyone approached Bryan to see about branching the code? I think that
                              with all of the proposed changes, and all of the changes that will occur
                              because of data model changes it might be better to brnach the code at
                              5.7.1 and develop on a separate tree. These changes are going to be so
                              broad that people are not going to want a mostly broken PCGen for 6
                              months.

                              --
                              regards,
                              Frugal
                              -OS Chimp
                            • Frugal
                              ... I have always thought that races should be class level 0. A first level human monk should be 0:Human, 1:Monk A first level Orc
                              Message 14 of 21 , Jan 20, 2004
                              View Source
                              • 0 Attachment
                                <quote who="Keith Davies">
                                > On Mon, Jan 19, 2004 at 09:57:55AM +0000, Frugal wrote:
                                > A class is a simpler case because it's defined as granting a hit die at
                                > each level (Rank). As such, granting a hit die is indeed a function of
                                > level, implemented as a recurring effect (that happens at each level;
                                > other recurring effects might happen only on odd levels, levels not
                                > divisible by 10, whatever).

                                I have always thought that races should be class level 0.

                                A first level human monk should be 0:Human, 1:Monk

                                A first level Orc should be 0:Orc-Race, 1:Orc

                                A first level Orc Monk should be 0:Orc-Race, 1:Monk

                                An Orge/Mnk1 shoudl be 0:Ogre, 1:Giant, 2:Giant, 3:Giant, 4:Giant, 5:Monk

                                An Ogre/Mnk1 character with 2ECL should be 0:Ogre, 1:Giant, 2:Giant,
                                3:Giant, 4:Giant, 5:ECL, 6:ECL, 7:Monk

                                An AstraDeva should be 0:Celestial, 1:AstraDeva, 2:AstraDeva ...

                                --
                                regards,
                                Frugal
                                -OS Chimp
                              • Frugal
                                ... I notice in you examples of races you have a by-class boolean attribute. How does your plan cope with 1HD creatures? i.e. an
                                Message 15 of 21 , Jan 20, 2004
                                View Source
                                • 0 Attachment
                                  <quote who="Keith Davies">
                                  > ask away! If it's not clear, I'm not describing it well enough.

                                  I notice in you examples of races you have a "by-class" boolean attribute.
                                  How does your plan cope with 1HD creatures?

                                  i.e. an "Orc" is a 1HD creature, an Orc with a level of fighter is a Ftr1.
                                  As soon as 1HD creatures take a class level they loose their 1 racial HD.

                                  What about the case of the Astra Deva? they can either progress by class
                                  or not depending on how you play them. Will we need 2 race definitions, or
                                  is the Savage Species 20 level progression a class progression rather than
                                  a race progression?

                                  --
                                  regards,
                                  Frugal
                                  -OS Chimp
                                • STILES, BRAD
                                  ... If you think about it, races are little more than templates laid over a generic character, adding or removing abilities. If you think of a character as
                                  Message 16 of 21 , Jan 20, 2004
                                  View Source
                                  • 0 Attachment
                                    RE: [pcgen-xml] How goes it?

                                    > -----Original Message-----
                                    > From: Frugal [mailto:frugal@...]
                                    >
                                    > I have always thought that races should be class level 0.

                                    If you think about it, races are little more than templates laid over a "generic" character, adding or removing abilities.  If you think of a character as nothing more than a set of stats, then selecting *anything* else becomes a set of modifiers, additions, restrictions, bonuses, penalties, etc to that character.  Including race, alignment, class, etc.

                                    I believe Keith noticed the transactional nature of most PCGen things when he got into the LST files.

                                  • CC Noram Carstensen James
                                    ... 5:Monk ... 3:Giant, 4:Giant, 5:ECL, 6:ECL, 7:Monk ... This I can sink my teeth into. I like it. Though the ECL example gets a bit odd because it s really
                                    Message 17 of 21 , Jan 20, 2004
                                    View Source
                                    • 0 Attachment
                                      Frugal wrote:
                                      > I have always thought that races should be class level 0.
                                      >
                                      > A first level human monk should be 0:Human, 1:Monk
                                      >
                                      > A first level Orc should be 0:Orc-Race, 1:Orc
                                      >
                                      > A first level Orc Monk should be 0:Orc-Race, 1:Monk
                                      >
                                      > An Orge/Mnk1 shoudl be 0:Ogre, 1:Giant, 2:Giant, 3:Giant, 4:Giant,
                                      5:Monk
                                      >
                                      > An Ogre/Mnk1 character with 2ECL should be 0:Ogre, 1:Giant, 2:Giant,
                                      3:Giant, 4:Giant, 5:ECL, 6:ECL, 7:Monk
                                      >
                                      > An AstraDeva should be 0:Celestial, 1:AstraDeva, 2:AstraDeva ...

                                      This I can sink my teeth into. I like it.

                                      Though the ECL example gets a bit odd because it's really a Level
                                      Adjustment, not a real level, so it doesn't trigger some level-based
                                      events (like feats and ability increases).

                                      Of course, I think that races, monster levels, templates, and class
                                      levels are all really the same thing at the core. Let's call that a
                                      Widget just for discussion.

                                      Frugal, would your comments above be okay with instead of being "a level
                                      0 widget" being "a widget that adds 0 levels"?

                                      If so, try something like this.

                                      Orc is a widget that contains all of the orcish racial adjustments,
                                      including abilities, skills, etc. One part is that it does not add to
                                      level.

                                      Monk[1] is a widget that contains all of the adjustments for being a 1st
                                      level monk. One part is that it does add a level. (And as a side note,
                                      most things like unarmed damage and the like it just increments by 1 on
                                      another chart as opposed to spelling it out.)

                                      So a 2nd level orc monk would have three widgets - an orc widget, a
                                      monk[1] widget, and a monk[2] widget. Only two of those increment
                                      level, so it's a 2nd level character.

                                      Some widgets might contain a level adjustment but not a level (or HD).
                                      So that you could easily build the Savage Species 20 widget version of
                                      the Astral Deva, which has only 12 widgets that add levels (and HD), and
                                      8 widgets that don't.

                                      (Note: This is just talking out loud, not proposing any changes to
                                      Keith's ideas.)

                                      Cheers,
                                      Jim
                                    • Keith Davies
                                      ... I d rather put constraints on what data goes in, than on what the container can hold. That is, I d rather design something that can exceed current
                                      Message 18 of 21 , Jan 20, 2004
                                      View Source
                                      • 0 Attachment
                                        On Tue, Jan 20, 2004 at 08:51:13AM +0000, Frugal wrote:
                                        > <quote who="Keith Davies">
                                        > > On Thu, Jan 15, 2004 at 08:46:18AM +0000, Frugal wrote:
                                        > >> To make PCGen a generic character editor it would be quicker to rewrite
                                        > >> the whole thing from scratch than to try and make the base of PCGen
                                        > >> generic.
                                        > >
                                        > > Probably. Doesn't mean we have to constrain what the data can do just
                                        > > because the program can't deal with it <g>
                                        >
                                        > Erm... Yes it does. This is supposed to be a new data model for PCGen.
                                        > If PCGen can not use the data in the data model then the data model is
                                        > useless.

                                        I'd rather put constraints on what data goes in, than on what the
                                        container can hold. That is, I'd rather design something that can
                                        exceed current capabilities -- especially if it leads to a more elegant
                                        design -- than artificially constrain things because we can't use it all
                                        yet.

                                        > If this is supposed to be a generic data model for D&D, or a generic
                                        > model for an arbitrary RPG then the majority of PCGen will need to be
                                        > rewritten to the extent that it will effectivly become a new program.

                                        Probably. We knew this going in. We can ameliorate it be limiting the
                                        use of the framework to something that is more readily mappable to the
                                        current internal store, but it's been known for a long time that that
                                        needs to be fixed anyway.

                                        > >> PCGen does not have a hope in hell of parsing XML at any point in
                                        > >> the near future. Too much of the data parsing is done in pcgen.core
                                        > >> rather than pcgen.persistence. It will be hundreds of man hours of
                                        > >> work to refactor all of this out. No one seems particually
                                        > >> interested in doing it as there is no immediate benefit.
                                        > >
                                        > > Probably true, sadly. It'll still need to be done, though. I thought
                                        > > Bryan had it on the list of Things to Be Done.
                                        >
                                        > There are items in the "list of things to do" from 2001. Don't hold
                                        > your breath. PCGen is a community effort, which means that people will
                                        > only do what they find interesting. changing the code base without any
                                        > change in interface or functionality is way down on most peoples list
                                        > of things they wish to do. It is only sick and twisted individuals
                                        > like me who see the horrors in the code and start twitching that will
                                        > make these changes.

                                        I understood it would be high on the list of Things to Be Done, because
                                        it paves the way for XML and what that can do. OTOH, what might have
                                        been done to date may be invalidated by what's going on now, so it's not
                                        necessarily a bad thing that it hasn't happened yet.

                                        > >> At the moment I have stopped dealing with the XML side of things
                                        > >> (because refactoring _must_ come before XML, and because I do not
                                        > >> fully understand Keith's XML layer)
                                        > >
                                        > > ask away! If it's not clear, I'm not describing it well enough.
                                        >
                                        > What I would really like to see is some concrete examples. You and
                                        > Steve have been having a wonderful discussion about Ranks and
                                        > Progressions and all kinds of Airy-Fairy ideas, but I am an old
                                        > fasioned kind of guy and I need to see some examples to prove that the
                                        > high levels ideas are actually practical. And ideally the XML examples
                                        > converted into LST so that it can be seen how the new concepts will
                                        > map onto the existing structure

                                        Examples? I'll see what I can come up with after work.

                                        > Has anyone approached Bryan to see about branching the code? I think
                                        > that with all of the proposed changes, and all of the changes that
                                        > will occur because of data model changes it might be better to brnach
                                        > the code at 5.7.1 and develop on a separate tree. These changes are
                                        > going to be so broad that people are not going to want a mostly broken
                                        > PCGen for 6 months.

                                        You're probably right. We may be able to get away with the original
                                        'map XML objects to LST objects and insert into existing program', but
                                        I'm somewhat inclined to just smash things to bits and put them back
                                        together again. Not having to keep the program running when it's
                                        unstable as this will be appeals to me... and I think that, not only do
                                        we have serious changes in the data format, but a different idealogy for
                                        managing the data internally that'll make things much better.


                                        Keith
                                        --
                                        Keith Davies I gave my 2yo daughter a strawberry
                                        keith.davies@... Naomi: "Strawberry!"
                                        me: "What do you say?"
                                        Naomi: "*MY* strawberry!"
                                      • Keith Davies
                                        ... I think I was going to drop the racial definition to 0HD, then add levels from there. The default orc is a War1, IIRC. ... I was expecting to make it a
                                        Message 19 of 21 , Jan 20, 2004
                                        View Source
                                        • 0 Attachment
                                          On Tue, Jan 20, 2004 at 12:43:33PM +0000, Frugal wrote:
                                          > <quote who="Keith Davies">
                                          > > ask away! If it's not clear, I'm not describing it well enough.
                                          >
                                          > I notice in you examples of races you have a "by-class" boolean
                                          > attribute. How does your plan cope with 1HD creatures?

                                          I think I was going to drop the racial definition to 0HD, then add
                                          levels from there. The 'default' orc is a War1, IIRC.

                                          > i.e. an "Orc" is a 1HD creature, an Orc with a level of fighter is a
                                          > Ftr1. As soon as 1HD creatures take a class level they loose their 1
                                          > racial HD.
                                          >
                                          > What about the case of the Astra Deva? they can either progress by
                                          > class or not depending on how you play them. Will we need 2 race
                                          > definitions, or is the Savage Species 20 level progression a class
                                          > progression rather than a race progression?

                                          I was expecting to make it a racial progression. 'by-class' was
                                          expected to mean 'don't add racial hit dice', which I suppose could be
                                          done by just not specifying advancement at all.


                                          Keith
                                          --
                                          Keith Davies I gave my 2yo daughter a strawberry
                                          keith.davies@... Naomi: "Strawberry!"
                                          me: "What do you say?"
                                          Naomi: "*MY* strawberry!"
                                        • Keith Davies
                                          ... Yep, though characters should fit particular molds. This realization is what led to the Entity and Progression thing, and my desire for a generic
                                          Message 20 of 21 , Jan 20, 2004
                                          View Source
                                          • 0 Attachment
                                            On Tue, Jan 20, 2004 at 07:52:41AM -0500, STILES, BRAD wrote:
                                            > > -----Original Message-----
                                            > > From: Frugal [mailto:frugal@...]
                                            > >
                                            > > I have always thought that races should be class level 0.
                                            >
                                            > If you think about it, races are little more than templates laid over
                                            > a "generic" character, adding or removing abilities. If you think of
                                            > a character as nothing more than a set of stats, then selecting
                                            > *anything* else becomes a set of modifiers, additions, restrictions,
                                            > bonuses, penalties, etc to that character. Including race, alignment,
                                            > class, etc.

                                            Yep, though characters should fit particular molds.

                                            This realization is what led to the Entity and Progression thing, and my
                                            desire for a generic GameObject class in Java (which I was unable to
                                            come up with a decent implementation of :/)

                                            > I believe Keith noticed the transactional nature of most PCGen things
                                            > when he got into the LST files.

                                            That came up when I was trying to resolve multiple elements with the
                                            same IDs. That violates XML methodology, *unless* the ID is referring
                                            to a entity to manipulate. The XML files are transactional, entity
                                            behavior isn't, quite, though it should be able to track changes over
                                            time.


                                            Keith
                                            --
                                            Keith Davies I gave my 2yo daughter a strawberry
                                            keith.davies@... Naomi: "Strawberry!"
                                            me: "What do you say?"
                                            Naomi: "*MY* strawberry!"
                                          • Keith Davies
                                            ... Or, say, Entity? With a subtype called Progression ? ... Yep, adding ranks in the Monk progression adds ranks in the Monk Unarmed Combat progression
                                            Message 21 of 21 , Jan 20, 2004
                                            View Source
                                            • 0 Attachment
                                              On Tue, Jan 20, 2004 at 09:57:45AM -0500, CC Noram Carstensen James wrote:
                                              > Frugal wrote:
                                              > > I have always thought that races should be class level 0.
                                              > >
                                              > > A first level human monk should be 0:Human, 1:Monk
                                              > >
                                              > > A first level Orc should be 0:Orc-Race, 1:Orc
                                              > >
                                              > > A first level Orc Monk should be 0:Orc-Race, 1:Monk
                                              > >
                                              > > An Orge/Mnk1 shoudl be 0:Ogre, 1:Giant, 2:Giant, 3:Giant, 4:Giant,
                                              > > 5:Monk
                                              > >
                                              > > An Ogre/Mnk1 character with 2ECL should be 0:Ogre, 1:Giant, 2:Giant,
                                              > > 3:Giant, 4:Giant, 5:ECL, 6:ECL, 7:Monk
                                              > >
                                              > > An AstraDeva should be 0:Celestial, 1:AstraDeva, 2:AstraDeva ...
                                              >
                                              > This I can sink my teeth into. I like it.
                                              >
                                              > Though the ECL example gets a bit odd because it's really a Level
                                              > Adjustment, not a real level, so it doesn't trigger some level-based
                                              > events (like feats and ability increases).
                                              >
                                              > Of course, I think that races, monster levels, templates, and class
                                              > levels are all really the same thing at the core. Let's call that a
                                              > Widget just for discussion.

                                              Or, say, Entity? With a subtype called 'Progression'?

                                              > Frugal, would your comments above be okay with instead of being "a
                                              > level 0 widget" being "a widget that adds 0 levels"?
                                              >
                                              > If so, try something like this.
                                              >
                                              > Orc is a widget that contains all of the orcish racial adjustments,
                                              > including abilities, skills, etc. One part is that it does not add to
                                              > level.
                                              >
                                              > Monk[1] is a widget that contains all of the adjustments for being a
                                              > 1st level monk. One part is that it does add a level. (And as a side
                                              > note, most things like unarmed damage and the like it just increments
                                              > by 1 on another chart as opposed to spelling it out.)

                                              Yep, adding ranks in the Monk progression adds ranks in the 'Monk
                                              Unarmed Combat progression' (for lack of a better name); I never even
                                              considered putting the actual monk unarmed stuff *in* Monk. Same with
                                              spellcasting ability (because prestige classes give ranks in it as
                                              well).

                                              > So a 2nd level orc monk would have three widgets - an orc widget, a
                                              > monk[1] widget, and a monk[2] widget. Only two of those increment
                                              > level, so it's a 2nd level character.

                                              Slightly different emphasis than I had, but not unreasonable.

                                              > Some widgets might contain a level adjustment but not a level (or HD).
                                              > So that you could easily build the Savage Species 20 widget version of
                                              > the Astral Deva, which has only 12 widgets that add levels (and HD),
                                              > and 8 widgets that don't.
                                              >
                                              > (Note: This is just talking out loud, not proposing any changes to
                                              > Keith's ideas.)

                                              Actually, what you're describing here very much matches what I've
                                              designed. Progressions group them to ensure they happen in a particular
                                              order without having extraneous prereqs ('to get Monk[2] you must have
                                              Monk[1]'). The 'Astral Deva Widgets' you describe fit the 'Astra Deva
                                              Pre-base Progression' I was trying to describe.

                                              There are few differences (such as having level just be another score;
                                              I don't recall if I was going to track it or just count when I needed to
                                              know, but tracking it makes a fair amount of sense), but nothing that
                                              far out of line.

                                              Remember, everyone, the Wiki describes *a* way to implement D&D.
                                              Details (structure of individual entities, etc.) are expected to change,
                                              though I expect the framework to stay much the same.


                                              Keith
                                              --
                                              Keith Davies I gave my 2yo daughter a strawberry
                                              keith.davies@... Naomi: "Strawberry!"
                                              me: "What do you say?"
                                              Naomi: "*MY* strawberry!"
                                            Your message has been successfully submitted and would be delivered to recipients shortly.