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

Re: [pcgen-xml] [int] and [ext]

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