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

Re: It lives! And is reborn! [Using defacto standards]

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.