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

[pcgen-xml] New .lst Format (was: It lives! And is reborn!)

Expand Messages
  • gamer_dude@comcast.net
    ... ... Certainly. It could even be stored as a single piece, but the data model should certainly distinguish the two aspects. Section 2 could be viewed as a
    Message 1 of 8 , Sep 30, 2005
    • 0 Attachment

      -------------- Original message --------------
      ...
      Certainly.  It could even be stored as a single piece, but the data
      model should certainly distinguish the two aspects.  Section 2 could
      be viewed as a set of annotations on section 1.  Keeping them separate
      could make it easier for a human to consume the storage file directly
      (in a text editor, for instance).  Keeping them together could make it
      easier for a human to modify the stored data in a text editor.

      So I'll go so far as to suggest that applications should write out
      both sections 1 & 2, and that humans armed with text editors remove
      section 1 if they modify section 2, and let applications regenerate
      that as needed.

      Hmm.  Should the sections have better names yet?  I could see
      something like Decision, Transformation, and Sheet sections.  (Where
      Sheet sections can occur zero or more times, and each has a reference
      to the point in the Decision or Transformation section that it
      corresponds to.
      --------------------------------------------------------------------

      I've been reading the discussion and thinking about what's been said.

      I can see why some users would want to have not just what was changed at each level but also the "totals" (aka "Results") at each level, as well as the current state of the character.

      But, even with that understanding, everything in my mind keeps screaming "normalization!  Never duplicate data unnecessarily".  So, I still have a problem wrapping my mind around needing a complete repeat of the Section 1 in Section 2.  If people are going to edit section 2 in a text editor and let the program rebuild section 1, then what purpose does section one actually serve? Why not just elimitate section 1?  This will elimiate not only the duplication, but the code in the program for checking if section 1 is there/does it match section 2/etc. (the fewer things you need to code for/check for, the fewer places for BUGS!).

      For section 3, I realized that while in most circumstances a level-roll-back wouldn't include changing their inventory of items. Typically "oh darn, your character just lost 3 levels and is back to 5th level AND he looses the equipment in that time too" isn't going to happen.  BUT, when loading the character to a previous version (past level) to be played at that level (i.e. the 8th lvl character being played at his 5th level incarnation in a 5th level game) WILL need to have his equipment rolled back (that nasty balance thing, just how many people are going to allow higher leveld items from a character's "Future" version?).

      Consider this:

      SECTION 1:
      A snapshot of the character at each level, taken immediately after being leveled up (1st, 2nd, 3rd) including equipment/items.
      SECTION 2:
      A snapshot of all totals such as BAB, Saves, etc.
      SECTION 3:
      The character in their current state (even if lower than the highest level reached).

      THis would provide all the information about a character, track changes at each increase in level, and present the current state of the character all a reduction of data duplication.

      Al B.
      Spokane, WA

       

       
    • Devon Jones
      Just to be clear (referencing the title) we are *not* considering XML for lst at this time, this is purely XML for the saved .pcg file. XML for lst is a much
      Message 2 of 8 , Oct 3, 2005
      • 0 Attachment
        Just to be clear (referencing the title) we are *not* considering XML
        for lst at this time, this is purely XML for the saved .pcg file. XML
        for lst is a much larger, much harder problem - but the coming changes
        in pcgen's internals will require a new character save format, and thus
        the door has been opened to consider a totally new format for the save
        files.

        gamer_dude@... wrote:

        > I've been reading the discussion and thinking about what's been said.
        >
        > I can see why some users would want to have not just what was changed
        > at each level but also the "totals" (aka "Results") at each level, as
        > well as the current state of the character.
        >
        > But, even with that understanding, everything in my mind keeps
        > screaming "normalization! Never duplicate data unnecessarily". So, I
        > still have a problem wrapping my mind around needing a complete repeat
        > of the Section 1 in Section 2. If people are going to edit section 2
        > in a text editor and let the program rebuild section 1, then what
        > purpose does section one actually serve? Why not just elimitate
        > section 1? This will elimiate not only the duplication, but the code
        > in the program for checking if section 1 is there/does it match
        > section 2/etc. (the fewer things you need to code for/check for, the
        > fewer places for BUGS!).
        >
        > For section 3, I realized that while in most circumstances a
        > level-roll-back wouldn't include changing their inventory of items.
        > Typically "oh darn, your character just lost 3 levels and is back to
        > 5th level AND he looses the equipment in that time too" isn't going to
        > happen. BUT, when loading the character to a previous version (past
        > level) to be played at that level (i.e. the 8th lvl character being
        > played at his 5th level incarnation in a 5th level game) WILL need to
        > have his equipment rolled back (that nasty balance thing, just how
        > many people are going to allow higher leveld items from a character's
        > "Future" version?).
        >
        > Consider this:
        >
        > SECTION 1:
        > A snapshot of the character at each level, taken immediately after
        > being leveled up (1st, 2nd, 3rd) including equipment/items.
        > SECTION 2:
        > A snapshot of all totals such as BAB, Saves, etc.
        > SECTION 3:
        > The character in their current state (even if lower than the highest
        > level reached).
        >
        > THis would provide all the information about a character, track
        > changes at each increase in level, and present the current state of
        > the character all a reduction of data duplication.
        >
        > Al B.
        > Spokane, WA
        >
        Ok, the deal is this, the 3 sections have different consumers:
        1) this section only contains what pcgen needs to recreate the
        character. *No* extra data. No final numbers. Nothing other then the
        bare minimum needed to recreate the character.
        2) This is purely a debug section (from my perspective). If someone were
        to use this data, that's fine - but this is intended to leave a record
        of what has happened so that pcgen developers can more easily debug
        problems with characters.
        3) We already basically create this document to do exports from, and I
        would like to eliminate that extra step, and just run exports off the of
        pcg file. Section 3 has other clear benefits - 1, it's a good export
        format, because it's utterly program neutral. 2, it can mean other
        programs can produce it, and we can make pretty character sheets (or
        other transformations for other programs, or even loading read only
        copies of characters from other programs)

        This isn't a database, so normalization doesn't necessarily apply, this
        is a consumer focused format - we are building each section to stand
        alone (as each section is optional) and to fill the needs of one group
        of consumers as perfectly as we can.

        Devon
      • Al Beddow
        I ll re-add my thoughts as others have... ... Fine ... Not needed... ... Of course ... I used normalization as a way to show where my thinking was coming
        Message 3 of 8 , Oct 3, 2005
        • 0 Attachment
          I'll re-add my thoughts as others have...

          Devon Jones wrote:

          > J
          > Ok, the deal is this, the 3 sections have different consumers:
          > 1) this section only contains what pcgen needs to recreate the
          > character. *No* extra data. No final numbers. Nothing other then the
          > bare minimum needed to recreate the character.

          Fine


          > 2) This is purely a debug section (from my perspective). If someone were
          > to use this data, that's fine - but this is intended to leave a record
          > of what has happened so that pcgen developers can more easily debug
          > problems with characters.

          Not needed...


          > 3) We already basically create this document to do exports from, and I
          > would like to eliminate that extra step, and just run exports off the of
          > pcg file. Section 3 has other clear benefits - 1, it's a good export
          > format, because it's utterly program neutral. 2, it can mean other
          > programs can produce it, and we can make pretty character sheets (or
          > other transformations for other programs, or even loading read only
          > copies of characters from other programs)

          Of course

          >
          > This isn't a database, so normalization doesn't necessarily apply, this
          > is a consumer focused format - we are building each section to stand
          > alone (as each section is optional) and to fill the needs of one group
          > of consumers as perfectly as we can.

          I used 'normalization' as a way to show where my thinking was coming
          from. As one person said on the list, when you are trying to compress
          whole campaings down to transfer on even a flash drive, size counts.
          Telling someone to 'just get a bigger flash drive' makes you sound like
          someone at microserf "we don't need to write tight effective code, just
          go out and get a faster computer."

          In my mind there seems to be a die-hard grip on what was originally
          proposed, to the point of insisting on it being 'this way' no matter what.

          Al B.
          Spokane, WA



          --
          No virus found in this outgoing message.
          Checked by AVG Anti-Virus.
          Version: 7.0.344 / Virus Database: 267.11.9/118 - Release Date: 10/3/2005
        • Devon Jones
          ... keep in mind, this is text. I just tested out one of these files (the ziped up style I was recommending in the next thread), and *with* an embedded image
          Message 4 of 8 , Oct 4, 2005
          • 0 Attachment
            Al Beddow wrote:

            >I used 'normalization' as a way to show where my thinking was coming
            >from. As one person said on the list, when you are trying to compress
            >whole campaings down to transfer on even a flash drive, size counts.
            >Telling someone to 'just get a bigger flash drive' makes you sound like
            >someone at microserf "we don't need to write tight effective code, just
            >go out and get a faster computer."
            >
            >
            keep in mind, this is text. I just tested out one of these files (the
            ziped up style I was recommending in the next thread), and *with* an
            embedded image it came out to a whopping 20k or so. As it stands, a) we
            have said that section 2 is optional, and b) it's for debug - but if you
            seriously think that being able to debug people's broken characters is
            unimportant....

            >In my mind there seems to be a die-hard grip on what was originally
            >proposed, to the point of insisting on it being 'this way' no matter what.
            >
            >
            Did you see the new proposal? It took a number of ideas people had
            (such as using other formats like Open rpg and twin rose), separated out
            the files, added them to a zip, and did a whole bunch of other
            transformations to what we are talking about. I think this charge is a
            little harsh, considering that the extended proposal is umm, pretty
            fundamentally different then the current one.

            Devon
          • Brass Tilde
            ... While I completely agree that the criticism is harsh (though I would say more than a little, and unjustified to boot), I m not sure I agree with
            Message 5 of 8 , Oct 4, 2005
            • 0 Attachment
              > >In my mind there seems to be a die-hard grip on what was originally
              > >proposed, to the point of insisting on it being 'this way'
              > > no matter what.

              > charge is a little harsh, considering that the extended proposal is
              > umm, pretty fundamentally different then the current one.

              While I completely agree that the criticism is harsh (though I would say
              more than a little, and unjustified to boot), I'm not sure I agree with
              "fundamentally" different. Significant, yes. Fundamental, no.

              What about your new proposal of a multi-document, single package format
              is different in kind, rather than degree, from the multi-section single
              file format proposed earlier? Off the top of my head, I didn't see
              anything in the new format that couldn't have been stored in the old one
              (though I will freely admit that storing an image as a 7 bit encoded
              CDATA element would be...unweildy. :-)

              It's certainly well within the realm of possibility that my failure to
              see this difference is my own lack of understanding.

              Bear in mind that I think your new proposal is a *good* one, and
              implemented properly, will help support an ever greater degree of
              functionality in PCGen
            • gamer_dude@comcast.net
              ... Debuging is nice and I agree that a data format which lets you debug will be helpful. I guessing that there is an idea that I m just not catching. In my
              Message 6 of 8 , Oct 4, 2005
              • 0 Attachment

                >keep in mind, this is text.  I just tested out one

                >of these files (the ziped up style I was recommending
                >in the next thread), and *with* an embedded image it
                >came out to a whopping 20k or so.  As it stands,
                >a) we have said that section 2 is optional, and b)
                >it's for debug

                Debuging is nice and I agree that a data format which lets you debug will be helpful.  I guessing that there is an idea that I'm just not catching.  In my mind, what was proposed for section 2 (S2) could handle the purposes of S1 and S2, without having S2. In other words, just put the totals in S1, forget duplicating of the bulk of the info.  If debugging is not implemented (or the feature not being used) then the program can just put the data away (so it will be saved out on an update) or ignore it and re-calculate it when the file is re-saved (or something in between, that's an implementation choice).

                I had a little character tracker a long time ago, written in GW Basic (pre-windows days) in which I did things like this.  I didnt' save as much info since the characters were simpler, but it was close.  Mainly I saved HP gained as well as the new total.  While this was just one peice of data, and the only one that was a 'randomly added' peice of inforation at each level, I didn't implement a two step process (S1, S2). 

                Yes drives are bigger today, we have great file compression tools, etc. but I come from the school of programming which hammered home: "keep your code neat, avoid duplication of data and code whenever possible, and document document document." (one of my first semester classes was "business programming logic" an entire semester of nothing but flow-charting logic, which tells you how long ago this was). So to me it doesn't matter if the file is text, a graphic, or random characters being tossed out to just fill drive space.  Duplication of information always makes me think three times about if that duplication is needed.


                >- but if you seriously think that being able to

                >debug people's broken characters is unimportant...
                Talk about "harsh", especially when I never criticized the idea of debugging and in light of the observation below. In my experiance, comments like that are used by people who have a 'death grip' on their viewpoint and are trying to paint the other person in a negative light (basically accuses the other person of not caring).

                >Did you see the new proposal? 
                No, I didn't see it until last night, when I got home after work.  It's on my 'read' list for this week.


                >I think this charge is a little harsh, considering

                >that the extended proposal is umm, pretty
                >fundamentally different then the current one.
                Please accept my appologies. Seriously, I didn't mean to be harsh or rude, just plain spoken.  The impression I stated ("seems to be" instead of "you have a") was just that, an impression.  I will try to be more aware of how I state my impression.

                 

                Al B.


              • Devon Jones
                ... Fair point :) Devon
                Message 7 of 8 , Oct 4, 2005
                • 0 Attachment
                  Brass Tilde wrote:

                  >While I completely agree that the criticism is harsh (though I would say
                  >more than a little, and unjustified to boot), I'm not sure I agree with
                  >"fundamentally" different. Significant, yes. Fundamental, no.
                  >
                  >What about your new proposal of a multi-document, single package format
                  >is different in kind, rather than degree, from the multi-section single
                  >file format proposed earlier? Off the top of my head, I didn't see
                  >anything in the new format that couldn't have been stored in the old one
                  >(though I will freely admit that storing an image as a 7 bit encoded
                  >CDATA element would be...unweildy. :-)
                  >
                  >It's certainly well within the realm of possibility that my failure to
                  >see this difference is my own lack of understanding.
                  >
                  >Bear in mind that I think your new proposal is a *good* one, and
                  >implemented properly, will help support an ever greater degree of
                  >functionality in PCGen
                  >
                  >
                  Fair point :)

                  Devon
                • Devon Jones
                  ... See, and I don t necessarily expect it to be quite that - I m expecting it to be more of a file that lets the program log, non-destructively, so that the
                  Message 8 of 8 , Oct 5, 2005
                  • 0 Attachment
                    gamer_dude@... wrote:

                    > Debuging is nice and I agree that a data format which lets you debug
                    > will be helpful. I guessing that there is an idea that I'm just not
                    > catching. In my mind, what was proposed for section 2 (S2) could
                    > handle the purposes of S1 and S2, without having S2. In other words,
                    > just put the totals in S1, forget duplicating of the bulk of the
                    > info. If debugging is not implemented (or the feature not being used)
                    > then the program can just put the data away (so it will be saved out
                    > on an update) or ignore it and re-calculate it when the file is
                    > re-saved (or something in between, that's an implementation choice).
                    >
                    > I had a little character tracker a long time ago, written in GW Basic
                    > (pre-windows days) in which I did things like this. I didnt' save as
                    > much info since the characters were simpler, but it was close. Mainly
                    > I saved HP gained as well as the new total. While this was just one
                    > peice of data, and the only one that was a 'randomly added' peice of
                    > inforation at each level, I didn't implement a two step process (S1,
                    > S2).
                    >
                    > Yes drives are bigger today, we have great file compression tools,
                    > etc. but I come from the school of programming which hammered home:
                    > "keep your code neat, avoid duplication of data and code whenever
                    > possible, and document document document." (one of my first semester
                    > classes was "business programming logic" an entire semester of nothing
                    > but flow-charting logic, which tells you how long ago this was). So to
                    > me it doesn't matter if the file is text, a graphic, or random
                    > characters being tossed out to just fill drive space. Duplication of
                    > information always makes me think three times about if that
                    > duplication is needed.
                    >
                    See, and I don't necessarily expect it to be quite that - I'm expecting
                    it to be more of a file that lets the program log, non-destructively, so
                    that the programmer can see a history of what's been done to the file.
                    Keith and I have a somewhat different outlook on some of these pieces.
                    I se it as this:
                    Section 1) Minimum of data needed to re-create character in pcgen
                    Section 2) Log
                    Section 3) Full character representation

                    But the important pare to me is that I see section 2 literally as a log,
                    not just a list of consequences and changes - but a record of what
                    operations were run on the file, for each program that wrote to it.

                    As it stands, this is all kind of different now (to some degree at
                    least) in the other thread.

                    And as I have said, I don't expect S2 to get implemented any time soon,
                    if at all. S1 & 3 are the ones that we need. S2 is just a nice to have.

                    > Talk about "harsh", especially when I never criticized the idea of
                    > debugging and in light of the observation below. In my experiance,
                    > comments like that are used by people who have a 'death grip' on their
                    > viewpoint and are trying to paint the other person in a negative light
                    > (basically accuses the other person of not caring).
                    >
                    Fair enough, I appologize.

                    > Please accept my appologies. Seriously, I didn't mean to be harsh or
                    > rude, just plain spoken. The impression I stated ("seems to be"
                    > instead of "you have a") was just that, an impression. I will try to
                    > be more aware of how I state my impression.
                    >
                    Appology accepted, sorry I was harsh in my reply. I really appreciate
                    input, and I deeply don't want to discourage people from stating their
                    ideas plainly as you have here - it really is appreciated.


                    Devon
                  Your message has been successfully submitted and would be delivered to recipients shortly.