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

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

Expand Messages
  • Steven Bethard
    ... Absolutely. It would only be a shorthand for the more explicit approach. If the bonuses applied by the
    Message 1 of 20 , Jan 21, 2004
      <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 2 of 20 , Jan 21, 2004
        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 3 of 20 , Jan 22, 2004
          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 4 of 20 , Jan 22, 2004
            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 5 of 20 , Jan 23, 2004
              <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 6 of 20 , Jan 23, 2004
                <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 7 of 20 , Jan 23, 2004
                  <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.