Meeting 2014 11 07

From PCGen Wiki
Revision as of 07:49, 8 November 2014 by LegacyKing (talk | contribs) (Fix typo)
Jump to: navigation, search

Members:

  • Chair/Content - Andrew
  • Code - James
  • Data 2nd - Doug
  • Arch - Tom
  • Data Team - Mark

Non-Quorum Meeting Minutes

Summary:

  • Discussed upcoming Projects slated for 6.6 and the time frame
    • James will begin planning and implementing the LST editor in 3 weeks
    • Tom and Andrew will begin tackling the Formula Parser and FACT/FACTSET planning and implementation in 3 weeks
    • Migration to GIT and breaking the project into separate repos to reduce excess memory usage (NewSource will be the flagship, followed by Main and Archive)
    • Release of 6.4.1 scheduled before 6.6 work begins
  • Post Meeting: Tom, Andrew and Mark discuss the Formula Parser and outstanding troubles to tackle (Separate Log provided after the Meeting Log)

Raw Log

  • James[Code_SB]: So looks like just us two again
  • @Andrew[Chair]: yup
  • Quick meeting then?
  • James[Code_SB]: Yeah
  • Main news from my side is that I've still got 2-3 weeks of low activity
  • However on the good side there haven't been too many code issues reported since the release
  • @Andrew[Chair]: Yeah, nothing too major - some odd corner cases have cropped up, but that's been mainly data twisting problems.
  • Data has been hammered with a slew of reports - some growing pains bringing sets up to new standards
  • James[Code_SB]: Yes that is where the big changes were so not too surprising. It seems to mostly be edge cases again though which is good
  • @Andrew[Chair]: Yeah, other items are DEFINES not properly defined, or BONUS:VARS not implement... One issue that is drawing my attention is the misnamed "Display Feat Descriptions"
  • James[Code_SB]: The one I changed late in the cycle?
  • @Andrew[Chair]: Did you? My memory is lapsing, did you address that issue and that's why BENEFIT is no longer displaying?
  • James[Code_SB]: Let me check
  • @Andrew[Chair]: If so, then excellent, means I can tackle the remaining BENEFITs to DESC except the Feats
  • James[Code_SB]: Fix bug: PDF sheets show the feat benefit twice under default settings
  • Issue#: CODE-2721
  • http://jira.pcgen.org/browse/CODE-2721
  • @Andrew[Chair]: Ah, didn't realize that impacted abilities with BENEFIT.
  • James[Code_SB]: Which was fixed in rc3
  • @Andrew[Chair]: Well, excellent, means one less concern if that is the case.
  • James[Code_SB]: That's good to hear
  • @Andrew[Chair]: Search and Replace with impunity then... Muah ha ha ha
  • James[Code_SB]: I think feats display both desc and benefit in the pdf OSes
  • @Andrew[Chair]: Correct
  • James[Code_SB]: but not other abilities
  • @Andrew[Chair]: Also correct. The abilities were toggling display based upon the setting, which meant haphazard result
  • James[Code_SB]: So this could be either a data or OS fix depending on what the desired output is
  • @Andrew[Chair]: End result expected: ONLY Feats should have a DESC and BENEFIT in place. ABILITIES should ONLY use DESC
  • That is the new data standard. If people want to toggle Ability DESC for Short/Long, they can implement a house rule
  • But at least that will be consistent application
  • James[Code_SB]: ok. Sounds good
  • @Andrew[Chair]: Much like the Spells are today
  • Okay, so upcoming Projects
  • James[Code_SB]: Which will leave the situation that noone would want to use that toggle option in prefs
  • @Andrew[Chair]: The Display full feat description? Yes, we can remove it as unnecessary
  • Projects slated for 6.6 -
  • You were planning on the LST Editor implementation - I assume 3 weeks out from today
  • Tom and I were doing the joint Arch/Data implementation of Formula Parser replacement and FACT/FACTSET - also slated in a couple of weeks (Pending confirmation from Tom)
  • James[Code_SB]: planning starts from 3 weeks yes
  • @Andrew[Chair]: That leaves a couple of weeks to package all compatible 6.4 changes and port them into the 6.4 branch for a final 6.4.1 release before that's closed off.
  • Which leaves the question, when did we want to migrate to GIT?
  • I would imagine it'd be best to do that before serious 6.6 development is underway
  • thoughts?
  • James[Code_SB]: That's not a bad idea
  • I would suggest starting now by porting the nfd stuff over to github
  • That will relieve your load the most I reckon
  • @Andrew[Chair]: If I recall, you wanted to spearhead that project. (Already done I think)
  • James[Code_SB]: and is a good isolated trial
  • I thought the nfd commits were coming back to svn still
  • @Andrew[Chair]: NFD has it's own repo... it's not in sync though...
  • Yes, cause it's the mirror svn on github.
  • We have to git devs who are using the main mirror for the PR...
  • James[Code_SB]: So lets back up a bit
  • I'm talking about closing the svn repo for first nfd and later pcgen and having the primary code base being on github.
  • @Andrew[Chair]: *Nods* Agreed.
  • James[Code_SB]: That would mean you would only interact on github to approve pull requests you wouldn't need to interact with Henk's server and svn commits would cease (no mirroring)
  • By the looks of it you are still doing mirroring for NFD with commits like http://sourceforge.net/p/pcgen/code/25396
  • @Andrew[Chair]: I'll make a broad announcement that all NFD needs to be in by Monday, and then sync the detached NFD to what is on.
  • then after Monday, all NFD development will be on the detached repo
  • James[Code_SB]: just to be sure, could you explain what you mean by detached repo please?
  • @Andrew[Chair]: Detached means it's own repo not tied to either the main GITHUB repo for our development pcgen/pcgen or svn
  • it would be it's own entity. Basically it's separate project
  • Was that what you had in mind?
  • Otherwise, NFD is really a moniker for branches in the main repo...
  • either method works.
  • one allows easy merging, the other means manually adding it from one repo to another
  • Hi Doug!
  • Distant_Scholar: Hello, everyone. Sorry I'm late.
  • James[Code_SB]: Hi Doug
  • @Andrew[Chair]: James - did you want one repo for development as we have and have the NFD stuff be a branch of sorts?
  • pcgen/newsource123
  • I don't have a problem with that, in fact it might make things a little saner for testing
  • James[Code_SB]: I think it is worth considering having nfd as a separate repo under the pcgen product, but only one repo, not one per source
  • @Andrew[Chair]: Oh, certainly.
  • NFD would be the repo name
  • James[Code_SB]: That way you can have it checked out locally and then have say vendordata in pcgen point to that folder
  • @Andrew[Chair]: Actually, we could probably call it something like NewSources
  • James[Code_SB]: That sounds good to me
  • so https://github.com/PCGen/NewSources ?
  • @Andrew[Chair]: Yes
  • Which begs the question, we have a lot of floating excess stored in our svn... should we put the excess stuff, like Website, utilities and such into another repo?
  • and have our main functional repo be just everything under the pcgen folder?
  • James[Code_SB]: That was the way I was thinking
  • @Andrew[Chair]: after all, unlike SVN, forking pulls everything, no pick and choose like svn allows
  • James[Code_SB]: As if you have the lot as one git repo, everyone has to grab the lot
  • yep
  • @Andrew[Chair]: correct
  •  :)
  • PCGen/NewSources - PCGen/Development - PCGen/???
  •  ??? = What do we call the extras
  • AdditionalResources?
  • Or PCGen/Main instead of Development, if you want something more neutral
  • James[Code_SB]: yeah pcgen/main or even pcgen/pcgen would work
  • @Andrew[Chair]: we already have pcgen/pcgen...
  • we'd have to nuke the existing one first
  • James[Code_SB]: ah ok - I was thinking we could reuse it
  • @Andrew[Chair]: Uhg, no thanks...
  • History is the major issue
  • You'd be forking the entire history, something we wanted to avoid if we're going smaller
  • James[Code_SB]: So we need to keep the github history as well as the port the history from svn
  • Ah ok
  • @Andrew[Chair]: Hence why I was using an alternative to work with, since I know you coders love history.
  • James[Code_SB]: ok, with you now - that is currently the lot
  • @Andrew[Chair]: Henk should be able to save the history of just the pcgen down - in theory.
  •  ???
  • James[Code_SB]: Yes we'll need to work out a time for a planning chat between the three of us
  • @Andrew[Chair]: I don't see a major need to save history for the NFD > NewSources move, so I'll just dump the updates in there. Give Mark and SecretWiz till Monday to push in their changes.
  • James[Code_SB]: Cool
  • We can see how that part goes
  • @Andrew[Chair]: then call a moratorium for NFD pushes
  • I just need a good name for the extra stuff
  • anything not NewSources and Main...
  • Ideas?
  • Distant_Scholar: Extras?
  • James[Code_SB]: We may want to split it into two and pull out the abandoned stuff e.g. architecture (6years since last update)
  • @Andrew[Chair]: Mothballed and Extras?
  • Or Obsolete and Extras
  • James[Code_SB]: Sure
  • and yeah extras, or admin might be options. No reason they can't be split up too
  • Archive?
  • @Andrew[Chair]: Oh Archive!
  • I like it
  • James[Code_SB]: but yes something along those lines
  • but that can be planned in a few weeks
  • @Andrew[Chair]: Excellent. So I'll put the NewSources up, we'll move to that between today and Monday
  • James[Code_SB]: Sounds good
  • @Andrew[Chair]: the rest we'll plan out with Henk.
  • Doug, any thoughts or items you wanted to discuss? This is a laid back since it's a small group today
  • Distant_Scholar: Nothing in particular.
  • I know; I'm boring.
  • @Andrew[Chair]: Here comes Tom
  • Hi Tom!
  • Tom[Arch_SB]: hey, sorry if I'm late, been a crazy day
  • @Andrew[Chair]: No worries, small meeting... Emailing you the notes.
  • We discussed the upcoming projects, move to GIT and time frame for most of it.
  • Basic gist, we get 6.4.1 out the door in a couple of weeks, and begin work on 6.6 in earnest. With the caveat we move to GIT before 6.6 is underway.
  • Tom[Arch_SB]: ok
  • @Andrew[Chair]: What is your schedule looking like for availability?
  • I should clarify - Tom, what is your schedule looking like for availability?
  • Tom[Arch_SB]: still setting in from moving and a bit of scramble to get the house unboxed and set up since I'm hosting Thanksgiving, should be more reasonable after that
  • James[Code_SB]: Wow, no pressure eh?
  • @Andrew[Chair]: Cool, coincides with James' time frame as well. I have this Thanksgiving off for a change. :)
  • Tom[Arch_SB]: Well, they want to see the house, which is fair, just keeps life interesting
  • @Andrew[Chair]: Was there anything we needed to deep dive discuss Tom or any items you wanted to bring up?
  • James[Code_SB]: I have to head off now
  • Have a good rest of the day all
  • Tom[Arch_SB]: I don't think so. I think the discussion on _exp about formulas/vars is a good one
  • You too James
  • @Andrew[Chair]: Take care James.
  • Agreed
  • END MEETING


