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

Meeting 2014 11 07

Contents

Non-Quorum Meeting Minutes

Raw Log

Log for New Formula Parser Discussion

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Start

Teams

Community

Strategic Development

Misc

Tools