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

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

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