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

Re: [pcgen-xml] [int] some responses / the big questions so far

Expand Messages
  • Frugal
    ... Okay, I have been having a play with this. It is in fact fairly trivial to implement this. what I have done is added
    Message 1 of 14 , Jan 28, 2004
      <quote who="Steven Bethard">
      > <quote who="Frugal">
      >> So all
      >> dependent children received an update either 0 or 1 times, and only if
      >> that update caused a change in their value did they notify their
      >> dependents. So for a Score with 4 dependent Sores the notifyObservers()
      >> will be called either 0 or 1 times.
      > </quote>
      >
      > It would be easy enough to put a conditional in to only call removeEffects
      > and apply effects if the value was going to change (take a look at
      > setValue). In general, if I had done things right (which I'm not claiming
      > is
      > true ;), the new method should only require O(2n) = O(n) method calls - in
      > place of calling notifyObservers, it should first call removeEffects and
      > second call applyEffects. (The notifyObservers call I have used is only to
      > notify the GUI. I wasn't too careful about that, so it's possible that
      > this
      > is being called too many times.)

      Okay, I have been having a play with this. It is in fact fairly trivial to
      implement this.

      what I have done is added stopNotifyingChanges() and
      startNotifyingChanges() methods to Entity. This increment/decrement a
      counter in the Entity class. If the counter is positive
      isNotifyingchanges() will return false.

      This way we can identify all operations that will need multiple processing
      before we should update the children:

      stopNotifyingChanges()
      /* do lots fo stuff */
      startNotifyingChanges();
      if (isNotifyingChanges()) {
      setChanged();
      NotifyObservers();
      }


      The advantage fo this is that we can perform special processing for each
      Entity subtype in the stop and start methods:

      E.g. In Score we store the current value if we are told to stop
      notification and the stop moves us from notification to not-notification.
      Then in startNotifyingChanges() we watch for the changes from
      not-notifying to notifying, then look to see if the current value is
      different to the value when we stopped notifyication, if ti is then call
      notifyObservers()

      > Remember also that my 'n' is not the same as your 'n'. I probably have
      > between half as many and a quarter as many Effects as the system did
      > originally. So to update for a single Effect the 3 Scores that it depends
      > on is the same in the original system as updating the 3 Scores that the 3
      > Effects that simulated this Effect were associated with.

      This is true, I had not really absorbed this artifact of your new
      solution. So with this new change we will in fact do about 1/3 of the
      updates that we used to do originally.

      > <quote who="Frugal">
      >> However as none of this is going to be implemented
      >> in the first phase it is all rather academic at
      >> the moment ;O)
      > </quote>
      >
      > True. On the other hand, this outcome of this discussion affects the final
      > syntax we support.

      It is also far more interesting than developing the test plan at work ;O)

      > So, moving to the questions that are important to the
      > first phase:
      >
      > * Do we use the $id syntax and allow Effects to be dependent on more than
      > one other Effect? That is, do people prefer something along the lines of
      > the
      > first or second syntax:
      >
      > 1)
      > <score-bonus targetid='score.ac.full'>
      > $score.stat.dex.mod +
      > $score.ac.mod.armor +
      > $score.ac.mod.shield +
      > $score.ac.mod.size +
      > $score.ac.mod.misc
      > </score-bonus>
      >
      > 2)
      > <effects sourceid='score.stat.dex.mod'>
      > <modify-score targetid='score.ac.full'>
      > $newsrc - $oldsrc
      > </modify-score>
      > </effects>
      > <effects sourceid='score.ac.mod.armor'>
      > <modify-score targetid='score.ac.full'>
      > $newsrc - $oldsrc
      > </modify-score>
      > </effects>
      > ....

      I do not really mind. They both have their own advantages: The first is
      more concise and obvious, but the second is closer to the obvious
      algorithm.

      I think that the deciding factor for me is that second syntax can be
      expressed by the first, but not the other way around. To me that makes the
      first syntax more powerful.

      i.e.

      <score-bonus targetid='score.ac.full'>$score.stat.dex.mod</score-bonus>
      <score-bonus targetid='score.ac.full'>$score.ac.mod.armor</score-bonus>
      <score-bonus targetid='score.ac.full'>$score.ac.mod.shield</score-bonus>
      ...


      > * Do we use a single Effect with a single test condition, or do we require
      > one Effect to apply each game-effect and one Effect to remove each
      > game-effect? That is, do people prefer something along the lines of the
      > first syntax or the second:
      > 1)
      > <score-bonus test="$score.skill.bluff.ranks >= 5"
      > targetid="score.skill.diplomacy.mod.synergy">
      > 2
      > </score-bonus>
      >
      > 2)
      > <effects stacks="true" test="$srcnew >= 5 && $srcold < 5"
      > sourceid="score.skill.bluff.ranks">
      > <modify-score id="modifyscore.skill.diplomacy.mod.synergy.bluff"
      > targetid="score.skill.diplomacy.mod.synergy">
      > 2
      > </modify-score>
      > </effects>
      > <effects test="$srcnew < 5 && $srcold >= 5"
      > sourceid="score.skill.bluff.ranks">
      > <remove-effect id="remove.skill.diplomacy.mod.synergy.bluff"
      > targetid="score.skill.diplomacy.mod.synergy"
      >
      > targeteffect="modifyscore.skill.diplomacy.mod.synergy.bluff"/>
      > </effects>

      Having looked at it, definitly the first, it is far less prone to bugs.
      The second syntax requires that you catch each rising and falling edge, if
      you miss it you are in trouble. The second syntax does at least give you
      the option of rebuilding the whole value from the ground up easily.

      I think that the next 2 phases of playing should be:

      1 - seeing how the system responds to this being assigned to a character
      (or more appropriately what changes need to be implemented to support 2+
      characters from the same model).

      2 - Seeing how the system needs to be expanded to cope with adding and
      removing Entities at runtime to a character (i.e. add and remove a feat
      Entity that gives a bonus to a stat).

      Then I think we need to think about some of the more interesting aspects
      fo PCGen: Classes, Spells and the dreaded %CHOICE tag. I would also be
      interested in peoples proposals for SpeciailAbility markup (i.e. values
      embedded in text and how that information should be stored in a Character
      object).

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