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

It lives! And is reborn!

Expand Messages
  • Keith Davies
    Hi All, I just finished an interesting IM conversation with Devon. Here s what he s looking for -- and it s pretty easy, I think. Continue using LST format
    Message 1 of 19 , Sep 29, 2005
    • 0 Attachment
      Hi All,

      I just finished an interesting IM conversation with Devon. Here's what
      he's looking for -- and it's pretty easy, I think.

      Continue using LST format for PCC files, for now at least. We may
      revisit it later and convert the LST files to XML.

      The character file would consist of three sections. Each section is
      optional, but there are reasons for each.


      Section 1

      The first is the primary working data for PCGen. It logs all
      construction decisions, but no consequences. For instance, it will
      log that you add a level of fighter, the hit points gained, the feat
      selected, and where the skill points were assigned.

      By using this structure (which is similar to that of CDOM), it becomes
      possible to roll back decisions. It'll be possible to remove levels,
      for example.

      Section 2

      The second expands on the first, showing the 'non-decision' data.
      For instance, where section shows "add a level of fighter, gain 8 hit
      points, take Cleave, assign 3 skill points to Swim skill", this would
      show "add a level of fighter, gain 8 hit points, take Cleave, assign 3
      skill points to Swim skill, +1 BAB, +1 Fort".

      Actually, I'd like to go a step further and show running totals:
      "add a level of fighter (now Ftr8), gain 8 hit points (57 total), take
      Cleave, assign 3 skill points to Swim skill (6 ranks now), +1 BAB (+8
      total), +1 Fort (+6 total)".

      (All examples above 'translated to English')

      This has two primary purposes. One is to allow third-party tools to
      reconstruct the character at various points -- show what a character
      looked like at fourth level, when now nineth. It should also be very
      useful for debugging purposes, especially if it shows running totals.
      It would basically be a (partial) dump of the character after each
      transformation. (I'd limit it to just showing the bits that actually
      change at each transformation, or it'd be an ugly thing to try to
      examine.)

      Section 3

      The third is the reason we're doing all this. It contains the
      character in final form. All totals shown, no subtotals, etc. (except
      where they are themselves useful, such as Touch AC).

      This section could be imported into other programs, pushed through a
      transformation to be output, or even imported by PCGen for
      presentation (but *not* for deconstruction, I think... way too hard).


      I considered having multiple versions of the character in the third
      section (in case you want a copy of the character at each character
      level) but for now I wouldn't worry about it. The first shows how the
      character is constructed (sufficent to reconstruct), the second shows
      details (for examination -- debugging or third-party reconstruction),
      the third shows only the results.

      Happily, all three sections will be relatively easy to design.


      Keith
      --
      Keith Davies "Always code as if the guy who ends up
      keith.davies@... maintaining your code is a psychopath
      keith.davies@... who knows where you live."
      http://www.kjdavies.org/ -- Damian Conway
    • Edwin Holley
      This would be awesome ... I would especially like to be able to (if I were GMing) be able to look at the way points were utilized at each level. It would also
      Message 2 of 19 , Sep 29, 2005
      • 0 Attachment
        This would be awesome ... I would especially like to be able to (if I were
        GMing) be able to look at the way points were utilized at each level. It
        would also allow the character to be played at any of his levels, which is
        great when visiting different games, I would love to be able to do some
        journaling in this section as well.

        -----Original Message-----
        From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com] On Behalf
        Of Keith Davies
        Sent: Thursday, September 29, 2005 16:02
        To: PCGen-XML
        Subject: [pcgen-xml] It lives! And is reborn!

        Hi All,

        I just finished an interesting IM conversation with Devon. Here's what
        he's looking for -- and it's pretty easy, I think.

        Continue using LST format for PCC files, for now at least. We may
        revisit it later and convert the LST files to XML.

        The character file would consist of three sections. Each section is
        optional, but there are reasons for each.


        Section 1

        The first is the primary working data for PCGen. It logs all
        construction decisions, but no consequences. For instance, it will
        log that you add a level of fighter, the hit points gained, the feat
        selected, and where the skill points were assigned.

        By using this structure (which is similar to that of CDOM), it becomes
        possible to roll back decisions. It'll be possible to remove levels,
        for example.

        Section 2

        The second expands on the first, showing the 'non-decision' data.
        For instance, where section shows "add a level of fighter, gain 8 hit
        points, take Cleave, assign 3 skill points to Swim skill", this would
        show "add a level of fighter, gain 8 hit points, take Cleave, assign 3
        skill points to Swim skill, +1 BAB, +1 Fort".

        Actually, I'd like to go a step further and show running totals:
        "add a level of fighter (now Ftr8), gain 8 hit points (57 total), take
        Cleave, assign 3 skill points to Swim skill (6 ranks now), +1 BAB (+8
        total), +1 Fort (+6 total)".

        (All examples above 'translated to English')

        This has two primary purposes. One is to allow third-party tools to
        reconstruct the character at various points -- show what a character
        looked like at fourth level, when now nineth. It should also be very
        useful for debugging purposes, especially if it shows running totals.
        It would basically be a (partial) dump of the character after each
        transformation. (I'd limit it to just showing the bits that actually
        change at each transformation, or it'd be an ugly thing to try to
        examine.)

        Section 3

        The third is the reason we're doing all this. It contains the
        character in final form. All totals shown, no subtotals, etc. (except
        where they are themselves useful, such as Touch AC).

        This section could be imported into other programs, pushed through a
        transformation to be output, or even imported by PCGen for
        presentation (but *not* for deconstruction, I think... way too hard).


        I considered having multiple versions of the character in the third
        section (in case you want a copy of the character at each character
        level) but for now I wouldn't worry about it. The first shows how the
        character is constructed (sufficent to reconstruct), the second shows
        details (for examination -- debugging or third-party reconstruction),
        the third shows only the results.

        Happily, all three sections will be relatively easy to design.


        Keith
        --
        Keith Davies "Always code as if the guy who ends up
        keith.davies@... maintaining your code is a psychopath
        keith.davies@... who knows where you live."
        http://www.kjdavies.org/ -- Damian Conway




        Yahoo! Groups Links
      • gamer_dude@comcast.net
        I know I m new to PCGen and the e-lists, but I have a reasonable background in computers, data, etc. and for what it is worth offer my 2 bits. Al B. Spokane,
        Message 3 of 19 , Sep 29, 2005
        • 0 Attachment
          I know I'm new to PCGen and the e-lists, but I have a reasonable background in computers, data, etc. and for what it is worth offer my 2 bits.
          Al B.
          Spokane, WA
           
          -------------- Original message --------------
          Hi All,

          I just finished an interesting IM conversation with Devon.  Here's what he's looking for -- and it's pretty easy, I think.
          Continue using LST format for PCC files, for now at least.  We may revisit it later and convert the LST files to XML.
          The character file would consist of three sections.  Each section is optional, but there are reasons for each.
          ------------ Original message  end ---------- 
           
          I like the idea of eventually going to XML.  Getting rid of all the tabs in favor of tags would make things easier  to 'read'.
           
          -------------- Original message --------------
          Section 1
          The first is the primary working data for PCGen.  It logs all construction decisions, but no consequences.  For instance, it will  log that you add a level of fighter, the hit points gained, the feat  selected, and where the skill points were assigned.
          ...
           
          Section 2
          The second expands on the first, showing the 'non-decision' data...
          Actually, I'd like to go a step further and show running totals:  "add a level of fighter (now Ftr8), gain 8 hit points (57 total), take Cleave, assign 3 skill points to Swim skill (6 ranks now), +1 BAB (+8 total), +1 Fort (+6 total)".

           (All examples above 'translated to English')

          This has two primary purposes.  One is to allow third-party tools to  reconstruct the character at various points -- show what a character looked like at fourth level, when now nineth.  It should also be very  useful for debugging purposes, especially if it shows running totals.  It would basically be a (partial) dump of the character after each transformation.  (I'd limit it to just showing the bits that actually  change at each transformation, or it'd be an ugly thing to try to  examine.)
          ------------ Original message  end ---------- 
           
          Great Idea!  Being able to roll a character back WITHOUT having to save it at each level is a concept overdue.  Imagine a program like PCGen offering the option to view (and print) a character at each stage of it's life.  Wow talk about almost no headaches when the big warrior gets drained of two levels in the middle of the session.
           
          My only concern in reading the suggestion is "why have TWO sections with basically identical data?"  I think the proposed section 2 could easily handle the purposes of what sections 1 and 2 are for, without the near complete duplication of the same information.
           
          -------------- Original message --------------
          Section 3

          The third is the reason we're doing all this.  It contains the character in final form.  All totals shown, no subtotals, etc. (except where they are themselves useful, such as Touch AC).

          This section could be imported into other programs, pushed through a transformation to be output, or even imported by PCGen for presentation (but *not* for deconstruction, I think... way too hard).
          ------------ Original message  end ---------- 
           
          First thought that comes to mind is... Wouldn't it be simpler to just have a field noting the current level of the character.  When a character has to be 'rolled-back' a nubmer of levels, none of the leveling information would be deleted, and instead of storing a duplicate of the information contained in the "current character level", the file just stores a simple field indicating the current character level.  No destruction of data and allows the GM/Player to store the character at their current level while using a minimum of space for all the information.
        • Brass Tilde
          ... Why have two sections containing the same data? Ease of processing, or some other reason? It would seem simpler to either confine section 2 to the
          Message 4 of 19 , Sep 29, 2005
          • 0 Attachment
            > Section 1
            >
            > Section 2
            >
            > The second expands on the first, showing the 'non-decision' data.
            > For instance, where section shows "add a level of fighter,
            > gain 8 hit points, take Cleave, assign 3 skill points to Swim skill",
            > this would show "add a level of fighter, gain 8 hit points, take
            > Cleave, assign 3 skill points to Swim skill, +1 BAB, +1 Fort".

            Why have two sections containing the same data? Ease of processing, or some
            other reason? It would seem simpler to either confine section 2 to the
            "non-decision" data, in your case +1 BAB, +1 Fort, or to just eliminate
            section 1 entirely. Unless I've missed something obvious, or you've left
            something out.

            > Actually, I'd like to go a step further and show running totals:

            Which is what section 3 is for, no?

            As I say, if I've missed something, let me know.
          • Keith Davies
            ... Please don t quote like that. It s very hard to read. I ve fixed it this time. ... That was part of my original impetus -- making all syntactical
            Message 5 of 19 , Sep 29, 2005
            • 0 Attachment
              On Thu, Sep 29, 2005 at 09:42:09PM +0000, gamer_dude@... wrote:
              > I know I'm new to PCGen and the e-lists, but I have a reasonable
              > background in computers, data, etc. and for what it is worth offer my
              > 2 bits.

              Please don't quote like that. It's very hard to read. I've fixed it
              this time.

              > > I just finished an interesting IM conversation with Devon. Here's
              > > what he's looking for -- and it's pretty easy, I think. Continue
              > > using LST format for PCC files, for now at least. We may revisit it
              > > later and convert the LST files to XML. The character file would
              > > consist of three sections. Each section is optional, but there are
              > > reasons for each.
              >
              > I like the idea of eventually going to XML. Getting rid of all the
              > tabs in favor of tags would make things easier to 'read'.

              That was part of my original impetus -- making all syntactical elements
              visible. Another was properly representing the hierarchical data.

              > > Section 1 The first is the primary working data for PCGen. It logs
              > > all construction decisions, but no consequences. For instance, it
              > > will log that you add a level of fighter, the hit points gained,
              > > the feat selected, and where the skill points were assigned. ...
              > >
              > > Section 2 The second expands on the first, showing the
              > > 'non-decision' data... Actually, I'd like to go a step further and
              > > show running totals: "add a level of fighter (now Ftr8), gain 8 hit
              > > points (57 total), take Cleave, assign 3 skill points to Swim skill
              > > (6 ranks now), +1 BAB (+8 total), +1 Fort (+6 total)".
              > >
              > > (All examples above 'translated to English')
              > >
              > > This has two primary purposes. One is to allow third-party tools to
              > > reconstruct the character at various points -- show what a character
              > > looked like at fourth level, when now nineth. It should also be
              > > very useful for debugging purposes, especially if it shows running
              > > totals. It would basically be a (partial) dump of the character
              > > after each transformation. (I'd limit it to just showing the bits
              > > that actually change at each transformation, or it'd be an ugly
              > > thing to try to examine.)

              > Great Idea! Being able to roll a character back WITHOUT having to
              > save it at each level is a concept overdue. Imagine a program like
              > PCGen offering the option to view (and print) a character at each
              > stage of it's life. Wow talk about almost no headaches when the big
              > warrior gets drained of two levels in the middle of the session.
              >
              > My only concern in reading the suggestion is "why have TWO sections
              > with basically identical data?" I think the proposed section 2 could
              > easily handle the purposes of what sections 1 and 2 are for, without
              > the near complete duplication of the same information.

              These two sections have different purpose and application, despite being
              somewhat similar.

              The first is intended to tell PCGen how the character is constructed.
              It depends on the rest of the data (class definitions, etc.) being
              available. It is expected to have minimal redundancy. It will be
              highly resilient in the face of changes to these definitions.

              The second would be *very* redundant, but also very incomplete. That
              is, if you have eight levels of fighter, it describes the effects of
              those levels of fighter on your character... with no indicatation that
              the fighter class even has a ninth level. It could be transformed to
              create the third section, if necessary, but contains way more than is
              needed by PCGen.

              Also, and very important to me, it runs the risk of introducing
              inconsistency. If the definition of an entity changes, the information
              in the second section could be rendered incorrect.

              I don't mind being *wrong*, but I had being inconsistent.

              Now, this potential inconsistency isn't a problem the way I propose to
              use it. In fact, it's quite useful because it makes it very easy to see
              what changes are being made and when, which can uncover problems with
              the data or software. I.e. *here*, inconsistency serves a useful
              purpose.

              Granted, we could simply ignore the inconsistencies, just picking up
              what we need when loading it for editing by PCGen.

              It's probably a matter of preference. The first section as I've
              described it is *necessary*. The second section isn't, but is useful.
              I don't like mixing optional data and required data in the same
              containers, especially when it isn't evident through examination which
              is which.

              Also, frankly, the first section as described is pretty easy to
              implement. The second will be harder and probably more error-prone.
              There's a certain amount of overlap between them and probably code
              reuse, but we can prove the first section fairly easily. The second
              will be more work.

              IOW, I want a nice, simple, easily implemented and proven section, and a
              rather-useful-but-not-*required* section... especially if that second
              section will be harder to implement and prove.

              > > Section 3
              > >
              > > The third is the reason we're doing all this. It contains the
              > > character in final form. All totals shown, no subtotals, etc.
              > > (except where they are themselves useful, such as Touch AC).
              > >
              > > This section could be imported into other programs, pushed through a
              > > transformation to be output, or even imported by PCGen for
              > > presentation (but *not* for deconstruction, I think... way too
              > > hard).
              >
              > First thought that comes to mind is... Wouldn't it be simpler to just
              > have a field noting the current level of the character. When a
              > character has to be 'rolled-back' a nubmer of levels, none of the
              > leveling information would be deleted, and instead of storing a
              > duplicate of the information contained in the "current character
              > level", the file just stores a simple field indicating the current
              > character level. No destruction of data and allows the GM/Player to
              > store the character at their current level while using a minimum of
              > space for all the information.

              Not really.

              See, the first section knows nothing about running totals. It's useless
              without the rest of the data.

              The second section *does* know about running totals, but *doesn't*
              include a snapshot of the entire character with each transformation. It
              would be huge, which makes it harder to use for a couple of reasons.

              1. storage requirements. Who cares? It seems highly unlike that it'd
              get big enough to matter.

              2. examination difficulty. This is a much more important one, IMO. If
              you show the entire state, that means the whole thing needs to be
              examined if you're trying to figure out what happened. If you only
              highlight what changed (including the new (and possibly old) values)
              then it's very easy to see the effects of the change.

              I see no reason why you couldn't generate the third section "as at" a
              particular transformation (right after 4th level, say), despite having
              10 levels of information present. In fact, you could generate *just*
              the third section, without including either of the others.


              Keith
              --
              Keith Davies "Always code as if the guy who ends up
              keith.davies@... maintaining your code is a psychopath
              keith.davies@... who knows where you live."
              http://www.kjdavies.org/ -- Damian Conway
            • Keith Davies
              ... Ease of processing and implementation, to start. . Section 1 is relatively easy to implement and prove. It has minimal redundancy (but depends on the rest
              Message 6 of 19 , Sep 29, 2005
              • 0 Attachment
                On Thu, Sep 29, 2005 at 06:21:00PM -0400, Brass Tilde wrote:
                > > Section 1
                > >
                > > Section 2
                > >
                > > The second expands on the first, showing the 'non-decision' data.
                > > For instance, where section shows "add a level of fighter,
                > > gain 8 hit points, take Cleave, assign 3 skill points to Swim skill",
                > > this would show "add a level of fighter, gain 8 hit points, take
                > > Cleave, assign 3 skill points to Swim skill, +1 BAB, +1 Fort".
                >
                > Why have two sections containing the same data? Ease of processing,
                > or some other reason?

                Ease of processing and implementation, to start.

                . Section 1 is relatively easy to implement and prove. It has minimal
                redundancy (but depends on the rest of the data being present). It
                has only what is needed to construct the character. It's also highly
                resilient in the face of data changes -- a change to the rest of the
                data won't introduce inconsistency because there's nothing to be
                inconsistent with.

                . Section 2 contains potentially huge redundancy, even apart from it
                being a superset of Section 1. It shows the effects of the decisions
                made and stored in Section 1. It's primarily of interest to PCGen
                developers (LST and code) since it makes it easier to see exactly what
                happened -- what the program and data decided to do, rather than what
                the monkeys *thought* would happen.

                > It would seem simpler to either confine section 2 to the
                > "non-decision" data, in your case +1 BAB, +1 Fort, or to just
                > eliminate section 1 entirely.

                Ease of processing again. In part, showing the decision information is
                necessary because it makes it possible for a human to map between the
                decisions and their effects, and putting them all in one place makes
                them easier to see.

                See, the decisions are nested:

                add level {
                // may add ability score bump
                // may add feat (before or after class level)
                add level of class {
                add hit points
                add skill points
                may add feat
                may add spells known
                // etc.
                }
                // may add feat (before or after class level)
                }

                As such, it's necessary to hold the 'parent decisions' for the internal
                ones to be at all meaningful.

                Also, I'd like to store "old value, change, new value" in here. This
                lets an examiner see "what it was, what happened, what it is now", very
                useful for debugging. The structure also demonstrates where the change
                came from, making it clear what happened. Consider:

                change {
                Str += 1
                BAB = 8
                BFort = 6
                Feats += Improved Critical(greatsword)
                Feats += Greater Weapon Focus(greatsword)
                Skills: Swim += 3
                }

                vs.

                add level (8) {
                Str += 1
                add level of fighter (8) {
                hit points: 57 + 8 == 65
                BFort: 5 + 1 = 6
                Feats += Greater Weapon Focus(greatsword)
                Skills: Swim += 3
                }
                Feats += Improved Critical(greatsword)
                }

                (syntax obviously not XML, but shows structure)

                Which would you rather see, from a debugger's point of view?

                The second is much clearer what happened... but contains information
                that isn't needed by PCGen.

                > Unless I've missed something obvious, or you've left something out.

                I don't think it was anything obvious, but I did have reasons.
                >
                > > Actually, I'd like to go a step further and show running totals:
                >
                > Which is what section 3 is for, no?

                No. Well, not really. Section three shows the final results. Section
                two shows only the running totals of what has changed -- showing *all*
                running totals and the like would get unwieldy when trying to examine
                it.


                Keith
                --
                Keith Davies "Always code as if the guy who ends up
                keith.davies@... maintaining your code is a psychopath
                keith.davies@... who knows where you live."
                http://www.kjdavies.org/ -- Damian Conway
              • Edwin Holley
                I agree, this seemed lost on me as well. I would love to be able to put PCGen into a mode where I can see the character progress. This is something difficult
                Message 7 of 19 , Sep 29, 2005
                • 0 Attachment
                  I agree, this seemed lost on me as well.
                  I would love to be able to put PCGen into a mode where I can see the
                  character progress. This is something difficult to do in P&P RPGs. While
                  you could easily create a new character sheet for each level, you would miss
                  out on "granted +1 spell success by wild magic misfire at level 1.43".
                  Although this level of logging would make pcg files BIG (say at level 10
                  from a first level character), it would be very cool to be able to turn this
                  on and see the characters improvements and losses over the long term.

                  -----Original Message-----
                  From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com] On Behalf
                  Of Brass Tilde
                  Sent: Thursday, September 29, 2005 18:21
                  To: pcgen-xml@yahoogroups.com
                  Subject: RE: [pcgen-xml] It lives! And is reborn!

                  > Section 1
                  >
                  > Section 2
                  >
                  > The second expands on the first, showing the 'non-decision' data.
                  > For instance, where section shows "add a level of fighter,
                  > gain 8 hit points, take Cleave, assign 3 skill points to Swim skill",
                  > this would show "add a level of fighter, gain 8 hit points, take
                  > Cleave, assign 3 skill points to Swim skill, +1 BAB, +1 Fort".

                  Why have two sections containing the same data? Ease of processing, or some
                  other reason? It would seem simpler to either confine section 2 to the
                  "non-decision" data, in your case +1 BAB, +1 Fort, or to just eliminate
                  section 1 entirely. Unless I've missed something obvious, or you've left
                  something out.

                  > Actually, I'd like to go a step further and show running totals:

                  Which is what section 3 is for, no?

                  As I say, if I've missed something, let me know.
                • Fred Drake
                  ... I m surprised technically-literate people are having a hard time with this. I don t even think the sections are all that similar, though I d expect the
                  Message 8 of 19 , Sep 29, 2005
                  • 0 Attachment
                    On 9/29/05, Keith Davies <keith.davies@...> wrote:
                    > These two sections have different purpose and application, despite being
                    > somewhat similar.

                    I'm surprised technically-literate people are having a hard time with
                    this. I don't even think the sections are all that similar, though
                    I'd expect the structure of the second would largely mirror and extend
                    the structure of the first.

                    > Also, and very important to me, it runs the risk of introducing
                    > inconsistency. If the definition of an entity changes, the information
                    > in the second section could be rendered incorrect.

                    I actually disagree on this point, however. As the sections have been
                    described so far, I think of them this way:

                    1. User decisions.

                    2. Software decisions.

                    3. Fluffy stuff.

                    The third section can clearly be regenerated, but supplemental tools
                    that only care about the "current" value of the information only need
                    to look there. This is nice to have, but could be dropped.

                    That leaves the first two, where all the contention seems to be.
                    Section 1 is obviously necessary, and seems well defined. Section 2
                    *appears* derivative of section 1 + game rule information (race &
                    class definitions, etc.), and usually will be. Where you're looking
                    at inconsistency, I see an opportunity to check that the character is
                    being viewed relative to the right "universe" (the game rule
                    information set); it also allows you to separate changes in game rules
                    from the characters created under different versions.

                    For example, suppose I create a character and play her until level 5.
                    The GM decides he doesn't like some rule, so forks the universe by
                    reducing the number of spells my character would have received at
                    level 3. Whether my character loses a spell or not, since she's
                    already in play, depends on the GM's policy for handling that. As
                    described, section 2 allows that decision to be handled either way.
                    The application that checks for this sort of inconsistency should
                    allow the policy to be applied on a case-by-case basis by inserting
                    "inconsistency approvals" into the second section for each
                    inconsistency. This would allow a character from a legacy universe to
                    continue to be used in the new universe in the same way that happens
                    in real games.

                    > I don't mind being *wrong*, but I had being inconsistent.

                    Absolutely understandable!

                    > It's probably a matter of preference. The first section as I've
                    > described it is *necessary*. The second section isn't, but is useful.
                    > I don't like mixing optional data and required data in the same
                    > containers, especially when it isn't evident through examination which
                    > is which.

                    Understandable, but I think the information is necessary.

                    > Also, frankly, the first section as described is pretty easy to
                    > implement. The second will be harder and probably more error-prone.
                    > There's a certain amount of overlap between them and probably code
                    > reuse, but we can prove the first section fairly easily. The second
                    > will be more work.

                    Most definately. They also serve clearly different purposes.

                    > 2. examination difficulty. This is a much more important one, IMO. If
                    > you show the entire state, that means the whole thing needs to be
                    > examined if you're trying to figure out what happened. If you only
                    > highlight what changed (including the new (and possibly old) values)
                    > then it's very easy to see the effects of the change.

                    This is very valuable. Anything that makes development easier is a good thing.


                    -Fred

                    --
                    Fred L. Drake, Jr. <fdrake at gmail.com>
                    Zope Corporation
                  • Keith Davies
                    ... The structure probably would be very close to the first, just with more information. ... ... I didn t write that, but that summarizes what I was trying to
                    Message 9 of 19 , Sep 29, 2005
                    • 0 Attachment
                      On Thu, Sep 29, 2005 at 09:11:43PM -0400, Fred Drake wrote:
                      > On 9/29/05, Keith Davies <keith.davies@...> wrote:
                      > > These two sections have different purpose and application, despite being
                      > > somewhat similar.
                      >
                      > I'm surprised technically-literate people are having a hard time with
                      > this. I don't even think the sections are all that similar, though
                      > I'd expect the structure of the second would largely mirror and extend
                      > the structure of the first.

                      The structure probably would be very close to the first, just with more
                      information.

                      > > Also, and very important to me, it runs the risk of introducing
                      > > inconsistency. If the definition of an entity changes, the information
                      > > in the second section could be rendered incorrect.
                      >
                      > I actually disagree on this point, however. As the sections have been
                      > described so far, I think of them this way:
                      >
                      > 1. User decisions.
                      >
                      > 2. Software decisions.
                      >
                      > 3. Fluffy stuff.

                      ... I didn't write that, but that summarizes what I was trying to say
                      very well.

                      > The third section can clearly be regenerated, but supplemental tools
                      > that only care about the "current" value of the information only need
                      > to look there. This is nice to have, but could be dropped.

                      I agree. The second should provide sufficient information to regenerate
                      the third section for the character at *any* point in the series of
                      transformations.

                      > That leaves the first two, where all the contention seems to be.
                      > Section 1 is obviously necessary, and seems well defined. Section 2
                      > *appears* derivative of section 1 + game rule information (race &
                      > class definitions, etc.), and usually will be. Where you're looking
                      > at inconsistency, I see an opportunity to check that the character is
                      > being viewed relative to the right "universe" (the game rule
                      > information set); it also allows you to separate changes in game rules
                      > from the characters created under different versions.

                      I agree that it could be used for sanity checks -- does this version
                      match what the software thought before?

                      That kind of falls down, though, in that if they differ between
                      versions, they *should* differ (code or data patch, most likely). I
                      wouldn't want to try to implement an automated check for this. Until we
                      decide to do something with a discovery of a mismatch, I wouldn't worry
                      about.

                      > For example, suppose I create a character and play her until level 5.
                      > The GM decides he doesn't like some rule, so forks the universe by
                      > reducing the number of spells my character would have received at
                      > level 3. Whether my character loses a spell or not, since she's
                      > already in play, depends on the GM's policy for handling that. As
                      > described, section 2 allows that decision to be handled either way.

                      Or at least automatically discover it.

                      > The application that checks for this sort of inconsistency should
                      > allow the policy to be applied on a case-by-case basis by inserting
                      > "inconsistency approvals" into the second section for each
                      > inconsistency. This would allow a character from a legacy universe to
                      > continue to be used in the new universe in the same way that happens
                      > in real games.

                      That's getting into the question of branching data and having multiple
                      versions extant -- to the point of "this is how it is for *me*".

                      I don't want to go here right now. It's an interesting idea, and
                      potentially quite valuable, but I'd like to keep it simple for now.
                      We're already going somewhere the program doesn't yet, let's not go too
                      far.

                      > > I don't mind being *wrong*, but I had being inconsistent.
                      >
                      > Absolutely understandable!

                      Heh, I learned that working for government. You can make a mistake
                      without it being *too* embarassing, but an inconsistency indicates you
                      didn't even *check*... and that's *very* embarassing.

                      > > It's probably a matter of preference. The first section as I've
                      > > described it is *necessary*. The second section isn't, but is
                      > > useful. I don't like mixing optional data and required data in the
                      > > same containers, especially when it isn't evident through
                      > > examination which is which.
                      >
                      > Understandable, but I think the information is necessary.

                      I think the second section would be terribly useful -- not necessary,
                      but from a pragmatic sense a damn good idea.

                      What I want to avoid is "here's a bunch of stuff, some of which you need
                      and some you don't, and it's up to the reader [program] to know which is
                      which". This is much more complex than "here's what you need to know,
                      and you need to know all of it". Simpler rules almost invariably lead
                      to simpler software.

                      > > Also, frankly, the first section as described is pretty easy to
                      > > implement. The second will be harder and probably more error-prone.
                      > > There's a certain amount of overlap between them and probably code
                      > > reuse, but we can prove the first section fairly easily. The second
                      > > will be more work.
                      >
                      > Most definately. They also serve clearly different purposes.

                      Yes. Even though the first one could be derived from the second, being
                      a subset of it.

                      > > 2. examination difficulty. This is a much more important one, IMO. If
                      > > you show the entire state, that means the whole thing needs to be
                      > > examined if you're trying to figure out what happened. If you only
                      > > highlight what changed (including the new (and possibly old) values)
                      > > then it's very easy to see the effects of the change.
                      >
                      > This is very valuable. Anything that makes development easier is a
                      > good thing.

                      Such is my thought.


                      Keith
                      --
                      Keith Davies "Always code as if the guy who ends up
                      keith.davies@... maintaining your code is a psychopath
                      keith.davies@... who knows where you live."
                      http://www.kjdavies.org/ -- Damian Conway
                    • Fred Drake
                      ... Exactly how an application should respond to such a mismatch should not be defined by the data model. It s likely fine to start by expecting the model of
                      Message 10 of 19 , Sep 29, 2005
                      • 0 Attachment
                        On 9/29/05, Keith Davies <keith.davies@...> wrote:
                        > I agree that it could be used for sanity checks -- does this version
                        > match what the software thought before?
                        >
                        > That kind of falls down, though, in that if they differ between
                        > versions, they *should* differ (code or data patch, most likely). I
                        > wouldn't want to try to implement an automated check for this. Until we
                        > decide to do something with a discovery of a mismatch, I wouldn't worry
                        > about.

                        Exactly how an application should respond to such a mismatch should
                        not be defined by the data model. It's likely fine to start by
                        expecting the model of the universe to match the fragments of the
                        universe model exposed in the character data (section 2).

                        I think it important to keep separate the (abstract) data model and
                        the application requirements. If you don't require sharing data with
                        an application that may have a different universe model, there's no
                        need to ever perform the checks of even store section 2 (other than
                        for debugging). However, the model should certainly *allow* an
                        application that cares about interchage or a universe in flux can make
                        the additional use of the information from section 2 to support
                        whatever operations it cares about. (For some reason, this makes me
                        think back to Jack Chalker's Flux & Anchor books; not really sure
                        why...)

                        > That's getting into the question of branching data and having multiple
                        > versions extant -- to the point of "this is how it is for *me*".
                        >
                        > I don't want to go here right now. It's an interesting idea, and
                        > potentially quite valuable, but I'd like to keep it simple for now.
                        > We're already going somewhere the program doesn't yet, let's not go too
                        > far.

                        Again, we need to keep distinct the model and the application. PCgen
                        is one application; perhaps it doesn't need all the bells and
                        whistles. I work on web-based content-management applications with
                        highly inter-related content objects, and the rules for checking and
                        enforcing relationships always belong in the software. The data model
                        needs to provide enough information for checks and future application
                        evolution; keeping these sorts of aspects separated is amazingly
                        important. (I also imagine any software I write that consumes more
                        than section 3 of this format would be very interested in detecting
                        changes in the universe after the fact rather than having to dig
                        through characters every time something in the universe changed.)

                        > What I want to avoid is "here's a bunch of stuff, some of which you need
                        > and some you don't, and it's up to the reader [program] to know which is
                        > which". This is much more complex than "here's what you need to know,
                        > and you need to know all of it". Simpler rules almost invariably lead
                        > to simpler software.
                        ...
                        > > Most definately. They also serve clearly different purposes.
                        >
                        > Yes. Even though the first one could be derived from the second, being
                        > a subset of it.

                        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.


                        -Fred

                        --
                        Fred L. Drake, Jr. <fdrake at gmail.com>
                        Zope Corporation
                      • andargor
                        ... I would strongly suggest that the character should be saved in a format based on a de facto XML standard for the sake of not reinventing the wheel, and
                        Message 11 of 19 , Sep 30, 2005
                        • 0 Attachment
                          --- In pcgen-xml@yahoogroups.com, Keith Davies <keith.davies@k...> wrote:
                          > Hi All,
                          >
                          > I just finished an interesting IM conversation with Devon. Here's what
                          > he's looking for -- and it's pretty easy, I think.
                          >
                          > Continue using LST format for PCC files, for now at least. We may
                          > revisit it later and convert the LST files to XML.
                          >
                          > The character file would consist of three sections. Each section is
                          > optional, but there are reasons for each.
                          >

                          I would strongly suggest that the character should be saved in a
                          format based on a "de facto" XML standard for the sake of not
                          reinventing the wheel, and interoperability. I have been citing
                          OpenRPG for some time. (get it here:
                          http://sourceforge.net/project/showfiles.php?group_id=2237&package_id=2193&release_id=201695))

                          Look in the OpenRPG\orpg\templates\nodes\d20character.xml file for the
                          format they use.

                          It could be another format, such as Twin Roses' or DMGenie, it doesn't
                          really matter, as long as tools out there can support the format.

                          I realize that PCGen might need "internal representations" or
                          additional info within the character just for PCGen. This is where the
                          power of XML comes in: you just add a <pcgen version="x.x"> section
                          and include whatever extra "mechanics" are needed by PCGen. The other
                          tools that support OpenRPG will simply ignore it, and use the common
                          OpenRPG data to import.

                          Please let us be truly open, and allow PCGen to finally be able to
                          work with other tools.

                          As for data sets, that's an entirely different discussion, but we'll
                          get to that eventually. I suggest you look at Frugal's stuff in this
                          list. He is in the process of revamping his XML based character
                          generator, and some ideas could be reused or expanded upon for the
                          future of PCGen.

                          Needless to say that I'm excited about this... :)

                          Andargor
                        • Edwin Holley
                          ... From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com] On Behalf Of andargor Sent: Friday, September 30, 2005 10:17 To:
                          Message 12 of 19 , Sep 30, 2005
                          • 0 Attachment
                            -----Original Message-----
                            From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com] On Behalf
                            Of andargor
                            Sent: Friday, September 30, 2005 10:17
                            To: pcgen-xml@yahoogroups.com
                            Subject: [pcgen-xml] Re: It lives! And is reborn! [Using defacto standards]

                            >SNIP< I should look at this stuff :-)

                            I would strongly suggest that the character should be saved in a
                            format based on a "de facto" XML standard for the sake of not
                            reinventing the wheel, and interoperability. I have been citing
                            OpenRPG for some time. (get it here:
                            http://sourceforge.net/project/showfiles.php?group_id=2237&package_id=2193&r
                            elease_id=201695))

                            >SNIP< I don't know that being open means that your software works with
                            other programs. This program is very unique; it has capabilities far beyond
                            any commercial program. I have compared any programs I could for evaluation
                            and found them severely lacking in even half the features\capabilities that
                            pcgen has. Even excluding some of the decent XML files. The available
                            programs do not have the capability to incorporate the games or character
                            classes that pcgen is currently includes or being used by various members.
                            Including creating new worlds like ice planets. The capabilities that we
                            wish to include in the data will require a level of sophistication far
                            beyond anything else I have seen. Also by creating an output sheet, you are
                            able to create your character in just about any format you can imagine.

                            Please let us be truly open, and allow PCGen to finally be able to
                            work with other tools.

                            >SNIP< I agree

                            Needless to say that I'm excited about this... :)

                            Andargor






                            Yahoo! Groups Links
                          • Devon Jones
                            ... In fact, in our discussions, section 2 will be the last to be implemented, as there are potentially major code hurtles. Section 2 is a debugging to IMHO,
                            Message 13 of 19 , Oct 3, 2005
                            • 0 Attachment
                              Keith Davies wrote:

                              >It's probably a matter of preference. The first section as I've
                              >described it is *necessary*. The second section isn't, but is useful.
                              >I don't like mixing optional data and required data in the same
                              >containers, especially when it isn't evident through examination which
                              >is which.
                              >
                              >Also, frankly, the first section as described is pretty easy to
                              >implement. The second will be harder and probably more error-prone.
                              >There's a certain amount of overlap between them and probably code
                              >reuse, but we can prove the first section fairly easily. The second
                              >will be more work.
                              >
                              >
                              In fact, in our discussions, section 2 will be the last to be
                              implemented, as there are potentially major code hurtles. Section 2 is
                              a debugging to IMHO, intended as a log so that we can more easily detect
                              errors. I don't see a real use for section 2 outside pcgen developers.

                              >I see no reason why you couldn't generate the third section "as at" a
                              >particular transformation (right after 4th level, say), despite having
                              >10 levels of information present. In fact, you could generate *just*
                              >the third section, without including either of the others.
                              >
                              >
                              Indeed, we essentially do now, the third section is for most intents and
                              purposes already implemented - it's called base.xml. My goal here is to
                              be able to drive exports completely from the new pcg format, as well as
                              allow other programs to transform section 3 into usable input for their
                              program.

                              Here is how I see the sections:
                              Section 1: this is designed to tell pcgen how to build a character.
                              This is meant purely for internal pcgen consumption. Using this and
                              cdom, there is no reason that we can't show a character at multiple
                              points in their development. This section will be absolutely necessary
                              if I want CDOM to happen.

                              Section 2: This is a log, and as such is mostly useful as a debugging
                              tool. This section in the hardest one to implement (for internal pcgen
                              reasons I don't want to go into right now). This section contains a log
                              of decisions and their consequences. It's really mostly useful for
                              debugging.

                              Section 3: This is for export, as well as import. This section allows
                              us to show a complete character, sans lst data, and sans decisions. It
                              can be used for exports, it can be use to generate character sheets, and
                              it can be used to build an object structure in pcgen such that we can
                              import read only characters from other programs.

                              Devon
                            • Devon Jones
                              ... Ok, my position on this is that we probably shouldn t. By being xml, we are being open, and we can certainly build xslt to transform to other formats, but
                              Message 14 of 19 , Oct 3, 2005
                              • 0 Attachment
                                andargor wrote:

                                >I would strongly suggest that the character should be saved in a
                                >format based on a "de facto" XML standard for the sake of not
                                >reinventing the wheel, and interoperability. I have been citing
                                >OpenRPG for some time. (get it here:
                                >http://sourceforge.net/project/showfiles.php?group_id=2237&package_id=2193&release_id=201695))
                                >
                                >Look in the OpenRPG\orpg\templates\nodes\d20character.xml file for the
                                >format they use.
                                >
                                >It could be another format, such as Twin Roses' or DMGenie, it doesn't
                                >really matter, as long as tools out there can support the format.
                                >
                                >I realize that PCGen might need "internal representations" or
                                >additional info within the character just for PCGen. This is where the
                                >power of XML comes in: you just add a <pcgen version="x.x"> section
                                >and include whatever extra "mechanics" are needed by PCGen. The other
                                >tools that support OpenRPG will simply ignore it, and use the common
                                >OpenRPG data to import.
                                >
                                >Please let us be truly open, and allow PCGen to finally be able to
                                >work with other tools.
                                >
                                >As for data sets, that's an entirely different discussion, but we'll
                                >get to that eventually. I suggest you look at Frugal's stuff in this
                                >list. He is in the process of revamping his XML based character
                                >generator, and some ideas could be reused or expanded upon for the
                                >future of PCGen.
                                >
                                >Needless to say that I'm excited about this... :)
                                >
                                >Andargor
                                >
                                >
                                >
                                Ok, my position on this is that we probably shouldn't. By being xml, we
                                are being open, and we can certainly build xslt to transform to other
                                formats, but we need more and different information then these programs do.

                                Section 1 is absolutely necessary. period.
                                Section 2 is not
                                Section 3 is IMHO utterly necessary, as I intend to drive our Sheet
                                exports off of it, and it makes a perfect interchange format, as it will
                                literally contain *all* the final data about a character, with zero
                                information that is driving the pcgen program.

                                Having looked at OpenRPG's format, their format is purely an internal
                                program representation, and (IMHO) not useful for really anything else -
                                it depends on things that are basically internal needs of their
                                program. What I intend with section 3 is essentially a representation
                                of a character that is utterly complete, and would result in the
                                capability of transforming into really any other data format that uses
                                xml. Furthur, if we *find* something that it can't be transformed to, I
                                would see us as adding to out format to make it capable of that kind of
                                transformation.

                                Finally, with this kind of transformation capability, we could finally
                                add the ability to save characters in these other formats, much like you
                                can save as rtf in word. The problem here is that these other programs
                                (OpenRPG, DMGenie and Twin Rose) were not designed as interchange
                                formats, and were designed with their programs in mind. I want to break
                                this model, and design a format that can function as a full interchange
                                format (section 3), and have sections designed in this format for other
                                usage (section 1 and 2). That being said, I would seriously consider a
                                section 4: external Apps. An optional section (since all the sections
                                are optional) that can contain the character, already transformed for
                                OpenRPG, DMGenie, Twin Rose, etc.

                                This is getting somewhat stream of consciousness now, but I could see us
                                developing one top level format that is intended to embed any number of
                                other formats, and then consider sections 1-3, and any other formats to
                                each be their own xml format, that is embeddable in the upper level
                                pcgen xml document.

                                Devon
                              • Brass Tilde
                                ... Ah hah! Now I get it. If this was explained earlier, I apologize for not understanding. Put this way, it makes excellent sense, though I might prefer it
                                Message 15 of 19 , Oct 3, 2005
                                • 0 Attachment
                                  > Section 1: this is designed to tell pcgen how to build a character.
                                  >
                                  > Section 2: This is a log, and as such is mostly useful as a debugging
                                  > tool.

                                  > Section 3: This is for export, as well as import. This section allows
                                  > us to show a complete character, sans lst data, and sans decisions.

                                  Ah hah! Now I get it. If this was explained earlier, I apologize for
                                  not understanding. Put this way, it makes excellent sense, though I
                                  might prefer it if the presence of the second section were a
                                  configuration option. I don't feel very strongly about that, though.

                                  In your design, I'm assuming that it would be possible to generate a
                                  "section 3" from any set of levels in section 1, e.g. if I have 10
                                  levels, but I want a sheet that shows what the character looked like at
                                  level 9.

                                  Good stuff. I wish I had more time to help with it.
                                • Brass Tilde
                                  ... the ... we ... programs do. Honestly, I don t think you two are that far apart on this. andargor s element is Devon s section 1 .
                                  Message 16 of 19 , Oct 3, 2005
                                  • 0 Attachment
                                    > > andargor wrote:
                                    >
                                    > >I realize that PCGen might need "internal representations" or
                                    > >additional info within the character just for PCGen. This is where
                                    the
                                    > >power of XML comes in: you just add a <pcgen version="x.x"> section
                                    > >and include whatever extra "mechanics" are needed by PCGen.

                                    > From: "Devon Jones" <soulcatcher@...>

                                    > Ok, my position on this is that we probably shouldn't. By being xml,
                                    we
                                    > are being open, and we can certainly build xslt to transform to other
                                    > formats, but we need more and different information then these
                                    programs do.

                                    Honestly, I don't think you two are that far apart on this. andargor's
                                    <pcgen version="x.x" /> element is Devon's "section 1".

                                    > > andargor again.

                                    > >Please let us be truly open, and allow PCGen to finally be able to
                                    > >work with other tools.

                                    This would be Devon's "section 3". The end product of all the
                                    calculations and other stuff that PCGen does, in a format that can be
                                    transformed to virtually anything anybody else needs. If a piece of
                                    info isn't there, it can be added (as long as PCGen processes that
                                    information).

                                    Publishing the schema to section 3 enables other programs, should they
                                    wish to do so, to publish transforms that can be used to use that data
                                    in whatever way they want.

                                    Brad
                                  • Devon Jones
                                    ... Section 2 will take a long time, and may never be fully realized. Section 2 may not appear it, but it s *hard* ... Precisely, we can even contain if we
                                    Message 17 of 19 , Oct 3, 2005
                                    • 0 Attachment
                                      Brass Tilde wrote:

                                      >
                                      >Ah hah! Now I get it. If this was explained earlier, I apologize for
                                      >not understanding. Put this way, it makes excellent sense, though I
                                      >might prefer it if the presence of the second section were a
                                      >configuration option. I don't feel very strongly about that, though.
                                      >
                                      >
                                      Section 2 will take a long time, and may never be fully realized.
                                      Section 2 may not appear it, but it's *hard*

                                      >In your design, I'm assuming that it would be possible to generate a
                                      >"section 3" from any set of levels in section 1, e.g. if I have 10
                                      >levels, but I want a sheet that shows what the character looked like at
                                      >level 9.
                                      >
                                      >
                                      Precisely, we can even contain if we wish, more then one section 3, and
                                      if we can get the code fast enough, that may end up defaulting to that
                                      for each level. If not, it'll be optional.

                                      >Good stuff. I wish I had more time to help with it.
                                      >
                                      >
                                      >
                                    • Brass Tilde
                                      ... I ll reiterate someone else s point here though, that some things are *not* necessarily level dependent, such as one s possessions. It *is* true that most
                                      Message 18 of 19 , Oct 3, 2005
                                      • 0 Attachment
                                        > > In your design, I'm assuming that it would be possible to generate a
                                        > > "section 3" from any set of levels in section 1, e.g. if I have 10
                                        > > levels, but I want a sheet that shows what the character
                                        > > looked like at level 9.

                                        > Precisely, we can even contain if we wish, more then one
                                        > section 3, and if we can get the code fast enough, that
                                        > may end up defaulting to that for each level. If not,
                                        > it'll be optional.

                                        I'll reiterate someone else's point here though, that some things are
                                        *not* necessarily level dependent, such as one's possessions. It *is*
                                        true that most people gather those things over the course of their
                                        careers, so a strict "point in time" snap-shot section 3 would show
                                        different equipment for each level.

                                        However, in the case of losing one or more levels, the equipment would
                                        need to be retained, and displayed for the new lower level. Not a
                                        showstopper by any means, and not terribly difficult to implement I
                                        imagine (I can think of at least one way to do it right now). The whole
                                        thing implies a sequence to the character, even if part of that sequence
                                        is going backwards!

                                        Again, good stuff. Keep up the good work.

                                        Brad
                                      • Fred Drake
                                        ... They were right, of course. Sections 1 and 2 are strictly level-based information; possessions or other point-in-time information ( broken arm ) is
                                        Message 19 of 19 , Oct 3, 2005
                                        • 0 Attachment
                                          On 10/3/05, Brass Tilde <brasstilde@...> wrote:
                                          > I'll reiterate someone else's point here though, that some things are
                                          > *not* necessarily level dependent, such as one's possessions. It *is*
                                          > true that most people gather those things over the course of their
                                          > careers, so a strict "point in time" snap-shot section 3 would show
                                          > different equipment for each level.

                                          They were right, of course. Sections 1 and 2 are strictly level-based
                                          information; possessions or other point-in-time information ("broken
                                          arm") is separate. I don't know if this really belongs in section 3
                                          or not, but seems parallel. Points in time also don't generally
                                          correspond to level transitions. (If you require training in-game to
                                          learn/advance skills, then levelling up earns skill points, and the
                                          decisions on spending them happen outside the levelling process.)

                                          I suspect that full point-in-time rollback should reasonably be
                                          considered out-of-scope for the data format. This sort of
                                          functionality is easily enough implemented using copies of the data
                                          files, either directly on the filesystem or using an external revision
                                          control system.

                                          Which is not to say that it's a bad idea to included other timestamped
                                          information: "Noon, 12 Octember 2345, -1 STR damage (permanent) from
                                          cursed ray gun." But that's game time; real-world time should still
                                          be handled externally. There's a lot of messy interactions between
                                          game time and real-world time, and more tricks to pull if the game
                                          world isn't on the Gregorian calendar.


                                          -Fred

                                          --
                                          Fred L. Drake, Jr. <fdrake at gmail.com>
                                          "Society attacks early, when the individual is helpless." --B.F. Skinner
                                        Your message has been successfully submitted and would be delivered to recipients shortly.