Log for New Formula Parser Discussion

  • Tom[Arch_SB]: Mark does have a point that the rules of stack/nostack are not necessarily in every object, so we may want to separate where that is defined
  • @Andrew[Chair]: Something that Mark pointed out to me, that isn't enforced by our JEP
  • Trait grants +1 to Skill Foo
  • Trait grants +2 to Situation Foo (Bar)
  • Bonus to Foo should be +1
  • Bonus to Foo (Bar) should be +2 but is +3
  • Tom[Arch_SB]: teh bonus should be coded as +1 to the situation
  • IMHO
  • The problem is that someone someday may need it to be +3
  • So some level of interepretation of the books is necessary by the data coder
  • @Andrew[Chair]: Unfortunately, those trait bonuses are two different sources, and puts a contract on the data developer to review all sources for such interactions. Not very feasible IMHO
  • Tom[Arch_SB]: and there is a ruling somewhere that the result is +2?
  • @Andrew[Chair]: Its bonus is TYPE=Trait
  • Stacking rule
  • The issue is +1 to base skill, and +2 to a situational skill
  • since the situation is inherenting the bonuses from the base, it should have the type on it.
  • But I don't know how the code is interacting under the hood.
  • Tom[Arch_SB]: it's probably not interacting at all
  • This is one of the problems with the TYPE= system
  • Let me give an example:
  • BONUS:Blah|1|TYPE=Foo
  • BONUS:Blah|2|TYPE=Bar
  • BONUS:Blah|1|TYPE=Foo.STACK
  • hmmm no
  • that doesn't go where I need it to go
  • hold on
  • nvm, I'm confusing two issues
  • so
  • Is Mark on?
  • @Andrew[Chair]: let me ping him
  • So, no issue with the TYPE issue... my only issue is negative values ignore TYPE completely
  • not getting a reply from Mark on gtalk... sent him an email.
  • Tom[Arch_SB]: So we have a value "1" which today has a TYPE
  • and that has to interact with the "2" on the situation that also has a TYPE
  • (the same TYPE)
  • yikes
  • @Andrew[Chair]: yes
  • tell me about it
  • Distant_Scholar: This is a special case with situational skills, yes? Maybe special code needs to be written for it?
  • Tom[Arch_SB]: I'm trying to avoid special code
  • that's half the problem with the code we have is so many special cases
  • @Andrew[Chair]: Situational skills are based off the parent skill
  • we wanted to avoid code churn and thus situational skills were created to avoid the churn
  • even if the conditional skill system were in place, this would still be a nightmare to solve.
  • that was skill displays under the base skill and took all the modifiers from the base, but was tasked to display only if the totals didn't match.
  • Tom[Arch_SB]: ok
  • So one of Mark's concerns in the last note was that the stacking rules for a BONUS TYPE (e.g. Trait) were not defined in each Trait, but defined universally in some other location in the book
  • am I interpreting that correctly?
  • @Andrew[Chair]: Uh, not sure... it's a TYPE'd bonus, so defined elsewhere is a null point.
  • Tom[Arch_SB]: but are there TYPES that can stack?
  • @Andrew[Chair]: One source has the Bonus +1 another source has the Bonus +2.
  • Yes, those are defined in the gamemode
  • Tom[Arch_SB]: no wait
  • @Andrew[Chair]: they don't require the .STACK tag as it's implied
  • I don't think he mentioned the rules changing a STACKLESS TYPE to STACKS
  • Tom[Arch_SB]: I'm saying his point was that someone defining the concept of that type defined what it was on page 2
  • I'm not trying to change one to another
  • and then it went on to use the concept of that type of BONUS throughout the book and others then used that concept later on
  • (for example)
  • ok, so some book somewhere said, there is a BONUS TYPE of Trait, and we know it doesn't stack
  • just bonuses in general
  • not asking about skills right now
  • and then pages 20-35 actually defined the thingies (Feats, whatever) that used the concept
  • I think that was his point with "The object that applies the bonus does not know or even care whether the default for that bonus type stacks or does not stack unless it specifically adds .STACK, or .REPLACE."
  • anyway, not that important for now
  • @Andrew[Chair]: I must have missed that in his email...
  • Tom[Arch_SB]: So with TYPE=Trait
  • Let's talk about non-stacking for a moment, which is what Trait is
  • @Andrew[Chair]: Okay
  • Tom[Arch_SB]: Making up something new for the moment
  • DEFAULTVARIABLEVALUE:NONSTACKING|0
  • VARTYPEDEF:NONSTACKING|NONSTACKINGBONUS
  • GLOBAL:NONSTACKINGBONUS|Trait
  • hmm no
  • LOCAL:ALL|NONSTACKINGBONUS|Trait
  • (and this is on the fly, so don't try to remember or quote me on this later as being set or coherent in any way)
  • @Andrew[Chair]: concepts and brainstorm sessions are like that... Nothing is set in stone.
  • Tom[Arch_SB]: MyTrait <> MODIFYOTHER:SKILL|Foo|Trait|APPLY|1
  • MyTrait.MOD <> MODIFYOTHER:SKILLSIT|Foo (Bar)|Trait|APPLY|2
  • MODIFYOTHER:SKILLSIT|ALL|Trait|APPLY|parent()
  • the last in the global file
  • APPLY as a modifier knows Trait is a NONSTACKINGBONUS
  • APPLY then performing the stacking rules
  • in the case of NONSTACKINGBONUS that is the equivalent of MAX
  • in the semiequivalent case of STACKINGBONUS it's ADD
  • @Andrew[Chair]: Okay, you lost me...
  • Tom[Arch_SB]: so "Trait" starts its life with value zero
  • @Andrew[Chair]: A bunch of new concepts packed in tightly...
  • Okay Trait = 0
  • Tom[Arch_SB]: since the default value for any NONSTACKING is zero as per the default variable value line
  • @Andrew[Chair]: Correct
  • Tom[Arch_SB]: Trait is local to all objects
  • that was caused by the LOCAL:ALL|NONSTACKINGBONUS|Trait
  • so Foo as a skill has a local variable Trait
  • then in MyTrait, we modified Trait on the skill to be 1
  • MODIFYOTHER:SKILL|Foo|Trait|APPLY|1
  • we also modified via the .MOD, the Trait on the Situation to be 2
  • MODIFYOTHER:SKILLSIT|Foo (Bar)|Trait|APPLY|2
  • globally we modified Trait on the situation to be equivalent to the parent
  • MODIFYOTHER:SKILLSIT|ALL|Trait|APPLY|parent()
  • thus if we didn't have the APPLY|2 it would be 1
  • since the parent (the skill foo)has Trait of 1
  • follow?
  • @Andrew[Chair]: Is APPLY a new Function? And is parent() a new function?
  • Tom[Arch_SB]: yes
  • things I'm creating on the fly
  • parent() is referring to the var on the skill (when used for a situation)
  • @Andrew[Chair]: Okay, then yes. Now I'm following. Takes a bit, I've been learning pseudocode algorithms in class
  • Tom[Arch_SB]: APPLY is equivalent to MAX if the underlying object is non-stacking
  • would be equivalent to ADD if the underlying object is stacking
  • just trying to give you guys ONE way to spell it out, with the ability elsewhere to declare stacking vs non stacking
  • that way you don't have to be concerned about which one it is when you are writing the modify
  • like you don't have to worry about it today with BONUS
  • @Andrew[Chair]: Cool. But not set in stone ;) - Mark is available. You able to chat on GTalk?
  • Tom[Arch_SB]: that would take a bit
  • @Andrew[Chair]: okay.
  • Tom[Arch_SB]: MODIFYOTHER:SKILL|ALL|Rank|Add|asnumber(Trait)
  • MODIFYOTHER:SKILLSIT|ALL|Rank|ADD|asnumber(Trait)
  • @Andrew[Chair]: Eh?
  • Tom[Arch_SB]: Trait is a NONSTACKINGBONUS
  • not a VAR
  • Rank is a (local) VAR
  • presumably
  • need to convert Trait to a VAR
  • which is actually a NUMBER
  • hence asnumber(Trait)
  • basically strips off the fact that it's non-stacking in this case
  • and just returns the value
  • @Andrew[Chair]: Gotcha.
  • Tom[Arch_SB]: ok, this authentication thing isn't going to happen tonight
  • haven't had to authenticate an app before and too much reading
  • @Andrew[Chair]: no worries, Mark hasn't popped online for me
  • the big issues left for the conversion:
  • 1) Apply Luck bonus boost to ALL existing Luck bonuses
  • Tom[Arch_SB]: have you seen my latest note to _Exp?
  • @Andrew[Chair]: something you mentioned in your last email
  • Tom[Arch_SB]: ok
  • I THINK that answers it
  • What I'd like to know is how you guys are doing the bauble thing today
  • @Andrew[Chair]: And the AC discussion... Periods were mentioned as legal in the wiki, is that no longer the case?
  • Tom[Arch_SB]: if you can't get a bonus from a type of object more than once
  • @Andrew[Chair]: Bauble thing caught me off-guard
  • today, if you put on three, you'd have a +3 bonus.
  • that's a tricky sneaky rule I wasn't aware of till today.
  • Tom[Arch_SB]: you are correct, period is legal as per the wiki
  • my bad
  • @Andrew[Chair]: Oh, Mark just popped on
  • Distant_Scholar: Typically, you can't get more than one of the same ability/feat/object anyway. How many objects would this apply to?
  • @Andrew[Chair]: Items
  • Tom[Arch_SB]: two identical rings for example would cause the issue
  • @Andrew[Chair]: Say an equipment without slots or two rings, yes
  • Tom[Arch_SB]: So today you'd probably just create a TYPE = localto that object?
  • TYPE=FooRingStuff
  • on the BONUS?
  • Distant_Scholar: Ah. To my eyes, the simplest "fix" would be to make up a new type. (Tom beat me to it.)
  • @Andrew[Chair]: pretty much
  • if I was made aware of it, I would have done something like that, yes
  • sounds like items will need those "types" to manage...
  • mjmeans: ok
  • hi
  • Tom[Arch_SB]: Hi Mark
  • @Andrew[Chair]: Yay!
  • Hi Mark
  • mjmeans: Dont worry about the fate's favored ability. It isn't possible with the current system either.
  • Tom[Arch_SB]: do you think my example work work though?
  • mjmeans: for fate's favores? no
  • Tom[Arch_SB]: why not?
  • mjmeans: consider a pc with one ability that gives a luck bonus to intimidate, one equipment that gives a luck bonus to AC and a eqmod that gives a luck bonus to shield.
  • There is no way a single modify would identify and add 1 luck to each and every one of those luck bonuses
  • Tom[Arch_SB]: oh, I get the question now
  • so it's actually based on the TYPE=
  • mjmeans: it's an array formuls that is required for that solution
  • Tom[Arch_SB]: that you are triggering off of
  • mjmeans: yeah. that's why the current JEP can't do it either
  • Tom[Arch_SB]: so one question
  • if you have a luck bonus to intimidate from item a and a luck bonus to intimidate from item b, each are 1. is the result 3 or 4?
  • mjmeans: i think there are more pressing concens than this one trait, so lets work on the regular issues with stacking.
  • Tom[Arch_SB]: well, I have a solution that may do both
  • so let's spend a few more moments on this
  • mjmeans: ok.. so i'll restate the issue with luck then
  • with expected results
  • pc has Ability1 that gicvs a +2 luck bonus to intimidate. PC has 1 equipment item that gives a +1 luck bonus to AC. PC has a spell that grants +1 luck bonus to AC, Attacks and saves. Got it so far?
  • Tom[Arch_SB]: y
  • mjmeans: So at this point (without the fate's favored trait) the PC has a total +2 luck bonus to intimidate, +1 luck bonus to AC, attacks and damage. The equipment and the spell both provide a +1 luck bonus to AC but they don't stack. Okay so far?
  • Tom[Arch_SB]: y
  • mjmeans: So now fate's favor is applied. each of the various luck bonuses go up by 1, but the net effect is the PC has +3 luck bonus to intimidate, and +2 to AC, attacks and damage.
  • Tom[Arch_SB]: k
  • mjmeans: Now consider that a luck bonus could apply to any skill or conditional skill, of which there are are least 100.
  • Tom[Arch_SB]: understand
  • my question was an order of ops issue
  • but because it doesn't stack it's moot
  • because max (1,1)+1 is the same as max (1+1,1+1)
  • mjmeans: To make fate's favored work, one method is to .MOD each existing item or ability or spell that is known to have a luck bonus, to add an additional 1 if the PC has fate's favoreed.
  • Tom[Arch_SB]: I think that' s a mess
  • mjmeans: But that is prone to error.
  • Tom[Arch_SB]: we need better
  • so let's leave that aside for a moment
  • mjmeans: Another method might be is there is a way to query the AC total to "know" if a luck bonus was applied and then apply 1 more if fate's favored. A smaller list to be sure, but still hundreds. And each SKILLSIT would still have to be .MODed since they are never added into any total.
  • Tom[Arch_SB]: still bad
  • I have better
  • mjmeans: right
  • Tom[Arch_SB]: So let's talk about the variable system as it's proposed
  • right now, there are some default types built into the system
  • One of those is NUMBER
  • In the variable proposal
  • every game mode will have to provide a default value:
  • DEFAULTVARIABLEVALUE:NUMBER|0
  • We can then define different types of numbers
  • think of these as local scopes in a way
  • VARTYPEDEF:NUMBER|VAR
  • mjmeans: ok
  • Tom[Arch_SB]: so any time we create a new VAR, it takes on the characteristics of NUMBER, including the default value of zero
  • GLOBAL:VAR|GlobalVariable
  • so GlobalVariable has a default value of zero
  • mjmeans: ok
  • next?
  • Tom[Arch_SB]: So NUMBER has the quirk, as you've pointed out, that with the operations we have, such as MAX and ADD, that if we use NUMBER for BONUSES (either as a VAR or as another type of NUMBER)
  • ...then we end up with a problem of locality of knowledge
  • meaning the BONUS type of Luck was defined in a book on page 2 for example
  • and was said to be non-stacking
  • mjmeans: right
  • Tom[Arch_SB]: then it was used on pages 25-30 in variables thingies
  • whatever they were
  • so as a thought exercise, let's define a new type, let's call it NONSTACKING
  • DEVAULTVARIABLEVALUE:NONSTACKING|0
  • VARTYPEDEF:NONSTACKING|NSBONUS
  • GLOBAL:NSBONUS|Luck
  • nope
  • sorry
  • LOCAL:ALL|NSBONUS|Luck
  • every object is given a local variable (type is NSBONUS/NONSTACKING) called Luck'
  • mjmeans: So all items get a Local Luck variable?
  • Tom[Arch_SB]: yes
  • defaulting of course to zero
  • mjmeans: so we have armor and shield. each one has a local Luck variable. Got it.
  • @Andrew[Chair]: and skills and spells, etc.
  • mjmeans: Now let's consider a +1 luck bonus to armor and a +1 luck bonus to shield and the PC has fate's favored.
  • Tom[Arch_SB]: hold on
  • mjmeans: ok
  • Tom[Arch_SB]: wait
  • let's not go there yet
  • By the way
  • This is a bit of brainstorming
  • so it may end up more verbose than necessary
  • and I may b acktrack here and there
  • mjmeans: just remember that if the the luck bonus is 0 it gets no benefit from fate's favored.
  • "Whenever you are under the effect of a luck bonus of any kind, that bonus increases by 1."
  • Tom[Arch_SB]: that's the easy part :D
  • mjmeans: do go on
  • @Andrew[Chair]: All, I have to head off... be back in 30...
  • mjmeans: BCNU
  • Tom[Arch_SB]: (thinking)
  • this is likely to be too verbose, but it should function
  • GLOBAL:NSBONUS|LuckBonus
  • mjmeans: or LOCAL:ALL?
  • Tom[Arch_SB]: global
  • mjmeans: ok
  • Tom[Arch_SB]: I need to summarize the local Lucks somewhere
  • mjmeans: Too bad there isn't a LOCAL:MODIFY|ALL|GLOBAL.Luck|ADD|Luck
  • a pseudo array forumula
  • Tom[Arch_SB]: There is: MODIFYOTHER:ALL|ALL|LuckBonus|ADD|Luck
  • mjmeans: Where the scope of the left argument is a global and the right argument is a local?
  • Tom[Arch_SB]: used once in the global file
  • local variables can't match the name of a global var
  • the data load would fail
  • mjmeans: that's bad
  • Tom[Arch_SB]: so the scope is directly known from the name
  • why is it bad
  • it's enormously confusing to have "Luck" in two places
  • these aren't programmers we're talkingabout
  • that do the data
  • mjmeans: So then from a data standpoint, all global variables should follow an obvious naming scheme that will help keep them separate
  • Tom[Arch_SB]: That's a data team thing
  • I don't think that's necessary
  • mjmeans: Are varioable type sensitive?
  • Tom[Arch_SB]: meaning what?
  • mjmeans: i.e. gFoo is a different variable than GFOO
  • like java or c++... case sensitive
  • Tom[Arch_SB]: not case sensitive
  • mjmeans: ick
  • Tom[Arch_SB]: it's a side effect of LST load
  • the files were always loaded in as all CAPS as part of the load process
  • that's the history we hav
  • have
  • mjmeans: ok
  • Tom[Arch_SB]: actually my MODIFYOTHER was wrong
  • because ADD would make them stack as it wer
  • *were
  • should be: MODIFYOTHER:ALL|ALL|LuckBonus|APPLY|Luck
  • APPLY is new for NONSTACKING and effectively acts as MAX
  • mjmeans: So let's get back to the LOCAL:ALL|NSBONUS|Luck... Luck to what? Some items will give Luck to AC, others will give Luck to a skill, others will give differing Luck to multiple skills or saves.
  • Tom[Arch_SB]: argh you're right
  • mjmeans: Consider AC only. So we use LOCAL:ALL|NSBONUS|LuckBonusToAC. Then on any item, ability or spell that gives a luck bonus to AC, it will SET it's local variable. SOmewhere else that is totaled back to a TotalACLuckBonus variable which is then totaled into the TotalAC variable reported on the OS.
  • So now we have NxN bonuses added to every item, spell or ability
  • Tom[Arch_SB]: except they are lazily instantiated, so they aren't really there if thye aren't used
  • mjmeans: Well, N1 x N2... where N1 is the number of types, and N2 is the number of object because each object cannot stack with itself.
  • N2 is HUGE
  • Tom[Arch_SB]: let's ignore the bauble thing for the moment
  • mjmeans: ok
  • For the simple case of types, there are about 20 types in Pathfinder.
  • Tom[Arch_SB]: one clarification
  • you woudlnt' SET the LuckBonusToAC
  • you'd APPLY it
  • that way if there was a later .MOD that was a different value it would take the max
  • in the case of nonstacking
  • mjmeans: So at the very least we have LOCAL:ALL|NSBONUS|XBonusToY where X is the type of bonus and Y is AC, or STR, or a skill, etc.
  • As an exercise, let's start with a simpler case, but complex enough. The spell Divine Favor "you gain a +1 luck bonus on attack and weapon damage rolls for every three caster levels you have (at least +1, maximum +3)."
  • Tom[Arch_SB]: let's step back for a moment
  • mjmeans: ok
  • Tom[Arch_SB]: I don't like X*Y even as you show it
  • If we were doing this in Java or C# or whatever
  • mjmeans: I dont like it either, but is there another way?
  • Tom[Arch_SB]: how would we accumulate it
  • we have some object that has a type and a value
  • call that class Bonus
  • mjmeans: If this was C# or Java, each spell, item or ability would be an Class in and of itself with shared and local variables
  • Tom[Arch_SB]: Luck:1, Luck:2 whatever
  • put on the constraint that each spell has no local or global variables
  • and design it that way :)
  • mjmeans: We'd use a singleton to handle the "not stacking with itself" behaviour
  • Tom[Arch_SB]: or assume you are using a visitor pattern to extract data from the list of objects
  • that's probably the better description of the scenario
  • mjmeans: I've never herd of a "visitor" pattern.
  • Tom[Arch_SB]: ok
  • let's do this then
  • mjmeans: but, ,yes, accessing data from a list of object, which each contain a list of bonuses
  • that;s back to an array formula
  • Tom[Arch_SB]: so we have a spell an an ability and a ring
  • to keep it simple
  • mjmeans: ok
  • Tom[Arch_SB]: each has a few bonuses
  • since we can .MOD items from differnet LST files
  • we have to assume thespell could have Luck for AC:1 and Luck for AC:2
  • so the order of ops has to be:
  • grab the list for object n
  • do a local consolidation (non stacking in this case)
  • then add that list to the global list
  • then do a global consolidation
  • right?
  • is the local one necessary?
  • mjmeans: yes
  • for luck's favor yes, but otherwise, maybe not
  • Tom[Arch_SB]: each bonus has 3 pieces of info
  • type, wher eto apply and a value
  • mjmeans: if global consolidation is "per total", and you have the ability ti query "was there a non-0 luck bonus, then add 1" then global consolidation would work for fate's favored.
  • Tom[Arch_SB]: k
  • mjmeans: but back to the single spell, item and ability
  • assuming the bastard fate's favored is not the ability
  • Tom[Arch_SB]: MODIFY:ACBonus|APPLY|Luck: 1
  • mjmeans: So the item, spell and ability would simply APPLY to a GLOBAL variable that it should apply to.
  • Tom[Arch_SB]: ACBonus is a global NSBONUS
  • (I've changed NSBONUS a bit from what we were doing before)
  • mjmeans: I don't see "Luck:1" as a legal syntax in the current examples on the wiki
  • Tom[Arch_SB]: hehe
  • It's not
  • but the forumula system can do some neat stuff :)
  • here's the key thing
  • when you have something like MODIFY:ACBonus|APPLY|Luck: 1
  • ACBonus is specific
  • mjmeans: AC is going to be totalled with each type of bonus separately because it gets reported on the OS as separate totals
  • Tom[Arch_SB]: it knows that is an NSBONUS
  • let's come back to that
  • and that NSBONUS is a NONSTACKINGBONUS
  • APPLY is made legal for the type of NONSTACKINGBONUS
  • and APPLY is taught to parse it's argument as expecting "TYPE:numeric VALUE"
  • mjmeans: once you finish your current train of through, let me know. I have a different question...
  • Tom[Arch_SB]: that way the type and value travel together
  • mjmeans: okay... good
  • Tom[Arch_SB]: and that way we can apply stacking
  • mjmeans: a vector number (or complex number)
  • Tom[Arch_SB]: effectively
  • mjmeans: That's one of my suggestions to andrew
  • Tom[Arch_SB]: the framework for that is already in place
  • the system is actually fairly flexible
  • I can do (and have sample code that supports):
  • VARTYPEDEF:LIST|MyList
  • @Andrew[Chair]: Back
  • Tom[Arch_SB]: MODIFY:List|ADD|4
  • sorry
  • MODIFY:MyList|ADD|4
  • MODIFY:MyList|ADD|5
  • and MyList is now [4, 5]
  • that isn't exposed right now
  • and I probably won't support that in the first release
  • but the power is there if we need it
  • (and there are places it will be useful)
  • so anyway, we create the type:value
  • and put it into AC
  • I think I've finished my thought, so what was your question
  • mjmeans: So MODIFY:MyList|ADD|Luck:4 MODIFY:MyList|ADD|Shield:5 becomes { [4,Luck], [5,Shield] } ?
  • Tom[Arch_SB]: give or take some complexities I've left out
  • MyList would need to have the underlyign type predefined
  • so you can't mix and match a VAR with a NONSTACKING
  • for example
  • mjmeans: My different question is... why in the world did you decide to use key words for ADD MULTIPLY, whatever rather than just using arythmatic operators... "variable = {equation}"
  • Tom[Arch_SB]: speed
  • mjmeans: x+=1 for ADD
  • Tom[Arch_SB]: launching a formula system to interpret value()+4 is about 10,000 times more expensive than knowing I need to add 1
  • mjmeans: y = m*x+b normal formula
  • precompiling +=1 to static is simple and only needs to be done once
  • Tom[Arch_SB]: it is conceptually simple
  • it takes a lot of code to do that though
  • mjmeans: In fact the assembly language INC and DEC ops exist because they are in fact much faster than ADD x,1
  • But compilers will always identify statics and optimize them for you.
  • Tom[Arch_SB]: but these aren't in cod
  • *code
  • they are in files we load
  • mjmeans: So you can code ADD x,1 and the compiler will automatically replace that with INC x.
  • Tom[Arch_SB]: and we aren't doing a compile of them in the java sense
  • walk through the process
  • we have an LST file
  • mjmeans: So it's beyond the scope of the formula parser to PCode the formulas, then?
  • Tom[Arch_SB]: it has MODIFY:Foo|SOLVE|value()+1
  • When this project was started, I submitted code to the project that took a formula and *literally* compiled it into bytecode
  • that would have made this pretty moot as then the JIT compiler could do whatever it needed to do
  • that was deemed too complex and the decision was made to leave the formula in a tree format and solve from there for easier debugging and understanding by new developers
  • mjmeans: ok
  • well each formula is currently stored in a string somewhere. right?
  • Tom[Arch_SB]: no
  • when you have something like value()+1 it's turned into a parse tree
  • there is a + object with 2 children
  • value() and 1
  • value is actually a formula object with 2 children
  • sorry vaule() is a formula object with 2 children
  • value (a formula name) and an argument child that has zero children
  • Distant_Scholar: Sorry to interrupt, but I have to go for today. I'll want to get a transcript later; this is interesting stuff. G'night.
  • Tom[Arch_SB]: night
  • I have to quit in about 10 anyway
  • that make sense Mark?
  • @Andrew[Chair]: I will log it, minus the chit chat part.... ;)
  • mjmeans: what are the two children of value() nothing is specified in the aparens?
  • Tom[Arch_SB]: yes, the function is split into the function name and a node representing the parens that has the arguments (that would be in the parens in some cases) as children
  • that allows us to just look at the function name node to look up the code that runs that function
  • and hand it the array of children
  • in the case of if(a>4,5,b)
  • mjmeans: so parent node is "function" and two children are "function" and "parameterlist"?
  • Tom[Arch_SB]: the two children would be "if" and "()" and the children of "()" would be ">", "5", and "b", and the children of ">" would be "a" and "4"
  • mjmeans: sorry, lag.. .didn't mean you if example, your previous example where you said function() had two children
  • So function() becomes parent "Formula" with children "function" and "parameterlist" ?
  • Tom[Arch_SB]: so there is a node that represents the total "value()" [I forget what this node is actually called - function perhaps?]... it has children of "value" [the type is a string, but is interpreted as a function name since it's the child of the node type above that I can't remember] and "()" [an otherwise empty node that is interpreted as arguments since it's part of a function].
  • so yes, basically you are correct in your last statement
  • have you ever used lex or yacc?
  • mjmeans: So let me try to describe how I'm seeing this, if this is right... MODIFY:Foo|SOLVE|if(a>4,5,b) -> {Foo, SOLVE, {function {if, {a, >, b}, 5, b}}}
  • Tom[Arch_SB]: not quite
  • When modify is struck by the LST parser, it is decomposed
  • It knows Foo is to be modified, and it validates that Foo is legal in that context (if Foo is local to equipment and in a spell, expect an error)
  • it then looks at the second arg for the modification type in this case SOLVE
  • that is looked up against the type of Foo, in this case NUMBER
  • the SOLVE code in Java is then passed "if(a>4,5,b)" as a String
  • then the String passed into SOLVE is broken up into the tree as described
  • if you hit ADD instead of SOLVE, it knows the argument must only be a decimal number (can't be a formula) so it can just call Double.valueOf(inputString)
  • and store the double for direct addition later on
  • rather than needing a tree
  • that help?
  • mjmeans: So you would never MODIFY:Foo|ADD|if(a>b,4,5)
  • Tom[Arch_SB]: that would cause an LST load error
  • mjmeans: because rith righ operand is a formula
  • Tom[Arch_SB]: correct
  • and ADD requires something that is effectively interpretable as a Double
  • mjmeans: And in the case MODIFY:Foo|SOLVE|Foo+5
  • Tom[Arch_SB]: "Foo+5" is passed to the parser, which generates a tree
  • mjmeans: the LST load does not see that as equivalent to ADD 5?
  • Tom[Arch_SB]: and the tree is interpreted at runtime to calculate
  • they are mathematically equivalent
  • but the SOLVE always triggers a tree
  • optimizing that call to detect equivalents is more code to write, maintain, test
  • mjmeans: Okay, so LST load hass areas where loading optimization can be applied behind the scenes, but that's not relevant at this early stage.
  • Tom[Arch_SB]: it could be improved, certainly, at the cost of time
  • I have not tried to do that optimization since I want to get the basics running to get out of the other issues we have
  • mjmeans: So back to nonstacking types... Do we have a xolution that is not X*Y variable names?
  • Tom[Arch_SB]: yes, remember the type:value setup
  • mjmeans: Using the concept Luck:1 (or whatever?
  • Tom[Arch_SB]: but I actually need to run
  • mjmeans: okay. greate chat
  • Tom[Arch_SB]: so we can pick this up later
  • mjmeans: yes
  • @Andrew[Chair]: Later Tom.
  • Tom[Arch_SB]: yes, thanks, I appreciate someone poking at this to make it better
  • mjmeans: BCNU
  • @Andrew[Chair]: Did you get all your major questions answered?
  • I briefly skimmed the stuff I missed
  • mjmeans: it's still alittle foggy because the concept has talked about where we can use Luck:1 as a vector (or complex) number is not desribed in the docs yet.
  • @Andrew[Chair]: Yes, since he's brainstorming a lot of it.
  • mjmeans: It still doesn't address the issue of an item not stacking with other instances of itself.
  • One question he has was, does the existing DATA support that. And I dont know.
  • Should be easy ehough to test though
  • @Andrew[Chair]: No, Bauble +1 and Bauble +1 would give +2
  • mjmeans: That's a problem
  • @Andrew[Chair]: untyped bonuses stack, and the data/system doesn't equate the non-stack of same source.
  • mjmeans: But the current DATA *could* support it by always adding |TYPE:itemname
  • @Andrew[Chair]: The work around is to place a unique type on those items.
  • yes

END OF CONVERSATION