Started at 12:00pm (PST) and ended at 4:00pm (PST)

Attendance:

Andrew Maitland
Douglas Limmer
Andrew Wilson
David Bender
Stefan Radermacher
Mark Means
Chris Chandler

Guest appearance by Unicorn437

Summary:

We discussed all topics laid out
Tom has a lot of questions asked by the group
Zaister/Nuance will make a program to gather the Vars and FACT stuff for easier documentation and consolidation for developers
OFF-TOPIC: Issue regarding Mystic Theurge
More Tom questions
Standards discussed
OFF-TOPIC: Isolating Data Sets better
Partial-Topic: Gamemode usage discussion

Raw Meeting Log - Premeeting and meeting.

Premeeting

[10:29] <@AndrewAAM> Ook!
[10:39] <PapaDRB> Hello.
[10:57] <Nuance> Yo!
[11:05] <@AndrewAAM> Hi,
[11:05] <@AndrewAAM> sorry, didn't see any activity
[11:06] <Nuance> I'm an hour early aren't I?
[11:06] <@AndrewAAM> you are
[11:07] <@AndrewAAM> 11am for me, so 7pm for you or did we not account for day light savings somewhere?
[11:07] <Nuance> Good, better that than an hour late
[11:07] <Nuance> nope, I thought I was an hour early, but better safe than sorry
[11:08] <Nuance> I'm adding spurious letters again, need to slow down and proff what I'm typing
[11:08] <@AndrewAAM> Well, glad you made it. Looking like a good turn out expected, which is awesome
[11:08] <Nuance> proff even
[11:08] <@AndrewAAM> proof?
[11:08] <Nuance> proof
[11:08] <Nuance> yeah
[11:08] <@AndrewAAM> must have been a long day
[11:08] <Nuance> nope, just my crappy fingers falling over themselves
[11:09] <@AndrewAAM> that too.
[11:09] <@AndrewAAM> finishing up UCA for release and dealing with alchemist bombs
[11:09] <Nuance> coolio
[11:10] <@AndrewAAM> I did some prelim mythic subrace work
[11:10] <Nuance> I've been following your wiki about data to replace attack sequences et.a l.
[11:10] <@AndrewAAM> but as-is we could probably send it out...
[11:11] <@AndrewAAM> Yeah, that needs some follow up from Tom, it's raw and feels incomplete
[11:11] <Nuance> Yeah, I saw the thing you posted about mythic races
[11:11] <@AndrewAAM> Cause we need to account for a speed weapon adding another top tier attack
[11:11] <@AndrewAAM> or Speed effect
[11:11] <Nuance> I'm not sure how that's going to work, I don't think we can totally move it into the data realm
[11:12] <henkslaaf> hi
[11:12] <@AndrewAAM> Well, my proposal was is BONUS
[11:12] <Nuance> Evenhi
[11:12] <@AndrewAAM> Hi Henk
[11:12] <@AndrewAAM> But since ALL bonus tags are going to the wayside, I was trying to work out a data solution
[11:13] <Nuance> Yeah, but what you currently have, needs some way to identify taht some variable should be part of an iterative attack sequence
[11:13] <@AndrewAAM> Tom isn't joking about the formula parser handling a lot of our existing items
[11:13] <@AndrewAAM> Oh, OS is a bit more manageable
[11:13] <Nuance> So you need some way to associate whatever variables your using with some kind of attack array
[11:13] <Nuance> if you have that speed is easy
[11:14] <@AndrewAAM> Well, consider this
[11:14] <@AndrewAAM> BONUS:WEAPON|ATTACKS already does this.
[11:14] <Nuance> Yes, but it has code scaffolding behind it that knows about iterative attacks
[11:14] <@AndrewAAM> the iterative stuff is handled by the OS and we should move away from OS control to data control.
[11:15] <@AndrewAAM> otherwise, Flurry of Blows can never be supported correctly.
[11:15] <Nuance> The attack string is built in an output token
[11:15] <@AndrewAAM> Yes, I know.
[11:15] <Nuance> which is java code
[11:15] <@AndrewAAM> it's a beast
[11:15] <Nuance> I know, I rewrote part of it
[11:15] <@AndrewAAM> Not sure if you saw Tom's last remarks, but the formula parser can handle LISTs
[11:16] <Nuance> Are you familiar with enums?
[11:16] <@AndrewAAM> not LIST like from CHOOSE but actual lists
[11:16] <@AndrewAAM> No, but I can learn fast enough. :)
[11:16] <Nuance> oh that's nice. Even better if they're dynamic
[11:16] <Nuance> they're basically a sequence that uses symbolic terms instead of numbers
[11:17] <@AndrewAAM> Yes, it's a plugin extensible system, we handle vectors or points "AREA=Face|x|5,5
[11:17] <henkslaaf> that new formula thing show much promise
[11:17] <Nuance> Speed, first, second, third, fourth instead of 0, 1, 2, 3, 4
[11:17] <Nuance> Ada uses them quite extensively
[11:17] <@AndrewAAM> Cool
[11:17] <Nuance> if you have an array indexed of tthat, then building your output string is a matter of starting with Speed instead of first
[11:18] <henkslaaf> i would really like the current syntax for archetypes to be more declarative, instead of that premult beast
[11:18] <@AndrewAAM> Flurry of blows has a interesting progression.
[11:18] <@AndrewAAM> Each weapon is a local var for attack sequence
[11:18] <Nuance> I know it's different, but I don't know the exact details
[11:19] <@AndrewAAM> Hi Henk, throwing a curveball in there
[11:19] <Nuance> If we can do lists, can we index into them like lisp?
[11:19] <@AndrewAAM> That would be a Tom question
[11:19] <@AndrewAAM> Henk - Explain?
[11:19] <Nuance> Can we push and pop? shift and unshift (same operations different end of the list)
[11:20] <henkslaaf> well, we repeat that syntax everywhere. just to support something thay is much like a pool. either this or that or that thing
[11:20] <@AndrewAAM> Nuance - more Tom questions. I've compiled most of the Tom released information on the data conversion wiki link.
[11:20] <Nuance> in perl syntax unshift @attacks $attacks[0]
[11:21] <henkslaaf> but i'd need to write this down in email somewhere to make it clear. nevermind
[11:21] <@AndrewAAM> Conversation would be at the bottom.
[11:21] <Nuance> take the first element of the array attacks and add it to the start of attacks pushing everything else back
[11:21] <@AndrewAAM> That'd be iterative standard plus a speed I assume
[11:22] <@AndrewAAM> flurry would need something a bit more elaborate.
[11:22] <Nuance> yes, or any list of values, but in this instance attacks
[11:22] <Nuance> What is the flurry progression?
[11:23] <Nuance> Henk, I'm not ignoring you. I agree it would be nice to replace that pre thing. I'm not sure that's in scope for the BONUS replacement.
[11:24] <@AndrewAAM> Let me find it, I think it's -2/-5/-5/-8/-8 but let me find an actual table
[11:25] <@AndrewAAM> +18/+18/+13/+13/+8/+8/+3
[11:25] <@AndrewAAM> at 20th level
[11:26] <@AndrewAAM> –1/–1 at 1st
[11:26] <@AndrewAAM> +4/+4/–1 @ 6th
[11:26] <@AndrewAAM> +6/+6/+1/+1 @ 8th
[11:26] <@AndrewAAM> +9/+9/+4/+4/–1 @ 11th
[11:27] <@AndrewAAM> +13/+13/+8/+8/+3/+3 @ 15th
[11:27] <henkslaaf> oh no. it is not the bonus thing. i just dropped it in like that, sorry
[11:27] <@AndrewAAM> +15/+15/+10/+10/+5/+5/+0 @ 17th
[11:27] <Nuance> oh, not 13th?
[11:27] <@AndrewAAM> +11/+11/+6/+6/+1 @ 13th
[11:27] <@AndrewAAM> no
[11:29] <@AndrewAAM> gains attacks at 6, 8, 11, 15, 16
[11:29] <@AndrewAAM> I'm using d20pfsrd so it may be wrong
[11:29] <@AndrewAAM> (Link: http://www.d20pfsrd.com/classes/core-classes/monk)http://www.d20pfsrd.com/classes/core-classes/monk
[11:29] <@AndrewAAM> (Link: http://paizo.com/pathfinderRPG/prd/classes/monk.html#monk)http://paizo.com/pathfinderRPG/prd/classes/monk.html#monk
[11:30] <Nuance> 8 & 15 are the ones that don't fit
[11:30] <@AndrewAAM> 2 attacks at 1st, 3 @ 6, 4 @ 8, 5 @ 11, 6 @ 15, 7 @ 16 - and we top there.
[11:32] <henkslaaf> monk uses level as bab for flurry, -2 because it is like TWF
[11:32] <@AndrewAAM> Base-2/Base-2/Base-7/Base-7/... so -5 to the next attacks like regular iteration, only doubles.
[11:32] <henkslaaf> the table is only for convenience
[11:32] <Nuance> If you've got general list processing, you can derive that from the standard progression
[11:32] <@AndrewAAM> yeah, complicated as always
[11:32] <@AndrewAAM> Hi Doug
[11:33] <henkslaaf> so it is actually just MonkLVL - 2
[11:33] <@AndrewAAM> Anyways, I'm hoping the FP can handle those iterations
[11:33] <Nuance> You build the list of standard attacks, then list process it to subtract 2 from each element
[11:33] <Distant_Scholar> Hello, each.
[11:34] <Nuance> then you build a new list that adds two entries for each entry. Then you pick the number you're supposed to have at this level.
[11:34] <Nuance> from the start of the list
[11:34] <@AndrewAAM> Yup, so the fun part - telling pcgen how many attacks are allowed, and then deriving the correct values for each attack
[11:35] <@AndrewAAM> Meeting starts in 25 minutes Doug, just some prelim talks
[11:35] <Nuance> really really easy if you have lst processing, really quite hard if you don't
[11:36] <@AndrewAAM> I'm hoping we can snag Tom for this meeting. He's the keystone of knowledge to what we can accomplish with the system
[11:36] <Nuance> so, anyway. Either the general java code, or the output token needs to know which variables we think are part of an attack sequence.
[11:36] <@AndrewAAM> The LIST was the newest tidbit.
[11:37] <@AndrewAAM> APPLY was a fun one... that was for dealing with NON_STACKING_BONUSes
[11:38] <Nuance> yes, there are lots of subtleties in that as well
[11:39] <@AndrewAAM> Were you able to look at the rest of the page? The Attack sequence was an after thought I put in there... pretty much as soon as I come up with an idea I'm jotting it down to not lose it.
[11:40] <Nuance> yes, I read the rest of it
[11:40] <@AndrewAAM> And another fun fact, if Tom's syntax is true - we can re-use names with different VARTYPE designations
[11:41] <Nuance> different namespaces. Cool.
[11:41] <Nuance> If that's true then we should be able to reuse between GLOBAL and local
[11:41] <@AndrewAAM> Again, still unconfirmed, but his syntax indicates it is the case
[11:41] <@AndrewAAM> No, Local and Global cannot reuse
[11:41] <Nuance> as long as we have a prefix to disambiguate
[11:42] <@AndrewAAM> since the MOD uses the TYPE=NAME designation
[11:42] <Nuance> g:myvar vs. l:myvar
[11:42] <@AndrewAAM> Tom was clear he wasn't allowing re-use between Global and local to avoid confusion
[11:42] <Nuance> He probably won't go with TYPE there,
[11:42] <Nuance> A reasonable enough reason to disallow
[11:43] <@AndrewAAM> Yeah, the logic is sound
[11:43] <Nuance> We probably aren't allowed : or ; in variable names though
[11:44] <@AndrewAAM> With that in mind though, we can have "MOVEMENT", "AC", and other types we wish to track apart from our normal var
[11:44] <Nuance> too many : in LST already
[11:44] <@AndrewAAM> We can use _ and .
[11:44] <@AndrewAAM> underscore and period
[11:44] <Nuance> yep
[11:44] <@AndrewAAM> I've asked if 'spaces' would be permissible
[11:44] <Nuance> Do we ahve a definitive list of allowed chars?
[11:45] <@AndrewAAM> Not yet, no. I imagine it's the same as before though
[11:45] <@Zaister> Good evening
[11:45] <Nuance> I think we should disallow all the maths operators +,-, *, / & %
[11:45] <@AndrewAAM> We add periods so "AC.Natural" would be legal
[11:45] <@AndrewAAM> absolutely
[11:45] <@AndrewAAM> Hi Zaister
[11:45] <@Zaister> Hm i’m not sure if allowing periods here is a good idea, because it has different meaning in other tokens
[11:45] <Nuance> Hi Zaister
[11:45] <@AndrewAAM> period is legal per Tom
[11:46] <@Zaister> I know
[11:46] <@Zaister> but since its usually a separator, I don’t think that's a good idea
[11:46] <Nuance> yeah - is legal in the current scheme. Which is an insanely bad idea.
[11:46] <@AndrewAAM> Where would it be used to cause conflict?
[11:47] <@Zaister> not necessarily conflict, but er’re used to see that the period separates two similar things, such as TYPEs
[11:47] <@Zaister> *things
[11:47] <@AndrewAAM> TYPEs are not used in vars. :P
[11:47] <@Zaister> I know
[11:47] <@Zaister> that’s not the point
[11:48] <@Zaister> but everywhere else in PCGen the period is a separator
[11:48] <@AndrewAAM> <usealternatedamage>${pcstring('VAR.UseAlternateDamage.INTVAL')}</usealternatedamage>
[11:48] <@AndrewAAM> like there?
[11:48] <@Zaister> yes
[11:48] <@AndrewAAM> Why didn't you say so. :P
[11:49] <@Zaister> now, it the Var name could contain a period, this couldn’t work
[11:49] <@Zaister> I think I did say that
[11:49] <@AndrewAAM> Okay, we discuss whether that can still be valid
[11:49] <Nuance> Isn't that going away?
[11:49] <@AndrewAAM> I don't know.
[11:50] <Nuance> Taht's asking the variable resolution system for the value of a variabel as an integer
[11:50] <@AndrewAAM> pcstring and pcvar are freemarker, and how it interacts could be different
[11:50] <@Zaister> freemarker also ues the period as an operator I think
[11:50] <@AndrewAAM> We haven't seen any OS syntax from Tom yet.
[11:51] <@Zaister> I mean the normal Freemarker code
[11:51] <@AndrewAAM> I don't know.
[11:51] <@AndrewAAM> <flat>${pcstring('AC.Flatfooted')}</flat>
[11:51] <@Zaister> such as pcstring(something).number
[11:51] <Nuance> Our current output tokens use the jep system to derive a lot of their data
[11:52] <@AndrewAAM> yup
[11:52] <Nuance> if we're losing jep, we're going to have to replace them too.
[11:52] <@AndrewAAM> which means different syntax I'd imagine
[11:52] <Nuance> probably, although now necessarily
[11:52] <@AndrewAAM> <flat>${pcstring('AC.Flatfooted')}</flat> <-- will have to change
[11:52] <@Zaister> Anyway, I think variable names should not be allowed to use symbols that are used as operators in other parts of the program.
[11:52] <@Zaister> *think
[11:53] <Nuance> I agree
[11:53] <@AndrewAAM> since AC.Flatfooted might not exist
[11:53] <Nuance> It leaves us symbol poor though
[11:53] <@Zaister> I am also opposed to spaces in variable names
[11:53] <@AndrewAAM> Yeah, the only symbol it leaves is underscore
[11:54] <Nuance> what about $, ^ & £ where are they used?
[11:54] <Nuance> oh and !
[11:54] <@AndrewAAM> $ is freemarker code
[11:54] <@AndrewAAM> ! is opposite for PRExxx
[11:54] <PapaDRB> While I am not a Java coder, I did do a bloody lot of tool coding (Rexx on the host) and I agree with Zaister. Get rid of all symbols in names except the underscore.
[11:54] <@AndrewAAM> && is math
[11:54] <@Zaister> ! is an operator, yes
[11:55] <@AndrewAAM> pound is not a common key for the US folks
[11:55] <Nuance> oh well & is a perl and c operator too
[11:55] <@Zaister> What would we need symbols in variable names for anyway?
[11:55] <Nuance> It's right above our 3
[11:55] <@AndrewAAM> caret is for powers but I don't think it's used
[11:55] <Nuance> not sure it's on German keyboards either, I doubt it
[11:55] <@AndrewAAM> # is out pound
[11:55] <@AndrewAAM> our
[11:56] <@AndrewAAM> 2^4 = 2*2*2*2
[11:56] <@AndrewAAM> That'd be useful for the equipment mods
[11:56] <@Zaister> i don’t care about operatores outside of PCGen
[11:56] <Nuance> yeah, I know. I have a US keyboard sitting here.
[11:57] <@Zaister> just as long as s´the symbol does not have another meaning in PCGen
[11:57] <@AndrewAAM> 2000*(PLUSHEAD^2)
[11:57] <Nuance> Yep, there it is. it's a jep operator
[11:57] <@Zaister> ah ok
[11:58] <Nuance> But jep is going away
[11:58] <Nuance> Can we make a not to ask TOM if he's intending to add Power as an OPERATOR
[11:59] <Nuance> to the new system
[11:59] <@AndrewAAM> I imagine we'll have a few pages of questions for Tom after this meeting :)
[11:59] <Nuance> we don't really need it for that we can do 2000*PLUSHEAD*PLUSHEAD
[12:00] <Nuance> hi Barak
[12:00] <@AndrewAAM> True, but I'm sure there are other systems that might use Powers
[12:00] <@AndrewAAM> Trust a publisher to do something like that.

Meeting

[12:00] <@AndrewAAM> Hi Barak
[12:00] <Nuance> I got 8
[12:00] <@Zaister> Hi Barak
[12:01] <Barak_> Hey. Got a couple minutes so I thought I'd drop in.
[12:01] <@AndrewAAM> I've got 12, so let's get started
[12:01] <PapaDRB> Yup, 1500 here.... Lets go

Intro

[12:01] <@AndrewAAM> Welcome everyone to our Data team meeting. Our agenda of items today are:
[12:01] <@AndrewAAM> GIT/GITHUB and us!
[12:01] <@AndrewAAM>
[12:01] <@AndrewAAM> NewSource is doing well, and proves to be a good test bed
[12:01] <@AndrewAAM> Workflow - What is that?
[12:01] <@AndrewAAM> Upcoming Architecture/Code Work
[12:01] <@AndrewAAM> JEP replacement Formula Parser (This is a major discussion!)
[12:01] <@AndrewAAM> FACT/FACTSET - this goes hand-in-hand with the JEP replacement
[12:01] <@AndrewAAM> Documentation
[12:01] <@AndrewAAM> XML project revival! Having a full fledged content per tag/token is a wonderful idea and I think we should revisit this project.
[12:01] <@AndrewAAM> FACT/FACTSET & JEP Replacement impact on Documentation. I would like to consider the Core hidden set per game mode to house the items, and think extracting that for documentation might be beneficial for the data team and possibly homebrewers - thoughts?

Github

[12:02] <@AndrewAAM> Item #1 - GIT/GITHUB
[12:02] <@AndrewAAM> Our plan is to migrate December 20th and reopen on December 21st (add a day if you're in Australia)
[12:03] <@AndrewAAM> Right now we have at least two repos planned for the migration: pcgen (the development folders) and the second is "everything else"
[12:03] <@AndrewAAM> everything else will likely end up in either pcgen-archive or it's own project, like prettylst.
[12:04] <@AndrewAAM> I started a wiki to document proper workflow procedures and commit practices.
[12:04] <@AndrewAAM> That is here: (Link: http://wiki.pcgen.org/GITHUB_and_proper_procedures)http://wiki.pcgen.org/GITHUB_and_proper_procedures
[12:05] <@AndrewAAM> Questions, comments or concerns about GIT and GITHUB?
[12:06] <Nuance> I've read it again and it makes sense to me this time. It sisn't the first time I read it.
[12:06] <Distant_Scholar> I understand the concept, but I'm still wrapping my head around how we're using it.
[12:07] <@AndrewAAM> Fair enough. I tried to cater to beginners and make it easy to understand without rewriting an entire GIT faq which are available everywhere online.
[12:07] <@Zaister> it might make sense to split up the „everything else“ some more.
[12:07] <Nuance> what's in "everything else"
[12:08] <Barak_> Seems to make sense. Guess I should get a GitHub account set up and a client. :p
[12:08] <@AndrewAAM> The rest of the top level trunk items
[12:08] <@Zaister> probably
[12:08] <@AndrewAAM> Content (except NFD), Architecture, etc.
[12:08] <@Zaister> what is architecture?
[12:08] <@AndrewAAM> It houses the utilities we use and text editors
[12:08] <@Zaister> as a file tree
[12:08] <@Zaister> wait, data and OS are not part of the main dev repo?
[12:08] <@AndrewAAM> .project; arch-5.16.0.0.tex
[12:09] <Nuance> The website certainly should get its own repo
[12:09] <@AndrewAAM> data and os are part of the main repo - that's everything in trunk/pcgen
[12:09] <@Zaister> then what’s in Content?
[12:09] <@AndrewAAM> we're talking top level that isn't pcgen
[12:09] <@Zaister> ah ok
[12:10] <@AndrewAAM> cmp conversion project, default monster validator, extras, mothballed data, outofcycledatasets, publisher source materials (i.e. srds)
[12:11] <@Zaister> some of those we might not even need to migrate
[12:11] <@Zaister> cmp stuff? what for?
[12:11] <@AndrewAAM> it was an old project that is obsolete now
[12:11] <@AndrewAAM> basically allow their data to talk with ours
[12:11] <@AndrewAAM> mainly the vars mismatched
[12:11] <@Zaister> yeah but we’re not doing any more work there, right?
[12:12] <@AndrewAAM> nope, as I said obsolete
[12:12] <@Zaister> the we don’t need it in the new repo
[12:12] <Nuance> no need to migrate it them. It will still exist in SVN
[12:12] <@AndrewAAM> right
[12:12] <@Zaister> ok
[12:13] <@AndrewAAM> I think James wanted an archive just to be safe, like a histories of sort
[12:13] <@Zaister> hm
[12:13] <Nuance> then it should be in its own repo
[12:13] <@Zaister> yes
[12:13] <@Zaister> that would also reduce repo size
[12:14] <@AndrewAAM> repos we have/are considering - pcgen, newsources, prettylst, web, utilities, archive-x
[12:14] <Nuance> hi Mark
[12:14] <@AndrewAAM> make sense?
[12:14] <@AndrewAAM> Hi Mark
[12:14] <Nuance> yes, well to me anyway
[12:14] <mjmeans> Hi. Other plans fell through. So I'm here
[12:15] <@AndrewAAM> So, other than splitting up the main svn into smaller repos, any other questions about workflows or what we have to help people get started?
[12:16] <Distant_Scholar> I'd like to run through the procedure to make sure I'm understanding it correctly...
[12:16] <@AndrewAAM> sure
[12:16] <@Zaister> what’s the reason to break out prettylst from the rest of the utilities?
[12:16] <@Zaister> hi Mark
[12:17] <Distant_Scholar> First, do this once (per repo): fork the official repo, "clone" it to my local computer, sync my fork to the official repo
[12:17] <@AndrewAAM> we actively use and update it, it has it's own jira tracker... so it seemed to be efficient.
[12:17] <Distant_Scholar> Then, occasionally re-sync with main fork.
[12:18] <@AndrewAAM> DS, yes. That sounds about right
[12:18] <Distant_Scholar> To work on a feature: check out a branch (using the feature name from JIRA), make changes, commit to the branch, and eventually create a pull request to get it into the main repo.
[12:18] <@AndrewAAM> Let me explain how it works and Henk can jump in with corrections
[12:18] <@Zaister> AndrewAAM: ok then
[12:20] <@AndrewAAM> You fork to create a remote copy that you control (it's yours). You clone the remote locally to edit and play with. When you want to share your work you push that work to the fork. Then you do a PR. In between the push and editing you can do a lot of fun things. But I would emphasize that you should always endeavor to keep your local in sync with the upstream to make sure your changes both WORK and can merge.
[12:21] <mjmeans> Keeping in sync with upstream is strongly recommended.. almost a MUST do.
[12:21] <@AndrewAAM> There is some confusion on how to do that, but UPSTREAM = parent of fork
[12:22] <@AndrewAAM> You can add remotes and make the parent a remote and PULL into your local. Which is what I recommend people use.
[12:22] <Distant_Scholar> I don't understand most of the important words in that sentence. :-)
[12:22] <PapaDRB> me too
[12:23] <@AndrewAAM> I can show you a video if that might help. :)
[12:23] <@AndrewAAM> Henk, you want to jump in?
[12:23] <Nuance> Where do we add the remote, to the fork or the local copy?
[12:23] <@AndrewAAM> Remote is added to your GIT client
[12:23] <@Zaister> to the local copy
[12:23] <@AndrewAAM> Let me clarify terms
[12:23] <mjmeans> When the migration occurs, if there are significant obsolete (will probably never be used again), then those things should be in a third repo. No need to anyone to pull that down for any normal work. It would be very rare if anyone would ever need obsolete projects, but nothing should ever be discarded.
[12:24] <@AndrewAAM> REMOTE = anything not local
[12:24] <mjmeans> to add a remote you "git remote add (Link: https://github.com/PCGen/pcgen)https://github.com/PCGen/pcgen"
[12:24] <@Zaister> correct @ mark
[12:24] <mjmeans> When you make your local clone, the remote named "origin" will already be set to your github.com/myusername/pcgen
[12:25] <@AndrewAAM> LOCAL = anything on your computer that you can directly edit. This is where you do all the work. You can pull changes from ANY remote. You can only PUSH changes to remotes you control (i.e. your FORK).
[12:25] <mjmeans> Actually, "git remote add upstream (Link: https://github.com/PCGen/pcgen)https://github.com/PCGen/pcgen"
[12:26] <Nuance> yes, you need to give the remote repository a name
[12:26] <Nuance> upstream in Mark's case
[12:26] <@Zaister> mjmeans: most here will probably not use the command line
[12:27] <@AndrewAAM> TortoiseGIT and SourceTree both have remote management in their options.
[12:27] <Distant_Scholar> The "git remote add" command needs only be done once (per repo), yes? Never again?
[12:27] <@Zaister> yes
[12:27] <@Zaister> once per clone
[12:28] <mjmeans> The confusion of git is that there are actually three levels... the main project is at githib.com/PCGen/pcgen and is called remote "upstream"... your fork of the project is at github.com/yourname/pcgen and is called "origin"... and your local copy on your hard drive. These do not automatically stay in sync, and that's what has to be covered in the wiki.
[12:28] <@Zaister> mjmeans: that’s more a Github thing then a general git thing.
[12:29] <@AndrewAAM> Yes, you are in control of when things enter or leave your repository in git. As it should be.
[12:29] <Nuance> maybe, but it's the way we're going to use it and is probably the only way the folk confused are ever going to use it
[12:29] <mjmeans> The Github for Windows client will automatically name syncing to origin, but you have to drop to a command line to sync to upstream.
[12:29] <@AndrewAAM> We'll add those instructions to the wiki.
[12:30] <PapaDRB> Can you add instructions on how to copy (clone) pcgen/pcgen to myname/pcgen (and same for newsources)?
[12:30] <mjmeans> "name" ^^ handle
[12:30] <PapaDRB> and same thing from myname/pcgen to local/pcgen?
[12:30] <@Zaister> AndrewAAM: I’ve added some detail to the Wiki page about the linux client
[12:30] <@AndrewAAM> Thanks
[12:31] <Nuance> @mjmeans I think that's why we aren't recommending the windows github client
[12:31] <@Zaister> From my friends I’ve heard that it sucks
[12:32] <@AndrewAAM> Yes, that's exactly the reason it wasn't a recommended program, because it causes more confusion. It's meant for only working on your own project, not big project collaboration
[12:32] <Barak_> Ok, that just cleared my confusion (I think)... there's actually THREE copies... the PCGEN projects main, my copy of that on the GitHub servers, and my copy on my HD. Do I have that right?
[12:32] <Nuance> I used it to clone the newsources repo. I haven';t gotten as far as making the local copy yet. Will probably use cygwin
[12:32] <@AndrewAAM> @Barak - Correct
[12:33] <@AndrewAAM> Any other questions about GIT/GUTHUB before we move onto the next major topic?
[12:33] <Nuance> nope
[12:33] <@Zaister> no
[12:34] <mjmeans> I'll offer some content for the WIki as well. Although Github for Windows is substandard as far ass features, it is the only open source client that completely shuts down when not in use. Both other projects either leave DLL's in memory or are closed source and as such have a potential for a security risk on the machine. Altantian (or whatever) is a commercial product and they have every incentive to keep it secure, but they also can be infil
[12:34] <@Zaister> I think I might try GitEye
[12:35] <@AndrewAAM> Okay, email recommendations and links to hel@pcgen.org and I'll get those included.
[12:35] <@AndrewAAM> help@pcgen.org
[12:35] <mjmeans> We might want a table of git clients in the wiki with columns for feature set and options
[12:36] <@AndrewAAM> okay, next topic:
[12:36] <@Zaister> There might be a table like that in wikipedia :)
[12:36] <@AndrewAAM> (there is)
[12:36] <Nuance> Then we should link to said table
[12:36] <@AndrewAAM> (We can link to it when we locate it...)
[12:36] <@AndrewAAM> ;)
[12:36] <mjmeans> :)

Formula Parser

[12:37] <@AndrewAAM> This one is the doozy project:
[12:37] <@AndrewAAM> Upcoming Architecture/Code Work
[12:37] <@AndrewAAM>
[12:37] <@AndrewAAM> JEP replacement Formula Parser (This is a major discussion!)
[12:37] <@AndrewAAM> FACT/FACTSET - this goes hand-in-hand with the JEP replacement
[12:37] <@AndrewAAM> Okay, before I dive in, has everyone had an opportunity to read the wikis?
[12:38] <Distant_Scholar> Probably not. :-)
[12:38] <@AndrewAAM> There is a LOT of information packed into those wikis, but our focus is what we as the DATA/OS team are planning on using the tools for.
[12:38] <@AndrewAAM> Let me give those links then
[12:38] <@AndrewAAM> (Link: http://wiki.pcgen.org/Formula_Parser_Conversion_-_Data)http://wiki.pcgen.org/Formula_Parser_Conversion_-_Data
[12:38] <mjmeans> no. i'll just lurk probably. I have no idea what FACT/FACTSET are
[12:39] <@AndrewAAM> everything I've compiled is there
[12:39] <@AndrewAAM> (Link: http://wiki.pcgen.org/Formula_Parser_Equip_Vars_Demo)http://wiki.pcgen.org/Formula_Parser_Equip_Vars_Demo
[12:39] <@AndrewAAM> is what we had tested and found worked. Has some general purpose syntax
[12:39] <@AndrewAAM> Older but still relevant - (Link: http://wiki.pcgen.org/Formula_Parser_Equip_Vars_Proposal)http://wiki.pcgen.org/Formula_Parser_Equip_Vars_Proposal
[12:40] <@AndrewAAM> This project is set to happen this cycle
[12:40] <@AndrewAAM> Now, to summarize:
[12:41] <@AndrewAAM> This is a complete JEP replacement - it will not interact with JEP. JEP is going bye-bye in a couple of cycles
[12:41] <@AndrewAAM> This system is also designed to replace the ENTIRE BONUS tag family
[12:42] <@AndrewAAM> BONUS:xxx|yyy
[12:42] <@AndrewAAM> becomes MODIFY:x|y|z
[12:42] <@AndrewAAM> or MODIFYOTHER:x|y|z
[12:42] <@AndrewAAM> MODIFY is the global, MODIFYOTHER is for local (and parts)
[12:43] <@AndrewAAM> It has three tiers
[12:43] <Nuance> Surely MODIFYOTHER is also where you want to modify say aspeel, for a feat
[12:43] <@AndrewAAM> GLOBAL - which is what our JEP is
[12:43] <@AndrewAAM> LOCAL - Spells or Equipment
[12:43] <@AndrewAAM> LOCAL.PART - A portion or part of a piece of equipment, like head of a weapon.
[12:44] <@Zaister> where does z come from?
[12:44] <@AndrewAAM> @Nuance - what was that last?
[12:44] <Distant_Scholar> @AndrewAAM: Do Abilities get local variables? Or Templates? Or ...
[12:44] <@AndrewAAM> X = Varname, Y = modifier, Z = formula
[12:45] <@Zaister> ok
[12:45] <Nuance> sorry, if you want to use a feat to modify something else a spell say, is that not also MODIFYOTHER?
[12:45] <@AndrewAAM> Yes, MODIFYOTHER is used for addressing a LOCAL
[12:46] <mjmeans> To clarify.. is this correct... MODIFYOTHER is used to modify a LOCAL of another ability, spell, item, whatever?
[12:46] <Nuance> what about the RACE modifying a feat? MODIFY or MODIFYOTHER?
[12:46] <@AndrewAAM> @ Distant_Scholar - Abilities/feats/templates are not local as far as I know.
[12:46] <@AndrewAAM> MODIFYOTHER is meant to change something on a specific item or group of items.
[12:46] <@Zaister> if the modied var is a local, you use OTHER
[12:47] <@AndrewAAM> @Zaister - correct
[12:47] <Barak_> MODIFYOTHER would be for the speed of a car (where you have several cars defined)
[12:47] <@AndrewAAM> Also correct
[12:48] <@AndrewAAM> @Distant_Scholar - feats aren't local by nature since they are unique. Any vars on them should be global.
[12:48] <Barak_> Unless you want to increase the speed of all cars, they you use MODIFY... or won;t modify work on a local var?
[12:48] <@AndrewAAM> MODIFYOTHER has an "ALL" option :)
[12:48] <Barak_> Ah! Cool.
[12:48] <Nuance> why OTHER, why not LOCAL?
[12:48] <Distant_Scholar> That's unfortunate. I was hoping to be able to have a "DC" or "Range" variable for an ability.
[12:48] <@AndrewAAM> Tom's term not mine -
[12:49] <@Zaister> because ths an other local, not a local of the current object
[12:49] <mjmeans> My grandson is coming over in a few minutes. When that happens I'll have to drop out. Sorry. ... One other question, will MODIFYOTHER be usable to modify the prerequisites of an ability?
[12:49] <@AndrewAAM> Only if it's based on a var. otherwise no.
[12:50] <@AndrewAAM> MODIFY and MODIFYOTHER are strictly the formula parser system.
[12:50] <mjmeans> Okay. then it can resolve to any numeric value, or string values as well, such as YES or NO or QUALIFY (for VISIBLE, etc).
[12:51] <Nuance> I think we're going to have trouble in the interim where we have both systems in place and no PRE to use the new MODIFY thingys
[12:51] <@AndrewAAM> PRENEQ and PREEQVAR are the PRExxx replacements
[12:51] <Nuance> all out PREVARs will break
[12:51] <Nuance> ah ok, scratch that then
[12:52] <@AndrewAAM> Probably should modify those to PREGVAR and PRELVAR for GlobalVAR and LocalVAR
[12:52] <@AndrewAAM> or something other than EQuipment and NonEquipment
[12:52] <@AndrewAAM> :P
[12:52] <Nuance> so, to recap on @Zaister's point. MODIFY can modify a local if it's on the same instance?
[12:53] <@AndrewAAM> As I understand it MODIFY is only global
[12:53] <@AndrewAAM> I could be mistaken.
[12:54] <Nuance> @Zaister is that understanding too?
[12:54] <Nuance> your! your understanding
[12:54] <@Zaister> I’m not sure
[12:54] <@Zaister> but it would make sense
[12:55] <@AndrewAAM> For now, if it's global I'd recommend MODIFY. If it's local use MODIFYOTHER.
[12:55] <Nuance> ok, something to clear up later then
[12:55] <@AndrewAAM> Yes, a Tom note.
[12:56] <mjmeans> Will there be an equivalent of .CLEAR on MODIFY so that another source can completely replace the MODIFY of an ability in a .MOD or .COPY?
[12:57] <@AndrewAAM> I have not seen any mention of .CLEAR
[12:58] <mjmeans> In the case of an ability with more than one MODIFY, will there be a way to symbolically name them so that a later .MOD can alter just that single MODIFY?
[12:58] <@AndrewAAM> If you have an ability completely wiping another, then it's a newer source and you can just write the new one which will ignore the older ability.
[12:59] <@AndrewAAM> I also am not aware of making any symbolic modify naming.
[13:00] <@AndrewAAM> Now, something we're going to also be replacing is most of the tags that are affected by BONUS. For instance "REACH", "SR", "CR" items that have actual tags but become redundant by the new system.
[13:00] <@AndrewAAM> This also includes MOVE, and most of the Equipment tags.
[13:01] <mjmeans> Let me provide a real-world example in Pathfinder... Weapon Finesse. A class grants Weapon Finesse, but only for light piercing weapons. So in principle the feat is still the feat, weapon fineesse, but it's MODIFY has to be changed. And I'm hoping for a way to implement these kind of things without having to go back into a released books to add supporting PRE's to make the later source work.
[13:02] <@AndrewAAM> Uh, then it's not granting the Feat, it's granting a class feature that acts almost like Weapon Finesse
[13:02] <mjmeans> Possibly not the best example
[13:03] <mjmeans> But my point is that it would be nice to have a framework that will minimize or eliminate the need to ever modify a released stable source.
[13:03] <@AndrewAAM> In that example you would use your own MODIFYOTHER to grant the bonus and use the APPLY method to avoid stacking with the Weapon Finesse bonus
[13:04] <@AndrewAAM> In your example there is no reason to re-write the original
[13:05] <Nuance> Does each individual weapon have its own TOHIT values?
[13:05] <Nuance> Hmm, I suppose it must
[13:05] <@AndrewAAM> Yes. Each weapon will have their own tohit values,
[13:05] <@AndrewAAM> and CRITMULT, CRITRANGE, HP, HARDNESS, RANGE, etc.
[13:06] <Nuance> Nice. have we thought about how to do power attack under this system?
[13:06] <@AndrewAAM> TEMPBONUS has not been brought up in discussion yet, but is on my list :)
[13:06] <Nuance> :)
[13:07] <@AndrewAAM> I imagine it'll continue in some form
[13:07] <@AndrewAAM> as we need a method to trigger conditional modifiers
[13:08] <@AndrewAAM> Questions so far?
[13:09] <mjmeans> yes
[13:09] <mjmeans> If the main focus of PCGen is to create a character sheet, why do we need TEMPBONUS?
[13:09] <mjmeans> Not really on topic, but...
[13:10] <@Zaister> because you might want sheets with certain abilities activated
[13:10] <@Zaister> such as rage, or long lasting spells
[13:10] <mjmeans> ok
[13:10] <@AndrewAAM> it caters to those who want those extra sheets.
[13:10] <mjmeans> I really do see a purpose with GMGen, but I don't even think that is on the horizon.
[13:10] <Nuance> Some folk use it live at the table too
[13:11] <@Zaister> I have a player for example whose cleric always cast ant haul, greater magic weapon, magic vestment
[13:11] <@Zaister> it would make no sense not to include those in the sheet
[13:12] <Distant_Scholar> I have a player with a barbarian, and having both a with rage and without rage character sheet is extremely helpful.
[13:12] <@Zaister> exactly
[13:12] <mjmeans> and since they are not "permanent" abilities, they need some method to add/remove them without triggering the "reminders", etc. COuld be done other ways, but sure. No reason to change it at this point.
[13:12] <@Zaister> good
[13:12] <@AndrewAAM> Not enough developers to projects. But that is another discussion
[13:13] <mjmeans> ok, let's go on
[13:13] <@AndrewAAM> Syntax for Var naming. For now I am using the dreaded "Period" if it isn't practical we swap out for an Underline.
[13:13] <@AndrewAAM> As was discussed premeeting the vars can have different vartypes
[13:14] <Nuance> Sorry, just before we move on can I ask a question
[13:14] <@AndrewAAM> @Nuance - yes?
[13:15] <Nuance> My point about power attack was that it adds different bonuses when you use it one handed or two handed. It behaves like a strength mod in that case. AFAIK we don't modify our output sheets for this properly currently. Will the new system handle this?
[13:16] <@Zaister> Nuance: the pathfinder set has multiple PA temp abilities to cater to that
[13:16] <Nuance> We print a nice matrix of all the ways to use a weapon and the to-hit and damage
[13:16] <Nuance> One of the values in that matrix is wrong
[13:17] <@AndrewAAM> Assuming the DAMAGE is replaced in the system, I don't see why that can't be corrected.
[13:17] <Nuance> which one depends on whether you've applied a two-handed or a one ahnded bonus
[13:17] <@Zaister> true
[13:17] <mjmeans> Plus a two-handed weapon can be used in one hand when the PC is enlarged
[13:18] <@AndrewAAM> Not an apples to apples comparison
[13:18] <@AndrewAAM> @Nuance - yes, if DAMAGE is replaced by the system, then it would make sense to alter those values accordingly.
[13:19] <Nuance> ok then. sorry for the interruption, carry on
[13:19] <@AndrewAAM> @mjmeans - A PC can already use a weapon smaller than them with a penalty.
[13:22] <@AndrewAAM> Back to syntax - based upon this inclusion, and without Tom expressing saying otherwise, this means namespace can be reused as long as they are different types BUT not across scopes (Global/local)
[13:22] <@AndrewAAM> I plotted out common naming based upon just using VARs
[13:23] <@AndrewAAM> Assume period and underscore are interchangeable pending confirmation with Tom about this syntax
[13:24] <@AndrewAAM> So, we have the value called AC, it encompasses a whole slew of various modifiers
[13:24] <@AndrewAAM> AC should be the total value
[13:24] <@AndrewAAM> AC.Flatfooted
[13:24] <@AndrewAAM> AC.Touch
[13:24] <@AndrewAAM> AC.Deflection
[13:24] <@AndrewAAM> AC.Dodge
[13:24] <@AndrewAAM> etc.
[13:25] <@Zaister> are these to be separate tokens or is it intended as a tree-like structure?
[13:25] <@AndrewAAM> these are global in nature and any feat or class feature should use MODIFY:AC.Deflection|SOLVE|CHA+3
[13:25] <Nuance> those aren't tokens they're vars
[13:25] <@AndrewAAM> Those are vars, they'll be housed in a central file
[13:25] <@Zaister> yeah sorry, meant to say vars
[13:26] <@AndrewAAM> Each var must be set in the file before it can be used.
[13:26] <@Zaister> but it’s basically coincidence they all begin with AC
[13:26] <@Zaister> they could have any name, right?
[13:26] <@AndrewAAM> Yes
[13:26] <@Zaister> ok
[13:27] <@AndrewAAM> Using standard naming we want to establish what a var does
[13:27] <@AndrewAAM> GLOBAL:VAR|AC.Deflection <> EXPLANATION:This sets the total value for the Deflection value for AC.
[13:28] <@AndrewAAM> I'm using AC since AC=Armor Class and the short term is AC.
[13:28] <@AndrewAAM> We have several types of AC so using a common connective makes sense AC.x or AC_x
[13:29] <@AndrewAAM> We could use the same for movement -
[13:29] <@AndrewAAM> MOVE.Walk vs. Walk
[13:29] <@AndrewAAM> However, the discussion is what standards do we want to use?
[13:30] <@AndrewAAM> We want to be consistent in our application across any given gamemode
[13:30] <@AndrewAAM> Realizing each gamemode gets its own standards
[13:31] <henkslaaf> sorry, had an emergency, had to go afk
[13:31] <@AndrewAAM> @henkslaaf - no worries
[13:31] <@Zaister> I’d say from general on the left to specialized on the rright
[13:31] <henkslaaf> guess I missed the whole thing?
[13:31] <Nuance> In that case we'll need to document the gamemode specific standards for each gamemode
[13:31] <@AndrewAAM> Yes, we will
[13:31] <@AndrewAAM> which is why the next topic was documentation standards
[13:32] <Nuance> I agree with Zaister
[13:32] <@AndrewAAM> luckily the file holds explanation for our review
[13:32] <@AndrewAAM> So, General which is what I'm using and specialization on right. Excellent :)
[13:32] <@AndrewAAM> For the folks following along this means AC is a generalization but Deflection is a specific
[13:33] <@AndrewAAM> AC.Deflection or AC_Deflection
[13:33] <Nuance> How many of the variable defining files will there be? are they all gamemode, or do we have source specific ones?
[13:34] <@AndrewAAM> I'm planning on ALL vars being in one file housed in the core set
[13:34] <@AndrewAAM> reasoning: removes chance for re-use by accident
[13:34] <Nuance> Hmm, does that mean chimp level access to work on any source?
[13:35] <@Zaister> what about vars defined by other sources?
[13:35] <@AndrewAAM> No, actually, since GITHUB allows PRs
[13:35] <Nuance> Otherwise I can't define new variables
[13:35] <@AndrewAAM> We can allow defines in newsources and then move them to the core
[13:35] <@Zaister> I think each source should be allowed to define it’s own variables, such as for feats
[13:36] <@Zaister> why should these definitions be loaded with the core for a huge number of sources that aren’t used actually?
[13:36] <Nuance> One file makes it easier to ensure they are unique
[13:36] <@AndrewAAM> We have a few items here so let me address them
[13:37] <@Zaister> doesn’t make sense for me for the core to contain vars that are only needed, for example, when you use occult Adventures
[13:37] <@AndrewAAM> 1) Core Files are allowed to be altered by non-chimps due to PRs since I'm going to review all PRs before accepting them.
[13:38] <@AndrewAAM> 2) We want a central location to house the variables so we know they are unique and what they do. They can be defined in additional sources, and from Tom, they won't hit performance till they are used.
[13:39] <@AndrewAAM> 3) Central means able to document them and with the EXPLANATION tag we can even declare their sourcebooks.
[13:39] <@Zaister> that makes it difficult to add homebrew sources
[13:40] <@AndrewAAM> EXPLANATION is a nonparsed token - basically a #COMMENT in lst parlance.
[13:40] <Nuance> Can we have more than one EXPLANATION tag, like with NAME:
[13:40] <mjmeans> Grandson is here gotta go.
[13:40] <Nuance> Surely the EXPLANATION is perfect for auto doc generation
[13:40] <@AndrewAAM> No, EXPLANATION is a one per line token, it will overwrite if found elsewhere
[13:40] <@Zaister> seem a bit verbose
[13:41] <Nuance> Can we revisit that, I think appending and .CLEAR is better functionality
[13:41] <@AndrewAAM> Yes, we can revisit that.
[13:42] <@Zaister> forcing vars for homebrew into a core file isn’t a good idea, I Think.
[13:42] <@AndrewAAM> @Zaister, homebrew is another beast and not relevant to the discussion
[13:42] <Nuance> I agree for homebrew, but for project standards, I don't see it as a problem
[13:43] <@AndrewAAM> Homebrewers are not held to our standards, and can define the vars anywhere they please
[13:43] <Nuance> As long as we CAN define them in other places, that has little bearing on whether we decide to put them all in one file
[13:43] <@Zaister> why is there a syntactical difference between an "official“ source and a "homebrew“? That doesn't make sense
[13:43] <@AndrewAAM> for our standards as a project though, the core file is the ideal housing location.
[13:43] <@Zaister> hm
[13:43] <@Zaister> I don’t like it
[13:43] <Nuance> There's not. There's a standard in place that homebrewers aren't forced to comply with
[13:44] <@AndrewAAM> The define file is a file that can be with ANY source.
[13:44] <@Zaister> All Pathfinder vars, all 3rd party stuff in one huge file?
[13:44] <Nuance> As long as it's just a standard, if it works out to be unwieldy we can always change it.
[13:44] <@AndrewAAM> We have a lot of variables. I actually like the idea of having a single location to find the var I want.
[13:45] <@AndrewAAM> We can have the files for each source, but the central one is easier to document and code from.
[13:45] <@Zaister> OK, well I can take all Paizo stuff in one file if necessary, but I’m very opposed to putting all kind of 3rd party stuff in there
[13:45] <@AndrewAAM> We can have a file in the core for each sourcebook if it really matters.
[13:46] <@AndrewAAM> var_uc.lst
[13:46] <@AndrewAAM> var_um.lst
[13:46] <Nuance> Then why not just have them with their sources?
[13:46] <@Zaister> if you have a file for each source, it makes no sense to keep them in the core
[13:47] <@AndrewAAM> Point is we want a gamemode wide standard that allows easy maintenance and avoids overlap
[13:47] <Nuance> Will the LST load tell us about duplicate defines?
[13:47] <Nuance> if it does we don't need them in one file.
[13:47] <@AndrewAAM> My thought was documentation can use the central file for having per gamemode defines
[13:47] <@Zaister> true
[13:47] <@Zaister> what about this
[13:48] <@AndrewAAM> as I understand it, duplicates do not get flagged
[13:48] <@Zaister> we keep the def files with their sources, and create a utility that can generate a global reference file
[13:49] <@Zaister> they should get flagged
[13:49] <Nuance> There should be exactly one place where a global is defined
[13:49] <Nuance> if there is more than one, that's an error and the lst load should flag it.
[13:49] <@Zaister> yes not flagging that is madness
[13:50] <Nuance> barring .MOD of course, which I think would be really useful
[13:51] <Nuance> but that's not a redefinition
[13:51] <@AndrewAAM> Uh, the define file is only the VAR and EXPLANATION
[13:51] <Nuance> Yeah, but if you allow appending then .MOD lets you split the tags across multiple lines
[13:52] <@Zaister> Why do we need a tag for comments? Hey not just go with „#“?
[13:52] <@AndrewAAM> Var sets the value to the default for that type, and EXPLANATION is only for explaining it. I don't see how .MOD is useful
[13:53] <Nuance> If you append multiple EXPLANATION tags then it's useful to be able to output those on separate lines
[13:53] <Nuance> if you don't then you don't need .MOD
[13:53] <@AndrewAAM> Okay, that's a change that needs to be run by Tom.
[13:54] <@AndrewAAM> @Zaister, for your reference file, are you offering to make that utility?
[13:54] <@Zaister> id the EXPLANATION tag used in anything or is it really just for comments?
[13:54] <@AndrewAAM> EXPLANATION is just for comments
[13:55] <Distant_Scholar> Comments and a potential auto-documenter.
[13:55] <@AndrewAAM> And I think it looks cleaner then
[13:55] <@Zaister> AndrewAAM: I can do that, yes
[13:55] <@AndrewAAM> # COMMENT: This does blah
[13:55] <@AndrewAAM> VAR
[13:55] <Nuance> If we're not using it, then we don't really need a tag, as @Zaister says
[13:55] <@AndrewAAM> #Comment
[13:55] <@Zaister> ah autodocument, makes sens
[13:55] <Nuance> var # this is my var
[13:56] <Nuance> is just as clear as
[13:56] <Nuance> var EXPLANATION:This is my var
[13:56] <@Zaister> if its used semantically, why not DESC?
[13:56] <Distant_Scholar> Are mid-line #s allowed in other LST files? [And if not, should they?]
[13:56] <@AndrewAAM> DESC is parsed
[13:56] <@AndrewAAM> # are not allowed midline
[13:56] <Nuance> yes, but we have code that does it already
[13:57] <Nuance> in modular form
[13:57] <@Zaister> but you want EXPLANATION to be parsed to?
[13:57] <Nuance> DESC is a plugin
[13:57] <Nuance> I'm presuming one plugin for any DESC in any file
[13:58] <Distant_Scholar> What does "parsed" mean in this context? Replacement of %1, and such?
[13:58] <@AndrewAAM> True, but then that means it's being run at LST load to not have % unbalanced parenthesis
[13:58] <@AndrewAAM> PARSED means it's loaded and tested
[13:58] <@AndrewAAM> unparsed means ignored
[13:59] <Distant_Scholar> Ah
[13:59] <@Zaister> wait you want a tag but one that’s not parsed?
[13:59] <@AndrewAAM> each token is run through a parse unparse cycle.
[13:59] <@Zaister> tag, not token
[13:59] <@Zaister> tokens are output sheets
[14:00] <@AndrewAAM> okay, tag, anyways, Tom made the EXPLANATION for just documenting the function cleanly on the line. Made it easy for documenting, later.
[14:01] <@Zaister> ok
[14:01] <@AndrewAAM> I don't see any value in having DESC on the var file.
[14:01] <@Zaister> I just meant instead of a new name, name ie it DESC because that’s what it is
[14:01] <@AndrewAAM> it's basically a developer cheat sheet for vars and what they are intended to do.
[14:02] <@AndrewAAM> We can ask Tom about it.
[14:02] <@AndrewAAM> I have 2 hours in, everyone still good or do we need to call it?
[14:02] <Nuance> I'm ok
[14:02] <Distant_Scholar> I'm ok
[14:02] <@Zaister> ok for me
[14:03] <@AndrewAAM> Okay, so let's re-hit the var file location really quick
[14:03] <@AndrewAAM> The first intention is make sure each var is unique
[14:04] <@AndrewAAM> I don't want Paizo source and 3rd party source using the same var and causing conflict with each other. This equals data bug and a pain for us
[14:05] <@Zaister> sure
[14:05] <@Zaister> thats why the parsed should flag duplicates in any case
[14:05] <@AndrewAAM> So, central spot is for developers to see what is used and why, and also for possible doc autogeneration
[14:05] <@AndrewAAM> and when would this check for dupes take place?
[14:05] <@Zaister> on load
[14:05] <@AndrewAAM> lst load?
[14:06] <@AndrewAAM> So, in order to catch a dupe I have to load every combination of sources?
[14:06] <@Zaister> when the var lst files are loaded, sure
[14:06] <@AndrewAAM> that's a poor design in my mind.
[14:06] <@AndrewAAM> it allows for too much error
[14:07] <Nuance> No
[14:07] <Nuance> The system should flag errors when it spots them
[14:07] <@Zaister> no it’S just a catch
[14:07] <@AndrewAAM> If I don't load Paizo source x with 3rd party z then we don't catch the dupe
[14:07] <Nuance> if you want to do a data review then @Zaister's application is a way better way to do that
[14:07] <@Zaister> not the one true var test
[14:07] <@Zaister> right, that app would also flag duplicates
[14:08] <Nuance> It should start at the root parse all the PCCs, separate them by gamemode and then find all the vars in this gamemode
[14:08] <@AndrewAAM> the intention is to avoid duplicates in the first place.
[14:08] <@Zaister> yeas sue
[14:08] <Nuance> You'd run it like you do with prettylst
[14:08] <@AndrewAAM> I like the idea of the app
[14:09] <@Zaister> but i just think it does not make sense for the core to now about each and every more or less obscure source
[14:09] <@AndrewAAM> will the app give me a nice compilation ?
[14:09] <@Zaister> *know
[14:09] <@Zaister> AndrewAAM: yes, that is the intent
[14:09] <Nuance> define "nice compilation"
[14:09] <@AndrewAAM> Game Mode header
[14:10] <@AndrewAAM> Variable name <> EXPLANATION
[14:10] <@AndrewAAM> line by line
[14:10] <@AndrewAAM> also, location should be there
[14:10] <@Zaister> some kind of sorting probably :)
[14:10] <Nuance> That should be trivial if you've already parsed the data
[14:10] <@AndrewAAM> Output to xml and htm :)
[14:10] <@Zaister> why not just text?
[14:10] <Nuance> now you're just being greedy
[14:10] <@AndrewAAM> Hey, go big right?
[14:11] <Nuance> so it can be part of the docs
[14:11] <@AndrewAAM> Txt is fine
[14:11] <@AndrewAAM> but an htm output would be easy for docs
[14:11] <@Zaister> yeah
[14:11] <@Zaister> should be easy to do
[14:12] <@AndrewAAM> Okay, so with the tool in mind, if you can deliver all that, then I'm fine with define vars per source book
[14:12] <@Zaister> Nuance: having PCGen create that from parsing would require to load all sources at the same time, might mot be a good idea.
[14:12] <@AndrewAAM> Tom might not like the change in behavior for the DEFINE catching dupes
[14:12] <Nuance> I'm not thinking PCGen, i was thinking perl
[14:13] <@AndrewAAM> since the define is always 0 or default value from the gamemode
[14:13] <@Zaister> Nuance:
[14:13] <@Zaister> ok
[14:13] <@Zaister> well not perl if I’m wring it :)
[14:13] <Nuance> yes, I can write it if you want
[14:13] <Nuance> perl, pythin (shudder), whatever
[14:13] <@Zaister> for me the shudder is for perl :)
[14:13] <Nuance> not. Absolutely NOT java
[14:14] <@Zaister> no
[14:14] <@Zaister> that should be scripted
[14:14] <Distant_Scholar> As long as it runs on my linux box.
[14:14] <@Zaister> Distant_Scholar: I run Linux too, I’m not creating anything that doesn’t work there :)
[14:14] <Nuance> I guarantee that your linux box can run perl and python
[14:14] <@AndrewAAM> Okay, program collaboration between Zaister and Nuance
[14:14] <@AndrewAAM> check
[14:14] <Nuance> and rex and bash and who knows how many other things
[14:15] <@Zaister> If I’d use the Language I use most, that’d be Tcl (shudder again), but I won’t subject anyone to that
[14:15] <@AndrewAAM> Any other questions about the formula parser?
[14:16] <@AndrewAAM> So, since we're writing the program will it be able to include FACT and FACTSET?
[14:17] <Nuance> probably
[14:17] <@Zaister> if that’s needed, why not

