Board index



Content Team - Meeting and Issues

Discussions between the code and data teams for new features and implementing long term projects

Content Team - Meeting and Issues

Postby LegacyKing » Mon Dec 08, 2014 7:20 pm

Hi Content Team (OS, DOC, DATA),

If people are available, I'd like to get together and have a full content team meeting (December 13, Saturday).

If you can't make it, not to worry. Here are the topics:
    GIT/GITHUB and us!
  • NewSource is doing well, and proves to be a good test bed
  • Workflow - What is that?
    Upcoming Architecture/Code Work
  • JEP replacement Formula Parser (This is a major discussion!)
  • FACT/FACTSET - this goes hand-in-hand with the JEP replacement
  • XML project revival! Having a full fledged content per tag/token is a wonderful idea and I think we should revisit this project.
  • 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?
Now, to recap and touch on everything:
GIT is a decentralized control system. It seems a little more complex at first, but once you dig in and realize what it is doing, it will blow you away. For the developers (That's every monkey that manipulates a file on this team), you can work on multiple projects and not cross-contaminate - all in the same repo!
Our workflow model is a simple design:

  • MASTER is the "trunk" if you will. This is where all finished features are placed.
  • RELEASE will be the "production" branch - since we tend to only focus on trunk and the most recent release, this seems ideal.
That's it, those are the two permanent branches. If you want to work on a bug or a new feature, you "checkout" a Branch "JIRA-ID_Description". Once you are happy with the bug fix/feature, you push your branch to your remote, PR to our main pcgen github location, and it will be merged into the master branch. This is the same procedure we already do for NewSource, only we don't have a release branch.

BIG topic: Tom has been working on the Data Team request for a Local EQVAR - to support magic items, specific item hardness ratings, and the like. Well, this project has a sandbox that went really well. We're in talks - James, Tom and myself to get this project moving full steam ahead.

Here are the issues:
JEP is our current Variable system. It is interwoven through the entire system and has been patched and bent to work with pcgen. In short, it's a true beast. It has served us well, but we need to move away from it for several reasons, but I'll give the two biggest ones:
  • 1) It's no longer updated as a free library. The maintainers have moved it to commercial licensing, and we only have it by a grandfather agreement.
  • 2) Continuing to rely on it has an escalation effect that data needs, code must provide. It is a cycle that can't be broken, but we can reduce the requests for escalation if we move to another system.
Tom made a draft proposal Formula Parser replacement. It's a new system built to handle PCGen specific needs:

  • It is set up as a two-tiered system: Global (What our JEP is) and Local (What we need to support items)
  • It is designed to be expandable and flexible. It can do VAR (Variables) and AREA (x,x), like FACE.
  • It is designed to replace the entire BONUS tag family. BONUS:COMBAT|AC|5|TYPE=NaturalArmor becomes MODIFY:AC.NaturalArmor|ADD|5
  • It is designed to replace many tokens that were affected by BONUS tags. 'FACE', 'REACH', etc.
To give a measure of respect to what this project will do, I've made a wiki page to encompass the anticipated changes - and just a warning, this is not completed, there are other items that must be considered and syntax to hammer out.

For those that want information about this, here are the wiki pages:

Next: FACT & FACTSET - this is another escalation issue that Tom seeks to remove by giving the Data team another tool. With FACT and FACTSET, the data team will be able to create new "tokens" per gamemode and designate their file usage, and if they export to the OS.

My initial thoughts - each FACT will be created and placed in the central core file. This will prevent overlap issues, and give us a clear idea what we have in each gamemode.

Finally, as many have guessed, the impact on documentation changes. We need to determine what we'll document and how. As most of the tokens are removed, we might want to utilize examples a bit more. And as part of a conversion process, I did want to have a "BONUS:COMBAT|AC|x|TYPE=y" became "MODIFY:AC.y|ADD|x" to aid users and monkeys alike in transitioning.

Finally, the XML document project. The idea of having a method to automate our documentation and correct typos in one central location appeals to me.

Okay, discuss away, ask questions, or make comments.

Andrew Maitland
PCGen Content SB

Andrew Maitland
PCGen Content SB
- Data Chimp
- Quicksilver Tracker Monkey
User avatar
Site Admin
Posts: 771
Joined: Fri Oct 11, 2013 12:35 pm
Location: California, US

Re: Content Team - Meeting and Issues

Postby Nylanfs » Mon Dec 08, 2014 9:11 pm

I'll be unavailable in the evening about 6 to 9. But plan to attend if possible.

Paul "Yes that Paul" Grosse
PCGen BoD - PR Silverback
ICQ: 14397299
Forums: Nylan (or Nylanfs)

Note: This forum will be closed within the next month. Pleas signup at
User avatar
Posts: 418
Joined: Thu Sep 11, 2014 6:06 pm
Location: Elkhart, Indiana, United States

Return to Experimental

Who is online

Users browsing this forum: No registered users and 1 guest