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 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
<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

Content Meeting 2015-08-15

Contents

Content Meeting 2015/08/15

Attendance

Summary

Log

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Start

Teams

Community

Strategic Development

Misc

Tools