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

Variable System / Broken Tests for 4 Bugs

Expand Messages
  • thpr
    I have committed 6 unit tests that test 4 different bugs I have found (and verified with help from Drew) with how variables are handled (primarily in PREVAR)
    Message 1 of 2 , Sep 13, 2009
      I have committed 6 unit tests that test 4 different bugs I have found (and verified with help from Drew) with how variables are handled (primarily in PREVAR)

      The challenge is that context is either lost (meaning things like CL or BASESPELLSTAT evaluate to zero) or context is artificial (meaning a variable like "MyVar" is evaluated in context to the class, but is globally present)

      I have two requests:
      1) Can someone take a look at the unit tests as built and verify that I have the correct result expectations? Another set of eyes would be great.

      2) I am looking for help on solution development. Basically there are forces pulling in two directions. In one way, we need variables (e.g. MyVar) to be "global", so they cannot be cached/tested on a local basis. (Local being a src of CLASS:Warrior). On the other hand, the built-in formula items must be resolved in context to the class, regardless of whether they are "raw" on the class or whether they are attached to sub-items (SAB, BONUS, etc.)

      On one hand, this may be possible with some knowledge of what variables cause locality, and changing the cache string appropriately. On the other hand, we may need two different sources passed into the variable evaluation system (one for locality, one for evaluation context)

      Any help would be appreciated. (Nuance, are you close enough to this to help out given your heavy work on the term system?)

      TP.
    • Andrew Wilson
      ... I m not convinced that s the full story. I ve had a quick look and I think the BASESPELLSTAT behaviour is a genuine bug. The code term object that
      Message 2 of 2 , Sep 13, 2009
        2009/9/13 thpr <thpr@...>:
        >
        > I have committed 6 unit tests that test 4 different bugs I have found (and
        > verified with help from Drew) with how variables are handled (primarily in
        > PREVAR)
        >
        > The challenge is that context is either lost (meaning things like CL or
        > BASESPELLSTAT evaluate to zero) or context is artificial (meaning a variable
        > like "MyVar" is evaluated in context to the class, but is globally present)

        I'm not convinced that's the full story. I've had a quick look and I think
        the BASESPELLSTAT behaviour is a genuine bug. The code term object that
        evaluates BASESPELLSTAT uses teh PC to look up the class. It will only ever
        work for classes that you currently have. I suspect a global lookup of the
        class object to test would help here.

        > I have two requests: 1) Can someone take a look at the unit tests as built
        > and verify that I have the correct result expectations?  Another set of eyes
        > would be great.
        >
        > 2) I am looking for help on solution development.  Basically there are forces
        > pulling in two directions.  In one way, we need variables (e.g. MyVar) to be
        > "global", so they cannot be cached/tested on a local basis.  (Local being a
        > src of CLASS:Warrior).  On the other hand, the built-in formula items must be
        > resolved in context to the class, regardless of whether they are "raw" on the
        > class or whether they are attached to sub-items (SAB, BONUS, etc.)
        >
        > On one hand, this may be possible with some knowledge of what variables cause
        > locality, and changing the cache string appropriately.  On the other hand, we
        > may need two different sources passed into the variable evaluation system
        > (one for locality, one for evaluation context)

        The term objects all implment an isSourceDependant method. At the moment I
        don't think we ever want true variables to be source dependant, unless we
        implement the local variable scheme that we've been talking about for years.

        Why does locality matter, how is it different from source? The variables are
        not handled by the term system. CL and BASSPELLSTAT aren't varibles
        They are handled very differently in the code.

        > Any help would be appreciated. (Nuance, are you close enough to this to help
        > out given your heavy work on the term system?)

        I think the stuff I did for this is below the level of the stuff you're talking
        about. I intercept the bits of the formula string after it has been split on
        operators, Some other piece of code has already decided what source to pass
        to the code I modified.

        I think that maybe we need to modify the concept of source. Only some types
        of source have an effect on builtins (CL, BL, etc.), in fact it might only be
        Classes and spells. and for spells it's really only CASTERLEVEL.

        If we can get classes to pass on to the objects attached to them, the fact
        that they exist in a class and forget about everything else passing on its
        source, that might get us where we want to be. So, SABs for instance
        passone "" for source, unless they're attached to a calss, then they pass
        on "CLASS:whatever"

        andrew
      Your message has been successfully submitted and would be delivered to recipients shortly.