Intermission

[14:17] <Unicorn437> Someone in here that knows how to trick PCgen to allow me mystic theurge because I have spell like abilities that make me qualify?
[14:17] <@AndrewAAM> Let's put that in consideration, since our talk is going to hit on that.
[14:17] <@Zaister> sure
[14:17] <@AndrewAAM> Hi Unicorn437, we're currently conducting a meeting.
[14:17] <Nuance> yes, use a .MOD to >CLEAR the PREs
[14:18] <Nuance> sorry >CLEAR
[14:18] <Nuance> sorry .CLEAR
[14:18] <Nuance> then police the qualification yourself
[14:18] <@AndrewAAM> You can also click the preference BYPASS CLASS RESTRICTIONS
[14:19] <@AndrewAAM> and 6.4.1RC1 should have a patch to make Mystic Theurge work.
[14:19] <@AndrewAAM> I'll check on that after the meeting
[14:19] <@Zaister> it’s not just the Theurge
[14:19] <@Zaister> stupid FAQ ruling :)
[14:20] <Nuance> Arcane Trickster
[14:20] <Nuance> et al
[14:20] <@Zaister> any spellcaster PrC basically
[14:20] <@AndrewAAM> Yeah, I was waiting on someones newtag...
[14:20] <@Zaister> and feats
[14:20] <Unicorn437> In general I think this needs to be changed, but I'm not part of the coding crew (yet) :(
[14:20] <@AndrewAAM> Pretty much anything with SLAs
[14:21] <@Zaister> AndrewAAM: got that… :)
[14:21] <Nuance> did someone say a new soul for the soul jar? where's Kar when you need him?
[14:21] <@AndrewAAM> I miss Kar
[14:21] <Unicorn437> I think all that needs to be done is add SLA to the spell list on the appropriate level
[14:21] <Distant_Scholar> And "the appropriate level" causes all kinds of arguments ...
[14:22] <Nuance> @Zaister had a proposal for a new SPELLS tag that would be just peachy
[14:22] <Unicorn437> well darkness clearly is a 2nd level spell, so the SLA should be as well
[14:22] <@Zaister> yeah Tom had some reservations that aren’t totally cleared I think
[14:22] <Nuance> ... but that's another meeting
[14:22] <@AndrewAAM> @Zaister had a tag to handle it but hasn't followed up on it...
[14:22] <@AndrewAAM> Anyways, yes, that is another meeting completely.
[14:22] <@Zaister> I’ll get back for that for 6.5.x
[14:22] <@AndrewAAM> Let's get back on topic though.
[14:23] <@Zaister> ok

