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

• <Andrew[Chair]> 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?
• <Tom[Arch_SB]> which Boolean thing?
• <@Zaister> Andrew was taling about something you’re planning
• <Tom[Arch_SB]> Andrew, were you thinking it would be a variable?
• <Andrew[Chair]> That's formula system and FACT/FACTSET
• <Tom[Arch_SB]> So the impression I got was "Can visibility be a formula value" - i.e. a local variable
• <Tom[Arch_SB]> So something like
• <ampersandrew> aren't those variant and invariant versionsof the same thing
• <Tom[Arch_SB]> pretty close yes
• <Tom[Arch_SB]> LOCAL:SKILL|FLAG=Visible
• <Tom[Arch_SB]> or some such
• <Tom[Arch_SB]> I may be a tiny bit off on syntax there
• <Tom[Arch_SB]> but make it a local variable
• <Tom[Arch_SB]> Flag is
• <Tom[Arch_SB]> NAMESPACEDEF:BOOLEAN|FLAG
• <Tom[Arch_SB]> so it's a boolean
• <Tom[Arch_SB]> 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
• <Tom[Arch_SB]> This is what Andrew is referring to
• <Tom[Arch_SB]> variables in the new system aren't just numbers
• <@Zaister> ah ok
• <Tom[Arch_SB]> they can be Boolean, String, and other things
• <DistantScholar> String variables! Woo!
• <@Zaister> and they’re typed, not dynamic, right?
• <Tom[Arch_SB]> If I can geta 5 min break I can come back and we can talk abou tit
• <Tom[Arch_SB]> I'm feeling a bit better
• <@Zaister> yes I’d appreciate the break myself
• <ampersandrew> Indeed. It's the potential for "dice" variables tht has me gpoing Ahh.
• <Andrew[Chair]> Sure. 5 minutes all. Bangs the Gavel. *Recess*
• <@Zaister> brb
• <ampersandrew> time for a cuppa
• <layip> afk making tea
• <ampersandrew> peach oolong anyone?
• <layip> i could get behind that, though it's just plain old irish breakfast for me
• <ampersandrew> how appropriate, since I am in fact in Ireland
• <Andrew[Chair]> Tazo Chai myself w/ a spoonful of honey.
• <Tom[Arch_SB]> ok back
• <layip> i have returned.
• <Andrew[Chair]> Excellent. Let's resume.
• <Tom[Arch_SB]> I recommend we close out BoD and make this the data discussion
• <layip> agree
• <StefanR> Ok back and on the road now
• <ampersandrew> me too
• <DistantScholar> never left :-)
• <ampersandrew> hang head in shame at me too ism
• <Andrew[Chair]> Kinda did that, but yes - Board Meeting is closed *bangs gavel* thanks for coming everyone.

Data Team meeting officially underway. ;)

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