Difference between revisions of "Content Meeting 2015-08-15"

From PCGen Wiki
Jump to: navigation, search
(Summary)
m
 
Line 72: Line 72:
 
* <Tom[Arch_SB]> At the base level, the difference is in the "format" of the variable
 
* <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]> 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]> 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]> in order to use a format, data needs to define a "namespace"

Latest revision as of 22:03, 15 August 2015

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