Fact & FactSet proposal and Standards

[14:23] <@AndrewAAM> Did everyone look at the FACT and FACTSET new tag proposal?
[14:23] <Nuance> a long time ago when it was mooted
[14:23] <Nuance> not recently
[14:23] <@AndrewAAM> It's pretty much a Data Team create your own tokens
[14:24] <@AndrewAAM> We dictate what file, whether it is usable as part of PRExxx and outputs to the OS.
[14:24] <@AndrewAAM> FACT is a single item, FACTSET is more than one item
[14:24] <@Zaister> hm
[14:25] <@AndrewAAM> Both allow you to determine whether the new "
[14:25] <@AndrewAAM> tag" is required or not
[14:25] <Nuance> so, PFS character number for instance.
[14:25] <@AndrewAAM> This eliminates a good portion of data>code escalation
[14:25] <@AndrewAAM> Yes
[14:26] <@AndrewAAM> However, probably not a good example
[14:26] <Nuance> no need to get someone to explicitly code it up
[14:26] <Nuance> why so
[14:26] <@AndrewAAM> since I don't know if the UI can interface with it.
[14:26] <Nuance> then it totally needs to
[14:26] <Nuance> :-)
[14:26] <@AndrewAAM> You can add that to the Tom list.
[14:26] <@AndrewAAM> :P
[14:26] <Nuance> otherwise we can't do PFS number
[14:27] <Nuance> :-p
[14:27] <@AndrewAAM> As I understand the "FACT" is a static value
[14:27] <@AndrewAAM> Examples of it
[14:27] <@Zaister> well the list in the center bottom is dynamic, something like that could get in there
[14:27] <@Zaister> *of the main window
[14:28] <@AndrewAAM> What list is this?
[14:28] <Nuance> I think the summary
[14:28] <@Zaister> the ine with AC, Saves, and so on
[14:28] <Nuance> yeah, that
[14:28] <@AndrewAAM> @Nuance - why not make an ABILITY with a CHOOSE:USERINPUT and use ASPECT:Whatever|%1|%LIST to display your number?
[14:29] <@AndrewAAM> That's actually each
[14:29] <@AndrewAAM> easy
[14:29] <Nuance> I usually just type in into the name file RAven 22479-1
[14:29] <Nuance> does me just fine
[14:29] <@Zaister> dont we have custom fields on description?
[14:30] <@AndrewAAM> I could add the PFS number after the name... did I mention easy?
[14:30] <@AndrewAAM> Yes, we do
[14:30] <@AndrewAAM> Our PFS players like uniformity though.
[14:31] <Nuance> what was the discussion here?
[14:31] <Nuance> I think I derailed it with PFS number
[14:31] <Distant_Scholar> Could you give an example of an excellent use of FACT and FACTSET?
[14:32] <@AndrewAAM> yes, one sec
[14:32] <@AndrewAAM> (Link: http://wiki.pcgen.org/FACT_Token)http://wiki.pcgen.org/FACT_Token
[14:32] <Nuance> is Diety a good example of a FACT?
[14:32] <@AndrewAAM> (Link: http://wiki.pcgen.org/FACTSET_Token)http://wiki.pcgen.org/FACTSET_Token
[14:33] <@Zaister> deity!
[14:33] <@AndrewAAM> FACTDEF:DEITY|Align <> DATATYPE:ALIGNMENT <> VISIBLE:YES <> SELECTABLE:YES
[14:33] <@AndrewAAM> FACTSETDEF:DEITY|Pantheons <> DATATYPE:STRING <> VISIBLE:EXPORT
[14:34] <@Zaister> hm
[14:34] <@AndrewAAM> one sec grabbing food...
[14:34] <@AndrewAAM> erm I mean brb
[14:37] <@AndrewAAM> Okay, so do we want the FACT define file central or by source?
[14:37] <@AndrewAAM> I feel central is likely best, but there are cases where there may be a single source that would need a one-off
[14:37] <@Zaister> well if the purpose of FACT is for a source to createe its own tags...
[14:38] <@AndrewAAM> and no, I don't know what happens with dupes
[14:38] <@AndrewAAM> If a third party makes FACTDEF:Clowns required then it's applied to ALL sources
[14:38] <@Zaister> hm
[14:39] <@AndrewAAM> not just the single source, so that is a consideration
[14:39] <@Zaister> hat might not be a good idea
[14:39] <Distant_Scholar> I'm still not sure what FACT/FACTSET actually do. Could you give a full example of one in use?
[14:39] <@AndrewAAM> Sure
[14:39] <Nuance> If you're using Ultimate Clown then FACTDEF:Clowns might be required
[14:40] <@AndrewAAM> Say I have a new deity category I want called Vestments
[14:41] <@AndrewAAM> FACTSETDEF:DEITY|Vestments <> DATATYPE:STRING <> VISIBLE:YES <> REQUIRED:NO
[14:41] <@AndrewAAM> FACTSET:Vestments|Purple Outfit,Lavender Shoes
[14:41] <Nuance> The fact that these can make items mandatory kinda pushes for per source
[14:41] <@Zaister> So, REQUIRED:YES on this would break all other sources?
[14:42] <@Zaister> I think that would be a very bad idea
[14:42] <@AndrewAAM> Nuance - no, REQUIRED:YES means you must use it in the sources
[14:42] <Nuance> With a global file, pretty much
[14:42] <@AndrewAAM> You would use it in the single source, and not put REQUIRED:YES, this is for things that absolutely must be included in an entire gamemode
[14:43] <Nuance> So, if I have a global file with a FACTSET:Clowns required and I don't load Ultimate Clown then that's breakage right there.
[14:43] <@Zaister> and what exactly does VISIBLE.YES entail, visible where?
[14:43] <@AndrewAAM> If you don't have FACTSET:Clowns for every deity line, then yes, broken
[14:44] <@AndrewAAM> REQUIRED:YES means this is absolutely crucial to have in this gamemode
[14:44] <@Zaister> thats seriously bad design
[14:44] <Nuance> so, sparingly used
[14:44] <Nuance> Can only appear in the Gamemode
[14:44] <@AndrewAAM> @Zaister, it's good design, just really powerful for us
[14:45] <@Zaister> I’m not convinced
[14:45] <Nuance> Are FACTDEF and FACTSETDEF gamemode files?
[14:45] <@AndrewAAM> Formula Parser and FACT/FACTSET is giving the data team the power to dictate what belongs in the gamemode, and when to use it
[14:45] <@AndrewAAM> They are lst files, like everything else. And can be loaded by any source
[14:46] <Distant_Scholar> So, " FACTSETDEF:DEITY|Vestments <> DATATYPE:STRING <> VISIBLE:YES <> REQUIRED:NO" says one is now allowed to have a FACTSET:Vestments tag in a DEITY file? ...
[14:46] <Nuance> I think that if we're having mandatory items then they should be Gamemode things
[14:46] <@AndrewAAM> Also realize this is not just d20-ism game systems, this is for any new systems we make
[14:46] <Distant_Scholar> And, "FACTSET:Vestments|Purple Outfit,Lavender Shoes" goes in the DEITY file, saying what the Vestments are for this deity?
[14:46] <Nuance> otherwise a FACT or FACTSET is never REQUIRED:Yes
[14:47] <@AndrewAAM> REQUIRED:NO means you don't have to include it for every single in that file type
[14:47] <@AndrewAAM> That's why I feel this is best as a Core Set file
[14:47] <@Zaister> If means that a single source can break all others
[14:47] <@Zaister> *It
[14:47] <Nuance> Right, I'm saying that we hsould have two versions of this. One for GAMEMODE where REQUIRED is possible and one for ordinary LOST that never has REQUIRED.
[14:47] <@AndrewAAM> Yes, which is why I wanted the control by core
[14:48] <Nuance> I think this really is two different use cases and warrants two different files.
[14:48] <@AndrewAAM> I would disagree
[14:48] <@AndrewAAM> it's a simple coding standard
[14:48] <@Zaister> I’m still opposed of putting stuff possible needed only by obscure, 3rd party sets into the core
[14:49] <Nuance> Which of my arguments isn't compelling :-)
[14:49] <@AndrewAAM> REQUIRED:YES is not allowed for anything that isn't mandatory
[14:49] <Nuance> Anything that's mandatory is a Gamemode thing
[14:50] <@AndrewAAM> @Zaister - I'm fine with leaving piddly things in the original sets, hence my earlier "Can the program do FACT and FACTSET as well?"
[14:50] <@Zaister> what if its only mandatory if obscure source xyz is used?
[14:50] <@Zaister> AndrewAAM: if it needs to, sure
[14:50] <@AndrewAAM> Gentlemen, let's be clear on terminology
[14:51] <@AndrewAAM> MANDATORY is system wide, which is set by either gamemode or the gamemode core set
[14:52] <@AndrewAAM> REQUIRED:YES is the same power as anything else. Saying we can't trust our coders with it is a disservice
[14:52] <@AndrewAAM> We're here to discuss the standards of use and when... we set the goals and standards then everything else should be smooth sailing.
[14:53] <@AndrewAAM> the idea behind these tags and formula parser are to consolidate and give us better flexibility.
[14:53] <@Zaister> I’m just saying, the „core“ should be the Core Rulebook. Not really much more, anything else that needs to be global belongs in the game mode
[14:53] <@AndrewAAM> It's to do what we need for published books without begging code for it.
[14:54] <Nuance> I like the tags, I think making the REQUIRED tag a Gamemode only thing is the right thing to do.
[14:54] <@AndrewAAM> Asking for a different system between gamemode and non-gamemode does not align with the less is more that Tom is going for.
[14:55] <Nuance> It's not a different system, one is a subset of the other.
[14:55] <Nuance> Gamemode has this one extra feature.
[14:55] <@AndrewAAM> At this point gamemode is not supported by FACT
[14:56] <@AndrewAAM> this is a lst file called by a data set
[14:56] <Nuance> It probably should be though
[14:56] <@Zaister> To be honest, having the core essentials stuff with the Core Rulebook set bothers me, too, but I have no solution to remedy that
[14:56] <Nuance> I'm surprised Tom isn't pushing for this. He's always into tightening up what is allowed in the LST
[14:56] <Distant_Scholar> I think PCGen is using "core" to mean core to the game mode, not the core rulebook.
[14:57] <@Zaister> exactly
[14:57] <@Zaister> there's a lot in the CE that is just for one book. anything else should really be part of the game mode somehow
[14:57] <@Zaister> that would of course require expanding the game mode, I’m not sure that's a good idea
[14:58] <@AndrewAAM> The idea is to shrink the gamemode, not expand it. Our biggest complaints stem from items being in the gamemode that can't be easily altered.
[14:58] <Nuance> IMO the Gamemode is a problem when it does stuff that we can't do in the LST.
[14:58] <@Zaister> yeah
[14:59] <@Zaister> I just think the Core Rulebook set is loaded with too much stuff that has nothing to do with the core rulebook
[14:59] <Nuance> I'm saying this should be two systems, almost identical with all the power in the normal LST. Except the things that rightly belong to the gammode
[14:59] <Nuance> The complaints are this is gamemode and I can't manipulate it easily.
[15:00] <Nuance> If we were only going to put FACTDEF in the Gamemode then that would be a problem
[15:00] <Nuance> putting it in both places mitigates against that complaint
[15:00] <@AndrewAAM> Let me ask this question
[15:01] <@Zaister> In an ideal setup, the core rulebook set, for example, would not need to know anything about archetypes
[15:01] <@AndrewAAM> What is the difference between the gamemode and a data set?
[15:01] <Nuance> IMO things in the Gamemode are fundamental
[15:02] <@Zaister> game mode is basically metadata
[15:02] <Nuance> unalterable or you're not in the same Gamemode
[15:03] <@AndrewAAM> Okay, so what exactly is the difference between loading a data set "Core" and another "Core Rulebook"?
[15:04] <@AndrewAAM> See, the gamemode is a meta dataset with some options we don't have, but it's another set all the same.
[15:04] <@Zaister> I’m not saying we should put the Core Essentials in the game mode, that would be silly
[15:05] <@AndrewAAM> hence why I'm resistant to gamemode only this, and non-gamemode that.
[15:05] <@AndrewAAM> The core rule book loads Core Essential set - a Metadata set to support the infrastructure of pathfinder
[15:05] <Nuance> Would you like to eliminate the Gamemode altogether?
[15:06] <@AndrewAAM> It has it's purpose, and I'm wanting to reduce it's immutable properties that trip us up later down the road.
[15:06] <@Zaister> let me ask this: what if archetypes were not some thing paizo had done, but a 3rd party source
[15:07] <@Zaister> would it really make sense to modeif y the CR set and CE stuff to support that?
[15:07] <@AndrewAAM> Easy, do you want it supported or not?
[15:07] <Nuance> By adding immutability to normal LST?
[15:08] <@AndrewAAM> The archetype system is in core cause APG wasn't a required item back then
[15:08] <@AndrewAAM> if you want to move the system into apg, then we can do that. Is that the main issue here?
[15:08] <@Zaister> AndrewAAM: I think PCGen should support a method that stuff like that can be put into the exact source that needs it and not force it upon other sources when pother people might never even need that functionality
[15:09] <Nuance> You can't move archetypes out of core. Every Class has to be modified to support them
[15:09] <@Zaister> it’S just an example
[15:09] <@Zaister> of the CR set being modified to support non-CR.stuff
[15:09] <@AndrewAAM> I'm a little perplexed by how this ties into FACT but I'm willing to go with it
[15:10] <@Zaister> it doesn’t really, well just peripherally
[15:10] <@AndrewAAM> Well, fine. Let me answer the question -
[15:10] <@AndrewAAM> Paizo has a history of placing books out, some systems gain popularity and are reused, other systems are only see in the same book
[15:10] <@Zaister> but I’d be opposed, for example to do similar operations on the CR set, for obscure 3rpd party sets
[15:11] <@AndrewAAM> It's a matter of practicality
[15:11] <@Zaister> yes I know
[15:11] <@AndrewAAM> in order to support the system, then I either need to alter the set with the base objects, or I completely obliterate those objects with new objects.
[15:11] <@Zaister> but if we are to do big changes on PCGen like what we are discussing, why not make it possible for data sets to be self-contained
[15:12] <@Zaister> that might need big code work, sure
[15:12] <@AndrewAAM> For your archetype example, that means every class in the core set is removed and duplicated by APG
[15:13] <Nuance> As I see it, Adding FACT and FACTSET to the Gamemode lets us define new Gamemode tags without code intervention. It make the Gamemode more flexible, not less flexible
[15:13] <@Zaister> that is what we might have to do now, yes, I’m advocating changing PGcen so that need not be possible
[15:13] <@Zaister> er need not be necessary
[15:13] <@AndrewAAM> However, that delves into CODE not DATA.
[15:14] <@Zaister> yes
[15:14] <@Zaister> sorry
[15:14] <@Zaister> back to FACT
[15:14] <@AndrewAAM> As a DATA monkey, I can only do what is possible today. To isolate sets would require a discussion on a massive project akin to this Formula parser
[15:15] <@Zaister> I think it should not be possible for one single source to possibly break every other sources. or even one other source
[15:15] <@AndrewAAM> I hear what you are saying Nuance, but I don't see why we should force more into the gamemode.
[15:15] <@Zaister> AndrewAAM: ok, lets leave whining about that for the future
[15:16] <@AndrewAAM> I'll advocate changes with good proposals, but our focus is data today. ;)
[15:16] <@Zaister> your required vestment example, for example, breaks the core
[15:16] <@AndrewAAM> Yes, so STANDARD then
[15:16] <Nuance> I don't think we are forcing things into the Gamemode. We're putting things in the most appropriate place. If the systems are identical apart from the ability to use REQUIRED: then they are easily—trivially movable between Gamemode and normal LST
[15:16] <@AndrewAAM> No REQUIRED:YES allowed outside of the core rule set
[15:17] <@Zaister> how can you enforce that?
[15:17] <@AndrewAAM> Is that a rhetorical question?
[15:17] <@Zaister> not really
[15:18] <@AndrewAAM> The same way we enforce all of our standards. Our team agrees to follow the standards
[15:18] <@Zaister> ok
[15:18] <@AndrewAAM> If you aren't following standards, then your content won't be accepted
[15:19] <@AndrewAAM> Hence why this is focused on our standards. The goal is setting the standards we agree to follow.
[15:19] <@Zaister> but you need to be prepared for error reports like „THe whole thing doesn’t work anymore“ and take god knows how long until you find out they have a homebrew set with a required FACT
[15:19] <@AndrewAAM> Yes, but that shouldn't slip past any of our watchful eyes
[15:19] <@AndrewAAM> we also have tests
[15:19] <@Zaister> how would you know
[15:20] <Nuance> Our watchful eyes won't be there. It's a homebrew
[15:20] <Nuance> I still think you're letting concerns about old style Gamemode colour your reaction to this Proposed new style Gamemode.
[15:21] <@AndrewAAM> Okay, lets back up a sec
[15:21] <@AndrewAAM> People keep introducing Homebrew to the equation
[15:21] <Nuance> What is the difference between your core set and a trivially expandable, easily modifiable Gamemode where things can be trivially moved to normal lst if that become necessary
[15:22] <@AndrewAAM> Hold Nuance, let me address one issue at a time
[15:22] <Nuance> ok.
[15:22] <@AndrewAAM> Homebrew falls outside of our purview
[15:22] <Nuance> brb
[15:23] <@AndrewAAM> We do not include homebrew sets, we do not release our materials with homebrews included.
[15:23] <@AndrewAAM> What a homebrewer chooses to do with their own sets is completely up to them.
[15:23] <@Zaister> I'm not saying we should police homebrews. But how often have you worked on a bug only to find out the root cause was something they homebrewd but didn't mention in their bug report.
[15:24] <@AndrewAAM> I do not want to plan our standards and methods around what happens outside our scope of control
[15:24] <@AndrewAAM> Yes, there are 1,000's of ways to screw up a homebrew and I've seen 1,001 of them... :P
[15:24] <@Zaister> It might help to have a mandatory but report field "I am using homebrew data sets" :)
[15:25] <@AndrewAAM> Only helps if they report through JIRA not lst file help
[15:25] <@AndrewAAM> or pcgen
[15:25] <@AndrewAAM> or the forum
[15:25] <@AndrewAAM> or my direct help line
[15:25] <@Zaister> yes and now you plan on adding a 1002nd one where the homebrew file not only screws up itselft but potentially every other set too
[15:26] <@AndrewAAM> Anyways, homebrews only matter to me if this involves conversions. Oh trust me Zaister, I've screwed up our release sets more than any homebrewer, besides, answering help desk questions gives some of us something to do
[15:26] <@Zaister> hm let's look at it this way: where would REQUIRED actually be needed?
[15:27] <@AndrewAAM> For our current slew of sets, nill
[15:27] <@AndrewAAM> For the non-d20, I see great potential
[15:27] <@Zaister> then it's perfect for the game mode
[15:27] <@AndrewAAM> it's an option to use if we want... it's no worse than EDITABLE:NO
[15:28] <@Zaister> Game X needs new tags X Y and Z, put them in the game mode
[15:28] <@AndrewAAM> Actually, let me amend a statement... REQUIRED:YES will NOT bork the entire system. It will flag an error.
[15:29] <@Zaister> yes, and you no longer have the core deities since they do not have vestments
[15:29] <@AndrewAAM> Just like everything else. Your game should still work, only you get a yellow or red flag.
[15:29] <@AndrewAAM> let's toss that to Tom to get an actual resolution
[15:29] <@Zaister> OK
[15:30] <@AndrewAAM> If REQUIRED:YES - will it break the entire game. :)
[15:30] <@Zaister> ah one more thin: how will a var file be added to a source? via ne line in the pcc?
[15:30] <@AndrewAAM> There is a X:var.lst like RACE:x or FEAT:x
[15:30] <@Zaister> ok
[15:31] <@AndrewAAM> it doesn't support include to my knowledge though :P
[15:31] <@Zaister> that wouldn't really make sense
[15:31] <@AndrewAAM> I have to say, I'm very surprised where the obstacles came up in these discussions.
[15:32] <@AndrewAAM> Anything else before I hit the last item?
[15:32] <@Zaister> yeah that happens when other people look at stuff, with other expectations and aspects
[15:32] <@Zaister> no, go on
[15:32] <@AndrewAAM> It's good. Gives more perspective. I wish we'd had some of these meetings earlier. But the timing is perfect.

