Skip to content

Meeting 2015 01 16

PCGen Meeting for January 16th, 2015

Attendance

  • Tom P. [Arch]
  • Paul G. [PR]
  • Douglas L. [Data 2nd]
  • Andrew W.
  • David B.
  • "Canda"

Summary

Raw Log

  • Probably just informal this evening, we are missing at least James and Andrew
  • <[OGL]Nylanfs> Mythic Adventures, AP#61 Shards of Sin, Blood of the Moon, Ultimate Campaign, Animal Archive, & Varisa: Birthplace of Legend have all been released into review or alpha state
  • nice
  • Very nice.
  • <[OGL]Nylanfs> Iron Gods Player's guide, AP #67 The Snows of Summer, Taldor, And Adventurer's Armory are being reviewed for licensing now
  • <[OGL]Nylanfs> I should have those done over the weekend.
  • <[OGL]Nylanfs> Heya DRB
  • Hi Paul!
  • wow busy
  • I'll be trying to pay attention as I work.
  • <[OGL]Nylanfs> I'm personally opening to have a chance to play in the new sandbox with the formula and FACT/FACTSET sometime in the next week or so. :)
  • <[OGL]Nylanfs> hoping
  • cool
  • I discovered one gap in that a few minutes ago, so there will probably be one change this weekend
  • Right now there is no ability to make a FACT or FACTSET "GLOBAL", it has to be tied to a specific object.
  • If we want to replace things like SORTKEY or the SOURCE* stuff then we need a GLOBAL location
  • <[OGL]Nylanfs> Is that really a problem?
  • problem, no
  • <[OGL]Nylanfs> Hmm, I see what you mean
  • convenient yes
  • So anyway, that's one of my projects for this weekend
  • Anything else Paul?
  • <[OGL]Nylanfs> Well I won't be going to GenCon this year
  • bummer
  • <[OGL]Nylanfs> Wife is dragging me to a Cat Convention. :)
  • [blinks] okay...
  • <[OGL]Nylanfs> But things are on track for possible having a booth next year for PCGen. :)
  • interesting
  • <[OGL]Nylanfs> There's been a fairly steady stream of donations to the funds
  • <[OGL]Nylanfs> Other than that I don't think I have anything else
  • ok
  • I'll paste in Andrew's content report
  • Content Report - New sources worked on and expected out soon: Technology Guide Taldor Blood of the Moon Iron Gods Player's Guide
  • Working hand-in-hand with Tom and the FACT/FACTSET items. Proposals are being pushed forward to institute some more progress (if you're a data chimp, please chime in with a vote or questions)
  • OS - (Stefan) - Stefan can fill in progress here Data - (Douglas) - Doug can fill in any other progress here Docs - (Eric) - Haven't seen any activity from Eric...
  • -end Andrew's content-
  • ...any questions since we have some folks on that may be able to answer?
  • @Tom when you said "Okay, I think there is a way for this to work as requested", did you mean we can put whatever numbers we like in SIZENUM: and expect the system to work it out?
  • I'm asking because you then start to talk about other objects
  • Hey there
  • Hiya
  • Yes, for example, the input values would be SIZENUM: 10, 20, 40, 50, whatever
  • and the code would produce SIZEORDER 0, 1, 2,3 , 4 etc
  • Nice
  • or whatever the constants are called
  • I actually found I don't need to change how Equipment thinks, just need to deal with the side effects on the other items ...
  • I take it these are then totally internal and not referenced in the LST
  • that means UI work though, and I'll need some guidance from James or Connor on that (already posted to _dev)
  • Yes, that calculation is internal, LST only worries about what was shown as SIZENUM in the example ablve
  • *above
  • One other comment though:
  • The data right now can do things with variables and produce sizes... so we will need to think about how that works going forward if they can be dynamic
  • since an insertion of a size would change the # for MEdium perhaps...
  • so the formula really shouldn't be "3+something"
  • it should be "sizeof(medium)+something"
  • or some such
  • we'll want to solve that before we allow sizes outside of game mode
  • currentsize+sizeof(medium)-sizeof(current) or whatever
  • something of that flavor, yes
  • Have we thought about replacements for the terms STR, DEX, etc.
  • which are currenlty derived from the ABB:
  • they can be derived from ABB/KEY while JEP is still around
  • and after that? global vars?
  • if the new system is integrated, it will depend on how the data is created :)
  • Well, just to make up one version...
  • perhaps you have a local variable "score" on each ability, then you could create global vars and do this on Strength:
  • MODIFY:STR|SOLVE|score
  • then STR would be a global var
  • usable just like the term today
  • solve? surely solve is the devil
  • :-)
  • MODIFY:STR|ADD|score
  • heh
  • So the base definition of ADD is that it requires a number
  • that is how the wiki reads today
  • and anything that refers to another variable needs to use SOLVE in order to invoke the formula system
  • ah right, so score is not a number , it is a free variable
  • (since we can do a shortcut if we are just doing an add of a number)
  • Having said that, the code is a bit ahead of the wiki
  • The formula system in SVN has a working copy (not fully tested!) that allows ADD and the others to invoke the formula system
  • since I got sick of typing SOLVE|value()+...
  • and got sick of seeing Andrew M type it in the sample data he built, too
  • OOh, does that not negate the benefits of cacheability
  • it is still "slower" than an integer in the sense that it invokes the formula system, but better syntax, IMHO
  • it's actually broken out in the LST load system
  • so it effectively builds a SOLVE in the background and submits that to the core
  • ah, so two different internal things
  • just that LST never sees SOLVE so you have clearer LST syntax
  • correct
  • a spoonful of syntatic sugar helps the medicine go down
  • :)
  • While we're on things, I'll note that there are currently 3 proposals in vote mode on _exp
  • I'm really likeing these FACT and formula systems
  • I'm not a chimp I don't get votes on those, I just stand ion the sidelines flinging poo
  • eliminating ABB's special behavior, eliminating implicit sequencing (which is all of Align, Size, Stats, and Checks
  • ) and the FACT/FACTSET/Output Model system
  • The first and last would happen reasonably quickly after approval, the implicit sequencing one requires a few infrastructure changes internally, so would take a few weeks to get into the main repository
  • yeah, the GUI changes there should be fun
  • I voted on at least two of those; I just have to remember which two. :-) I did find the FACT/facet/FACTSET terminology amusing.
  • presumeably the number of stats as well as their order will become dynamic
  • We've run out of words in the English language!
  • Yes, one of the use cases is to cover where we have a different # of stats, including the 3.x expansions that added Luck, or whatever
  • which is an achievement in itself, what with english being synonym central
  • I've probably asked this before, but I'm forgetful: Are there plans to allow ABILITYs to have local variables? 'Cause it'd be very handy.
  • that's... interesting
  • it is the intent
  • but the whole "category/nature" application of abilities makes it a bit tougher
  • because putting them in without the ability to get them out really isn't all that useful
  • The general gist is that I made an early assumption of being able to share certain infrastructure between two things, and I can't do that
  • so I need to separate it and then do the work required to get it to work in abilities
  • part of the reason I'm doing FACT/FACTSET first is that there is shared infrastructure between that and the variable system
  • and they got out of sync a while ago, and that is just a pain
  • so I want one of them (FACT being easier) in the main repo so it can serve as the master upon which the other is built
  • the basic bonus being that almost any type that can serve as a FACT can be very easily transplanted as a variable
  • Hmm one more use of type that means something else ... :-)
  • well, one of my secret goals is to delete the TYPE token... ;)
  • although you raise a good point
  • You're using GROUP but not KIND
  • I'm fond of kind when naming things that I don't want to call a type
  • I'm using it as data format
  • so if I enable POINT in FACT, it will also work as a var
  • ah ok, haven't seen that
  • This is actually a good discussion
  • right now it's DATATYPE: in the definition file
  • and that is BOOLEAN or STRING or NUMBER
  • or whatever
  • probably should be DATAFORMAT
  • and then the managers that do that work should be in plugin.format not plugin.type
  • I think I'll make that change this weekend
  • avoiding calling another thing "type" is a good change
  • yes
  • good to get it changed before it get integrated into the main
  • exactly
  • gets
  • Any other questions on that?
  • no, it seems straightforward. We'll see when I start working with it
  • I also started a discussion on _dev just a bit ago on output and replacement (things like OUTPUTNAME DESC and TARGETAREA) so open to ideas and input there as well... long term project, but want to get some ideas from folks
  • I spotted the email but haven't read it, I spotted the reminder about this at the same time at 10:58 (i.e. 2 mins to go)
  • :)
  • That's it from me. Any questions or topics from anyone else?
  • <[OGL]Nylanfs> Nothing from me, I'm just enjoying watching the formula discussion. :)
  • Still lots of work to do on that one before it gets near the main release
  • thank you and good night

Source: Meeting 2015 01 16 (original PCGen wiki)