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

Re: [pcgen-xml] my schema: races/GUIs/code

Expand Messages
  • Frugal
    ... The problem is that I can have a piece of equipment giving a bonus of +4 to score.ac.mod.armor and a spell effect giving +5 to score.ac.mod.armour. 1 - How
    Message 1 of 20 , Jan 20, 2004
    • 0 Attachment
      On Tuesday 20 January 2004 16:54, Steven Bethard wrote:
      > <quote who="Frugal">
      >
      > > How would an observer pattern deal with variables which do not stack.
      > > I.e. if you have a +4 armuor bonus and you get an item that give a +2
      > > armour bonus you should end up with a +4, not a +6
      >
      > </quote>
      >
      > The way I've planned on doing this so far is to have a separate Score for
      > each type of bonus mod. In general, bonus mod Scores are set, not added
      > to. So, for your example, your AC Score would be the sum of (maybe 10?)
      > different bonus-type scores. When setting one of these bonus mod Scores,
      > you could just do a max() of the calculated score for the mod, and the
      > current score for the mod. (max() can be provided as a formula function,
      > or a shorthand attribute depending on what we decide is cleaner.)

      The problem is that I can have a piece of equipment giving a bonus of +4 to
      score.ac.mod.armor and a spell effect giving +5 to score.ac.mod.armour.

      1 - How does it know that the +5 does not stack with the +4 ?

      2- If I take the higher of the 2 (in this case +5) and then remove the +4
      equipment what is to stop the score.ac.mod.armour from dropping to +1 ?

      --
      regards,
      Frugal
      -OS Chimp
    • CC Noram Carstensen James
      Steve, I like what you re saying, but I m not sure PCGen is the forum for it. I would love a very open way to represent a character and the rules for
      Message 2 of 20 , Jan 20, 2004
      • 0 Attachment
        Steve,

        I like what you're saying, but I'm not sure PCGen is the forum for it.

        I would love a very open way to represent a character and the rules for
        generating it, so I could use the same generator for D&D, Champions, and
        any other game I play. I think what you're suggesting could handle
        that.

        However, I see this as being a pain to write. In a fairly rules-static
        game (say a closed source game where the publisher isn't adding new
        rules all the time), this isn't an issue. For something like D20, where
        there one of the design goals is to make it easy for people to
        understand and enter LST files by hand, I think what you have is
        overkill and harder to use because it's a step farther from what people
        are doing - coding D20. Or, as Keith would say, representing the
        problem set.

        Even considering different XML schemas, we'd be looking at: One generic
        master schema, one easy-user-entry schema, and one pcgen data schema,
        with the later two convertible to the first. From a debugging point of
        view (what you put in is really what you get), the user-entry schema and
        the PCGen schema should be the same.

        Which means you have a schema that users write and PCGen reads, and a
        master schema that it can be converted into. At this point, since
        neither the users nor PCGen read the master schema, it can be develop
        separately without impact on the PCGen project. I would actually be
        interested in discussing it - I have some ideas that I think fit very
        well with what you have already envisioned, but I'm not sure that
        for-PCGen-use is the place to consider this, at least at this point.

        Cheers,
        Jim
      • Steven Bethard
        ... I m not sure what the Master schema is - could you explain? I had in mind only two schemas currently: a easy-user-entry schema,
        Message 3 of 20 , Jan 20, 2004
        • 0 Attachment
          <quote who="Jim">
          > Even considering different XML schemas, we'd be looking at: One generic
          > Master schema, one easy-user-entry schema, and one pcgen data schema,
          > with the later two convertible to the first. From a debugging point of
          > view (what you put in is really what you get), the user-entry schema and
          > the PCGen schema should be the same.
          </quote>

          I'm not sure what the Master schema is - could you explain? I had in mind
          only two schemas currently: a easy-user-entry schema, and a generic pcgen
          data schema. I have been discussing the generic pcgen data schema here, but
          if this forum is intended mainly for the easy-user-entry schema (not the
          pcgen data schema), I can certainly start a separate forum for this
          discussion.

          Yes, it does mean that there are now two levels to debug - the code and the
          user data -> pcgen data transform. But I would contend that because of the
          simplicity of the encoding, both the code and the transform will be simpler
          to debug. If I'm wrong here though, I certainly see your point - two levels
          that are hard to debug is worse than one level that is hard to debug...

          Steve
          _____

          You can wordify anything if you just verb it.
          - Bucky Katt, Get Fuzzy
        • Keith Davies
          ... No need, as long as it s clearly indicated. Perhaps flag the subject with [int] and [ext]? I ve mostly be focusing on the easy-user-entry schema ([ext]);
          Message 4 of 20 , Jan 20, 2004
          • 0 Attachment
            On Tue, Jan 20, 2004 at 10:31:26AM -0700, Steven Bethard wrote:
            > <quote who="Jim">
            > > Even considering different XML schemas, we'd be looking at: One
            > > generic Master schema, one easy-user-entry schema, and one pcgen
            > > data schema, with the later two convertible to the first. From a
            > > debugging point of view (what you put in is really what you get),
            > > the user-entry schema and the PCGen schema should be the same.
            > </quote>
            >
            > I'm not sure what the Master schema is - could you explain? I had in
            > mind only two schemas currently: a easy-user-entry schema, and a
            > generic pcgen data schema. I have been discussing the generic pcgen
            > data schema here, but if this forum is intended mainly for the
            > easy-user-entry schema (not the pcgen data schema), I can certainly
            > start a separate forum for this discussion.

            No need, as long as it's clearly indicated. Perhaps flag the subject
            with [int] and [ext]?

            I've mostly be focusing on the easy-user-entry schema ([ext]); you were
            describing generic (internal) pcgen data schema ([int]). Both are
            appropriate for this list.

            > Yes, it does mean that there are now two levels to debug - the code
            > and the user data -> pcgen data transform. But I would contend that
            > because of the simplicity of the encoding, both the code and the
            > transform will be simpler to debug. If I'm wrong here though, I
            > certainly see your point - two levels that are hard to debug is worse
            > than one level that is hard to debug...

            ext->int provides a clear validation layer. As a result, you don't have
            to worry about even starting to load a file that turns out broken for
            syntactic reasons. This is very good.

            ext->int converts between something a user understands -- it looks like
            the data they're trying to encode, after all -- and something PCGen
            understands. This means that a knowledgeable reader will be able to
            easily get at both what he entered, and what PCGen understands. This is
            very, very good.

            In fact, we may even want to offer a facility for examining these
            files -- open the ext file and the int file (the elements in both
            should more or less correspond, or be made to) and visually compare
            them. This would probably help no end with troubleshooting data.

            Do you have a specification for your schema? I'm becoming very
            interested in how to map between them, and if your effects model suits I
            may lift that in toto.


            Keith
            --
            Keith Davies I gave my 2yo daughter a strawberry
            keith.davies@... Naomi: "Strawberry!"
            me: "What do you say?"
            Naomi: "*MY* strawberry!"
          • Steven Bethard
            Awesome, sounds like we re more or less in agreement on some important points. Woo-hoo! =) So we ll aim for a user-entry schema [ext] to be translated to a
            Message 5 of 20 , Jan 20, 2004
            • 0 Attachment
              Awesome, sounds like we're more or less in agreement on some important
              points. Woo-hoo! =) So we'll aim for a user-entry schema [ext] to be
              translated to a system-internal schema [int]. Note that exactly where the
              translation happens is not horribly crucial at the moment - we can either
              have a "compile" step for the users which actually outputs the transformed
              file, or the function that loads resources can take an optional XSLT
              parameter, and the transform can be applied immediately before the data is
              read in. Either way, the system only sees [int] data.

              I'd like to work on mapping your schema to mine, which will inevitably
              involve modifying my schema some to accommodate - but hey, that's part of
              the development process, right? I'll need to make sure I understand all the
              bits of your schema first, though, so I'm going to ask a few questions here
              first.

              kjd:Entities
              You said that kjd:Entities can be characters, spells, etc, and I can then
              "associate" any kjd:Entity with any other kjd:Entity. I'm a little unclear
              as to what "associate" means in system mechanics. If I associate a Feat
              entity with a Spell entity, what are the semantics here? Does this mean
              that the Spell (as a being) can use the Feat? Or that the Spell grants the
              Feat to the character using that Spell?

              kjd:Progressions
              Your progressions are a means of associating kjd:Effects with a variable,
              depending on the value of the variable, right? So if Strength is a
              kjd:Progression, I could define that at Strength 25, the kjd:Effect "grant
              character a Feat" would occur. Or if the Fighter class is a
              kjd:Progression, I could define that at Fighter class level 1, the
              kjd:Effect "increase base attack bonus by 1" would occur. Am I interpreting
              this correctly?

              kjd:Effects
              I know you haven't spent too much time on these yet, but can any kjd:Entity
              cause an kjd:Effect on any other kjd:Entity, or do they have to be
              "associated" kjd:Entities? (You may end up answering this in your response
              to my kjd:Entities section, so if so, please disregard it here.)


              For contrast, here would be the important elements for my schema:
              sjb:Features
              These are "things" (which generally cause sjb:Effects) that can be
              associated with game entities (I had assumed we would only be associating
              things with Characters, but it sounds like you have some good reasons for
              associating things with other game entities too, so I'm open to this
              interpretation as well.)

              sjb:Scores
              If my description of kjd:Progressions above is correct, sjb:Scores provide
              exactly the same functionality in my system. You associate sjb:Effects with
              the various values of a sjb:Score and those sjb:Effects occur when that
              value is attained (and are removed if that value later drops).

              sjb:Ratings
              These were just my way of requiring a character to select a sjb:Feature from
              the list. In retrospect, this sounds more like an attribute to the
              <add-feature /> sjb:Effect than an actual game Entity. Okay - drop 'em.

              sjb:Items
              These actually act much like sjb:Features, so they could probably be merged
              if I was careful about this. I only treated them different because I
              thought it might be useful to make a distinction between sjb:Features that
              always grant their Effects and sjb:Features which only grant their Effects
              when equipped. In retrospect though, it would be relatively simple to keep
              two lists - the list of sjb:Features currently applying to the character
              (this would include all Feats and any equipped Items), and the list of all
              sjb:Features in the posession of the character but that do not currently
              apply (e.g. unequipped items). Sure, get rid of sjb:Items. They're
              unnecessary.

              So the only elements in my (revised) schema are sjb:Features and sjb:Scores.
              I definitely need to wait for your responses here, but it sounds like we
              might have the beginning of a mapping:
              kjd:Entity -> sjb:Feature
              kjd:Progression -> sjb:Score

              Steve
              _____

              You can wordify anything if you just verb it.
              - Bucky Katt, Get Fuzzy

              P.S. I'm open to renaming some of my classifications once we've hashed some
              of this out, if it seems like that would make the translation clearer. We
              can talk about this once I'm more certain of the correspondence.
            • Keith Davies
              ... I was speaking a little imprecisely. Technically we *can*, but it doesn t always make sense to. Your example is a good case of that. To be more precise,
              Message 6 of 20 , Jan 20, 2004
              • 0 Attachment
                On Tue, Jan 20, 2004 at 01:48:54PM -0700, Steven Bethard wrote:
                > Awesome, sounds like we're more or less in agreement on some important
                > points. Woo-hoo! =) So we'll aim for a user-entry schema [ext] to be
                > translated to a system-internal schema [int]. Note that exactly where
                > the translation happens is not horribly crucial at the moment - we can
                > either have a "compile" step for the users which actually outputs the
                > transformed file, or the function that loads resources can take an
                > optional XSLT parameter, and the transform can be applied immediately
                > before the data is read in. Either way, the system only sees [int]
                > data.
                >
                > I'd like to work on mapping your schema to mine, which will inevitably
                > involve modifying my schema some to accommodate - but hey, that's part
                > of the development process, right? I'll need to make sure I
                > understand all the bits of your schema first, though, so I'm going to
                > ask a few questions here first.
                >
                > kjd:Entities
                > You said that kjd:Entities can be characters, spells, etc, and I can
                > then "associate" any kjd:Entity with any other kjd:Entity. I'm a
                > little unclear as to what "associate" means in system mechanics. If I
                > associate a Feat entity with a Spell entity, what are the semantics
                > here? Does this mean that the Spell (as a being) can use the Feat?
                > Or that the Spell grants the Feat to the character using that Spell?

                I was speaking a little imprecisely. Technically we *can*, but it
                doesn't always make sense to. Your example is a good case of that. To
                be more precise, it is my expectation that it will be possible to
                describe how they interact and are associated. If no such description
                exists, there is no immediate association. I do not currently have a
                way devised for specifying these relationships and associations.


                > kjd:Progressions
                > Your progressions are a means of associating kjd:Effects with a variable,
                > depending on the value of the variable, right?

                I suppose it could be seen that way.

                > So if Strength is a
                > kjd:Progression, I could define that at Strength 25, the kjd:Effect "grant
                > character a Feat" would occur. Or if the Fighter class is a
                > kjd:Progression, I could define that at Fighter class level 1, the
                > kjd:Effect "increase base attack bonus by 1" would occur. Am I interpreting
                > this correctly?

                This is true. I expect to have recurring effects, though, so it isn't
                necessary to repeat effects in each rank. For instance, I expect to be
                able to say 'add 1 to BAB at each level' rather than, in each level, say
                'add 1 to BAB'.

                (incidentally, IMC I plan to define 'Good BAB', 'Medium BAB', and 'Poor
                BAB' progressions (which add to BAB), then have class levels grant ranks
                in these progressions. This means that a Sor1/Wiz1 will have a BAB of +1
                rather than +0. Same thing for base saves.)

                > kjd:Effects
                > I know you haven't spent too much time on these yet, but can any
                > kjd:Entity cause an kjd:Effect on any other kjd:Entity, or do they
                > have to be "associated" kjd:Entities? (You may end up answering this
                > in your response to my kjd:Entities section, so if so, please
                > disregard it here.)

                I expect that almost all Entities will only affect what they are
                associated with. However, the effects available from an entity are
                unlimited, the full range will be available. If desired, for example, a
                feat can give an extra level of spellcasting ability, a rank of a skill
                could give a level in a class, whatever.

                Synergy bonuses are the only case I can really think of that isn't
                immediately attached, and that's because I don't see that it would be
                appropriate to include it in either the source skill or the target skill
                of the synergy bonus. This is mostly for maintenance reasons, though;
                I'm trying to make it so that adding a new entity to the system doesn't
                require modification of another, old entity -- I'm trying to keep their
                content static.

                > For contrast, here would be the important elements for my schema:
                >
                > sjb:Features
                > These are "things" (which generally cause sjb:Effects) that can be
                > associated with game entities (I had assumed we would only be
                > associating things with Characters, but it sounds like you have some
                > good reasons for associating things with other game entities too, so
                > I'm open to this interpretation as well.)

                I think it's a good idea. Many things are subject to creation,
                modification. or customization. For instance, magic weapons -- an
                enchanted sword might be a longsword, plus a masterwork modification,
                plus a number of ranks in 'enchanted weapon' progression, plus some
                assorted other modifications (which themselves may be either entities or
                progressions, depending how they behave). A spell... doesn't have a lot
                of room for customization, unless we create new entities for spells with
                attached metamagics (which might not be *that* bad an idea, actually).

                I see no reason for characters to be a special case.

                > sjb:Scores
                > If my description of kjd:Progressions above is correct, sjb:Scores
                > provide exactly the same functionality in my system. You associate
                > sjb:Effects with the various values of a sjb:Score and those
                > sjb:Effects occur when that value is attained (and are removed if that
                > value later drops).

                That seems right.

                > sjb:Ratings
                > These were just my way of requiring a character to select a
                > sjb:Feature from the list. In retrospect, this sounds more like an
                > attribute to the <add-feature /> sjb:Effect than an actual game
                > Entity. Okay - drop 'em.

                Okay. A rating (which you'll probably note isn't in the UML) was
                originally a method of associating things, a constrained selection list.
                I agree that it can be dropped; it doesn't really make sense if we're
                going to have other ways of requiring associations anyway (such as 'each
                character must have an attached race').

                > sjb:Items
                > These actually act much like sjb:Features, so they could probably be
                > merged if I was careful about this. I only treated them different
                > because I thought it might be useful to make a distinction between
                > sjb:Features that always grant their Effects and sjb:Features which
                > only grant their Effects when equipped. In retrospect though, it
                > would be relatively simple to keep two lists - the list of
                > sjb:Features currently applying to the character (this would include
                > all Feats and any equipped Items), and the list of all sjb:Features in
                > the posession of the character but that do not currently apply (e.g.
                > unequipped items). Sure, get rid of sjb:Items. They're unnecessary.
                >
                > So the only elements in my (revised) schema are sjb:Features and
                > sjb:Scores. I definitely need to wait for your responses here, but it
                > sounds like we might have the beginning of a mapping:
                > kjd:Entity -> sjb:Feature
                > kjd:Progression -> sjb:Score

                Given that kjd:Entity is something that we want to keep track of for its
                own sake -- spell, skill, etc. -- then I think that looks about right.
                An association between an Entity and a Progression does have a 'score'
                (the number of ranks in that Progression).

                So, if we've come this far and determined that they are in fact the same
                thing, how 'bout we settle on using a single term for each of them? (of
                course, I lean more toward mine...). I'm not at all concerned that you
                take an ext:class and smash it down to an int:Progression; in fact,
                that's what I expected to do.

                How were you planning to associate effects to scores, though? In XML,
                do something like:

                <score id='score.str' />

                <effect refid='score.str' test='$old < 25 and $new >= 25'>
                <!-- do stuff -->
                </effect>

                ?

                I can see that converting a Class progression to that wouldn't be too
                hard, but what about the other direction? Or in memory, are the effects
                associated to the thing they are based on, that is

                Score {
                Effect[] effects;
                }

                and when the score changes all effects are scanned and processed as
                needed? (or scanned when doing output, for example).


                Keith
                --
                Keith Davies I gave my 2yo daughter a strawberry
                keith.davies@... Naomi: "Strawberry!"
                me: "What do you say?"
                Naomi: "*MY* strawberry!"
              • Steven Bethard
                ... to ... Hey, sorry, you re right - I apoligize for not thinking about this one hard enough before I responded. What we really
                Message 7 of 20 , Jan 20, 2004
                • 0 Attachment
                  <quote who="Frugal">
                  > The problem is that I can have a piece of equipment giving a bonus of +4
                  to
                  > score.ac.mod.armor and a spell effect giving +5 to score.ac.mod.armour.
                  >
                  > 1 - How does it know that the +5 does not stack with the +4 ?
                  >
                  > 2- If I take the higher of the 2 (in this case +5) and then remove the +4
                  > equipment what is to stop the score.ac.mod.armour from dropping to +1 ?
                  </quote>

                  Hey, sorry, you're right - I apoligize for not thinking about this one hard
                  enough before I responded. What we really want here is a way that one
                  sjb:Effect can suppress another sjb:Effect. So, I think the way to do this
                  to declare for a sjb:Score the number of allowable sjb:Effects that can be
                  applied to this sjb:Score at one time. In XML, this could look something
                  like:
                  <def:score id="score.ac.mod.armor" maxeffects="1" />
                  The idea here is that you should only have one effect that grants a bonus to
                  the AC armor mod being applied at any given time.

                  For this problem, we also want which armor mod gets selected to be chosen by
                  selecting the one with the maximum value. I would suggest encoding this as:
                  <def:score id="score.ac.mod.armor" maxeffects="1"
                  effectpriority="maxvalue" />
                  Thus you select 1 sjb:Effect by choosing the sjb:Effect for this Score that
                  would produce the highest value.

                  The current code model I proposed does not directly support this, though I
                  believe there is still a relatively easy way with the Observer-Observable
                  pattern to support this kind of behavior (involving using a custom
                  Observable base class.) I'll hold off on comments about the code end until
                  I'm certain that this is true.

                  As far as the [int] schema is concerned, I'm convinced that we do need to
                  provide some additional attributes or something to allow for this type of
                  behavior. If there is a clearer (but still relatively game system
                  independent) way of representing this, I'm open to suggestions.

                  Steve
                  _____

                  You can wordify anything if you just verb it.
                  - Bucky Katt, Get Fuzzy
                • Steven Bethard
                  ... Yeah, I agree. Much as I like namespaces, I wouldn t mind not having to write them anymore ;). Having discarded sjb:Rating
                  Message 8 of 20 , Jan 20, 2004
                  • 0 Attachment
                    <quote who="Keith">
                    > So, if we've come this far and determined that they are in fact the same
                    > thing, how 'bout we settle on using a single term for each of them? (of
                    > course, I lean more toward mine...). I'm not at all concerned that you
                    > take an ext:class and smash it down to an int:Progression; in fact,
                    > that's what I expected to do.
                    </quote>

                    Yeah, I agree. Much as I like namespaces, I wouldn't mind not having to
                    write them anymore ;). Having discarded sjb:Rating and sjb:Item, I like
                    your term Entity much better than my term Feature, so from now on, I'll use
                    Entity.

                    In the sjb:Score vs. kjd:Progression situation, I think that sjb:Score is
                    the more natural term. Effects are associated both with the values of a
                    variable in a kjd:Progression and with other Entities. The term
                    "progression" sounds to me like the Effects are an inherent part of
                    Progressions, whereas "entity" doesn't sound like Effects are an inherent
                    part of Entities. Note that D&D has a number of skills (which are
                    represented as Progressions) that do not cause Effects based on their value.
                    So it doesn't seem like Effects are inherent in kjd:Progressions. I guess
                    the terminology seems a little inconsistent to me, so unless you don't mind
                    calling them Scores, I'm inclined to put off merging the two terms until we
                    see better how Effects will be implemented in the two schemas (with the
                    hopes that the use of Effects will clarify which is the more natural term.)

                    <quote who="Keith">
                    > How were you planning to associate effects to scores, though? In XML,
                    > do something like:
                    >
                    > <score id='score.str' />
                    >
                    > <effect refid='score.str' test='$old < 25 and $new >= 25'>
                    > <!-- do stuff -->
                    > </effect>
                    >
                    > ?
                    </quote>

                    Frugal and I have been discussing some of these issues - I would now code
                    the example above something like:
                    <effects sourceid="score.ability.str" threshold="25">
                    <add-entity targetid="character.x.y" entityid="feat.uberstrength">
                    </effects>
                    With the idea being that if Strength reaches 25, the Feat "Uberstrength" is
                    added to the character with the id "character.x.y" (and vice-versa, if
                    Strength drops below 25, this Feat would be removed.)

                    I also expect to use the same kind of shorthands you do to indicate
                    recurring Effects (e.g. you should not have to indicate that for a class, at
                    a score of 1, you get a d8 HD, at score of 2 you get another d8 HD, etc.)

                    <quote who="Keith">
                    > I can see that converting a Class progression to that wouldn't be too
                    > hard, but what about the other direction?
                    </quote>

                    Sorry, I missed this one. What do you mean by "the other direction"? From
                    an Effects list back to a kjd:Progression?

                    <quote who="Keith">
                    > Or in memory, are the effects
                    > associated to the thing they are based on, that is
                    >
                    > Score {
                    > Effect[] effects;
                    > }
                    >
                    > and when the score changes all effects are scanned and processed as
                    > needed? (or scanned when doing output, for example).
                    </quote>

                    Yes, this is basically what the Observer-Observable pattern does - the
                    sjb:Score would tell all Effects dependent on it that its value had changed,
                    and then the Effects could correct themselves as necessary (which would
                    occasionally cause other sjb:Scores to update, etc.) The advantage of this,
                    is that we never scan irrelevant lists of things to update. Only the
                    Effects that depend directly on the value of this sjb:Score are called to
                    correct themselves. If we don't update these values at some point, they're
                    wrong, so it's not like we can avoid doing these updates forever.

                    The other solution to this (something similar to what Scott was suggesting,
                    I think) is to associate with each Score a flag that says "I could be
                    wrong!" and every time you need that Score, you first check it's "I could be
                    wrong!" tag and the "I could be wrong!" tags of any Scores that it depends
                    on. Note that even in this scheme, at some point, you'll have to go and
                    check all the Scores that the Score you want to update is dependent on. (Or
                    just check /all/ the other Scores if you don't want to maintain a dependency
                    list. This makes me nervous though because it doesn't necessarily guarantee
                    a reasonable order of Score updating.)

                    My experience is that the Observer-Observable pattern solves this problem
                    with the least hassle and the easiest to maintain code. If anyone has a
                    simpler or cleaner way to handle the update problem though, I'm open to
                    suggestions.

                    Steve
                    _____

                    You can wordify anything if you just verb it.
                    - Bucky Katt, Get Fuzzy
                  • Keith Davies
                    ... Sure. ... In most cases I prefer to store the definitions of the effects in the Progression because they don t make sense outside it. At at least one
                    Message 9 of 20 , Jan 20, 2004
                    • 0 Attachment
                      On Tue, Jan 20, 2004 at 03:54:02PM -0700, Steven Bethard wrote:
                      > <quote who="Keith">
                      > > So, if we've come this far and determined that they are in fact the
                      > > same thing, how 'bout we settle on using a single term for each of
                      > > them? (of course, I lean more toward mine...). I'm not at all
                      > > concerned that you take an ext:class and smash it down to an
                      > > int:Progression; in fact, that's what I expected to do.
                      > </quote>
                      >
                      > Yeah, I agree. Much as I like namespaces, I wouldn't mind not having
                      > to write them anymore ;). Having discarded sjb:Rating and sjb:Item, I
                      > like your term Entity much better than my term Feature, so from now
                      > on, I'll use Entity.
                      >
                      > In the sjb:Score vs. kjd:Progression situation, I think that sjb:Score
                      > is the more natural term. Effects are associated both with the values
                      > of a variable in a kjd:Progression and with other Entities. The term
                      > "progression" sounds to me like the Effects are an inherent part of
                      > Progressions, whereas "entity" doesn't sound like Effects are an
                      > inherent part of Entities. Note that D&D has a number of skills
                      > (which are represented as Progressions) that do not cause Effects
                      > based on their value. So it doesn't seem like Effects are inherent in
                      > kjd:Progressions. I guess the terminology seems a little inconsistent
                      > to me, so unless you don't mind calling them Scores, I'm inclined to
                      > put off merging the two terms until we see better how Effects will be
                      > implemented in the two schemas (with the hopes that the use of Effects
                      > will clarify which is the more natural term.)

                      Sure.

                      > <quote who="Keith">
                      > > How were you planning to associate effects to scores, though? In XML,
                      > > do something like:
                      > >
                      > > <score id='score.str' />
                      > >
                      > > <effect refid='score.str' test='$old < 25 and $new >= 25'>
                      > > <!-- do stuff -->
                      > > </effect>
                      > >
                      > > ?
                      > </quote>
                      >
                      > Frugal and I have been discussing some of these issues - I would now code
                      > the example above something like:
                      > <effects sourceid="score.ability.str" threshold="25">
                      > <add-entity targetid="character.x.y" entityid="feat.uberstrength">
                      > </effects>
                      > With the idea being that if Strength reaches 25, the Feat
                      > "Uberstrength" is added to the character with the id "character.x.y"
                      > (and vice-versa, if Strength drops below 25, this Feat would be
                      > removed.)
                      >
                      > I also expect to use the same kind of shorthands you do to indicate
                      > recurring Effects (e.g. you should not have to indicate that for a
                      > class, at a score of 1, you get a d8 HD, at score of 2 you get another
                      > d8 HD, etc.)

                      In most cases I prefer to store the definitions of the effects in the
                      Progression because they don't make sense outside it. At at least one
                      level, I'm trying to reduce the number of things to keep track of...
                      there's enough of them already, and blowing classes out to (potentially)
                      20 times the number of objects doesn't set right with me.

                      > <quote who="Keith">
                      > > I can see that converting a Class progression to that wouldn't be too
                      > > hard, but what about the other direction?
                      > </quote>
                      >
                      > Sorry, I missed this one. What do you mean by "the other direction"?
                      > From an Effects list back to a kjd:Progression?

                      Yes. We have to be able to export the definitions back out of the
                      program.

                      > <quote who="Keith">
                      > > Or in memory, are the effects
                      > > associated to the thing they are based on, that is
                      > >
                      > > Score {
                      > > Effect[] effects;
                      > > }
                      > >
                      > > and when the score changes all effects are scanned and processed as
                      > > needed? (or scanned when doing output, for example).
                      > </quote>
                      >
                      > Yes, this is basically what the Observer-Observable pattern does - the
                      > sjb:Score would tell all Effects dependent on it that its value had
                      > changed, and then the Effects could correct themselves as necessary
                      > (which would occasionally cause other sjb:Scores to update, etc.) The
                      > advantage of this, is that we never scan irrelevant lists of things to
                      > update. Only the Effects that depend directly on the value of this
                      > sjb:Score are called to correct themselves. If we don't update these
                      > values at some point, they're wrong, so it's not like we can avoid
                      > doing these updates forever.

                      Hrm. I'm familiar with Observer-Observable, but in this case doesn't it
                      lead to a huge number of links back and forth? Any Entity may have
                      observable properties, so wouldn't each Entity need to register?

                      Assuming, of course, that loaded Entities aren't locked down so they
                      cannot change.


                      > The other solution to this (something similar to what Scott was
                      > suggesting, I think) is to associate with each Score a flag that says
                      > "I could be wrong!" and every time you need that Score, you first
                      > check it's "I could be wrong!" tag and the "I could be wrong!" tags of
                      > any Scores that it depends on. Note that even in this scheme, at some
                      > point, you'll have to go and check all the Scores that the Score you
                      > want to update is dependent on. (Or just check /all/ the other Scores
                      > if you don't want to maintain a dependency list. This makes me
                      > nervous though because it doesn't necessarily guarantee a reasonable
                      > order of Score updating.)


                      > My experience is that the Observer-Observable pattern solves this
                      > problem with the least hassle and the easiest to maintain code. If
                      > anyone has a simpler or cleaner way to handle the update problem
                      > though, I'm open to suggestions.

                      There may not be really *good* way of doing it when we have this many
                      entities to track. Both Observer and Scott's solution depend on things
                      being readonly in order to avoid using lots of resources if any Entity
                      is subject to change.

                      . Observer would require that each thing that can change have an
                      observer attached; managing this would lead to massive resource
                      consumption.
                      . Scott's model would, since dependencies presumably run only one way,
                      require that invalidated data be checked frequently.

                      Now, if things are limited as to when they can change (either readonly
                      once loaded, or allowed to change only if in the file being edited [my
                      preference, since it allows for multiple edits at once], or readonly
                      unless 'edit mode' is entered) then the resources for Observer and
                      Scott's model both drop immensely.

                      I think we can simplify things for ourselves significantly if we make a
                      few rules. How do these sound?

                      0. a file may contain more than one type of Entity.

                      Convention and practice may choose not to do this ('only put skills in
                      this file') but it will not be enforced by us. It must be possible
                      to, for example, export everything needed for a campaign into a single
                      file (it is not necessary to implement this function, just that file
                      must be capable of holding this information).

                      1. a file may contain more than one Entity.

                      This one seems pretty obvious; if we have to define each spell in a
                      separate file it's going to get really old, really fast.

                      2. all Entities loaded from a file will have the same readonly status.
                      3. only Entities from the file being edited may be directly modified.

                      These two tie together. A file may depend on a number of files, but
                      when editing a single file, only things in that file may be directly
                      changed. Everything else is locked down. This will reduce the
                      potential number of dependencies that have to be managed at any given
                      time -- if I know that 'Fighter' isn't going to change I don't need to
                      watch for changes (Observer) or check for invalidated information
                      (Scott).

                      Entities in the file being modified still need to be watched, but that
                      is a very much smaller subset of what will be available to work with.

                      4. transaction-type operations in a file may modify Entities from
                      another file; this is expected to be done primarily in central files
                      to avoid loss.

                      This is for the MOD capability we have in LST now, though Doug and I
                      think we may have a better way of doing it. Basically, it means that
                      if someone wants to redefine something he can, but it does not change
                      the core definition. These changes should be kept in a central area
                      (not the core area, but under custom/ or something) so that it can be
                      reused.


                      Keith
                      --
                      Keith Davies I gave my 2yo daughter a strawberry
                      keith.davies@... Naomi: "Strawberry!"
                      me: "What do you say?"
                      Naomi: "*MY* strawberry!"
                    • Frugal
                      ... The easiest way to do this is to keep a track of which effect gave which bonus. i.e. when Score.update(int) is called also
                      Message 10 of 20 , Jan 21, 2004
                      • 0 Attachment
                        <quote who="Steven Bethard">
                        > For this problem, we also want which armor mod gets selected to be chosen
                        > by
                        > selecting the one with the maximum value. I would suggest encoding this
                        > as:
                        > <def:score id="score.ac.mod.armor" maxeffects="1"
                        > effectpriority="maxvalue" />
                        > Thus you select 1 sjb:Effect by choosing the sjb:Effect for this Score
                        > that
                        > would produce the highest value.

                        The easiest way to do this is to keep a track of which effect gave which
                        bonus. i.e. when Score.update(int) is called also pass the effect that is
                        calling this update so you have Score.update(Effect, int). Then store a
                        map from Effect->Integer.

                        When asked for the value of the Score you find the highest Integer in the
                        Map.

                        This would still need a little expanding for Effects that STACK and
                        untyped Effects that always Stack.

                        --
                        regards,
                        Frugal
                        -OS Chimp
                      • CC Noram Carstensen James
                        ... recurring Effects (e.g. you should not have to indicate that for a class, at a score of 1, you get a d8 HD, at score of 2 you get another d8 HD, etc.)
                        Message 11 of 20 , Jan 21, 2004
                        • 0 Attachment
                          Steve wrote:
                          > I also expect to use the same kind of shorthands you do to indicate
                          recurring Effects (e.g. you should not have to indicate that for a
                          class, at a score of 1, you get a d8 HD, at score of 2 you get another
                          d8 HD, etc.)

                          Would the ability not to do the shorthand still exist? For example, the
                          3.0 Dragon Disciple did have varying HD by level.

                          Hmm, which of course makes me think about the fun undead types that
                          change every previous and future HD to d12. Could something like that
                          be represented?

                          Cheers,
                          Jim
                        • Frugal
                          ... While spanners are cheerfully being thrown into the works: Unarmed Damage. It alters by level, by size category.
                          Message 12 of 20 , Jan 21, 2004
                          • 0 Attachment
                            <quote who="CC Noram Carstensen James">
                            > Steve wrote:
                            >> I also expect to use the same kind of shorthands you do to indicate
                            > recurring Effects (e.g. you should not have to indicate that for a
                            > class, at a score of 1, you get a d8 HD, at score of 2 you get another
                            > d8 HD, etc.)
                            >
                            > Would the ability not to do the shorthand still exist? For example, the
                            > 3.0 Dragon Disciple did have varying HD by level.
                            >
                            > Hmm, which of course makes me think about the fun undead types that
                            > change every previous and future HD to d12. Could something like that
                            > be represented?

                            While spanners are cheerfully being thrown into the works: Unarmed Damage.
                            It alters by level, by size category. Also certain prestige classes allow
                            you to change unarmed damge to the next size category larget, or to the
                            next dice size larger

                            --
                            regards,
                            Frugal
                            -OS Chimp
                          • Steven Bethard
                            ... Absolutely. It would only be a shorthand for the more explicit approach. If the bonuses applied by the
                            Message 13 of 20 , Jan 21, 2004
                            • 0 Attachment
                              <quote who="CC Noram Carstensen James">
                              > Steve wrote:
                              >> I also expect to use the same kind of shorthands you do to indicate
                              > recurring Effects (e.g. you should not have to indicate that for a
                              > class, at a score of 1, you get a d8 HD, at score of 2 you get another
                              > d8 HD, etc.)
                              >
                              > Would the ability not to do the shorthand still exist? For example, the
                              > 3.0 Dragon Disciple did have varying HD by level.
                              >
                              > Hmm, which of course makes me think about the fun undead types that
                              > change every previous and future HD to d12. Could something like that
                              > be represented?
                              </quote>

                              Absolutely. It would only be a shorthand for the more explicit approach.
                              If the bonuses applied by the shorthand are not what you want, you could
                              always go the explicit route.

                              I've got some thought about how to simplify some of the formulae in my code
                              (without losing any of the expressiveness). I'll try to get some time to
                              make these thoughts more explicit and post something in the next few days.

                              <quote who="Frugal>While spanners are cheerfully being thrown into the
                              works:
                              > Unarmed Damage.
                              > It alters by level, by size category. Also certain prestige classes allow
                              > you to change unarmed damge to the next size category larget, or to the
                              > next dice size larger
                              </quote>

                              Yup. So shorthands may not always be possible (though I think a clean
                              solution to part of this problem would be like what I did with size:
                              associate integer values with the different size categories, and just treat
                              increasing size category as increasing the variable in an
                              sjb:Score/kjd:Progression.)

                              --
                              regards,
                              Frugal
                              -OS Chimp



                              Yahoo! Groups Links

                              To visit your group on the web, go to:
                              http://groups.yahoo.com/group/pcgen-xml/

                              To unsubscribe from this group, send an email to:
                              pcgen-xml-unsubscribe@yahoogroups.com

                              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                            • Keith Davies
                              ... For that matter, I would expect that you could make it two recurring effects. One from levels 1-n, another from n+1-10 (or higher, if you go Epic). Keith
                              Message 14 of 20 , Jan 21, 2004
                              • 0 Attachment
                                On Wed, Jan 21, 2004 at 10:07:40AM -0700, Steven Bethard wrote:
                                > <quote who="CC Noram Carstensen James">
                                > > Steve wrote:
                                > >> I also expect to use the same kind of shorthands you do to indicate
                                > > recurring Effects (e.g. you should not have to indicate that for a
                                > > class, at a score of 1, you get a d8 HD, at score of 2 you get another
                                > > d8 HD, etc.)
                                > >
                                > > Would the ability not to do the shorthand still exist? For example, the
                                > > 3.0 Dragon Disciple did have varying HD by level.
                                > >
                                > > Hmm, which of course makes me think about the fun undead types that
                                > > change every previous and future HD to d12. Could something like that
                                > > be represented?
                                > </quote>
                                >
                                > Absolutely. It would only be a shorthand for the more explicit
                                > approach. If the bonuses applied by the shorthand are not what you
                                > want, you could always go the explicit route.

                                For that matter, I would expect that you could make it two recurring
                                effects. One from levels 1-n, another from n+1-10 (or higher, if you go
                                Epic).


                                Keith
                                --
                                Keith Davies I gave my 2yo daughter a strawberry
                                keith.davies@... Naomi: "Strawberry!"
                                me: "What do you say?"
                                Naomi: "*MY* strawberry!"
                              • CC Noram Carstensen James
                                ... solution to part of this problem would be like what I did with size: associate integer values with the different size categories, and just treat increasing
                                Message 15 of 20 , Jan 22, 2004
                                • 0 Attachment
                                  Steve wrote:
                                  > Yup. So shorthands may not always be possible (though I think a clean
                                  solution to part of this problem would be like what I did with size:
                                  associate integer values with the different size categories, and just
                                  treat increasing size category as increasing the variable in an
                                  sjb:Score/kjd:Progression.)

                                  Could you have multi-dimensional kjd:Progressions? Frugal mentioned
                                  monk unarmed damage. To put this into array-speak, could you have a
                                  progression Unarmed[Level,Size] such that you can represent all of the
                                  different combinations, and also have easy ways of doing things like
                                  representing the enlarged (+1 size) monk who is wearing a Monk's Belt
                                  (bonus to monk level) because it just changes the lookup on the table.

                                  (I mention size because for some reason the 3.5 monk damage table for
                                  sizes other then medium doesn't quite follow the 3.5
                                  weapon-damage-change-by-size table.)

                                  -- Jim
                                • Keith Davies
                                  ... I was doing something like this using an order attribute in rating but I think you may be right that a Progression may be a better choice. hrm. If we re
                                  Message 16 of 20 , Jan 22, 2004
                                  • 0 Attachment
                                    On Thu, Jan 22, 2004 at 12:15:50PM -0500, CC Noram Carstensen James wrote:
                                    > Steve wrote:
                                    > > Yup. So shorthands may not always be possible (though I think a clean
                                    > solution to part of this problem would be like what I did with size:
                                    > associate integer values with the different size categories, and just
                                    > treat increasing size category as increasing the variable in an
                                    > sjb:Score/kjd:Progression.)

                                    I was doing something like this using an 'order' attribute in rating but
                                    I think you may be right that a Progression may be a better choice.

                                    hrm. If we're using Progression for things that *aren't* being applied
                                    in layers (the functionality is quite similar) I think that you may be
                                    right that 'Progression' isn't a great name for the generic form. OTOH,
                                    I think that 'Score' isn't such a great name either... we may want to
                                    think of a different term altogether.

                                    > Could you have multi-dimensional kjd:Progressions? Frugal mentioned
                                    > monk unarmed damage. To put this into array-speak, could you have a
                                    > progression Unarmed[Level,Size] such that you can represent all of the
                                    > different combinations, and also have easy ways of doing things like
                                    > representing the enlarged (+1 size) monk who is wearing a Monk's Belt
                                    > (bonus to monk level) because it just changes the lookup on the table.

                                    I hadn't considered it, but it does make some sense. Actually, 'Array'
                                    might not be a bad name for a collection of related/linked effects.

                                    > (I mention size because for some reason the 3.5 monk damage table for
                                    > sizes other then medium doesn't quite follow the 3.5
                                    > weapon-damage-change-by-size table.)

                                    of course not, that would make sense.


                                    Keith
                                    --
                                    Keith Davies I gave my 2yo daughter a strawberry
                                    keith.davies@... Naomi: "Strawberry!"
                                    me: "What do you say?"
                                    Naomi: "*MY* strawberry!"
                                  • Frugal
                                    ... Can you then either change the Array you are dealing with, or assign a new level to the array? For one of the feats in
                                    Message 17 of 20 , Jan 23, 2004
                                    • 0 Attachment
                                      <quote who="Keith Davies">
                                      > On Thu, Jan 22, 2004 at 12:15:50PM -0500, CC Noram Carstensen James wrote:
                                      >> Could you have multi-dimensional kjd:Progressions? Frugal mentioned
                                      >> monk unarmed damage. To put this into array-speak, could you have a
                                      >> progression Unarmed[Level,Size] such that you can represent all of the
                                      >> different combinations, and also have easy ways of doing things like
                                      >> representing the enlarged (+1 size) monk who is wearing a Monk's Belt
                                      >> (bonus to monk level) because it just changes the lookup on the table.
                                      >
                                      > I hadn't considered it, but it does make some sense. Actually, 'Array'
                                      > might not be a bad name for a collection of related/linked effects.

                                      Can you then either change the "Array" you are dealing with, or assign a
                                      new level to the array? For one of the feats in Oriental Adventures you
                                      can change the monks unarmed damage progression to something comlpetely
                                      different...

                                      --
                                      regards,
                                      Frugal
                                      -OS Chimp
                                    • Frugal
                                      ... Variable ? -- regards, Frugal -OS Chimp
                                      Message 18 of 20 , Jan 23, 2004
                                      • 0 Attachment
                                        <quote who="Keith Davies">
                                        > hrm. If we're using Progression for things that *aren't* being applied
                                        > in layers (the functionality is quite similar) I think that you may be
                                        > right that 'Progression' isn't a great name for the generic form. OTOH,
                                        > I think that 'Score' isn't such a great name either... we may want to
                                        > think of a different term altogether.

                                        "Variable" ?

                                        --
                                        regards,
                                        Frugal
                                        -OS Chimp
                                      • Frugal
                                        ... You would not register the Entity, but rather the effects of the Entity. ... The other problem is that any time you add a new
                                        Message 19 of 20 , Jan 23, 2004
                                        • 0 Attachment
                                          <quote who="Keith Davies">
                                          > Hrm. I'm familiar with Observer-Observable, but in this case doesn't it
                                          > lead to a huge number of links back and forth? Any Entity may have
                                          > observable properties, so wouldn't each Entity need to register?

                                          You would not register the Entity, but rather the effects of the Entity.

                                          >> The other solution to this (something similar to what Scott was
                                          >> suggesting, I think) is to associate with each Score a flag that says
                                          >> "I could be wrong!" and every time you need that Score, you first
                                          >> check it's "I could be wrong!" tag and the "I could be wrong!" tags of
                                          >> any Scores that it depends on. Note that even in this scheme, at some
                                          >> point, you'll have to go and check all the Scores that the Score you
                                          >> want to update is dependent on. (Or just check /all/ the other Scores
                                          >> if you don't want to maintain a dependency list. This makes me
                                          >> nervous though because it doesn't necessarily guarantee a reasonable
                                          >> order of Score updating.)

                                          The other problem is that any time you add a new Effect or Score/Variable
                                          to the character you have to invalidate everything. You can not just
                                          invalidate the things that the Effect invalidates, because you have no way
                                          of knowing what newly invalidated Score/Variable will invalidate.

                                          > . Observer would require that each thing that can change have an
                                          > observer attached; managing this would lead to massive resource
                                          > consumption.

                                          Does anyone know just how heavyweight the Observer pattern is in Java?
                                          From what I understand the only thing that the Observable object adds is a
                                          lookup table of Observers (i.e. A reference per Observer (4bytes on a
                                          32bit system)).

                                          > Now, if things are limited as to when they can change (either readonly
                                          > once loaded, or allowed to change only if in the file being edited [my
                                          > preference, since it allows for multiple edits at once], or readonly
                                          > unless 'edit mode' is entered) then the resources for Observer and
                                          > Scott's model both drop immensely.

                                          I am a bit confused by your reference to Data being Editable... Can you
                                          explain under what circumstances an Entity gets edited?

                                          The way I currently view what people are saying is that the Character is a
                                          set of Progression/Score/Variable (what ever they get called) and a set of
                                          references to Entities that can manipulate those P/S/Vs.

                                          As a Character is defined by its' P/S/Vs it will need to have its' own
                                          local copy of each P/S/V that applies to that Character. So character
                                          Alice will have a P/S/V with the ID 'score.stat'. Bob will also have the
                                          P/S/V with the id 'score.stat' but the two P/S/Vs are not the same Object.

                                          As Entities are applied to a Character the character will have a reference
                                          to each Entity, but will never be able to alter it. Alice can have the
                                          Entity "feat.toughness" applied to her, and Bob can have the Entity
                                          "feat.toughness" applied to him. The two Objects will be the same object.

                                          Or are people talking about a completely different layer to me?

                                          --
                                          regards,
                                          Frugal
                                          -OS Chimp
                                        Your message has been successfully submitted and would be delivered to recipients shortly.