Dynamic 6.08

Deprecated

This page is deprecated and kept around because it is still a valuable code explanation that is not elsewhere. For updated content please see: Setting up the new Formula System

Original (Raw) Content

On Vision (and movement for that matter)

Since originally designing the variable system, I have long considered vision to be just another variable, with "vision" actually being a namespace.  I have shown examples of such, with VISION=Darkvision as a namespace and variable.  This has long been an interest to clean up because Vision is actually a rather weird object within PCGen.  It's halfway to things like Template and Skill, but leaves a lot of its code unused.  So it's a bit wasteful, but there is a recognition that it needs to have *some* level of "power".

That being said, my desire for a separate namespace has been built upon an assumption that I would eventually build a method of exposing all varibles of a certain namespace (to allow an output sheet to increment across all of the forms of vision).  We didn't cover that in the data meeting simply because we ran out of time (after running for 3 hours!?!)

Unfortunately, using a mere variable this runs into two challenges.  

The first is that there is data that "turns on and off" the vision based on the variables.  This hadn't really worried me - doing a bit of "pushing" on the data team to find constructs that work in the new system is good, and if it's really a problem, we can figure something out once I understand the exact rules construct that doesn't seem to work easily.

However, in planning conversion there is an issue when looking at one of the types of vision: Low-light Vision

This is a problem (and the second challenge).  Obviously "-" is a prohibited character in a variable name.  So is the space.  So we would have to have LowLightVision as the variable and then figure out a way for that to get "Low-Light Vision" onto the Output Sheet.  Preferably without hardcoding awareness of Low-Light vision  into the output sheet.  Could it be done? Yes.  Does it make a lot of sense to introduce LowLightVision (no minue, no space) as another String to be dealt with?  No.

Reality is this: We have a "string name" (Low-Light Vision) and a numeric Range (60).  This fits better with the model of certain types of Vision also not having a range (but being present).

Trying to extract and carry together both a name and a number in a single variable is a bit crazy.  I could easily define a new format, but then that format suffers from the same conversion issues I challenged Mark on with respect to OrderedPair a while ago.  It's worse, actually.  And I'm not sure it even solves the "how to increment across all variables of a type" problem, which is code I haven't written.

What we really need is the ability to define a "scope" on the fly, which creates a basically hollow, simple object.  So the scope is "VISION", and we can then instantiate "Low-Light Vision" and give it a variable "Range":

  DYNAMICSCOPE:VISION
  VISION:Low-Light Vision
  LOCAL:VISION|NUMBER|Range

This can then be modified as:

  MODIFYOTHER:VISION|Low-Light Vision|Range|SET|60

Since Vision is then an object that is in our "object library" (ReferenceContext to the code folks), we can pull the entire list from there (that code has long been written).  We can then expose the dynamic types in its own subvariable, and we then have a pretty easy way to increment across all vision objects:

  <#list ${pc.dynamic.vision} as vision>
    ${vision.name} ${vision.val.number.range}
  </#list>

(this ignores converting 60 to local units and all that, but you get the idea)

So the proposal is this:

1) DYNAMICSCOPE: becomes a new data control variable.

Like other LST tokens, this is case insensitive, but usage in later tokens is always capitalized, so I suspect the data standard should be all CAPS.

Any argument to that then becomes a legal "subtoken" in FILE:

2) DYNAMIC: becomes a new token legal in PCC files.  It's format is:

  DYNAMIC:x
  x is the file just as in tokens like DEITY or DOMAIN

INCLUDE/EXCLUDE on the line are are legal.

The prefix MUST appear on the line, e.g.:

  VISION:Darkvision
  VISION:Low-Light Vision

3) A Dynamic can not contain any information (no tokens).  It is NOT a full CDOMObject.

4) For Variable Definition and usage in MODIFYOTHER, the appropriate argument "x" matches the DYNAMICSCOPE (e.g. VISION would sensibly be "x" below)

  LOCAL:x|VAR|Range
  MODIFYOTHER:x|Low-Light Vision|SET|Range|60

5) We introduce a new token usable in LST files:

  GRANT:x|y
  x is a DYNAMICSCOPE
  y is the name of the dynamic object.

6) A Dynamic object MUST be granted in order to have its local variables modified or to have its modifiers have an impact (just like any other object)