Meeting 2015 01 30

Board Meeting

Attendance

• Chair - Andrew Maitland
• Data 2nd - Doug Limmer
• OS 2nd - Stefan Radermacher
• Arch - Tom Parker
• Observer - David Bender
• Observer - Jeff (Swiftbrook)

Summary

• License will review newer sources finished this weekend
• Stefan will finish data reviews this weekend
• Doug is still working on Advanced Class Guide
• James will release 6.5.1 next weekend (Feb 7/8)
• Code Bug introduced for deities tab
• Deep Dive discussion by Tom:
  • Proposed integrating the non-solver portion of the formula parser - this would allow the BOOLEAN functions that we're using for Archetypes and Racial Traits
  • Brought up Performance issue for Trailing PRExxx
  • Brought up thoughts about handling the PRE/REQ concepts and PRETHIS
  • Discussed a solution for the REQ/PRE but would lose user feedback - re-thinking how to utilize that better
  • Eluded to new tools for the data team

RAW LOG

• [15:01] <@Andrew[Chair]> I have 3pm PST/6pm EST
• [15:01] <@Andrew[Chair]> it's time according to my schedule
• [15:01] <@Andrew[Chair]> We want to wait another 5 minutes for James?
• [15:02] <Distant_Scholar> I just got an e-mail saying James won't make it (I imagine y'all did, too).
• [15:02] <@Andrew[Chair]> I didn't...
• [15:03] <Distant_Scholar> I got it on the BOD mailing list.
• [15:03] <Distant_Scholar> I'll (try to) copy it in below.
• [15:03] <Distant_Scholar> JD: Hi, I'm not able to make today's meeting sorry
• [15:03] <Distant_Scholar> JD: Code report:
• [15:03] <Distant_Scholar> JD: * Welcome to Mark Cline who joined the code monkeys last week.
• [15:04] <Distant_Scholar> JD: * Some small non arch changes to the code
• [15:04] <Distant_Scholar> JD: * Aiming to put out 6.5.1 soon. Could be next weekend if everyone is ok with that.
• [15:04] <Distant_Scholar> JD: Cheers, James.
• [15:04] <@Andrew[Chair]> Okay, cool
• [15:04] <@Andrew[Chair]> Guess we should start then
• [15:04] <@Andrew[Chair]> *Bangs gavel*
• [15:05] <@Andrew[Chair]> Hi all, welcome to the PCGen Board of Directors meeting for January 30th, 1500 hours PST
• [15:05] <@Andrew[Chair]> Agenda:
• [15:05] <@Andrew[Chair]> Quick reports for immediate items
• [15:05] <@Andrew[Chair]> Nixed - Release Schedule (James isn't present)
• [15:05] <@Andrew[Chair]> Tom's Deep Dive Discussion
• [15:06] <Tom[Arch_SB]> Not sure if deep dive is useful without James
• [15:06] <Tom[Arch_SB]> that's really one of the sounding boards
• [15:06] <@Andrew[Chair]> Hm, well... We can pitch ideas at him.
• [15:07] <@Andrew[Chair]> He does read the reports too... :)
• [15:08] <@Andrew[Chair]> Okay, since the deep dive won't be happening as deeply, I'll just report my absent report blurb as well.
• [15:08] <@Andrew[Chair]> Content Report:
• [15:08] <@Andrew[Chair]> Data: Cleared two new sources into the release "Adventurer's Armory" and "AP #67"; waiting on Stefan to clear a few more sources now - Blood of the Moon, Taldor, Technology Guide.
• [15:08] <@Andrew[Chair]> I just finished coding up Inner Sea Combat - that's now off to License and Data for review. Doug is still working on Advanced Class Guide.
• [15:08] <@Andrew[Chair]> I had to redo the system that controlled Ranger Bonus Feats, and the Archetype control for the Ranger Combat Style.
• [15:08] <@Andrew[Chair]> We are in discussion about EQMOD naming standards, looks like we'll be doing real names to follow object naming like we do for equipment.
• [15:08] <@Andrew[Chair]> Documentation: Found a few bugs, but otherwise nothing is happening here.
• [15:09] <@Andrew[Chair]> Outputsheets: Working with Tom to update items to use the new FACT/FACTSET system. Stefan is working on a few issues.
• [15:09] <@Andrew[Chair]> That's it for Content
• [15:09] <@Andrew[Chair]> Questions before I post Paul's License report?
• [15:09] <Tom[Arch_SB]> not from me
• [15:09] <Distant_Scholar> There is someone else working on ACS; I forget who, though. Andrew Wilson, maybe?
• [15:10] <@Andrew[Chair]> There's been a few.
• [15:10] <@Andrew[Chair]> I added a one-off contributor as well
• [15:11] <@Andrew[Chair]> Okay, Paul reports: I intend to have all the files for licensing cleared this weekend.
• [15:11] <@Andrew[Chair]> I haven't heard from Admin.
• [15:12] <@Andrew[Chair]> Tom, you're up. *passes talking stick*
• [15:12] <Tom[Arch_SB]> So as you mentioned, FACT/FACTSET went in with the new output models
• [15:12] <Tom[Arch_SB]> so working to add to those as necessary, will take a bunch of effort to get through those
• [15:13] <Tom[Arch_SB]> Looking further at the formula system and how that can be integrated, perhaps a short discussion on that at the end
• [15:13] <Tom[Arch_SB]> Main focus though is driving as much as we can to the new output system to try to decouple from the old output tokens/code
• [15:13] <Tom[Arch_SB]> that gives learning of what can be/has to be done in the OS and what macros and other things will be useful
• [15:14] <Tom[Arch_SB]> as what as what will still require some code support (hopefully very little)
• [15:15] <Tom[Arch_SB]> I also merged a change today that will hopefully quiet Jenkins
• [15:15] <@Andrew[Chair]> :-) Thank You
• [15:15] <Tom[Arch_SB]> lots of "administrative code cleanup" if you will
• [15:15] <Tom[Arch_SB]> any questions?
• [15:16] <@Andrew[Chair]> Not really a question, more of a "When you free to work on it?"
• [15:16] <Tom[Arch_SB]> We can cover that offline, not sure how to predict that well
• [15:17] <@Zaister> good evening
• [15:17] <@Andrew[Chair]> Fair enough. Otherwise, no direct question. Just eager to hear what you want to share about the system changes.
• [15:17] <Tom[Arch_SB]> Hi Stefan
• [15:18] <@Andrew[Chair]> Hi Stefan
• [15:19] <@Zaister> Did we get the domain tabs stack trace fixed? That was caused by the FACT merge
• [15:19] <@Andrew[Chair]> Stefan, since you're here, you have anything to add to the reports or discussion? :)
• [15:19] <@Andrew[Chair]> (before we drag out more details from Tom)
• [15:19] <Tom[Arch_SB]> Didn't see that bug report, is there a JIRA for it?
• [15:19] <@Zaister> I hope I finally get the reviews done over the weekend, I have nothing more at the moment
• [15:19] <@Andrew[Chair]> I didn't see any report either.
• [15:20] <@Zaister> tom: I don't think so, but I get a stack trace everytime I run the program, and the deity list is empty. I think there was a list posting
• [15:20] <Tom[Arch_SB]> looks like James opened one
• [15:20] <Tom[Arch_SB]> CODE-2818
• [15:20] <Tom[Arch_SB]> I'll look at that
• [15:20] <Tom[Arch_SB]> thanks for the pointer
• [15:21] <@Zaister> cool
• [15:22] <@Andrew[Chair]> Okay Tom... you teased us about Formula parser stuff, fact/factset and some nifty super secret project... so discuss. :)
• [15:24] <Tom[Arch_SB]> Well, tonight is going to be on the formula parser
• [15:25] <Tom[Arch_SB]> There have been ongoing concerns about integration, and still trying to work through a decent way to do that
• [15:25] <Tom[Arch_SB]> Was thinking it might be good to integrate but in the initial pass, without any ability to do equations
• [15:25] <Tom[Arch_SB]> This sounds a bit strange, but it's actually still a lot of capability
• [15:25] *** PapaDRB has quit IRC: Quit: ~ Trillian Astra - www.trillian.im ~
• [15:25] <Tom[Arch_SB]> much of the FLAG stuff could work, so the data could be removing the current "it's a var but we're using it as a flag"
• [15:26] <Tom[Arch_SB]> which offloads BONUS and thus would help out
• [15:26] <Tom[Arch_SB]> also is better semantics
• [15:26] <Tom[Arch_SB]> I can also use the solving system internally to get rid of some code
• [15:26] <Tom[Arch_SB]> and make things more consistent and debuggable
• [15:27] <Tom[Arch_SB]> (anything passing through a solver would appear in the solver debugging system which was in the EqVar demo)
• [15:28] <Tom[Arch_SB]> It actually brings in the solver so we get some experience with it, starts to move data without trying the more risky rip up of formulas (but certainly reduces use of BONUS so there is less to worry about later)
• [15:28] <Tom[Arch_SB]> I think it's a good first step and wanted to get thoughts on that
• [15:28] <@Andrew[Chair]> Sounds really good to me. Ranger already proved we need that.
• [15:29] <@Andrew[Chair]> This means we'd get PREBOOL for the initial pass?
• [15:29] <Tom[Arch_SB]> Yes, that would be part of it
• [15:30] <@Andrew[Chair]> Archetypes would be a great test bed, see how that helps performance :)
• [15:30] <Tom[Arch_SB]> well...
• [15:30] <Tom[Arch_SB]> to set expectations....
• [15:30] <Tom[Arch_SB]> there are a few things in the performance issue category
• [15:30] <Tom[Arch_SB]> one is BONUS
• [15:30] *** Swiftbrook has quit IRC: Ping timeout: 246 seconds
• [15:30] <Tom[Arch_SB]> but one is having a trailing PRExxx at all
• [15:30] <Tom[Arch_SB]> so eventually we need to think in mental models that try to minimize trailing PRExxx
• [15:31] <Tom[Arch_SB]> (The default object trick, while useful to get around some issues PCGen has had and a few that it may still have is a long term issue)
• [15:31] <@Andrew[Chair]> If you have a better model to handle Archetypes, I'm very open to discussions.
• [15:32] <Tom[Arch_SB]> That's one thing I've been looking at to try to figure out a good model
• [15:32] <Tom[Arch_SB]> It's kind of an interesting problem
• [15:32] <Tom[Arch_SB]> was looking at Stefan's PRETHIS FREQ as well and want to find something better than that when it's "can't do another of <blah>"
• [15:33] <@Zaister> ah that one
• [15:33] <@Andrew[Chair]> Yeah, the basic PRExxx turn red issue, and that doesn't even touch the MULT:YES items
• [15:34] <Tom[Arch_SB]> it really highlights a few different things all at once.
• [15:34] <Tom[Arch_SB]> Well, that's what I think anyway, based on my research so far
• [15:34] <@Andrew[Chair]> Yes, many issues. All stem from no better solution has been presented to solve it.
• [15:34] <Tom[Arch_SB]> One is the "there is a <foo> modification performed by an archetype and once you have one that does that you can't take another"
• [15:35] <Tom[Arch_SB]> (that performs that mod)
• [15:35] <Tom[Arch_SB]> One is the red display issue, so it's really back to PRE/REQ
• [15:35] <Tom[Arch_SB]> and separating those concepts
• [15:35] <@Andrew[Chair]> Yes, separating concepts is a good idea.
• [15:36] <Tom[Arch_SB]> One of the big challenges is in communication back to the user
• [15:37] <Tom[Arch_SB]> I have at least one model that would work logically, but the info window wouldn't necessarily be able to say why it wasn't available
• [15:37] <Tom[Arch_SB]> I'm unsure what the reaction to that would be
• [15:37] <@Andrew[Chair]> Which situation is this?
• [15:38] <@Andrew[Chair]> Feedback is important for debugging issues
• [15:38] <Tom[Arch_SB]> Any Ability
• [15:38] <Tom[Arch_SB]> sorry, not the use case I'm talking about
• [15:38] <Tom[Arch_SB]> When you go in to select a Feat, for example
• [15:38] <Tom[Arch_SB]> Super Weapon Foo is red because you need to be specialized in something first
• [15:39] <Tom[Arch_SB]> right now, presumably, there is a PREFEAT:Weapon Specialization or whatever
• [15:39] <@Andrew[Chair]> yes
• [15:39] <Tom[Arch_SB]> (or maybe it's implicitly the choose? I should actually check that)
• [15:39] <@Andrew[Chair]> PREABILITY:1,CATEGORY=Feat,Weapon Focus
• [15:39] <Tom[Arch_SB]> anyway, presume it's a PREFEAT for discussion
• [15:39] <Tom[Arch_SB]> ok
• [15:40] <Tom[Arch_SB]> so that PREABILITY produces text in the info window of "must have 1 of Ability (Feat ) Weapon Focus"
• [15:40] <Tom[Arch_SB]> or some such
• [15:40] <Tom[Arch_SB]> and that text will be red
• [15:40] <@Andrew[Chair]> yes
• [15:40] <Tom[Arch_SB]> since it's not met
• [15:40] <Tom[Arch_SB]> that's the text I'm talking about
• [15:40] <@Andrew[Chair]> okay
• [15:40] <Tom[Arch_SB]> I have a system that might dramatically simplify the data, but those would be lost
• [15:41] <Tom[Arch_SB]> but I suspect the "why can't I take this" might be important to some folks
• [15:41] <@Andrew[Chair]> Yes, we'd have an increase in help desk "calls"
• [15:41] <Tom[Arch_SB]> so not sure about that model and whether I can adapt it
• [15:42] <@Andrew[Chair]> So, silly question, why can't we just use a PRETEXT:Must have Weapon Focus to take this feat. ?
• [15:43] <Tom[Arch_SB]> two reasons
• [15:43] <@Andrew[Chair]> not sure if we need the color coding to indicate, but having a message on what is required regardless would be the minimal thing to me.
• [15:43] <Tom[Arch_SB]> one would be data sprawl
• [15:43] <Tom[Arch_SB]> the other is... hard to explain
• [15:44] <Tom[Arch_SB]> This isn't what I'm thinking, so dont' take it AT ALL literally, but imagine the ability to do a PREOTHER to apply a PRE to another object
• [15:44] <Tom[Arch_SB]> you'd need the PRETEXTOTHER as well
• [15:44] <Tom[Arch_SB]> hmm
• [15:44] <Tom[Arch_SB]> that's interesting though
• [15:44] <Tom[Arch_SB]> let me think on that
• [15:44] <Tom[Arch_SB]> there are ways something like that could work
• [15:45] <Tom[Arch_SB]> maybe
• [15:45] <Tom[Arch_SB]> need more brainpower than I have after a long week :/
• [15:45] <@Andrew[Chair]> PREOTHER is an interesting concept...
• [15:45] <Tom[Arch_SB]> don't even go there
• [15:45] <@Andrew[Chair]> :P
• [15:45] <Tom[Arch_SB]> the goal is less PRExxx not more
• [15:45] <@Andrew[Chair]> You brought it up.
• [15:45] <Tom[Arch_SB]> as an analogy
• [15:46] <@Andrew[Chair]> Okay, so model with deficiencies to be thought about later.
• [15:47] <@Andrew[Chair]> Did that tie into less trailing PRExxx?
• [15:48] <Tom[Arch_SB]> yes
• [15:49] <@Andrew[Chair]> All right, so for now, PREBOOL will allow a smooth switch over, performance might not improve due to the prexxx trailing issue.
• [15:50] <@Andrew[Chair]> but it will be less to migrate when we integrate more of the formula system.
• [15:50] <Tom[Arch_SB]> It will improve some
• [15:50] <Tom[Arch_SB]> since the system will only solve once not every loop
• [15:50] <Tom[Arch_SB]> just not as dramatic as one might hope for
• [15:50] <Tom[Arch_SB]> need a more dramatic data architecture change to get that
• [15:51] <Tom[Arch_SB]> and you guys need new tools before that is a reasonable request
• [15:51] <@Andrew[Chair]> hm, sounds good, but you do understand how archetypes work right?
• [15:51] <@Andrew[Chair]> when you say "solve once" I don't want to have an issue with things not updating when an archetype is taken
• [15:52] <Tom[Arch_SB]> solve once means solve once
• [15:52] <Tom[Arch_SB]> it "knows" dependencies
• [15:53] <@Andrew[Chair]> Okay, as long as it works. I'm happy. Just jumping on potential issues before we get to converting.
• [15:53] <@Andrew[Chair]> When would you plan on implementing this phase of the Formula System Parser then?
• [15:54] <Tom[Arch_SB]> Need to get the git infrastructure set up first
• [15:54] <Tom[Arch_SB]> James helped me the first part of that a bit ago, but we need to finish that up so I understand the setup
• [15:54] <@Andrew[Chair]> ok
• [15:54] *** Swiftbrook has joined #pcgen
• [15:54] <Tom[Arch_SB]> then it's in a git sandbox anyway and we can figure out what the criteria are for swapping it in
• [15:55] <Tom[Arch_SB]> kind of like we did with FACT/FACTSET
• [15:55] <Tom[Arch_SB]> there is some research required to make sure there aren't nasty issues
• [15:55] <Tom[Arch_SB]> so it may be a slower integration
• [15:55] <@Andrew[Chair]> Sounds like about a month out if not more then
• [15:55] <Tom[Arch_SB]> I don't have a good sense to put a calendar up for it though
• [15:56] <Tom[Arch_SB]> I'd like to have it running in git within a few weeks, then figure it out from there
• [15:56] <Tom[Arch_SB]> I'm not sure I have deep time to invest until mid Feb anyway
• [15:57] <Tom[Arch_SB]> any other ?, I need to duck out at 7
• [15:57] <@Andrew[Chair]> Okay, and I presume the new data tools comment was for finishing up the DSL discussion.
• [15:57] <Tom[Arch_SB]> no
• [15:57] <Tom[Arch_SB]> those are unrelated
• [15:58] <@Andrew[Chair]> New toys then, goodie :) Okay, I've got nothing else to ask. Anyone else in the last minute or so?
• [15:58] <Distant_Scholar> Not me.
• [16:00] <@Andrew[Chair]> Thanks for coming everyone. Meeting adjourned *Bangs gavel*