Content Meeting 2016-02-27

From PCGen Wiki

Revision as of 17:33, 27 February 2016 by LegacyKing (talk | contribs) (→‎RAW LOG)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Jump to: navigation, search

Team Members

Tom - Arch SB
Andrew - Content SB
Doug - Data 2nd
Stefan - OS 2nd

RAW LOG

[08:34] <@[Content]Andrew> Thanks for coming to the meeting all. And thanks to Tom for taking the initiative getting things primed. I've been taking some early tests and playing with the system the previous few days.
[08:35] <Tom[Arch_SB]> I'm back
[08:35] <@[Content]Andrew> My only initial thoughts is we need a central location for finding the syntax for both the data and OS changes that will need to happen. Makes conversion a bit easier
[08:36] <Tom[Arch_SB]> I think there are a few things that should be centralized
[08:36] <Tom[Arch_SB]> I think having a matrix of what datasets have done what conversions (and if they haven't, if there are gates on code) would be helpful
[08:36] <@[Content]Andrew> Agreed
[08:37] <Tom[Arch_SB]> On the conversions, I started a wiki page to use as a central location
[08:37] <Tom[Arch_SB]> Not all the conversions I added in the last day or so have been announced on _exp, so not all in the wiki
[08:37] <Tom[Arch_SB]> but they will get there
[08:38] <Tom[Arch_SB]> Is that what you were looking for Andrew (have you looked at the wiki page?)
[08:39] <@[Content]Andrew> Yes, however, the conversion wiki has the codecontrol, I needed to verify the MODIFY syntax, specifically the if() statement syntax.
[08:40] <@[Content]Andrew> I was referencing the discussions on _exp to find that.
[08:40] <@[Content]Andrew> Knowing the valid syntax will help determine if we encounter a bug.
[08:41] <Tom[Arch_SB]> We may have to go put up a wiki page that links to the NEWTAG entries
[08:41] <Tom[Arch_SB]> I don't really want to reproduce all of that stuff, and we need the NEWTAG to be complete anyway so the docs get right
[08:41] <@[Content]Andrew> That would be a good. Limit the amount of writing so we focus on code and content.
[08:42] <Tom[Arch_SB]> Something I will reference shortly: https://groups.yahoo.com/neo/groups/pcgen_experimental/conversations/messages/19736 (This is ARRAY[x] format)
[08:43] <Tom[Arch_SB]> Has everyone read through the ARRAY[x] proposal, so I can assume that as common knowledge
[08:43] <@[Content]Andrew> Yes
[08:43] <@Zaister> yes
[08:44] <Tom[Arch_SB]> ok, if folks have questions, they can speak up
[08:45] <Tom[Arch_SB]> So backing up to the broad conversion for a moment
[08:45] <Tom[Arch_SB]> This is actually going to encompass both things we traditionally thought of as formula items as well as things the formula system can now do
[08:46] <Tom[Arch_SB]> Think REGION on a PC as something we can now process in a formula system rather than with custom tokens (This one has some really nasty side effects though, so will likely be in that last bucket I talked about in the BoD meeting)
[08:46] == PCGenGuest [92c68a43@gateway/web/freenode/ip.146.198.138.67] has joined #pcgen
[08:47] <Tom[Arch_SB]> Some of those will have dependencies (or you will discover dependencies) as we convert more traditional items
[08:47] <Tom[Arch_SB]> I want to focus on a few things so folks understand what it will take to convert things
[08:47] <Tom[Arch_SB]> First, let's discuss the terms
[08:48] <Tom[Arch_SB]> There are various items where the inputs flow to a term. Terms are the built-in variables of the old formula system
[08:48] <Tom[Arch_SB]> This creates a bit of a situation in that we want to keep the two systems separate, but I also would like to not carry around all of the old info and all of the new info at the same time
[08:48] <Tom[Arch_SB]> So my current plan is to have those terms "break" when the new code control is enabled
[08:49] <Tom[Arch_SB]> when "LEGS:" is enabled as a code control, for example, the "LEGS" term would break
[08:49] <Tom[Arch_SB]> this means any formula that uses that in the old system would also break
[08:49] <Tom[Arch_SB]> obviously the data team would have the option of building an "old style" variable for conversion
[08:49] <Tom[Arch_SB]> (as a bridge of sorts)
[08:50] <Tom[Arch_SB]> this will depend on how invasive the term is and how complicated the calculation of it is
[08:50] <Tom[Arch_SB]> Note that we *cannot* detect these at LST load
[08:50] <Tom[Arch_SB]> or we don't - and if we did something it would be partially successful - which is why we haven't done it in the past
[08:51] <Tom[Arch_SB]> So this means there will be file searching during conversion to ensure the data team catches things that will be a problem in conversoin
[08:51] <Tom[Arch_SB]> any concerns there?
[08:51] <Distant_Scholar> ...
[08:51] <@Zaister> SO, IF IT BREAKS, BUT IS NOT RECOGNIZED AT LOAD, HOW EXACTLY DOES IT BREAK?
[08:51] <@Zaister> oops, excuse the cpas
[08:51] <Tom[Arch_SB]> message at runtime
[08:52] <Tom[Arch_SB]> when a formula tries to use it
[08:52] <@Zaister> I see
[08:52] <@[Content]Andrew> Yeah, enabling the codecontrol is very thorough.
[08:52] <Tom[Arch_SB]> this limitation is one of the reasons we want to get away from the old formula system. We want to catch at LST load...
[08:52] <@[Content]Andrew> It caught the feat that wasn't loaded.
[08:52] <@Zaister> makes sense
[08:52] <Tom[Arch_SB]> just that transition is hard, which is why it took so long to get here
[08:53] <Distant_Scholar> I fell like I'm not quite understanding some of the terms being used. What is "a code control"?
[08:53] <Tom[Arch_SB]> ah, good question
[08:54] <Tom[Arch_SB]> Each Game Mode now has a new file, it's called "codeControl.lst"
[08:54] <Tom[Arch_SB]> in it are "Code Control" tokens
[08:54] <Tom[Arch_SB]> it basically turns on and off certain code in PCGen
[08:54] <Tom[Arch_SB]> So when we have two ways of doing things (the old system and the new formula system) we can choose which is used
[08:54] <Tom[Arch_SB]> this is highly relevant for bridging things like the export tokens to the new system
[08:55] <Tom[Arch_SB]> what I'm trying to avoid is making folks transition all data and all output sheets at the same time
[08:55] <Tom[Arch_SB]> that's kind of a pain
[08:55] <@Zaister> isn't it per source, not per game mode?
[08:55] <Tom[Arch_SB]> so the code control for LEGS for example, would specify the new formula system variable holding Legs of a PC
[08:55] <Tom[Arch_SB]> (it's per game mode, so two sources in the same game mode can't try to use mix n match systems)
[08:56] <Tom[Arch_SB]> I tried per source and broke it very quickly
[08:56] <@Zaister> but sources are able to expand upon it, right?
[08:56] <Tom[Arch_SB]> no
[08:56] <@Zaister> ah i guess i'm confusing it with data control
[08:56] <Tom[Arch_SB]> sources can add new variables and things of that nature, but the code control itself is just game mode
[08:56] <@Zaister> where is that file located, then?
[08:56] <Tom[Arch_SB]> yes, data controls are possible by each source as are variables
[08:56] <Tom[Arch_SB]> the codeControl.lst file is in the game mode folder
[08:57] <@Zaister> ok
[08:57] <Tom[Arch_SB]> along side miscinfo et al
[08:57] <Tom[Arch_SB]> anyway, the LEGS output token would now make a decision
[08:57] <Tom[Arch_SB]> if no LEGS code control, use the old system (which depends on LEGS: tokens in LST files)
[08:57] <Tom[Arch_SB]> if there is a LEGS code control, grab the new variable name and output the value of that variable
[08:58] <Tom[Arch_SB]> that way, the output sheets can continue to use "LEGS" as the old style output token
[08:58] <Tom[Arch_SB]> and convert at their convenience to $pc.val.legs (or whatever the var is called)
[08:58] <Tom[Arch_SB]> make sense?
[08:58] <@Zaister> how would it look in LST?
[08:58] <Tom[Arch_SB]> meaning Legs?
[08:58] <@Zaister> yes
[08:59] <Tom[Arch_SB]> MODIFY:Legs|SET|2
[08:59] <@Zaister> ah
[08:59] <@Zaister> teh "Define" equivalent being the code control i take it
[08:59] <Tom[Arch_SB]> no
[08:59] <@Zaister> oh
[08:59] <Tom[Arch_SB]> the define equivalent is in the variable file
[09:00] <Tom[Arch_SB]> (which is doable by source)
[09:00] <@Zaister> ok
[09:00] <Tom[Arch_SB]> the code control is just a pointer for the code to say "which variable has this thing I need to know about"
[09:00] <Distant_Scholar> What does a line in the code control LST file look like?
[09:00] <Tom[Arch_SB]> LEGS:Legs would be an example
[09:00] <@[Content]Andrew> ALTHP:AltHp
[09:00] <@[Content]Andrew> FACE:Face
[09:01] <Tom[Arch_SB]> LEGS is the token (it's what the internal code thinks of as the control)
[09:01] <Tom[Arch_SB]> Legs is a variable and has to be a legal (in this case Global) variable defined in the variable file
[09:01] <Distant_Scholar> And if there's no "LEGS:Legs" variable, it uses the old "term"?
[09:01] <@Zaister> token as known by the output system
[09:01] <Distant_Scholar> I mistyped; I meant "LEGS:Legs" tag.
[09:01] <Tom[Arch_SB]> if no LEGS: is encountered, then it uses the old system
[09:02] <@Zaister> ok
[09:02] <Tom[Arch_SB]> so using LEGS: in the code control will have a number of effects:
[09:02] <Tom[Arch_SB]> (1) Race and Template LEGS: tokens will report an error at LST load - they are no longer valid if a formula is used to solve legs
[09:02] <Tom[Arch_SB]> (2) The LEGS term would break
[09:02] <Tom[Arch_SB]> (3) The LEGS output token would use the variable pointed to by the LEGS: code control
[09:02] <Tom[Arch_SB]> ...and PRELEGS ... well, let's come back to that :)
[09:03] <@Zaister> oh so it dows break at load
[09:03] <Tom[Arch_SB]> the old tokens will - that will help to ensure data is either converted or not converted
[09:03] <Tom[Arch_SB]> otherwise we risk half converted, which really can't work
[09:04] <@Zaister> good
[09:04] == AndrewAAM [~AndrewAAM@104-60-239-112.lightspeed.frsnca.sbcglobal.net] has joined #pcgen
[09:04] == mode/#pcgen [+o AndrewAAM] by ChanServ
[09:05] <Tom[Arch_SB]> okay, moving on
[09:06] <Tom[Arch_SB]> We are going to encounter some issues where we have some magic in the code from before
[09:06] <Tom[Arch_SB]> Race sizes are one example
[09:06] <Tom[Arch_SB]> right now, we can CHOOSE based on Race size
[09:06] <Tom[Arch_SB]> e.g. CHOOSE:RACE|BASESIZE=Small
[09:07] <Tom[Arch_SB]> Now, if we converted this to a formula, that produces a bit of a challenge, since CHOOSE doesn't work with formula values
[09:07] == [Content]Andrew [~AndrewAAM@104-60-239-112.lightspeed.frsnca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
[09:07] <Tom[Arch_SB]> Not to mention that we really want the size at the PC level eventually, not necessarily local to the race
[09:08] <Tom[Arch_SB]> we could do a FACT local to the race, and then push that into a global var, that being a bit annoying as well since things like this will likely happen a lot
[09:08] == AndrewAAM_ [~AndrewAAM@104-60-239-112.lightspeed.frsnca.sbcglobal.net] has joined #pcgen
[09:08] == PapaDRB [~Papa-DRB@pool-100-40-208-253.pghkny.fios.verizon.net] has quit [Quit: ~ Trillian Astra - www.trillian.im ~]
[09:08] <Tom[Arch_SB]> So one possibility is to provide for ... let me call it initialization for a moment. Not sure I have a great word to use
[09:09] <Tom[Arch_SB]> The basic point is we want a FACT (so we can CHOOSE based on it, if we make the fact SELECTABLE: )
[09:09] == Andrew_web [683cef70@gateway/web/freenode/ip.104.60.239.112] has joined #pcgen
[09:09] <Tom[Arch_SB]> but we also want that to flow automatically into the variable system
[09:09] <Tom[Arch_SB]> Something like: INITIALIZE:BaseSize|Small
[09:10] <Tom[Arch_SB]> That would be treated as equivalent to
[09:10] <Tom[Arch_SB]> FACT:BaseSize|Small
[09:10] <Tom[Arch_SB]> and MODIFY:BaseSize|SET|Small
[09:10] == AndrewAAM [~AndrewAAM@104-60-239-112.lightspeed.frsnca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
[09:10] <Tom[Arch_SB]> at the same time
[09:10] <Tom[Arch_SB]> this keeps the data a bit more dense
[09:11] <Tom[Arch_SB]> and allows the code to continue to just display facts in the UI rather than variables. If we want something displayed we initialize rather than set
[09:11] <Tom[Arch_SB]> thoughts?
[09:11] <AndrewAAM_> Sorry connection to IRC acting up today... so INITIALIZE is a pseudo Fact?
[09:12] <Distant_Scholar> ...
[09:12] <Tom[Arch_SB]> (oh, one thing, note the value would have to be compatible with FACT, meaning it can't be a variable, it has to be an actual, concrete, unchangeable obeject)
[09:12] <Tom[Arch_SB]> treated as both a FACT and a variable
[09:12] <@Zaister> looks good. I'd rather go with INIT, as it's shorter to type and just as clear
[09:12] <Tom[Arch_SB]> I'm not attached to the name of the token. INIT is fine
[09:12] <Distant_Scholar> Unless someone thinks it means "initiative". :-)
[09:12] <Tom[Arch_SB]> true, but that's a data team thing for you guys to discuss what is best
[09:13] <Distant_Scholar> I'm sure I'm misunderstanding something ...
[09:14] <Distant_Scholar> FACT:BaseSize|Small -- does that set up a FACT named BaseSize (attached to whatever object the tag is used in), and set its contents to "Small"?
[09:14] <Distant_Scholar> MODIFY:BaseSize|SET|Small -- I had thought this is for variables. Does it work on FACTs, also?
[09:15] <Tom[Arch_SB]> It doesn't work on Facts
[09:15] <Tom[Arch_SB]> in this case, there is a fact and a variable with the same name
[09:15] <Distant_Scholar> OK.
[09:15] <@Zaister> isn't that confusing?
[09:15] <AndrewAAM_> Does that imply it is mutable and can be changed by the MODIFY tag?
[09:16] <Tom[Arch_SB]> The FACT can't change
[09:16] <Tom[Arch_SB]> The variable can
[09:16] <Tom[Arch_SB]> So we can leave out the shortcut
[09:16] <Tom[Arch_SB]> that's why we're discussing it :)
[09:16] <@Zaister> Not sure if its a good idea to allow duplicate names here
[09:16] <Tom[Arch_SB]> fair enough
[09:16] <Tom[Arch_SB]> So in cases like Race Size
[09:16] <Tom[Arch_SB]> if you want to be able to use CHOOSE:RACE|RACESIZE=x
[09:16] <Tom[Arch_SB]> then you will need a RACESIZE fact
[09:17] <Tom[Arch_SB]> and then that fact would need to be drawn into the formula system in order to have it processed as the starting size of the PC
[09:17] <Tom[Arch_SB]> not a big deal, only one more token
[09:17] <Tom[Arch_SB]> just wanted to toss out the possibility
[09:17] <Distant_Scholar> I don't think it's a bad idea. I just wasn't immediately aware that there was both a fact and a variable invovled.
[09:18] <Tom[Arch_SB]> we can leave that for folks to stew on... but happy to address other questions so folks can really think it through
[09:18] <[Code]meister> with regards to the ARRAY[x] support, how is it different from just supporting a generic map type, like MAP[x]?
[09:19] <Tom[Arch_SB]> like HashMap?
[09:19] <Tom[Arch_SB]> I didn't want to go there
[09:19] <[Code]meister> pretty much
[09:19] <[Code]meister> too soon? :)
[09:20] <Tom[Arch_SB]> I'm not convinced that is necessary
[09:20] <Tom[Arch_SB]> Most of the cases where a Map would be useful are actually covered by DYNAMICSCOPE
[09:20] <Tom[Arch_SB]> with additional capabilities beyond what the Map would have
[09:21] <Tom[Arch_SB]> So let me back up a second on this
[09:21] <Tom[Arch_SB]> Map,for those following along at home, is a key->value pair
[09:21] <Tom[Arch_SB]> The key can be strings, value whatever
[09:21] == PCGenGuest [92c68a43@gateway/web/freenode/ip.146.198.138.67] has quit [Ping timeout: 252 seconds]
[09:22] <Tom[Arch_SB]> Let's assume we had a MAP data format, and the target was, say, an integer
[09:22] <Tom[Arch_SB]> let's call our Map, I don't know, how about VISION
[09:23] <Tom[Arch_SB]> now we have a bit of a challenge when we strike the output sheet.
[09:23] <Tom[Arch_SB]> We can ask for the keys http://freemarker.incubator.apache.org/docs/ref_builtins_hash.html
[09:23] <Tom[Arch_SB]> (Freemarker calls a map a hash - lots of different programming terms for the same thing)
[09:24] <Tom[Arch_SB]> but we have a problem - if we are going to have localized data, how do we know how to translate the key?
[09:24] <AndrewAAM_> Python it would be a dict
[09:24] <Tom[Arch_SB]> What is "Darkvision" in another language?
[09:24] <Tom[Arch_SB]> By carrying Vision in a dynamic scope, Darkvision is an object, which means once we get localized, we can have it translated like any other object
[09:25] <Tom[Arch_SB]> So part of "putting on the handcuffs" of not allowing map is to not let folks trap themselves in places that are hard to dig out later on
[09:25] <Tom[Arch_SB]> If we *really* find a case that is dysfunctional without it, we can work through if it's the best solution
[09:26] <Tom[Arch_SB]> but I'm not starting with trying to enable things just because
[09:26] <Tom[Arch_SB]> make sense?
[09:26] <[Code]meister> what if you used map as a way to track AC mod sources?
[09:28] == TiBook_ [~tibook_@rrcs-67-52-166-34.west.biz.rr.com] has joined #pcgen
[09:28] <Distant_Scholar> You mean like armor, shield, natural armor, dodge, dodge, deflection, dodge, and so on?
[09:28] <[Code]meister> yep
[09:28] <Tom[Arch_SB]> That's possible, but so are individual variables
[09:30] == Jagbear [63c6ac9f@gateway/web/freenode/ip.99.198.172.159] has joined #pcgen
[09:31] <Tom[Arch_SB]> ok, any other questions there? I think detailed working out of a use case there and what would really be a problem without it can be offline
[09:31] == AndrewAAM_ has changed nick to [Content]Andrew
[09:31] <@Zaister> not at this time from me
[09:31] <[Content]Andrew> No questions regarding that.
[09:32] <[Code]meister> none here
[09:32] <Tom[Arch_SB]> ok, I'm going to pause my topics for a second to ask if there are general questions on the conversion things folks have seen so far
[09:34] <[Content]Andrew> Just an observation - looks like Output sheets will be the last thing we actually convert at this point. Since the codeControl will convert it to the existing output token. Is that a safe assumption?
[09:34] <Tom[Arch_SB]> that's the goal
[09:34] <Tom[Arch_SB]> there may be some exceptions, but my notes to _Exp will make those very clear
[09:35] <Tom[Arch_SB]> one other comment on formulas
[09:35] <Tom[Arch_SB]> folks actually need to be somewhat careful in that in the old system, output tokens could be used in a formula
[09:36] <Tom[Arch_SB]> I can't really protect you from that easily, so if an output token is used in a formula
[09:36] <Tom[Arch_SB]> and the code control is used to change where that output token draws from
[09:36] <Tom[Arch_SB]> I make no guarantees as to PCGen behavior
[09:36] <Tom[Arch_SB]> the two formula systems don't mix and shouldn't be mixed if at all possible
[09:37] <[Content]Andrew> BONUS:VAR|Foo+var("OutputToken") yeah, I can see that going South.
[09:37] <Tom[Arch_SB]> it is definitely possible to make an infinite loop
[09:37] <Tom[Arch_SB]> definitely possible
[09:37] <Tom[Arch_SB]> so please, please, when you are doing conversions search for both terms and output token usage in the data
[09:38] <Tom[Arch_SB]> this is especially true if you have any trailing PRExxx on any token that may depend on a variable
[09:38] <Tom[Arch_SB]> (and old varibale)
[09:38] <Tom[Arch_SB]> *an
[09:39] <Tom[Arch_SB]> I did the code control to split the difficulty, but there are "corner cases" (which in some ways are kind of common) that the data team will need to manage
[09:39] <[Content]Andrew> Search for var(" and that should turn up those old use cases.
[09:40] <Tom[Arch_SB]> A few other thoughts on the recent discussions on _exp
[09:40] <Tom[Arch_SB]> If you run into something where you need local vars in a new place (such as SIZE or whatever) - we call this a scope - just open a NEWTAG asking for the scope. You can see Andrew did that earlier this week for some items
[09:40] == Andraxx [4e46b21e@gateway/web/freenode/ip.78.70.178.30] has joined #pcgen
[09:41] <Andraxx> too late ?
[09:41] <[Content]Andrew> Still going.
[09:41] <Andraxx> awesome !
[09:42] <Tom[Arch_SB]> when converting things in the output sheets, be aware it may be more complex than the original output token
[09:42] <Tom[Arch_SB]> the original ones usually had code doing a lot of formatting and such
[09:42] <Tom[Arch_SB]> Using FACE as an example
[09:42] <Tom[Arch_SB]> it used to put in dimensions, whatever else
[09:42] <Tom[Arch_SB]> "ft."
[09:42] <Tom[Arch_SB]> for those of us in one country anyway
[09:43] <Tom[Arch_SB]> That will now be the responsibility of the OS
[09:43] <Tom[Arch_SB]> so once we get to that point, it's likely that there will be a few macros that are useful to write - like wrapping in localized dimensions
[09:43] == Jagbear [63c6ac9f@gateway/web/freenode/ip.99.198.172.159] has quit [Ping timeout: 252 seconds]
[09:43] <Tom[Arch_SB]> So as folks look at output sheets, think about and speak up about those "utilities"
[09:44] <Tom[Arch_SB]> Okay, now let's talk about the overall conversion process
[09:44] == AndrewAAM [~AndrewAAM@104-60-239-112.lightspeed.frsnca.sbcglobal.net] has joined #pcgen
[09:44] == mode/#pcgen [+o AndrewAAM] by ChanServ
[09:44] == Andrew_web [683cef70@gateway/web/freenode/ip.104.60.239.112] has quit [Ping timeout: 252 seconds]
[09:44] <@AndrewAAM> Sorry, router reset itself....
[09:45] <@AndrewAAM> I was going to ask :: Sizeadjustment is a new scope then?
[09:45] <Tom[Arch_SB]> will be at some point
[09:45] <Tom[Arch_SB]> it has some... dynamics
[09:45] <Tom[Arch_SB]> so it will probably take 2 or 3 code controls to be able to even move it from Game Mode to PCC
[09:45] == [Content]Andrew [~AndrewAAM@104-60-239-112.lightspeed.frsnca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
[09:45] <Tom[Arch_SB]> but yes, we will get it to PCC rather than gamemode
[09:45] <Tom[Arch_SB]> and then give it a scope
[09:46] <Tom[Arch_SB]> over this process, we will likely gut much of what is in the game mode today
[09:46] <Tom[Arch_SB]> Anyway, Andrew has started a branch in his repo exploring some items in the new formula system, and folks may have seen that on _exp
[09:47] <Tom[Arch_SB]> I asked about unwinding some of the objects, and that will be one of the keys to getting this to meet what I think are the performance expectations
[09:47] <Tom[Arch_SB]> it will be especially important to start to get rid of trailing PRExxx when possible
[09:47] <Tom[Arch_SB]> those are especially nasty performance wise, and I'm really pushing to see if we can eliminate the concept altogether
[09:48] <[Code]meister> what is going to be the replacement for PRExxx?
[09:48] <Tom[Arch_SB]> Two answers
[09:48] <Tom[Arch_SB]> Well, three actually
[09:48] <Tom[Arch_SB]> For trailing PRExxx, I expect to not replace the concept
[09:49] <Tom[Arch_SB]> Many of those can be handled in a different fashion, once the formula system starts to consume more of the responsibilties in the system
[09:49] <Tom[Arch_SB]> I can't really generalize a solution there, since they exist for a few different reasons
[09:50] <Tom[Arch_SB]> But those that exists to do a "one shot" (think Pathfinder Archetypes) have one solution
[09:50] <Tom[Arch_SB]> Those that are doing list management another
[09:50] <Tom[Arch_SB]> That will probably be the topic of our next data meeting :D
[09:50] <Tom[Arch_SB]> As far as standalone PRExxx, we need to address what we have called the "PRE/REQ" problem
[09:51] <Tom[Arch_SB]> Some things are "prerequisites" in the sense of a "can only do this if you are in this state right now"
[09:51] <Tom[Arch_SB]> others are "requirements" as in "you lose this if you ever don't meet this state"
[09:51] <Tom[Arch_SB]> So the goal will be to have a set of tokens that addresses those concepts as stand alones
[09:51] <Tom[Arch_SB]> equivalent to using a stand along PRExxx today
[09:52] <Tom[Arch_SB]> Since we have a very capable formula system, we should be able to write it as a formula that returns a Boolean
[09:52] <Tom[Arch_SB]> so basically it could be as easy as:
[09:52] <Tom[Arch_SB]> IF:x and WHEN:x
[09:52] <Tom[Arch_SB]> as tokens
[09:52] <Tom[Arch_SB]> where IF is the "prerequisite" and WHEN is the "requirement"
[09:53] <Tom[Arch_SB]> again, open to whatever names, really about the ideas here
[09:53] <Tom[Arch_SB]> this will start to interact with the formula conversion before we get done, so it was one of my topics to introduce today
[09:54] <Tom[Arch_SB]> since it's a boolean and the full power of the formula system is behind it, it can pretty much do whatever logic is needed....
[09:54] <Tom[Arch_SB]> provided the right formula functions are available.... again, that's a bit of a "speak up when you need it" thing
[09:55] == Andraxx [4e46b21e@gateway/web/freenode/ip.78.70.178.30] has quit [Quit: Page closed]
[09:55] <Tom[Arch_SB]> thoughts?
[09:55] == TiBook_ [~tibook_@rrcs-67-52-166-34.west.biz.rr.com] has quit [Remote host closed the connection]
[09:56] <Tom[Arch_SB]> looks like people hit the sugar low after breakfast :D
[09:56] <@AndrewAAM> Sounds good. A lot of information to take into account.
[09:56] <@Zaister> indeed
[09:56] <@AndrewAAM> Multi-tasking. :P
[09:56] <[Code]meister> I think I'm good for now
[09:57] <Tom[Arch_SB]> I think the last thing I want to cover is really trying to isolate the data changes somehow
[09:57] <Tom[Arch_SB]> I would really like to be able to review what the changes are in small buckets to ensure we are doing them effectively
[09:58] <Tom[Arch_SB]> I think this is especially important at the start
[09:58] <Tom[Arch_SB]> So I'd like to talk through how we get that, since right now we have a lot of things mixed into one branch
[09:59] <Tom[Arch_SB]> Andrew? thoughts?
[10:00] <@AndrewAAM> I agree. My branch was to get the concepts tested. But I think branching off separate branches for each bucket is a good approach.
[10:00] <@AndrewAAM> The hard part is deciding what goes into said "bucket"
[10:01] <@AndrewAAM> Ideally I want to get the low hanging fruit converted first, but that can be sprawled through a lot of sources in a single game system
[10:01] <Tom[Arch_SB]> I think the starting point is "one game mode, one code control"
[10:02] <Tom[Arch_SB]> that will break occasionally, but it's the smallest possible change
[10:02] == TiBook_ [~tibook_@rrcs-67-52-166-34.west.biz.rr.com] has joined #pcgen
[10:02] <Tom[Arch_SB]> and yes, this stuff rapidly cuts across different sources
[10:04] <@AndrewAAM> That said, I think the easiest changes are simple DESC w/ vars that are self contained. i.e. no reliance of a Stat Mod
[10:04] <Tom[Arch_SB]> well, yes, this will interact with INFO/INFOVARS as well
[10:04] <@AndrewAAM> Those are converted to an INFO/INFOVAR.
[10:04] <Tom[Arch_SB]> lots of parallel things will happen
[10:05] <Tom[Arch_SB]> the reason this has taken so long is that these things are all interrelated
[10:06] <@AndrewAAM> Weapons should be easy, but will require some surgery to the OS, and of course those functions mentioned earlier. :)
[10:06] <Tom[Arch_SB]> heh
[10:06] <Tom[Arch_SB]> the output tokens are huge there
[10:06] <Tom[Arch_SB]> so lots of work for me :)
[10:07] <@AndrewAAM> Yeah, trade-offs... :) To cover the majority of the class features, we will need access to the Stat Mods
[10:08] <@AndrewAAM> that should cover 95% of the features
[10:08] <@AndrewAAM> The remainder of feats and abilities will need access to corner case items such as class levels, total levels, and replacement to those old output tokens.
[10:09] <@AndrewAAM> Stats scope and Saves scope should be "easy" for the data team.
[10:09] <@AndrewAAM> But everything is tied to stats
[10:10] <Tom[Arch_SB]> ok, I'll look at the stat thing first then
[10:10] <Tom[Arch_SB]> get that moved over
[10:10] <Tom[Arch_SB]> and then have to link to the UI as well
[10:10] <Tom[Arch_SB]> So let's talk through that for a second
[10:10] <Tom[Arch_SB]> ConScore you pointed out as ALTHP need
[10:11] <@AndrewAAM> correct
[10:11] <Tom[Arch_SB]> That implies the need for a STAT scope
[10:11] <@AndrewAAM> and Total Levels
[10:11] <Tom[Arch_SB]> and a local variable .. let's call it "score"
[10:11] <@Zaister> yes it is important to be able to access stat scroes and modifiers
[10:11] <Tom[Arch_SB]> so something like localVar("STAT","Constitution",score)
[10:12] <@Zaister> lots ab abilities base bonuses or times/day of those
[10:12] <Tom[Arch_SB]> would be how it would be accessed, and if you wanted to put that in a global var called ConScore, that's up to you
[10:12] <Tom[Arch_SB]> here's the other "rub"
[10:12] <Tom[Arch_SB]> the stat score is actually set in the UI by the user
[10:12] <@AndrewAAM> Yeah
[10:12] <Tom[Arch_SB]> So within the Stat, when setting "score" we need that info
[10:13] <Tom[Arch_SB]> This is the current thought - subject to polishing
[10:13] <Tom[Arch_SB]> assume a new function "ui"
[10:13] <Tom[Arch_SB]> ui("x")
[10:13] <Tom[Arch_SB]> "x" will be a "magical term" we will have to document, that will vary for each item that can be pulled from the UI
[10:14] == TiBook_ [~tibook_@rrcs-67-52-166-34.west.biz.rr.com] has quit [Remote host closed the connection]
[10:14] <@Zaister> not sure that makes sense, in the end, everything comes form the ui if you will
[10:14] <Tom[Arch_SB]> so in the STAT PCC file (to be created as an option, per earlier discussion)
[10:14] <Tom[Arch_SB]> well, but this has state in the UI
[10:14] <Tom[Arch_SB]> others don't have state
[10:14] <Distant_Scholar> "state in the UI"?
[10:14] <Tom[Arch_SB]> adding an ability doesn't have state, it fills a pool
[10:15] <Tom[Arch_SB]> So if my PC has a strength of "15"
[10:15] <Tom[Arch_SB]> what knows that info is the UI
[10:15] <Tom[Arch_SB]> not the data
[10:15] <Tom[Arch_SB]> if I change the 15, the PC changes,
[10:15] <@Zaister> would you also call it a ui stat what feats are selected for example?
[10:15] <Tom[Arch_SB]> so the UI is the "source" of that info
[10:15] <Tom[Arch_SB]> no, the core maintains the list of feats and the UI displays it
[10:15] <Tom[Arch_SB]> it's output
[10:16] <@Zaister> but the ui decides which feats the charater actually has
[10:16] <Tom[Arch_SB]> the data defines an available pool
[10:16] <Tom[Arch_SB]> the user then places feats into that pool
[10:16] <@Zaister> what about batch processing?
[10:16] <Tom[Arch_SB]> the pools came from data
[10:16] <Tom[Arch_SB]> a kit can also place into the pool, as can the PCG today
[10:17] <Tom[Arch_SB]> all UI independent
[10:17] <@Zaister> ok
[10:17] <Tom[Arch_SB]> here is the issue
[10:18] <@Zaister> still feels weird to have the UI appear there
[10:18] <Tom[Arch_SB]> and I guess this exists elsewhere in things like feats as well -
[10:18] <Tom[Arch_SB]> but in a very different way -
[10:18] <Tom[Arch_SB]> Let's look at "score" as a local variable
[10:18] <Tom[Arch_SB]> let's assume some data can mess with that scope
[10:18] <Tom[Arch_SB]> *score
[10:18] <Tom[Arch_SB]> bonuses perhaps
[10:18] <Tom[Arch_SB]> maybe undead sets something to 10
[10:19] <Tom[Arch_SB]> at some point, we need to have an explicit or implied "where does the user control in the UI" fall into the PRIORITY scheme
[10:19] <Tom[Arch_SB]> I would rather it be explicit and in control of the data team
[10:20] <@AndrewAAM> Cause of DEFINESTAT and limits by publisher. Agreed.
[10:20] <@Zaister> I'm not deeing why this distinction is importatnt
[10:20] <@Zaister> *seeing
[10:20] <Tom[Arch_SB]> which distinction?
[10:21] <[Code]meister> I tend to think of the UI as for choice resolution. It is up to the data to decide what variables are choosable in the UI.
[10:21] <@Zaister> that something comes from the UI
[10:22] <Tom[Arch_SB]> ok, think of it as "able to pull from the UI" rather than "comes from the UI"
[10:22] <@Zaister> yes but what is this imporatnt forß
[10:22] <@Zaister> ?
[10:22] <Tom[Arch_SB]> ability scores
[10:22] <Tom[Arch_SB]> today, the system is "magical"
[10:22] <Tom[Arch_SB]> it magically creates variables called "???" and "???SCORE" for each stat based on the stat's abbreviations
[10:23] <Tom[Arch_SB]> I would rather data be in control of all variables
[10:23] <@Zaister> sure that makes sense
[10:23] <Tom[Arch_SB]> so we need to reproduce the behavior of those magical items
[10:23] <@Zaister> but it does not need to be "UI"
[10:23] <Tom[Arch_SB]> the function name?
[10:23] <Tom[Arch_SB]> sure, it can be changed
[10:23] <Tom[Arch_SB]> input("STR")
[10:23] <Tom[Arch_SB]> or whatever
[10:23] <Tom[Arch_SB]> userinput("STR")
[10:23] <@Zaister> values can come from a pcg file without the ui in batch run for example
[10:24] <Tom[Arch_SB]> fair enouigh
[10:24] <Tom[Arch_SB]> *enough
[10:24] <Tom[Arch_SB]> or a batch file that has "character creation commands" (not that it exists today, but would be possible someday)
[10:25] <Tom[Arch_SB]> the major point is that the stat score specifically has to draw on that user input
[10:25] <Tom[Arch_SB]> whatever we call it
[10:25] <@Zaister> input makes more sense, or base or something like that
[10:25] <Tom[Arch_SB]> so we will need to resolve what that function is called to be able to complete being able to draw upon that info in the new system
[10:25] <@Zaister> (sorry noebook was out of power)
[10:26] <Tom[Arch_SB]> I'm good with input
[10:26] <Tom[Arch_SB]> I think it's better than ui
[10:26] <@AndrewAAM> Agreed with input being the function name
[10:26] <@Zaister> goot thenk
[10:26] <@Zaister> -.k
[10:26] <[Code]meister> I agree, input sounds better
[10:26] <Tom[Arch_SB]> ok, so expect an input("x") function to come across _exp
[10:27] <Tom[Arch_SB]> Same for a SIZE PCC token
[10:27] <@Zaister> stat modifiers are used very heavily in data, so it should not be too complex to access
[10:28] <@AndrewAAM> For the input, I think I'll give that a quick pass approval since we need that function
[10:28] <Tom[Arch_SB]> I expect the data team to create a global var "STR" and assign it "localVar("STAT","Strength",score)
[10:28] <@AndrewAAM> Just post what it does on _exp, but unless something drastic changes, I think the concept is acceptable for what we need.
[10:29] <Tom[Arch_SB]> and have the local var set from input("STR") or some such
[10:29] <@Zaister> ok, that sounds good
[10:29] <Tom[Arch_SB]> well, I just did STRSCORE
[10:29] <Tom[Arch_SB]> since STR is really the modifier not the score, but you get the idea
[10:29] <@Zaister> yes
[10:30] * AndrewAAM nods
[10:30] <Tom[Arch_SB]> everyone's head hurt?
[10:30] <Tom[Arch_SB]> :)
[10:30] <@AndrewAAM> No, this is easy. And I'm awake. :)
[10:30] <Distant_Scholar> Not mine. But I won't full understand all the implications until I sit down and use it.
[10:31] <@AndrewAAM> Quick question
[10:31] <@AndrewAAM> input("Stat Name in full or a Key")?
[10:31] <Tom[Arch_SB]> neither
[10:32] <Tom[Arch_SB]> Input("SomeMagicalValueDocumentedSomewhere")
[10:32] <Tom[Arch_SB]> we would likely make the magical value line up with the key/abbreviation for simplicity
[10:32] <Tom[Arch_SB]> but it will be unique to the "input channel"
[10:32] <Tom[Arch_SB]> not based on an object
[10:32] <Tom[Arch_SB]> because one object could have more than one input channel
[10:33] <Tom[Arch_SB]> so we can't use keys or whatever. Might as well give the input channels names
[10:33] <Tom[Arch_SB]> So probably "StrScore"
[10:33] <[Code]meister> so would input replace some choose tokens?
[10:33] <Tom[Arch_SB]> no
[10:33] <Tom[Arch_SB]> ugh, CHOOSE
[10:33] <Tom[Arch_SB]> we should probably talk about that too
[10:33] <Tom[Arch_SB]> too m any moving pieces
[10:34] <@AndrewAAM> Heh
[10:34] <Tom[Arch_SB]> So one thing folks will encounter is needing to pull from CHOOSE
[10:34] <Tom[Arch_SB]> bonuses are controlled this way in various forms
[10:34] <@AndrewAAM> and TEMPVALUE
[10:35] <Tom[Arch_SB]> if it's being drawn upon as a value, then it should be fairly easy
[10:35] <Tom[Arch_SB]> MODIFY:Foo|SET|chooseValue()
[10:36] <Tom[Arch_SB]> or some such
[10:36] <Tom[Arch_SB]> trying to find my notes on when it's the target
[10:38] <Tom[Arch_SB]> can't find it quiclky. so basically, let's continue to use stat as an example
[10:38] <Tom[Arch_SB]> we'll cover the theme of what will happen
[10:38] <Tom[Arch_SB]> MODIFYOTHER:STAT|chooseValue()|Score|ADD|1
[10:38] <Tom[Arch_SB]> it wouldn't literally be chooseValue() there
[10:39] <Tom[Arch_SB]> but that expresses the theme
[10:39] <Tom[Arch_SB]> this would require CHOOSE:STAT
[10:39] <Tom[Arch_SB]> note that the type safety that we introduced back in 5.14 or so starts to *really* come home to roost
[10:39] <Tom[Arch_SB]> if it's not CHOOSE:STAT it breaks
[10:39] <Tom[Arch_SB]> so CHOOSE:STRING, we need to be thinking about whether they need to be more specifically identified than a STRING
[10:40] <Tom[Arch_SB]> because BONUS was tolerant. MODIFY won't be
[10:40] <Tom[Arch_SB]> make sense in general?
[10:40] <Distant_Scholar> sure
[10:41] <@AndrewAAM> So the ModifyOther we can choose scope and what value to impact.
[10:41] <Tom[Arch_SB]> the scope is hardcoded, must match what the CHOOSE selects
[10:41] <Tom[Arch_SB]> (not that the names are literally the same - they won't always be I don't think - but the object types have to be compatible)
[10:42] <Tom[Arch_SB]> the target will be able to vary based on the CHOOSE
[10:42] <@AndrewAAM> Tom - Clarification question:
[10:43] <Tom[Arch_SB]> 15 minute warning for me
[10:43] <@AndrewAAM> How will I be able to determine whether the Stat Choice grants a Score vs. Mod?
[10:43] <Tom[Arch_SB]> I dont' understand the question
[10:43] <@AndrewAAM> Most bonuses use the Stat Modifier (STR vs. STRSCORE)
[10:44] <Tom[Arch_SB]> ok
[10:44] <@AndrewAAM> But in some rare cases we might need Score
[10:44] <Tom[Arch_SB]> ok
[10:44] <Tom[Arch_SB]> So I suspect a STAT will have two local variables, Score and Mod
[10:44] <@AndrewAAM> STRING covered those rare cases if I recall correctly.
[10:45] <Tom[Arch_SB]> You'll have to bring me a specific example
[10:45] <Distant_Scholar> I think I'm confused by some terminology; in what way would STR and STRSCORE be "local"?
[10:45] <Tom[Arch_SB]> I'm still not sure of your concern
[10:45] <Tom[Arch_SB]> Most likely we get this:
[10:45] <Tom[Arch_SB]> All STAT have two local vars: Score, Mod
[10:46] <Tom[Arch_SB]> We set a "global modifier" to calculate the Mod from the Score, since that is standard for 35e, PF, et al
[10:46] <Tom[Arch_SB]> We create a global var called STR and set it to the local Var "Score" on "Strength"
[10:46] <Tom[Arch_SB]> doh
[10:46] <Tom[Arch_SB]> no
[10:46] <Tom[Arch_SB]> that's the global var STRSCORE
[10:46] <@AndrewAAM> I'd have to dig for it, sorry. STR = Mod
[10:46] <Tom[Arch_SB]> We create a global var called STR and set it to the local Var "Mod" on "Strength"
[10:47] <Tom[Arch_SB]> so we have 2 local vars and 2 global vars
[10:47] <Tom[Arch_SB]> the global ones are totally for convenience of not typing the localVar(...) function all the time
[10:47] <Tom[Arch_SB]> make sense?
[10:47] <@AndrewAAM> Yes
[10:48] <Tom[Arch_SB]> DS?
[10:48] <Tom[Arch_SB]> (BTW, I'm still not sure of your concern was addressed to Andrew not Distant_Scholar)
[10:48] <Distant_Scholar> So, rather than having "STR" and "STRSCORE" variables, x6, there are six "stats", and each stat has a local "Mod" and "Score" variable.
[10:49] <Tom[Arch_SB]> well I think it ends up as both
[10:49] <@AndrewAAM> We end up with both for data team ease
[10:49] <Tom[Arch_SB]> today we have two magical "terms" called STR and STRSCORE (plus for the other stats)
[10:49] <Tom[Arch_SB]> to literally hold that info going forward we want two local vars Score and Mod (on each stat)
[10:50] <Tom[Arch_SB]> then for convenience we probably create two global vars called STR and STRSCORE
[10:50] <Tom[Arch_SB]> so the formulas probably don't have to change as much in the end, only get pointed to the new formula system
[10:50] <Tom[Arch_SB]> may be helpful to see it once we can get it in sample data
[10:51] <@AndrewAAM> Tom - My concern is what will CHOOSE:STAT send to MODIFY?
[10:51] <Tom[Arch_SB]> a Stat
[10:51] <Tom[Arch_SB]> the object itself
[10:51] <Tom[Arch_SB]> well, to MODIFY, nothing
[10:51] <Tom[Arch_SB]> to MODIFYOTHER, you can transfer the Stat itself
[10:51] <Tom[Arch_SB]> just to clarify
[10:52] <Distant_Scholar> How 'hardcoded' is the two value system? D&D older than 3rd ed. had 0 or more modifiers per stat. M&M just has the modifier.
[10:52] <Tom[Arch_SB]> (I did use MODIFY incorrectly earlier meant MODIFYOTHER)
[10:52] <Tom[Arch_SB]> today it's hardcoded
[10:52] <Tom[Arch_SB]> the reason to put it in the data is to get rid of that and allow the data to define what is necessary for any given game system
[10:52] <Tom[Arch_SB]> if you need 30 local variables on a stat, go for it
[10:53] <@AndrewAAM> Okay, so I want to Grant a bonus to my Kung Fu skill with a stat bonus, but my feat allows a choice of which stat I use, how would that look in the new system?
[10:53] <@AndrewAAM> Old system was CHOOSE:STAT|ALL <> BONUS:SKILL|Kung Fu|%CHOICE - which gave the Mod version of the Stat
[10:53] <Tom[Arch_SB]> CHOOSE:PCSTAT|ALL
[10:53] <Tom[Arch_SB]> actually
[10:54] <@Zaister> wouldn't we usually set up an ability pool for that with six different abilties?
[10:54] <Tom[Arch_SB]> the CHOOSE doesn't change
[10:54] <@AndrewAAM> Ah, choosevalue("Mod")?
[10:54] <@AndrewAAM> or something like that to control what we are granting?
[10:55] <Tom[Arch_SB]> BONUS changes to MODIFYOTHER:SKILL|Kung Fu|Score|ADD|localVar("STAT",chooseValue(),Mod)
[10:55] <Tom[Arch_SB]> or something very close to that
[10:56] <@AndrewAAM> Okay, that's what I needed to see. Thanks.
[10:56] <Tom[Arch_SB]> yw
[10:56] <Tom[Arch_SB]> any other questions?
[10:56] <[Code]meister> none here
[10:56] <Tom[Arch_SB]> I need to duck out in about 5 min
[10:56] <@AndrewAAM> Link to the inforvars format? There was like three different methods to have data decide on a standard
[10:57] <@AndrewAAM> and I can't find where that discussion happened.
[10:57] <@AndrewAAM> INFO:Something {x, number, integer}. was one method.
[10:57] <Tom[Arch_SB]> https://groups.yahoo.com/neo/groups/pcgen_experimental/conversations/messages/19346
[10:57] <Tom[Arch_SB]> is the thread
[10:58] <Tom[Arch_SB]> I'd have to pull out the final format, the NEWTAG entry is wrong I think
[10:58] <Tom[Arch_SB]> oh THOSE
[10:58] <Tom[Arch_SB]> those are Java based controls
[10:58] <Tom[Arch_SB]> read this
[10:58] <Tom[Arch_SB]> https://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html
[10:58] <@AndrewAAM> Okay, thanks, good discussion.
[10:58] <Tom[Arch_SB]> thanks all
[10:59] <@AndrewAAM> That's a wrap. Thanks for coming everyone.

Retrieved from "http://159.203.101.162/w/index.php?title=Content_Meeting_2016-02-27&oldid=3972"