Content Meeting 2015-08-15¶

Content Meeting 2015/08/15¶

Attendance¶

Tom P.
Andrew M.
Andrew W.
Stefan R.
Doug L.
Paul G.
Li-aung Y.

Summary¶

Discussed the logistics of the Formula System
Discussed the OUTPUT System
Discussed how INFO/INFOVARS interacts

Log¶

Well, if nothing else, I'll be able to touch base with the team and plan out some next steps.
<@Zaister> Is there documentation about this boolean thing?
which Boolean thing?
<@Zaister> Andrew was taling about something you’re planning
Andrew, were you thinking it would be a variable?
That's formula system and FACT/FACTSET
So the impression I got was "Can visibility be a formula value" - i.e. a local variable
So something like
aren't those variant and invariant versionsof the same thing
pretty close yes
LOCAL:SKILL|FLAG=Visible
or some such
I may be a tiny bit off on syntax there
but make it a local variable
Flag is
NAMESPACEDEF:BOOLEAN|FLAG
so it's a boolean
so "Visible" is "Boolean"
<@Zaister> was referring to something andrew mentioned a few times like „we can do this or that wehn Tom’s Boolean is implemented“ or some such
This is what Andrew is referring to
variables in the new system aren't just numbers
<@Zaister> ah ok
they can be Boolean, String, and other things
String variables! Woo!
<@Zaister> and they’re typed, not dynamic, right?
If I can geta 5 min break I can come back and we can talk abou tit
I'm feeling a bit better
<@Zaister> yes I’d appreciate the break myself
Indeed. It's the potential for "dice" variables tht has me gpoing Ahh.
Sure. 5 minutes all. Bangs the Gavel. Recess
<@Zaister> brb
time for a cuppa
afk making tea
peach oolong anyone?
i could get behind that, though it's just plain old irish breakfast for me
how appropriate, since I am in fact in Ireland
Tazo Chai myself w/ a spoonful of honey.
ok back
i have returned.
Excellent. Let's resume.
I recommend we close out BoD and make this the data discussion
agree
Ok back and on the road now
me too
never left :-)
hang head in shame at me too ism
Kinda did that, but yes - Board Meeting is closed bangs gavel thanks for coming everyone. Data Team meeting officially underway. ;)
ok thx
as Andrew is currently doing the BoD meeting log :P
So maybe it's best to walk through the lifecycle of a variable
and what concepts show up at each step
As mentioned, things don't have to be numbers
variables dont' have to be numbers. I'll try to be precise :P
At the base level, the difference is in the "format" of the variable
NUMBER, BOOLEAN, STRING, AREA to start
This was a typo, AREA was not a format, it was GRIDPOINT, and is now ORDEREDPAIR based on the outcome of the meeting
there will be more over time, and I'll touch on a few as I go
in order to use a format, data needs to define a "namespace"
each format can have more than one namespace
NAMESPACEDEF:BOOLEAN|FLAG
NAMESPACE:NUMBER|VAR
oops lost the DEF
NAMESPACEDEF:NUMBER|VAR
NAMESPACEDEF:NUMBER|MOVEMENT
et al
is it the namespace that is then used when the variable is referred to. The format is after that point "implicit" based on the namespace
Slight jump ahead to show this
MODIFY:MyVar|ADD|4
MyVar is by default a VAR namespace
if it's not a VAR, we need to specify
MODIFY:AREA=Face|SET|10,10
the "blah=" sets the namespace
for what follows
ok, jumping back
once a namespace is defined, then variables can be defined
are namespaces compatible? can I add movement to a VAR, or vice versa?
Ok so far
@ampersandrew - will get back to that if it's okay to defer?
yes, certainly
thx
In your second MODIFY, is AREA a "format" or a "namespace"?
AREA is namespace
The Format is actually GridPoint
since it's effectively an x,y value
NAMESPACEDEF:GRIDPOINT|Area
yes that
I find that moderatelt bothersome
in what way?
an area is not a point
So, areas can only be square like that? I'm with Andrew.
Should the format be XY? rather than GRIDPOINT?
that would be better
ok, that's easy enough to change
Stefan?
Andrew?
Basically yore defining an area to be a square from 0,0 to x,y
rectangle technically
My inner mathematician (which is most of me) wants ORDEREDPAIR.
Yes right
well a rectangle form 0,0 to x,y
POint taken, let's use _exp to find a good name
3e support the output expects the x,y format, so as long as we support the existing stuff, I'm fine.
and not delve into that detail here
I'm a mathemTician as well and grid point for an area feels weird
yes, I was thinking ordredpair, but couldn't put my finger on the exact name
Ok
So back to defining variables
There is a separate file for doing this (which basically won't work initially since we will keep things in the code for a bit to keep the transition orderly)
Actually, there are separate files (plural)
These items are referred to from the PCC file, so more than one file is legal
nothing here in the game mode
woot!
The system will enforce compatibility
So if you define NAMESPACEDEF:STRING|MOVE
and NAMESPACEDEF:NUMBER|MOVE
expect a load error
Makes sense
but if it's both NUMBER, it will happily "listen twice"
same for variable names. redundancy isn't an issue if it's consistent
Two ways to define variables: GLOBAL and LOCAL
GLOBAL first
It can be as simple as
HP
This is implicitly global
and implicitly in the VAR namespace
So equivalent to
GLOBAL:VAR|HP
it will happily take
VAR|HP
and add the GLOBAL:
For local variables, one needs to define a scope
aside: I'm going to advocate for "GLOBAL:VAR|HP" to be the data standard
if the team wants the implicits taken away, that can be done as well
For every reference?
no, just whne you're definig it
Ah yes
ok, should I take the implicit things away then?
@amperandrew - Agreed.
to make sure it's clear what is beign done?
@Tom - naw, leave the implicit
Silverback's call
I think it's ok for references
we're talking in the var definition file right now
not elsewhere
different code
Ok
will leave implicit for now
can change later if folks want to discuss on _exp
Anyway, Scope
"Skill" is a scope (since we have skill objects). Same for "Equipment"
it is the type of object on which a local variable can be placed
There can be "subscopes"
EQUIPMENT.PART
(what we currently in the code call "equipment heads")
the . separates scope from subscope
The scopes require code work, so we will start with a small set
SKILL, EQUIPMENT, EQUIPMENT.PART
expect others, SPELL, RACE, CLASS all have good reason to exist
Ability?
heh, was waiting for that
:)
Template?
The answer to that is "we have to define what it means to have a local variable in Ability"
Template we can do
IF an Ability is MULT:YES and taken twice... one or two local variables?
True, other abilities might need to refer me
Reference
Groups of abilities and so on
That is a much longer discussion and I think the answer is it would be useful both ways, we need to look at it
Sir would they need to be global then? Or
there is a lot we can do without it, so let's take that as future work for now
yes, both, but that sounds complicated.
Dynamic namespace would be cool
runs screaming for the hills :-)
Hehe
might be a good test to see if I can run faster than ampersandrew
What is a "Dynamic Namespace"?
one defined dynamically
sounds scary
I.e. By an ability
and very very complicated, I imagine
Might be too complex, yes
Let's put that aside
Ok
Going on with local variables
the token format is much like GLOBAL, just adding the SCOPE as the first argument
LOCAL:EQUIPMENT|VAR|EqVarOne
Every piece of Equipment in the game then has EqVarOne as a local variable
The answer is: Yes, this will create some things that don't need it, but that isn't a big deal in reality
so we can't do weapons separate from rings separate from armour, etc.
no
Yes but rings will not use bars made for weapons and probably not consume memory
The equipment is a sparse tensor, like some Mosul dis use
Um autocorrect fail
parts are separate from equipment.
Some nosql dibs use
Dbs
!@#$
parts are a subpiece of equipment
I think Stefan needs more Coffee....
so the "Plus" for example would be on the Part
LOCAL:EQUIPMENT.PART|VAR|Plus
I'm typing on an iPad in the back of a moving car here :)
[07:58] @Stefan, always fun.
[07:58] :)
[07:58] watch outr for motion sickness. It's a bitch
[07:58] Tom, would that last example mean that every part on every piece of equipment gets a Plus?
[07:58] correct
[07:58] but it defaults to 0
[07:58] it has the variable anyway
[07:58] ah, good question
[07:59] it defaults to whatever the format was set to default to :)
[07:59] DEFAULTVARIABLEVALUE:NUMBER|0
[07:59] *** [OGL]Nylanfs has quit IRC: Quit: Page closed
[07:59] so, for example, DEFAULTVARIABLEVALUE:NUMBER|10 for armour class?
[07:59] no
[08:00] it's setting it for the entire format
[08:00] all NUMBER through all namespaces and variables
[08:00] NUMBERS are set to 0, BOOLEANs set to False, etc.
[08:00] ps. is NUMBER always integer?
[08:00] NUMBER is a number, not integer
[08:00] So idealtypisch 0 andere empor String
[08:01] Oops
[08:01] wow, that is some special-squirrel autocorrect
[08:01] does that mean #real?
[08:01] If data always uses integers, the system will use integer math to avoid creating things like 4.9999999999
[08:01] Ideally 0 and empty string
[08:01] Language was set to German ....
[08:01] it can process the effective equivalent of Integer and Double
[08:01] so yes, 5.6778 is legal
[08:01] as would be 1E10
[08:02] so one real number buggers up our formats for output?
[08:02] no, you can ask for integers
[08:02] okly
[08:02] Is integer/double on a variable-by-variable case?
[08:02] yes, calculation by calculation actually
[08:02] so if you had something like:
[08:02] MyVar (defaults to 0)
[08:02] ADD|5
[08:02] (goes to 5)
[08:03] MyOtherVar (defaults to 0)
[08:03] MyOtherVar|SET|if(MyVar<4,5.6,7)
[08:03] even with the 5.6 there (in true) the 7 (false) is used and thus stays Integer
[08:03] assumign that first ADD was to MyVar
[08:04] what about divide?
[08:04] and have you considered using rationals?
[08:04] Divide attempts to use integer math
[08:04] and if it can it will stay integer
[08:05] Will the system attempt to auto round like it currently does? Or will we be able to just set that where desired by formula?
[08:05] I avoided that to avoid the complexity
[08:05] The system does not round
[08:05] if you want rounding, you ask for it
[08:06] Hallelujah!
[08:06] ok, so we're kind of into using variables
[08:06] let's talk about MODIFY
[08:06] MODIFY:MyVar|SET|1
[08:06] Sets MyVar (defaults to VAR namespace) to 1 (integer)
[08:07] a note on Scope
[08:07] If you are in an object without a scope (e.g. RACE today), MyVar must be global
[08:07] if you are in an object WITH scope, MyVar can be local, or local to any parent scope (which implicitly includes GLOBAL)
[08:08] So this does impose that any local variables can't conflict with names from any parent scope to avoid confusion
[08:08] *** StefanR_ has joined #pcgen
[08:08] Is that enforced or recommended?
[08:08] enforced
[08:09] confusion in this case is "ambiguity in the code" which I can't solve
[08:09] I have to force it
[08:09] otherwise, every reference to every variable needs a scope
[08:09] and the formulas will become unreadable
[08:09] Consider this:
[08:09] ok, spent and hour debugging something last week where someone forgot to delete a local and was expecting the global to change value. Not a happy bunny
[08:10] so this:
[08:10] GLOBAL:MyVar
[08:10] LOCAL:EQUIPMENT|VAR|MyVar
[08:10] *** StefanR__ has quit IRC: Ping timeout: 250 seconds
[08:10] fails at LST load
[08:10] can't reuse the name
[08:10] so there is no "shadowing" of variables
[08:11] (so can't create the case you described)
[08:11] make sense?
[08:11] Good
[08:11] Yes
[08:11] yes
[08:11] So, if there is a global HP variable for the character, one would want to use something like EquipHP for the equipment variable
[08:11] would have to yes
[08:11] We can also do "Equip.HP" :)
[08:12] what are the legal characters for varable names?
[08:12] A-Za-z0-9 and _
[08:12] so no .
[08:12] Case sensitive?
[08:13] no
[08:13] not case sensitive
[08:13] Ok
[08:13] (can't be due to how LST files are processed)
[08:13] oh, and have to start with a letter
[08:13] MYVAR, MyVar and myvar are all the same?
[08:13] yes
[08:14] whY start with a letter?
[08:14] @Tom - Did we remove the "." support from variable naming?
[08:14] . Is a. Separator in Chen
[08:14] Pcgen
[08:14] Start with a letter so an equation parser can know what it's looking at
[08:15] i.e. is 1E9 a variable name or a Double value?
[08:15] dont' want ot create that ambiguity.
[08:15] Can a variable name start with an _?
[08:15] no
[08:15] Yeah, but starting with _ is a venerable tradition
[08:16] like c compilers use to mean this is mine don't ever use this
[08:16] so the code uses "*" actually
[08:16] because then you really can't use it
[08:16] because the parser will think you're trying to multiply
[08:16] if you try to use it
[08:17] let's see. Missed the "." discussion
[08:17] yes, "." was there in early builds, is not now
[08:18] * ampersandrew is still not sure why leading _ is a problem
[08:19] Not sure it is, though how would it be used?
[08:19] what semantically would it be communicating?
[08:19] never mind, not my problem
[08:19] I will look at the parser to see if it can handle leading _
[08:19] we might choose to use it on locals si it's obvious when you see wone that it's local
[08:20] there are actually multiple components that I need to be sure can handle that
[08:20] if it's major work for get it. We can probably do without it.
[08:20] Well, looking, it would change the parser, so it's pretty deep
[08:21] I'd say we start without and I can go back... would need to write a bunch of tests to be comfortable it doesn't mess anything up
[08:21] Then we don't really need it.
[08:21] So, Equip_HP for now...
[08:21] y
[08:21] as a data standard you could use lower case starting letter for local and Upper for Global
[08:22] Or just EquipHP
[08:22] I wrote all this code already and it's not there is perfectly acceptible
[08:22] I don't know if we need it (now), but could one use the same variable name for both skills and equipment?
[08:22] while the code sees them as equivalent that doesn't mean the data can't be capitalized to provide clarity
[08:22] yes, because SKILL and EQUIPMENT are "disjoint" scopes, it is legal to reuse a variable name
[08:23] that was a specific request some time ago, as the initial builds did not support that
[08:23] Should we move on to MODIFY?
[08:23] i'm happy
[08:23] Yes
[08:23] Ok
[08:24] Okay, so I described how scope impacts MODIFY
[08:24] The example being
[08:24] have a conference call, will be monitoring...
[08:24] MODIFY:MyVar|SET|1
[08:24] This can also be a formula
[08:24] MODIFY:MyVar|SET|if(OtherVar>5,15,floor(HisVar))
[08:25] there are various built in functions, things like ceil, floor, round, if, abs, max, min
[08:25] It's also possible to use a "previous version of self"
[08:25] MODIFY:MyVar|SET|if(OtherVar>5,15,floor(value()))
[08:26] value() is a special function
[08:26] this means "the value of the variable" (in this case MyVar) before this MODIFY was applied
[08:26] the other thing to recognize is the default namespace
[08:26] in the items above, both OtherVar and HisVar MUST be VAR
[08:27] because MyVar is VAR
[08:27] you can "grab out of namespace" if you need to
[08:27] going to use an arbitrary function name here since this isn't built yet)
[08:28] MODIFY:MyVar|SET|value()+getVar("Movement","Walk")
[08:28] getVar would "drop into" the MOVEMENT namespace and then return the value of MOVEMENT=Walk
[08:28] whoops don't want all the quotes
[08:28] MODIFY:MyVar|SET|value()+getVar("Movement",Walk)
[08:28] this answers the question I deferred earlier. make sense?
[08:30] Set with value + is the same as add, right?
[08:30] value()+
[08:30] similar result as ADD
[08:30] but ADD will be less memory
[08:30] Ok
[08:30] and if is a non-formula, such as a static value, ADD will be orders of magnitude faster
[08:30] because no formula parser has to be invoked
[08:31] So the standard should be "use ADD, MULTIPLY or the other specific modifiers if possible"
[08:31] Makes sense
[08:32] @ampersandrew, I hope I got to your question about adding movement to a var. ask if you have other questions on that
[08:33] So the second argument to MODIFY also has legal values based on the FORMAT of the first argument
[08:33] you can ADD to a NUMBER, but not a STRING for example
[08:33] all of them can SET
[08:34] and things like value() replacing existing content is for numbers (can't do formulas in strings)
[08:34] @Tom[Arch_SB] yes, that answers my question. Sorry was away for sec.
[08:35] The other thing in MODIFY is setting the order of calculations
[08:35] First, it follows rules we (hopefully) all learned in elementary school
[08:35] e.g. MULTIPLY before add
[08:35] We also SET before MULTIPLY
[08:36] if we want to override those default rules, we can add a PRIORITY
[08:36] MODIFY:MyVar|SET|40|PRIORITY=50
[08:36] The system starts with priority 0 and proceeds to infinity, applying things as it goes
[08:36] if more than one MODIFY has the same priority then it defaults within those items with matching (user) priority to the "natural order"
[08:38] how do we think we'll do thngs like take the best of the currently available values. LIke we do with AC, armour doesn't stack
[08:38] Higher value means higher priority I assume.
[08:38] @Stefan: Yes, because it processes lowest priority first
[08:38] so higher will overwrite
[08:38] Ok
[08:39] @ampersandrew So with best of currently available those can be MAXes
[08:39] MODIFY:Armor|MAX|OtherArmor
[08:40] or maybe a hardcoded value of 20 rather than OtherArmor
[08:40] actually I have that backwards
[08:41] no, I have that right
[08:41] MAX is equivalent of max(a,b)
[08:41] max(value(),20)
[08:41] we went back and forth on that a bit
[08:42] one thought was MAX set a cap, other was it invoked the max function
[08:42] so I'm open a better name to get it semantically clear what it is doing
[08:42] *open to a better
[08:43] I suppose something like UPTO or NOGREATERTHAN could be a synonym for MIN.
[08:43] so, would each piece of armour have MODIFY:Armor|MAX|<5>
[08:43] where <5> is a placehoplder for this items AC
[08:44] more likely MODIFY:Armor|MAX|Equip_AC
[08:45] so let me build a scenario for a moment
[08:45] and everything that provides a non-stacking armour bones does that.
[08:45] Let's assume Armor is composed of two things: A Non-Stacking set of things (let's call it BaseArmor) and a stacking set (lets call it ArmorBonus)
[08:46] So part of what we want is MODIFY:Armor|SET|BaseArmor+ArmorBonus
[08:47] where that goes? back to that in a bit
[08:47] Then for each piece of Armor perhaps we have
[08:47] MODIFY:EquipBaseArmor|SET|5
[08:47] this is a local variable
[08:48] BaseArmor is global as is Armor, ArmorBonus
[08:48] So we need to take each piece of Equipment's EquipBaseArmor and add to the global value
[08:48] MODIFYOTHER:EQUIPMENT|ALL|BaseArmor|ADD|EquipBaseArmor
[08:48] we do this once in a global file (same place the SET for Armor went
[08:49] DOH
[08:49] Surely that should be MAX not add
[08:49] yes that!
[08:49] :D
[08:49] or SET?
[08:49] MAX
[08:49] MODIFYOTHER:EQUIPMENT|ALL|BaseArmor|MAX|EquipBaseArmor
[08:49] Nice
[08:49] this "magically" adds that MODIFY to every piece of equipment
[08:49] so the equipment itself only needs the SET to set its own value
[08:49] keepign the equipment simple
[08:50] I like that
[08:50] MODIFYOTHER:EQUIPMENT|ALL|ArmorBonus|ADD|EquipBaseBonus
[08:50] sorry, probably better as EquipArmorBonus
[08:50] but you get the idea
[08:50] yes, EquipArmorBonus stacks and EquipBaseBonus doesn't
[08:51] So hopefully, most of the local variables can be simple SETs, and the entire "algorithm" for how results are calculated are centralized in a "global modifier" file
[08:51] Will this tie into the COST system of Equipment?
[08:51] where the data team can have multiple variables, calculations at whatever priority is necessary, et al to get the right result
[08:51] I suspect COST will eventually be a local variable
[08:52] but let's talk about that for a moment
[08:52] COST is interesting because there are rules... and then exceptions
[08:52] Taking all that code out and replacing it with this. Very nice.
[08:53] So the main structure could be set up to calculate things using the pattern, but what if a piece of equipment is "out of line"
[08:53] MODIFY:Cost|SET|1835|PRIORITY=20000
[08:53] The high priority just "overwrites" whatever else there would have been
[08:53] allows exceptions
[08:53] The game mode could do things as well
[08:53] MODIFY:HP|MIN|1|PRIORITY=500000
[08:54] for example
[08:54] so "global" minimums and maximums just become a global MODIFY with a very high priority
[08:54] it's "soft" enforcement that someone can override when a rulebook says "ignore that rule, really"
[08:54] So we still keep gamemode?
[08:54] it won't go away in the short term
[08:55] but it will be chipped away at certainly
[08:55] q: with things overwriting other things - how can list file writers see the list of things that might have been applied, before the final value was obtained?
[08:55] aha!
[08:55] I thought we were moving away from gamemode to global files that can be loaded by PCCs
[08:55] fantastic question. layip
[08:55] @ampersandrew: The global modifiers are also in files loaded by PCC not in the game mode
[08:56] @layip: There is a debugging tool in the UI
[08:56] You identify the namespace, scope, and variable name, and it will tell you in gory detail every step it took to calculate the value
[08:56] like: http://imgur.com/qRoo5ak
[08:56] That's in the "calculator"?
[08:56] the original value, the resulting value, the modifier applied and the object from which the MODIFY came
[08:57] let me find a screen shot, I think I have one
[08:57] hmm, not finding it quickly
[08:58] wiki it?
[08:58] yes, I will get a sample of it up onto the wiki
[08:58] is it in a similar spirit to what is shown in the imgur screenshot; shows the sources of all modifiers in enough detail to figure out where some crazy effect is coming from?
[08:59] similar
[08:59] I am doing a build of PCGen then can pull up a sample
[09:00] http://ft.trillian.im/f2a02d5db0b6c7e07d3245dbcdc32e5cd3686d51/6ANVeHNHg2TvpdnBwE5zVPelRZryz.jpg
[09:00] aha, yes, like that
[09:00] So Unnamed 1 is the PC
[09:00] VAR is the namespace
[09:00] EQUIPMENT is the scope
[09:00] The Axe is the actual object within that scope
[09:01] AllowedCharms is the variable name
[09:01] shows the modifier (both just basic sets), the resulting value, priority of the MODIFIER and source of the MODIFIER
[09:01] does the parser currently keep track of input file line numbers, for list file debugging purposes?
[09:01] only during active load
[09:02] meaning if there is an error in the file during load we have it, but once load is complete, no, it is not kept
[09:02] alright, answers my question
[09:03] So that's basically the formula system as it works internally. I can talk a bit about output...
[09:03] (how one would access a variable in an output sheet)
[09:03] other questions before I do that?
[09:03] Yes
[09:04] Subsytems order that you planned for conversion? Or should that come after?
[09:04] I don't have it planned out past the first two yet
[09:04] ALTHP will be first since it is rather simple
[09:05] then probably SR
[09:05] Both simplistic and straightforward. I imagine DR will be a beast.
[09:05] other early ones are likely to be VISION, CR, Stat Locking, Region/SubRegion, Weight
[09:05] For output now, right?
[09:05] I'm not even sure DR will be converted
[09:06] Pie in the sky: how insanely impossible would it be to have a DIEROLL variable format (eventually allowing MODIFY and/or random generation)?
[09:06] talking which subsystems we will convert to the new formula system
[09:06] that holds values like d6 and if you add d6 you get 2d6, et al?
[09:06] Ah
[09:06] Not insane by any stretch
[09:07] not where I'm going to start, but well within reason to do as we progress
[09:07] what makes it interesting is where you have a 6d6 dieroll and something want to modify that to 6d8
[09:07] agree
[09:07] Or 1d10 to 2d6 (size increase)
[09:08] or crazy stuff like 2d6 +1d6 fire
[09:08] yes, just needs clear rules on what happens
[09:09] Wouldn't that be an index reference style list? if base die =1d6 use blah.
[09:09] the 6d6 to 6d8 example is one of them. If it's DIESTEPINCREASE, for example, then what happens if it's 6d6+1? Is that really 6d6+1 or 6d6+1d1? Does it become 6d8+1 or 6d8+1d2?
[09:09] LOTS of questions. We shouldn't even try to solve that here
[09:09] no, but we're aware it's hairy
[09:10] one other thought occurs to me.
[09:10] The base damage plus this extra damage from here, oh and a size increase. is very similar to multiple sources of DR that all need to be aggregated
[09:11] We may need some way to aggregate die rolls from varioious sources to produce the final
[09:11] so 1d120 + 1d6 (fire) + 5 is three separate things
[09:12] each separately modifyable
[09:12] let's take it to a thread on _exo
[09:12] where d120 is d10 really
[09:12] _exp
[09:12] Yeah, that's a rats nest
[09:12] _exp for sure.
[09:12] I'm not sure I get it with the example you gave and want to give it appropriate attention without diverting this
[09:13] Any other questions before I go to output?
[09:13] I think that is actually three different variables, no aggregation required.
[09:13] _exp please
[09:13] Let's move on to Output. :)
[09:13] if it's the damage your sword does you need to aggregate it for output
[09:14] Nice cat-herding, Tom. I'll have to go now.
[09:14] *** DistantScholar has quit IRC:
[09:14] Global variables "output by default" (meaning they are always visible to output)
[09:14] output yes
[09:14] in Freemarker, we have the "pc" variable, accessible by "$pc" that has subvariables
[09:14] test for defined?
[09:15] meaning what?
[09:15] There isn't a concept like DEFINE in the old system
[09:15] test for actually modified by the system?
[09:15] no
[09:15] does this var exist on this PC, has the system used it in any way
[09:15] because setting the default value to 0 is a modification
[09:16] they exist when the GLOBAL: is struck in the var definition file
[09:16] Wouldn't that simply be a >0?
[09:16] no, you could add one for this ability then subtract one for that. the variable is in use and affects your chgaracter
[09:16] Ah, okay.
[09:16] but is indistinguishable from not reallyu on tis char
[09:17] output all of these aspects even though they don't really apply
[09:18] so what's the specific use case there?
[09:18] Are there aspects that can be zero but have enabled/disabled state as well?
[09:18] we need to replace aspects. not every ability has an aspect and we switch on their existance
[09:18] local variables exist on all copies of whatever they;'ve been defined on
[09:19] might need to use flags instead
[09:19] let's get a concrete example to _exp and work through it
[09:19] figure out how to do it without making things insane
[09:19] ok
[09:20] sorry for the derail
[09:20] no worries, the goal here is to expose issues, just want to solve them elsewhere so we can discover more :D
[09:20] so not really a derail anyway
[09:20] ok, output
[09:21] ${pc.var.area.face}
[09:21] "var" is the subname dropping into the variable system
[09:21] "area" is the namespace
[09:21] "face" is the variable name
[09:21] all global variables can be accessed this way
[09:21] where do we tell it integer or 2 digits of precision
[09:22] What else could be in place of var there?
[09:22] ${pc.languages} would give you the list of languages
[09:23] Ah
[09:23] ${pc.var.var.hitpoints?round=2} would give you two decimal points of accuracy (rounded)
[09:23] var, so good we mentioned it twice :-)
[09:24] the first one being dropping into the variable system, the second being the namespace
[09:24] a bit goopy, but hey...
[09:24] "Heal me, I have only 0.05 hp left!"
[09:24] if there is a better name for the first one, even spelling out to "variable" let me know
[09:24] yesh, I'm mostly being factious. I did know it was intentional.
[09:25] but it can be confusing, so good to have it called out
[09:25] everyone good on global variables?
[09:25] I like the shorthand 'var' but we are calling it the formula system... would 'form' be a bit easier?
[09:25] I'm ok
[09:25] otherwise, looks good to me.
[09:26] local variables... aren't output yet
[09:26] so we can discuss how we want to do it
[09:26] Do we have stuff that is not pc.something?
[09:26] there are 2 ways
[09:26] yes, in particular gamemode.something and pcgen.something
[09:26] ${pc.val.var.hp}
[09:26] Ok
[09:26] for those items that are game mode scope and application scope
[09:27] I like val better than form
[09:27] Agreed. Val works great.
[09:27] on local variables, we could do the similar thing to global and make them ouptut by default
[09:27] Val is good
[09:27] ${pc.languages[0].val.var.whatever}
[09:27] or... we can make it more like FACT
[09:28] where there has to be a visibility set in the variable definition file
[09:28] and it becomes shorthand, e.g.
[09:28] ${pc.languages[0].whatever}
[09:28] I like sommonality with FACT.
[09:28] doh! Commonality
[09:29] The more alike these new system are the better in my view
[09:29] the difference being that this then "implies" it's a variable and the namespace (Which was learned from the token in the definition file). The disadvantage being that it shares an output namespace with FACT/FACTSET and all the namespaces, so common items can't be output
[09:29] specifically if there is a FACT that is "Foo" and a local variable "Foo" only one can be legal in output
[09:29] since ${pc.languages[0].foo} can't be ambiguous
[09:30] Would the fact be on the language there?
[09:30] I think consistency should win out then. Since FACT is on most files.
[09:30] because I would be ok with that if it was
[09:30] FACTs are always on objects yes
[09:30] you either have a FCT or a local
[09:30] using a name
[09:31] or a "builtin" of sorts
[09:31] ${pc.language[0].key} gives you the key
[09:31] *** Tom[Arch_SB] has left #pcgen
[09:31] *** Tom[Arch_SB] has joined #pcgen
[09:31] doh, sorry
[09:31] np
[09:31] if you ever define a local called key you're just asking for trouble
[09:31] it will reject it if you try to export
[09:31] ${pc.languages[0].val.var.whatever} means less worry about a shared name between vars and fact.
[09:31] any of the builtins create a reserved namespace
[09:32] reserved name I should say
[09:32] ${pc.language[0].outputname}
[09:32] there are more
[09:32] and you can go look in the NEWTAG feature requests to find them :D
[09:32] @Andrew yes, that is the tradeoff
[09:33] so the data team needs to decide what it wants
[09:33] I vote for the more verbose but no shared name space.
[09:33] I'm open to either, the longer version you just showed is a tiny bit easier, but we're talking maybe 15 minutes difference
[09:33] in my time to do the other
[09:34] I think it's probably an _exp discussion as well to get input
[09:34] I lean towards the thing but am not wedded to it.
[09:34] the other thing
[09:34] FACT/Local sharing
[09:34] Okay, we can discuss it over on _exp.
[09:34] yes, single namespace for FACTs and locals tagged for output
[09:35] So my time is starting to run short actually (gack, it's past noon!)
[09:35] So I'd like to touch on INFO/INFOVARS as well
[09:35] Which is the key it's not all locals, just the ones we want to output. anyway discussion on _exp
[09:35] Tom - is the output the defining factor?
[09:35] yes, the namespace overlap is restricted to output
[09:36] so that is all we're really discussing in that thread
[09:36] oh, that makes things less restricted. Okay, to _exp for that then.
[09:36] if you start these threads I can enhance them with detail later
[09:36] So let's start with INFO
[09:37] takes 2 arguments
[09:37] an info name and the format
[09:37] the "info name" is dynamic. Just use one in the data that is unique to that object
[09:37] All it will do it "tie it" to the matching INFOVARS token
[09:37] so an INFO that needs a variable without an INFOVARS with a matching info name will generate a load error
[09:38] likewise an INFOVARS with no info will generate a load error
[09:38] the variables are counted, so if INFO needs 3 vars and you provide only 2 to INFOVARS, you get an LST load error
[09:38] are they type checked?
[09:38] the vars? not at this time
[09:38] two ints and a string in that order? or no?
[09:39] good. Can I use the same variable in two locations?
[09:39] the problem is I don't necessarily know what is asked for
[09:39] {1} could be anything, not just number or string
[09:39] INFOVARS:HP,HP,HP?
[09:39] yes, you can use the same thing over and over, but it isn't necessary
[09:40] The format can be: I have {0,number,integer} HP which is really {0} if you want the decimal point
[09:40] the 0 indicating the first item in INFOVARS... can be used multiple times
[09:40] Ah but it lets me subvert your can't define my own variable yest and put in INFOs instead of DESCs. I have a large update to do on modern and don't want to do it with DESCs
[09:40] I fear my power is running out, so I may drop out on.
[09:41] Well, maybe
[09:41] DESCs that I'm going to have to replace very soon
[09:41] INFOVARS have to be variables not formulas
[09:41] you can't do:
[09:41] INFOVARS:Something|1+2
[09:41] that will fail
[09:41] if you define one variable in the system anywhere an it doesn't type chack I can use it :-)
[09:41] I look forward to your creativity :D
[09:41] on my own head be it etc.
[09:42] (variables are type checked though, just not the passage from INFOVARS to INFO)
[09:42] So if the variable is Number, you can't set it to a String
[09:42] anyway.... good for folks to learn about MessageFormat
[09:43] there are various formatting options as well as methods of doing internal choices to get the right string presented
[09:43] I'm not intending to set these variables just mention them and have a comment with the actual variable I'M PLANNING TO USE EVENTUALLY
[09:43] oops shouty
[09:43] ah right
[09:44] INFOVARS same rules as elsewhere, defaults to VAR= namespace
[09:44] others have to specify
[09:44] there is a limit of 10 variables (0 through 9)
[09:44] please speak up if anyone runs into that
[09:45] the general message I can't reinforce enough is that if something feels complicated, ask.
[09:45] I can't imagine running into that
[09:45] there may be places where a simple feature I have planned can be added to make your life easier, I just didn't realize it was needed yet
[09:46] So going back to this example I used on _exp
[09:46] INFO:InfoTextName|"There {0,choice,0#are no files|1#is one file|1<are {0,number,integer} files}.
[09:46] INFOVARS:InfoTextName|FileCount
[09:46] this implies there is a GLOBAL:VAR=FileCount in the variable definition file
[09:47] that will, of course, be checked at LST load
[09:47] guys. I'm sorry but I'm going to have to head. wil read the log
[09:47] Actually, FileCount could be a local variable as well. This follows the same "scope rules" I defined earleir
[09:47] no worries, I think we're close to wrapping anyway
[09:47] *** ampersandrew has quit IRC:
[09:48] Yeah, I'm going to have to head to work shortly as well.
[09:48] okay, one more quick point
[09:48] If you want to finish your thought Tom.
[09:48] outptu of INFO
[09:48] ${pc.langauges[0].info.infoname}
[09:49] where "infoname" is the (case insensitive) name provided as the first arg to INFO (and INFOVARS, if necessary)
[09:49] BTW: IF there is no variable in INFO, there is no need to use INFOVARS
[09:49] okay, we'll call that a wrap on my end
[09:49] any last questions?
[09:50] Looks great. So the "|" is a separator in the INFO sequence?
[09:50] yes
[09:50] the separator
[09:50] name|format
[09:50] the format can use | as well, but those are ignored
[09:50] for purposes of splitting up what is what
[09:51] INFO has only one format as the argument
[09:51] Okay, thanks for the meeting Tom. I've got the log. And I think we have a few emails to push to _exp.
[09:52] ok, thanks all, I hope this was helpful and we can follow up on _exp with additional questions or comments, etc

Source: Content Meeting 2015-08-15 (original PCGen wiki)