Meeting 2014 07 11

Deep Dive Meeting

Participants:

• Chair - Andrew
• Arch - Tom
• Code - James
• Docs - Eric

Agenda:

1. Continue Compatibility Discussion
2. Discuss impact of Documentation

Summary: Continued discussion of the Incompatibility problem with JEP. Discussed that conversion would be manual multiple sweeps, one sweep for each token as it was replaced with the MODIFY: system. The JEP and New Parser would run parallel but NEVER interact with each other. SPROP would convert to PROP and DESC would convert to DESCR. Then topic switched to how to handle the deprecations and impact on the Documents. Then it was discussed how the new Formula Parser would interact with the OS.

Raw Log:

• [17:03] <@[Chair]Andrew> I believe this is all who were planning on being here.
• [17:04] <Tom[Arch_SB]> Hi Eric & James
• [17:05] <Tom[Arch_SB]> I think we're picking up on the formula system, should I just start?
• [17:05] <@[Chair]Andrew> *Bangs gavel* Welcome everyone. Our meeting is now in session. This is a Deep Dive discussion with Tom driving the topic at large. :)
• [17:05] <@[Chair]Andrew> Tom, floor is yours.
• [17:06] <Tom[Arch_SB]> thanks Andrew
• [17:06] <Tom[Arch_SB]> So this is continuing the discussion from - I guess 5 weeks ago now - which was on Formulas and Compatibility
• [17:07] <Tom[Arch_SB]> After working through some additional examples and doing some additional investigation, I think I have a recommendation on how to go forward
• [17:08] <Tom[Arch_SB]> The challenge is in doing a transition where we get the benefit of the new system, while not having either ( a ) a major cut-over [high risk in data and code] or ( b ) have to get the two systems to interact, such that it becomes a very high-cost transition in code
• [17:09] <Tom[Arch_SB]> I think what I would recommend is having the two systems run fully in parallel. Let me explain what that would mean
• [17:09] <Tom[Arch_SB]> We have a set of tokens, things like DEFINE, BONUS, and some others, that use the existing formula system. Those would each "stay" with the existing (JEP) formula system
• [17:10] <Tom[Arch_SB]> New tokens, specifically starting with MODIFY (but we will need some others - more on this in a moment) would use the new system
• [17:10] <Tom[Arch_SB]> This way, we can take one "small" step at a time, converting, for example, Critical Range on Equipment, relatively independent of other changes
• [17:11] <Tom[Arch_SB]> The relatively is that some variables may interact and have to be moved together
• [17:11] <Tom[Arch_SB]> This does introduce a few challenges
• [17:11] <Tom[Arch_SB]> First is that the two systems will both exist for a time, and we will have to keep folks aware of which tokens are using which system.
• [17:12] <Tom[Arch_SB]> This shouldn't be too bad as few tokens should use the new system
• [17:12] <Tom[Arch_SB]> (They are more general and more powerful, thus less are needed)
• [17:12] <Tom[Arch_SB]> It does create some awkwardness in some existing tokens that can refer to formulas, such as DESC
• [17:13] <Tom[Arch_SB]> I'm afraid we have to replace those (and have "duplicates" as well) since they will refer to variables in both old and new
• [17:13] <Tom[Arch_SB]> so there isn't really a way to do a "cutover" of that token independent of the other systems
• [17:14] <Tom[Arch_SB]> The advantage here is that this can keep us in the Trunk, since they can coexist
• [17:14] <James[Code_SB]> Hmm, that would affect any token taking a formula?
• [17:14] <Tom[Arch_SB]> So we don't have a major branch with all of the risks and associated perceptions
• [17:14] <Tom[Arch_SB]> @James, yes, to some degree it HAS to
• [17:14] <James[Code_SB]> That could be quite a few, including game mode tokens
• [17:15] <Tom[Arch_SB]> otherwise we're back into the "which formula system is it" question that causes us issues today
• [17:15] <James[Code_SB]> Given that we need to call a moratorium on adding formula support to tags
• [17:15] <Tom[Arch_SB]> I'd say there are 3 categories of tokens
• [17:15] <Tom[Arch_SB]> that use a formula
• [17:15] <Tom[Arch_SB]> well, 4
• [17:15] <Tom[Arch_SB]> one category is those directly related to formulas, let's put DEFINE and BONUS in that bucket
• [17:16] <Tom[Arch_SB]> another is LST tokens that are themselves just a formula, there are various examples, though I can't name one off the top of my head
• [17:17] <Tom[Arch_SB]> another is those that can leverage a formula, DESC and SPROP I think are two examples
• [17:17] <Tom[Arch_SB]> another is the game mode tokens
• [17:17] <Tom[Arch_SB]> I'd expect categories 1 and 4 to both be more deprecation and replace by MODIFY than replace by a near-clone
• [17:17] <@[Chair]Andrew> Q: You mentioned DESC: which formula system would that use? JEP, New Parser or both?
• [17:17] <Tom[Arch_SB]> sorry, categories 2 and 4. Category 1 naturally goes away
• [17:17] <Tom[Arch_SB]> DESC has to say with the existing system
• [17:18] <Tom[Arch_SB]> otherwise data goes boom
• [17:18] <@[Chair]Andrew> And how about SPROP?
• [17:18] <Tom[Arch_SB]> so we would need a DESCR perhaps that is the new system
• [17:18] <Tom[Arch_SB]> anything that exists today has to stay JEP for that reason
• [17:18] <@[Chair]Andrew> *nods* Okay, so massive conversion when those switch over then.
• [17:18] <Tom[Arch_SB]> No, I think that's the point
• [17:18] <Tom[Arch_SB]> it's not a massive conversion related to that token
• [17:19] <Tom[Arch_SB]> Let's use SPROP for a moment
• [17:19] <Tom[Arch_SB]> Let's say today it's doing something that refers to "AltCritRange" (let's assume this is a built-in capability even if it does not exist - just as an example)
• [17:20] <Tom[Arch_SB]> we would convert that to PROP: (the new version) when we converted the CritRange variables from using CRITRANGE: and ALTCRITRANGE: to defining variables and MODIFY:
• [17:20] <Tom[Arch_SB]> so each SPROP would convert at the moment the variables convert, not all in one batch
• [17:20] <Tom[Arch_SB]> follow?
• [17:20] <James[Code_SB]> What we are talking about though is a massive manual conversion that takes place over a long time, just not in one go
• [17:21] <Tom[Arch_SB]> In this scenario, yes
• [17:21] <@[Chair]Andrew> So we're looking at converting based upon attached Var then. Which will be a pain if we encounter something with two or more.
• [17:21] <Tom[Arch_SB]> I'm struggling to find a silver bullet, I just don't think there is one
• [17:22] <Tom[Arch_SB]> @Andrew: We will have to map out variable relationships to catch those scenarios.
• [17:22] <Tom[Arch_SB]> Probably some custom code to analyze data
• [17:22] <@[Chair]Andrew> This sounds like the most prudent plan. I just know we have some interesting combos out there.
• [17:23] <Tom[Arch_SB]> I think the thing here is that there isn't much that is automatically converted
• [17:24] <Tom[Arch_SB]> a BONUS would go away and there would be a MODIFY that would have to be added to replace it
• [17:24] <Tom[Arch_SB]> the formula may use COUNT[SKILLS] which wouldn't exist in MODIFY...
• [17:24] <Tom[Arch_SB]> so it would have to be count("SKILL",...) or some such
• [17:26] <James[Code_SB]> Its is worth noting that having the systems coexist leads to the issue we have today with jep and the old broken parser - we can never pull the old code out
• [17:27] <Tom[Arch_SB]> This coexist is parallel but not interacting
• [17:27] <Tom[Arch_SB]> so in some ways, perhaps more confusing, but won't have that issue
• [17:28] <Tom[Arch_SB]> It's the "fallback" that is the problem
• [17:28] <Tom[Arch_SB]> which I don't intend to do (hence replacing DESC, SPROP, et al
• [17:29] <James[Code_SB]> yep
• [17:30] <@[Chair]Andrew> I think it's as sound as a plan as we'll get. Just give me the roadmap on the token of the day/week and I think we'll be able to cope. grep and find are useful tools for these sorts of things. :)
• [17:30] <James[Code_SB]> By coexist I meant interacting where old and new can share values.
• [17:30] <@[Chair]Andrew> Data go Boom if that happens.
• [17:30] <Tom[Arch_SB]> yea, I'd REALLY like to stay away from that
• [17:30] <James[Code_SB]> Agreed
• [17:31] <Tom[Arch_SB]> One thing that probably deserves some research is probably a quick hack of a tool to look at variable interaction
• [17:31] <James[Code_SB]> That would be quite useful
• [17:31] <Tom[Arch_SB]> if we have 2000 variables and it turns out that 1500 of them interact and have to be swapped at once, this proposal won't work
• [17:32] <Tom[Arch_SB]> The proposal kind of needs it anyway, since the map of relationships tells what to convert first, second, etc
• [17:32] <Tom[Arch_SB]> So I'll look at that before we really make any decisions here
• [17:32] <Tom[Arch_SB]> (wasn't intending to make this a final decision day on this topic)
• [17:32] <James[Code_SB]> Sounds good
• [17:33] <James[Code_SB]> It is possible the variable definition report code I put together might be useful here, but it doesn't delve into usage, so perhaps not
• [17:33] <Tom[Arch_SB]> Not to shut down discussion (we can continue if folks have questions or comments) but do we want to leave that topic there and talk a bit about the impact to docs of this proposal since we have Eric?
• [17:33] <James[Code_SB]> yep
• [17:34] <@[Chair]Andrew> yes
• [17:34] <Tom[Arch_SB]> ok
• [17:34] <Tom[Arch_SB]> So I can think of a few major impacts to our docs that this will trigger:
• [17:35] <Tom[Arch_SB]> First, there will be a major decrease in the number of tokens. Eric handles deprecation and stuff well, so that is just "busywork"
• [17:35] <Tom[Arch_SB]> Second, the replacement tokens are much more "generic" than the existing ones
• [17:35] <Tom[Arch_SB]> Today we may have something like CRITRANGE: in Equipment. In the future, this changes to something like: MODIFY:CritRange|SET|x
• [17:35] <Tom[Arch_SB]> There are a few things here:
• [17:36] <Tom[Arch_SB]> "SET" is one of a series of modifications that can occur (also includes things like ADD)
• [17:36] <Tom[Arch_SB]> "CritRange" is actually a variable name (must have been defined in the variable file)
• [17:36] <Tom[Arch_SB]> So the syntax is more like: MODIFY:w|x|y|PRIORITY=z
• [17:36] <Tom[Arch_SB]> lots of things can swap around
• [17:37] <Tom[Arch_SB]> Some potentially confusing parts:
• [17:37] <Tom[Arch_SB]> IF CritRange is a number (or VAR as I have it hardcoded in the demo) and something like "FACE" is an AREA, we can do things like:
• [17:38] <Tom[Arch_SB]> MODIFY:AREA=Face|SET|10,10 and MODIFY:CritRange|SET|2
• [17:38] <Tom[Arch_SB]> we can also do
• [17:38] <Tom[Arch_SB]> MODIFY:CritRange|ADD|3
• [17:38] <Tom[Arch_SB]> but not MODIFY:AREA=Face|MULTIPLY|...
• [17:38] <Tom[Arch_SB]> because we probably won't define a MULTIPLY modification for things that are Areas
• [17:39] <Tom[Arch_SB]> so what is legal in x will be dependent on what w is...
• [17:39] <Tom[Arch_SB]> a number, a point, etc. (the variable format)
• [17:39] <Tom[Arch_SB]> So I think the docs become very "cross referential" rather than trying to pack in all the docs into each token
• [17:40] <[Doc]Maredudd> Thats fine. I'm certain the cross-referencing can be done clearly.
• [17:40] <Tom[Arch_SB]> (By the way, for those thinking MODIFY is not consistent, note that to keep things simple on the "most used" item, a "VAR=" is implied on the first argument to save some typing
• [17:41] <Tom[Arch_SB]> (so in effect MODIFY:CritRange|SET|2 is actually MODIFY:VAR=CritRange|SET|2 to the code)
• [17:42] <Tom[Arch_SB]> I think the other thing to note is that things like FACT will also interact and share parts of the variable system
• [17:43] <Tom[Arch_SB]> So if you look at a FACTDEF, it has a DATATYPE: token (which I will likely change to FORMAT: for consistency of terms) that includes things like "NUMBER" or "GRIDPOINT"
• [17:44] <Tom[Arch_SB]> Those formats are the exact same formats that appear as the first argument of DEVAULTVARIABLEVALUE or the first argument of VARTYPEDEF
• [17:44] <Tom[Arch_SB]> so again, cross referencing will be very valuable to save typing and to help users understand that things are consistent
• [17:45] <Tom[Arch_SB]> (It also happens to give us the ability with one Java class to add a format to FACT and the variable system all at once)
• [17:45] <James[Code_SB]> nice
• [17:45] <Tom[Arch_SB]> :)
• [17:46] <@[Chair]Andrew> Very nice
• [17:47] <Tom[Arch_SB]> Any questions ? It should be more clear once I finish up the proposals for all 3... I can actually cross reference stuff on the wiki pages to help build out the relationships
• [17:48] <@[Chair]Andrew> I've been following the wiki, most of it is straightforward enough.
• [17:48] <[Doc]Maredudd> I'm still catching up on the proposals but I'm with you so far.
• [17:48] <Tom[Arch_SB]> (3 being FACT, FACTSET and the variable system... not that the proposals aren't MOSTLY cooked, just finalizing terms so we end up with things that are precise and avoid too much confusion)
• [17:49] <Tom[Arch_SB]> The other key challenge will be that ... well, a BUNCH of structure goes away
• [17:49] <Tom[Arch_SB]> Entire tokens sets will disappear, and probably a slew of game mode tokens, the result being that variables take on increased importance
• [17:49] <Tom[Arch_SB]> of course, since those are defined in data it starts to make the docs a bit more tricky
• [17:50] <Tom[Arch_SB]> either the docs need to borrow some info from the data (per data set/game mode) or they need to "teach folks to fish" - meaning how to look up what things mean
• [17:51] <Tom[Arch_SB]> That's one where I think we should talk through some considerations - does the data include anything at all, do we write something to derive some docs from the data, etc
• [17:51] <Tom[Arch_SB]> I'm open to ideas
• [17:51] <Tom[Arch_SB]> comments, etc.
• [17:52] <James[Code_SB]> At one stage we talked about generating the docs and having examples pulled into the code for testing. Is this a good point to consider that?
• [17:52] <@[Chair]Andrew> Well, I think Data will have the list of all variables and EXPLANATION
• [17:53] <@[Chair]Andrew> @James - If we could combine that, and make the xml doc project a reality, this might be the best point to do that.
• [17:53] <James[Code_SB]> If we include the variables in the docs, I think it should be a javadoc-like process (not format)
• [17:54] <Tom[Arch_SB]> @James, I tend to agree if they are to be included it should be derived automatically
• [17:54] <James[Code_SB]> Where the variables are processed into a set of html documents and then linked to by the docs
• [17:54] <[Doc]Maredudd> I can see a Tag Dictionary of the new core tokens with all of the relevant cross-references as the basis for the Data Authoring docs and then each gamemode having its own doc section where the variables that are used to build the game rules are defined and explained.
• [17:56] <Tom[Arch_SB]> @Maredudd "The variables that are used to build the game rules are defined and explained"... does that imply that not all variables in the data should make it into the docs?
• [17:56] <[Doc]Maredudd> Automatic generation of the gamemode specific variables works for me.
• [17:58] <Tom[Arch_SB]> Thinking out loud, since that may be true, perhaps we want a "ADDTODOCS:" in addition to "EXPLANATION:" in the variable file?
• [17:58] <[Doc]Maredudd> @Tom, not at all. If the gamemode specific section is generated autmatically then we should include all variables. My statement was iconsidering mor the variables created at data load.
• [17:58] <Tom[Arch_SB]> @Maredudd There are no game mode defined variables. All are delegated to LST data
• [17:59] <Tom[Arch_SB]> no two-tier system like we have with ABility categories
• [17:59] <James[Code_SB]> yay
• [17:59] <@[Chair]Andrew> Yeah, we might as well have an ADDTODOCS otherwise the list of misc vars will be huge
• [17:59] <Tom[Arch_SB]> ok, I'll add that in. Not hard to add informational stuff like that
• [18:00] <James[Code_SB]> Is that really needed though?
• [18:00] <@[Chair]Andrew> Most will be understandable if referencing the docs... ClericLVL, FighterLVL, each class has one of those, I doubt we need to explain to folks their purpose beyond what is in the Explanation of the var file. I think the items we want are the big ticket replacements - CRITMULT, CRITRANGE, etc.
• [18:01] <James[Code_SB]> We can identify core sets as different to sets for supplements
• [18:01] <Distant_Scholar> quit
• [18:01] <James[Code_SB]> and thus give the core set variables the most prominence
• [18:01] *** Distant_Scholar has quit IRC: Quit: Leaving
• [18:02] <@[Chair]Andrew> My plan is to try to keep all the information kept to the core sets
• [18:02] <James[Code_SB]> supplements will still define their own variables
• [18:02] <[Doc]Maredudd> @Tom, right, I understand that. I'll have to rethink how I communicate my thought.
• [18:02] <Tom[Arch_SB]> Thinking through this out loud.... but my caution is that there are "varaibles" that are "internal guts" (turn abilities on and off in Pathfinder) that I don't know if they deserve being in the HTML docs
• [18:03] <James[Code_SB]> Well, those are what homebrewers will likely want to know about
• [18:03] <Tom[Arch_SB]> It really raises the question of what the docs are trying to accomplish
• [18:03] <@[Chair]Andrew> Presently - big items that are replaced by the MODIFY system I would think.
• [18:04] <[Doc]Maredudd> When I say gamemode specific variables I do not mean they are defined in the gamemode files. I mean they are variables that are used in the lst files to defines the variables that are intended to replace many of the tags we currently use.
• [18:04] <Tom[Arch_SB]> This is interesting. If we do only a subset, then what user base does that serve?
• [18:04] <@[Chair]Andrew> Could we separate out the 'core' vars for display - items replacing deprecated BONUS and then have a section for all the rest?
• [18:04] <Tom[Arch_SB]> The homebrews have to read the data anyway to get what they want, and others probably aren't using that level of the docs
• [18:05] <Tom[Arch_SB]> I'm not even sure it's worth having docs for vars at all
• [18:05] <Tom[Arch_SB]> because folks will have to look into the system to look at how they interact and are defaulted anyway
• [18:05] <Tom[Arch_SB]> and you almost want to encourage that
• [18:05] <Tom[Arch_SB]> (to have them actually look at the data)
• [18:06] <Tom[Arch_SB]> (by defaulted, I don't mean all numbers default to zero which is in the game mode, I mean things like a MODIFY that defaults CRITRANGE to 1)
• [18:06] <James[Code_SB]> That's a tough ask when we used to have FACE and HANDS documented nicely in a simple lokup
• [18:06] <James[Code_SB]> It is a big drop in usability IMO
• [18:06] <Tom[Arch_SB]> yea, thinking out loud
• [18:07] <Tom[Arch_SB]> I'm concerned about trying to find them in a sea of 2000 variables though
• [18:07] <Tom[Arch_SB]> that's where I'm struggling to find a "good" answer
• [18:07] <James[Code_SB]> It probably needs experimentation
• [18:07] <@[Chair]Andrew> ADDTODOCS:<Location>?
• [18:08] <@[Chair]Andrew> Location being <BONUS REPLACEMENT> and <Internal Variables>
• [18:08] <Tom[Arch_SB]> I don't know why BONUS would be special
• [18:08] <@[Chair]Andrew> Cause it's the one that most everyone uses.
• [18:08] <James[Code_SB]> I'd start with the question - what can we make automatic without extra tags and extra data team effort
• [18:08] <Tom[Arch_SB]> I understand it provides comfort to people, but it's inconsistent in what is there today
• [18:08] <[Doc]Maredudd> AltCritRange s a good example of what I would consider a core variable. It, or someting like ot, is a musyt if we are to simulate the rule mechanics for the d20 system. I would have that documented in the docs.
• [18:09] <[Doc]Maredudd> What that leads to is each gamemode would have its own Variable Dictionary.
• [18:09] <Tom[Arch_SB]> By the way, we are past 9, so not sure if folks have a stop
• [18:09] <James[Code_SB]> Yeah I have to head off sorry - missed the time
• [18:10] <[Doc]Maredudd> I'm free for the night . . . :-)
• [18:10] <Tom[Arch_SB]> no problem, I think we got through a good discussion and got issues on the table for further thought. that's the point
• [18:10] <James[Code_SB]> We got into some cross conversations there, but I just wanted to make the point that trend in most systems these days is to aim at convention over configuration
• [18:11] <[Doc]Maredudd> I'll go finish reading the three proposals . . .
• [18:11] <@[Chair]Andrew> And I'm still here :)
• [18:11] <@[Chair]Andrew> Are we calling it a night then?
• [18:11] <James[Code_SB]> It is a huge labour saving approach and to me it is worth achieving if we can
• [18:11] <[Doc]Maredudd> Did you guys see the file I uploaded to the BOD File section?
• [18:11] <James[Code_SB]> I'm off now - night guys
• [18:12] <Tom[Arch_SB]> later James
• [18:12] <[Doc]Maredudd> Night James!
• [18:12] <@[Chair]Andrew> Night James
• [18:12] *** James[Code_SB] has left #pcgen
• [18:12] <Tom[Arch_SB]> I did, I posted a response a bit ago
• [18:12] <[Doc]Maredudd> Tom and Andrew, and anyone else who wishes to speak up, what do you see as the purpose of the docs?
• [18:13] <@[Chair]Andrew> To give insight
• [18:14] <@[Chair]Andrew> The tag section is meant to instruct people how to use the tags properly
• [18:14] <[Doc]Maredudd> I just saw your response Tom. The diargam I posted doesn't include a section for formulas as you say as I don't understand the issue well enough yet. I'll get there. :-)
• [18:15] <Tom[Arch_SB]> So thinking out loud on the docs - I think what is effectively happening with FACT, the variable system change, and the like is that the "data architecture" is being handed back to the data team. Before it was implied in the token structure
• [18:15] <@[Chair]Andrew> Since we are converting these by hand, it should have some instructional use to lead those who follow in the same steps - BONUS:XXX > is not handled by MODIFY > see particular gamemode for further.
• [18:15] <[Doc]Maredudd> The diagram I posted covers five areas, four of which we currently cover to different degrees. The discussion tonight will mostly affect section 3.
• [18:16] <@[Chair]Andrew> *Now
• [18:16] <Tom[Arch_SB]> So we have two items to document: the token formats (literally what to do - a reference if you will) and the data design - why things are done they way they are done
• [18:17] <@[Chair]Andrew> *nods* Correct
• [18:17] <[Doc]Maredudd> Tom, Thats what I'm seeing. Thats why I see a subsection of the Data Authoring docs for each gamemode.
• [18:17] <Tom[Arch_SB]> the challenge with why is that it's more than the explanation
• [18:18] <Tom[Arch_SB]> Go here for a moment:
• [18:18] <Tom[Arch_SB]> http://wiki.pcgen.org/index.php?title=Formula_Parser_Equip_Vars_Demo#An_Example
• [18:18] <[Doc]Maredudd> Yep. Much more than the explanation.
• [18:19] <Tom[Arch_SB]> The challenge with that example is that there are actually two variables involved (CritRange and EqCritRange) one of which impacts the other
• [18:19] <Tom[Arch_SB]> So that relationship is important
• [18:19] <Tom[Arch_SB]> that's why I was having the reaction earlier that you really DO want folks to actually read the data
• [18:19] <Tom[Arch_SB]> because otherwise, how do you get at that relationship?
• [18:20] <Tom[Arch_SB]> Does the EXPLANATION: need to do that? Won't that get old keeping those up to date?
• [18:20] <Tom[Arch_SB]> (and Andrew - we should post this informal followup discussion as well so James and others can catch up on it)
• [18:21] <@[Chair]Andrew> Tom - Agreed
• [18:22] <Tom[Arch_SB]> @Andrew on your BONUS to MODIFY comment, I think the deprecated BONUS should refer to its replacement
• [18:23] <Tom[Arch_SB]> Since 99% of those will follow the same conversion across different existing game modes that should be doable
• [18:23] <[Doc]Maredudd> I see your point Tom. As I said I'm still catchiing up on the proposals. My thoughts may change once I do. My goal though is to provide some documentation to help the Lst Monkey, be they new PCGen team member or grizzled homebrewer have a refence to get a head start on the data architecture.
• [18:24] <Tom[Arch_SB]> and don't take my thoughts as being final or necessarily the most useful answer. I'm just trying to put down what crosses my mind so folks can consider implications
• [18:24] <Tom[Arch_SB]> I still don't know that I have a good sense of what is best right now
• [18:24] <[Doc]Maredudd> Linking to the replacement is standard practice when deprecating a tag, and in the case of a BONUS deprecation we would provide an example.
• [18:26] <@[Chair]Andrew> Yes, deprecation always has a link to it's replacement. Been standard practice.
• [18:28] <[Doc]Maredudd> We might even consider a "Conversion Guide" that specifically covers the new style tags and how they can be used to replace the old style tags, complete with honest to PCGen examples . . .
• [18:30] <[Doc]Maredudd> Tom, I know its kind of early to prognosticate on this matter, but do you have a feeling for how long we would be running the old and new variable systems side-by-side?
• [18:31] <Tom[Arch_SB]> Hard to say, since it is dependent upon code and data interacting
• [18:32] <Tom[Arch_SB]> I can't imagine it being less than 2 releases
• [18:32] <@[Chair]Andrew> Hmm, I just thought of something
• [18:33] <@[Chair]Andrew> our export system is using pcvar to get JEP values, do we have something to capture new parser values or will pcvar handle both?
• [18:33] <@[Chair]Andrew> at least the freemarker xml stuff
• [18:35] <Tom[Arch_SB]> have you seen the output demo?
• [18:36] <Tom[Arch_SB]> well, don't even need to have done that
• [18:36] <Tom[Arch_SB]> VISIBLE for VARTYPEDEF
• [18:37] <@[Chair]Andrew> Explain, how it is it tied to the OS?
• [18:37] <@[Chair]Andrew> (Dinner time be back in a few)
• [18:37] <Tom[Arch_SB]> actually, not VARTYPEDEF
• [18:37] <Tom[Arch_SB]> but in the variable file - let me explain
• [18:38] <Tom[Arch_SB]> Let's say we have in the variable file:
• [18:38] <Tom[Arch_SB]> LOCAL:EQUIPMENT|CritRange
• [18:39] <[Doc]Maredudd> Got it.
• [18:39] <Tom[Arch_SB]> Then in the XML in Freemarker we use a directive to loop over the Equipment:
• [18:40] <Tom[Arch_SB]> <#list equipment as eq>
• [18:40] <Tom[Arch_SB]> blah
• [18:40] <Tom[Arch_SB]> </#list>
• [18:40] <Tom[Arch_SB]> in blah we can do:
• [18:40] <Tom[Arch_SB]> eq.critrange
• [18:40] <Tom[Arch_SB]> IF and only if
• [18:40] <Tom[Arch_SB]> we did this:
• [18:40] <Tom[Arch_SB]> LOCAL:EQUIPMENT|CritRange <> VISIBLE:YES
• [18:40] <Tom[Arch_SB]> VISIBLE:EXPORT would, of course, also work
• [18:41] <Tom[Arch_SB]> so variables have visibility, and if visible, attach to the object in question
• [18:41] <Tom[Arch_SB]> always fully lower case, as we are keeping all the output that way by convention
• [18:42] <Tom[Arch_SB]> in that way, the Freemarker output is actually controlled by the data and the code doesn't really care that critrange exists or not
• [18:42] <Tom[Arch_SB]> the core processes it through "transparently" just as any other variable would be
• [18:44] <Tom[Arch_SB]> if you need to mess with it in some way, then you can do math directly in freemarker:
• [18:44] <Tom[Arch_SB]> <#list equipment as eq>
• [18:44] <[Doc]Maredudd> Cool.
• [18:44] <Tom[Arch_SB]> <#list eq.head as head>
• [18:44] <Tom[Arch_SB]> <#if ${head.critrange} == 1> "20" <#else> ${20 - head.critrange + 1} "-20" </#if>
• [18:45] <Tom[Arch_SB]> </#list>
• [18:45] <Tom[Arch_SB]> </#list>
• [18:45] <Tom[Arch_SB]> of course in that case, critrange is an EqPart variable
• [18:45] <Tom[Arch_SB]> LOCAL:EQUIPMENT.PART|CritRange <> VISIBLE:YES
• [18:46] <Tom[Arch_SB]> (give or take that I'm accidentally mixing head and part and really we would use part)
• [18:47] <Tom[Arch_SB]> I'm going to have to duck out, any last questions?
• [18:49] <Tom[Arch_SB]> ok, catch folks later. have a good evening
• [18:49] <[Doc]Maredudd> Nope. Thanks!