Documentation

[15:33] <@AndrewAAM> Okay, the last item was documentation. Eric sent me a note, which sounds like he has a decent handle. Plus, with that promised program we should be able to keep docs current for releases.
[15:34] <@AndrewAAM> However, I was wondering about the xml doc project.
[15:34] <@AndrewAAM> Let me grab Eric's email
[15:34] <@Zaister> it shouldn't be difficult to create multiple output formats for the tool
[15:35] <@AndrewAAM> Yeah, but the doc xml project was to include ALL the existing tags LST and Output - in a code, data display
[15:35] <@AndrewAAM> Documenting this will be fairly straight forward. I do need to make sure I go through the proposed implementation to work out exactly what will be documented where and will do up a reasonable representation for the doc entries as required. It is a given that we will have conversion examples from old tags to the new tags. We currently do this when we deprecate an existing tag/syntax in favor of a new tag/syntax.
[15:35] <@AndrewAAM> As I commented in a previous email, my thoughts on this is to have a new section of the tag dictionary that covers the core FACT/FACTSET tags and then subsections that cover gamemode specific implementations adopted by the PCGen Data team.
[15:35] <@AndrewAAM>
[15:35] <@AndrewAAM> I do have a question though . . . Is this intended to replace all existing tags one day? Or just supplement them? I ask because I have seen examples that demonstrate the replacement of existing tags. If this is the case, this will influence the XML Doc timeline.
[15:36] <@AndrewAAM> As I note above, if the FACT/FACTSET project is intended to replace the existing tags then it would likely be better to concentrate the XMLization of the tag dictionary by focusing on the FACT/FACTSET implementation. No use in converting the existing tags if they will be going away and it will be easier to implement if we build it into the FACT/FACTSET implementation. Of course this really depends on the time frame within which we can expect the FACT/FACTSET implementation to mature.
[15:36] <@AndrewAAM> Also, as I stated in and earlier post, we need to develop a good set of requirements for the xml implementation, and that really starts with a good concept of operations. (Uh oh . . . the PM/SE in me comes out again! ) We don’t need a formal ConOps but we do need a clear idea of how the XMLized tag/token dictionaries will be used from which we can derive specific operational requirements. I’ll take a shot at starting a ConOps on wiki so we have something to talk about going forward.
[15:36] <@AndrewAAM> There, enshrined for all to see. :)
[15:36] <@Zaister> :)
[15:37] <@Zaister> I don't think we want to replace all tags :)
[15:37] <@AndrewAAM> No, the ones that are not replaced have use.
[15:37] <@Zaister> wait
[15:37] <@Zaister> are we replacing existing tags?
[15:38] <@AndrewAAM> With the formula parser - yes
[15:38] <@Zaister> or is this just for expansion where no tag exists
[15:38] <@Zaister> i mean FACT/FACTSET
[15:38] <@AndrewAAM> FACT/FACTSET is for new tags
[15:38] <@Zaister> ok
[15:38] <@AndrewAAM> I have no plans to replace existing ones at this time
[15:38] <@Zaister> ok just making sure :)
[15:39] <@AndrewAAM> We could, but at this point, it's not a goal of mine right now
[15:39] <Nuance> If we got FACT and FACTSET added to the Gamemode, we could probably eliminate most of it entirely
[15:39] <@AndrewAAM> I figure the formula parser conversion is going to eat up December
[15:39] <@AndrewAAM> We could
[15:39] <Nuance> eventually
[15:40] <@AndrewAAM> But unless you guys are volunteering to tackle that, I'm not squeezing it into my 6.6 to do list
[15:40] <@AndrewAAM> My goal is set standards for these tags, and roll them out as needed for 6.6.
[15:40] <Nuance> I'm not advocating that we eliminate the Gamemode in 6.6, but adding the possibility is another matter
[15:41] <@Zaister> hm
[15:41] <@Zaister> yeah
[15:41] <Nuance> Also, if we can trivially extend/replace the Gamemode then it's less reason to have REQUIRED: in the normal LST
[15:41] <@Zaister> something to keep in mind
[15:41] <@AndrewAAM> The gamemode has a few functions that set standards, we could eliminate it, but we would need to have the structure in place to handle it.
[15:42] <Nuance> I don#'t think we Don't need REQUIRED: I do think we don't need it in the normal LST
[15:42] <@AndrewAAM> REQUIRED: was tabled as a Tom ask - since the concern was breaking sets, correct?
[15:43] <Nuance> oh, right. Must have missed that when I came back.
[15:43] <@Zaister> breaking *other* sets, specifically
[15:43] <@AndrewAAM> Yes, breaking other sets. If that can be mitigated, then it's not a concern.
[15:43] <@Zaister> not in general
[15:44] <Nuance> I still think this belongs in the Gamemode. Whether we're breaking other sets or not. I just realized I've slipped over into dogma :-(
[15:44] <@AndrewAAM> If you have 1 line that says "Hey, you have REQUIRED for Clowns, but lack clowns, double check your requirements" then great. If you have 1 line for every line then yes, boom.
[15:44] <Nuance> programming by dogma is usually a bad idea.Usually
[15:44] <@AndrewAAM> Uh oh, dogma?
[15:45] <@Zaister> Nuance: not every use. Say you have a 3rd party set that want to define some weird tag using FACT. Why should that go in the game mode
[15:45] <@Zaister> ?
[15:45] <Nuance> because it's not really mandatory in that case.
[15:46] <@AndrewAAM> Let me lay out my expectations for the content team and more specifically the data team. I want to have the full faith and control of our systems in the data sets eventually. I made eclipse which piggybacks on the existing d20 games and having gamemode control thwarted my changes
[15:46] <Nuance> It makes their data totally unusable with other data that doesn't have the tag. Aarrgh! that's a new gamemode.
[15:47] <Distant_Scholar> Or a bunch of .MODs
[15:47] <@AndrewAAM> @Zaister - he only wants REQUIRED:YES versions in the gamemode
[15:47] <Nuance> Right, the system I'm advocating you'd have said. "oh this thing I need to modify is Gamemode—I'll jut move that and make it non-manditiry"
[15:48] <@AndrewAAM> I understand his point, but the dogma is "We can't trust our programmers" is what I'm getting back.
[15:48] <Nuance> no the dogma is separation of concerns.
[15:48] <@Zaister> ah ok
[15:48] <@Zaister> it sounded a bit like all FACTs in th game mode
[15:48] <Nuance> this BELONGS in the Gamemode, or not.
[15:49] <Nuance> no, I want the ability to freeely and easily move things in and out of the Gamemode. IF it's in the Gamemode it's required. IF it's not in the Gamemode it's not required.
[15:49] <@AndrewAAM> I trust all of my programmers. They aren't perfect, but neither am I. The point is we make books that follow the rules the publisher dictates and with minimal interference from gamemode.
[15:50] <Nuance> The Gamemode should be a help, at the moment it's a hinderance beacuse it's not easily changteable.
[15:51] <Nuance> I see my proposed change as making the system more flexible and trusting our programmers to put something in the right place. not the convenient place.
[15:51] <@AndrewAAM> Anyways, the point is moot, until Tom alters the proposal it's a non-gamemode. It also sets bad precendence. ABILITYCATEGORY is both GAMEMODE and LST, and it has no restrictions on use
[15:52] <Nuance> ISn't taht one that started as a Gamemode tag and got expanded because it wasn't flexible enough?
[15:52] <@AndrewAAM> Do we have any object that shares gamemode and lst that has different properties?
[15:52] <@AndrewAAM> yes, I believe so
[15:52] <Nuance> This is a radical new system. Just because we don't currently do it doesn't mean we shouldn't do it.
[15:53] <Nuance> If the new syustem is better why not use it
[15:53] <@Zaister> What! We've never done that!
[15:53] <@Zaister> :)
[15:53] <Nuance> Just because we're capable of replace 90% of our tags with FACT and FACTSET doesn't mean we're going to do it. We might someday
[15:53] <@AndrewAAM> Yes, but what is the justification? That's my point. It's not a matter of convenience, but a matter of condensing code, and allowing the lst monkeys more freedom.
[15:54] <Nuance> Because the only essentail difference between Gamemode and non-Gamemode is anything in Gamemode is Required.
[15:54] <Nuance> otherwise it's just a fact or a set of facts (see what I did there?)
[15:55] <@AndrewAAM> And if the goal is to move away from gamemode - then what?
[15:55] <@AndrewAAM> and yes, punny
[15:55] <Nuance> Well, is it?
[15:55] <Nuance> I think the goal should be to move away from Inflexibility
[15:55] <@AndrewAAM> Yes, the goal is to move more away from gamemode
[15:56] <@AndrewAAM> I agree, inflexibility is a major hurdle
[15:56] <Nuance> The Gamemode serves a useful purpose. This is the set of things that make this game unique.
[15:56] <@AndrewAAM> agreed
[15:56] <Nuance> It's main problem is its inflexibiilty. Lets fix the actual problem and not throw out the baby with the bathwater
[15:58] <Nuance> Your problem on Exlipse was you couldn't easily subtract from the Gamemode.
[15:58] <@AndrewAAM> Which I haven't suggested. But here's the thing. We've take a lst file proposal, and want to make two versions of it - gamemode and lst, with only one tag different. How is that more flexible? Flexible is keeping it out of gamemode and trust the monkey coding to follow standards.
[15:58] <Nuance> If it was defined in terms of this, then it's not just easy, it's trivial.
[15:58] <@AndrewAAM> Eclipse has a ton of issues
[16:00] <@AndrewAAM> Skill rank max, skill point assignment, skills as class or not, exceeding max ranks for select skills, natural attack progressions outside of normal die progression, HD flexibility, multiple companions, granting companions extra benefits, etc.
[16:00] <Distant_Scholar> As interesting and informative as much of this discussion has been, I think I'll have to call it quits at 4 hours. :-)
[16:00] <Nuance> because I don't want the ability to put Required anywhere but in a gamemode file. But, then I'm not the Silverback. If I haven't convinced yuou, I'm probably not going to. Let's move on.
[16:01] <@AndrewAAM> Anyways, let's shelf that... yeah
[16:01] <@AndrewAAM> Okay, it's four hours we've hit all topics, any comments or questions before we call this a wrap?
[16:01] <@Zaister> I'm good
[16:02] <Nuance> yeah, me too.
[16:02] <Distant_Scholar> Just let me know if I break anything trying to use git. :-)
[16:02] <@Zaister> haha
[16:02] <Distant_Scholar> (Yes, I know it's set up to not be broken.)
[16:02] <@AndrewAAM> Okay, thanks everyone, great discussion. I'll toss out a log for this discussion.
[16:02] <@AndrewAAM> Appreciate your time and participation. :)
[16:02] <Distant_Scholar> quit
[16:02] <@Zaister> :)
[16:02] <@AndrewAAM> you can't
[16:02] <@AndrewAAM> soul jar
[16:02] <Distant_Scholar> apparently not.
[16:03] <@Zaister> you can check in any time you like...
[16:03] <@AndrewAAM> muwa ha ha ha
[16:03] <Distant_Scholar> \quit
[16:03] <Nuance> Thanks you and good night
[16:03] <@AndrewAAM> other way
[16:03] <Nuance> you totally have to leave that in the log :-)
[16:03] <@AndrewAAM> I am
[16:03] *** Nuance has quit IRC: Quit: bye bye

END

Content Meeting 2014-12-13

Contents

Premeeting

Meeting

Intro

Github

Formula Parser

Intermission

Fact & FactSet proposal and Standards

Documentation

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Start

Teams

Community

Strategic Development

Misc

Tools