Topics

[Proposal] CHOOSE:ABILITYSELECTION & CHOOSE:ABILITYLIST

Andrew Maitland
 

In order to allow abilities to mimic feats correctly, we need the ability to take selection from
another ability with only the selection made.

This proposal has two parts -
CHOOSE:ABILITYSELECTION [Designed to mimic CHOOSE:FEAT]
CHOOSE:ABILITYLIST [Designed to mimic CHOOSE:FEATLIST]

####
CHOOSE:ABILITYSELECTION|w|x

Variables Used (w): Text (Category defined)
Variables Used (x): Text (Ability Name)

NOTE:This would duplicate the existing behavior we have in CHOOSE:FEAT (Example is Weapon
Specialization)

Example:
CHOOSE:ABILITYSELECTION|FEAT|Weapon Focus
- Would return any values weapon focus had taken


####
CHOOSE:ABILITYLIST|w|x|x

Variables Used (w): Text (Category defined)
Variables Used (x): Text (Name of abilities to list)
Variables Used (x): TYPE= (TYPE to list by)

NOTE: This would allow you to get a list of Abilities by name.

Example:
CHOOSE:ABILITYLIST|Special Ability|Finder Monkey|TYPE=Inspiring Tales

Would return a list of 'Finder Monkey' and any 'Special Ability' with the Type 'Inspiring Tales'


--
Andrew Maitland (LegacyKing)
Admin Silverback - PCGen Board of Directors
Data 2nd, Docs Tamarin, OS Lemur
Unique Title "Quick-Silverback Tracker Monkey"
Unique Title "The Torturer of PCGen"

Andrew Maitland
 

Hi,

*bump*

On 3/19/2012 9:54 AM, Andrew wrote:
In order to allow abilities to mimic feats correctly, we need the ability to take selection from
another ability with only the selection made.

This proposal has two parts -
CHOOSE:ABILITYSELECTION [Designed to mimic CHOOSE:FEAT]
CHOOSE:ABILITYLIST [Designed to mimic CHOOSE:FEATLIST]

####
CHOOSE:ABILITYSELECTION|w|x

Variables Used (w): Text (Category defined)
Variables Used (x): Text (Ability Name)

NOTE:This would duplicate the existing behavior we have in CHOOSE:FEAT (Example is Weapon
Specialization)

Example:
CHOOSE:ABILITYSELECTION|FEAT|Weapon Focus
- Would return any values weapon focus had taken


####
CHOOSE:ABILITYLIST|w|x|x

Variables Used (w): Text (Category defined)
Variables Used (x): Text (Name of abilities to list)
Variables Used (x): TYPE= (TYPE to list by)

NOTE: This would allow you to get a list of Abilities by name.

Example:
CHOOSE:ABILITYLIST|Special Ability|Finder Monkey|TYPE=Inspiring Tales

Would return a list of 'Finder Monkey' and any 'Special Ability' with the Type 'Inspiring Tales'

--
Andrew Maitland (LegacyKing)
Admin Silverback - PCGen Board of Directors
Data 2nd, Docs Tamarin, OS Lemur
Unique Title "Quick-Silverback Tracker Monkey"
Unique Title "The Torturer of PCGen"

Tom Parker
 

We have two CHOOSE:FEAT's so this proposal is confusing as to what is trying to mimic what...

Also, the first argument to the (5.17 version of) CHOOSE is the "target object type"... meaning that's what the CHOOSE is selecting. We should not have two different subtokens selecting the same type of object.

I understand the ABILITY subtoken (similar to CHOOSE:FEAT| [the NEW 5.17+ CHOOSE:FEAT, NOT CHOOSE:FEAT=]), since that would choose something like "Martial Weapon Proficiency"

I understand ABILITYSELECTION, since that parallels CHOOSE:FEATSELECTION, and would choose something like "Martial Weapon Proficiency (Longsword)" (both the Ability and an association).

I don't understand CHOOSE:ABILITYLIST. What type of object are you selecting? How is this different than CHOOSE:ABILITY? Or is this a proposal to attempt to replace it since there is a conversion issue? If so, this proposal needs to highlight conversion rules for CHOOSE:ABILITY and the deprecation of CHOOSE:ABILITY. Note also that "ABILITYLIST" should be a reserved name (aee NEWTAG-77), so ABILITYLIST is a bad choice here if you intend to return an Ability. We should do something like CHOOSE:ABIL if you are looking for that replacement.

TP.

--- In pcgen_experimental@..., Andrew <drew0500@...> wrote:

Hi,

*bump*

On 3/19/2012 9:54 AM, Andrew wrote:
In order to allow abilities to mimic feats correctly, we need the ability to take selection from
another ability with only the selection made.

This proposal has two parts -
CHOOSE:ABILITYSELECTION [Designed to mimic CHOOSE:FEAT]
CHOOSE:ABILITYLIST [Designed to mimic CHOOSE:FEATLIST]

####
CHOOSE:ABILITYSELECTION|w|x

Variables Used (w): Text (Category defined)
Variables Used (x): Text (Ability Name)

NOTE:This would duplicate the existing behavior we have in CHOOSE:FEAT (Example is Weapon
Specialization)

Example:
CHOOSE:ABILITYSELECTION|FEAT|Weapon Focus
- Would return any values weapon focus had taken


####
CHOOSE:ABILITYLIST|w|x|x

Variables Used (w): Text (Category defined)
Variables Used (x): Text (Name of abilities to list)
Variables Used (x): TYPE= (TYPE to list by)

NOTE: This would allow you to get a list of Abilities by name.

Example:
CHOOSE:ABILITYLIST|Special Ability|Finder Monkey|TYPE=Inspiring Tales

Would return a list of 'Finder Monkey' and any 'Special Ability' with the Type 'Inspiring Tales'

--
Andrew Maitland (LegacyKing)
Admin Silverback - PCGen Board of Directors
Data 2nd, Docs Tamarin, OS Lemur
Unique Title "Quick-Silverback Tracker Monkey"
Unique Title "The Torturer of PCGen"


[Non-text portions of this message have been removed]

Andrew Maitland
 

Hi,



On 4/2/2012 12:55 PM, thpr wrote:
We have two CHOOSE:FEAT's so this proposal is confusing as to what is trying to mimic what...

Also, the first argument to the (5.17 version of) CHOOSE is the "target object type"... meaning that's what the CHOOSE is selecting. We should not have two different subtokens selecting the same type of object.

I understand the ABILITY subtoken (similar to CHOOSE:FEAT| [the NEW 5.17+ CHOOSE:FEAT, NOT CHOOSE:FEAT=]), since that would choose something like "Martial Weapon Proficiency"

I understand ABILITYSELECTION, since that parallels CHOOSE:FEATSELECTION, and would choose something like "Martial Weapon Proficiency (Longsword)" (both the Ability and an association).
ABILITYSELECTION is looking to grab just the association of the selected ability(ies). If my target
is 'Martial Weapon Proficiency' and the associations are 'Longsword' and 'Greatsword' then the
selections should be 'Longsword' and 'Greatsword'. Which would enable the selection to be placed
into an appropriate BONUS statement 'BONUS:WEAPONPROF=%LIST|TOHIT|1'


I don't understand CHOOSE:ABILITYLIST. What type of object are you selecting? How is this different than CHOOSE:ABILITY? Or is this a proposal to attempt to replace it since there is a conversion issue? If so, this proposal needs to highlight conversion rules for CHOOSE:ABILITY and the deprecation of CHOOSE:ABILITY. Note also that "ABILITYLIST" should be a reserved name (aee NEWTAG-77), so ABILITYLIST is a bad choice here if you intend to return an Ability. We should do something like CHOOSE:ABIL if you are looking for that replacement.
I'm looking for just a List of Abilities to use just the name. We can change it to CHOOSE:ABIL,
though if it's not an issue I'd prefer CHOOSE:ABILLIST I'm not sure if I want to completely convert
CHOOSE:ABILITY, as there might be use though I'm a bit pressed to think where it would be useful on
the data side... With that in mind, sure let's call it a replacement for CHOOSE:ABILITY which gives
(CATEGORY=blah|Ability Name) and convert it to CHOOSE:ABIL which gives (Ability Name).

As a Data Monkey, it's certainly a lot easier to program this:
BONUS:VAR|MonkeyFuBonus|2|PREABILITY:1,CATEGORY=Special Ability,Chooser Ability(Choice) as opposed to
BONUS:VAR|MonkeyFuBonus|2|PREABILITY:1,CATEGORY=Special Ability,Chooser Ability(CATEGORY=Special
Ability|Choice)

Would a pipe even be allowed in the second instance???

So, for conversion, I'm gonna need help here...

I looked at the NEWTAG-77, I'm not seeing the correlation. That tracker is asking to add a group of
selected abilities to a selectable group for a certain classes bonus feats or class abilities.

That sounds like we'd need a method to add an 'ITYPE' to feats and abilities so they'll be added to
an ABILITYGROUP.

We have ABILITYLIST in ABILITYCATEGORY, which will list abilities, and then we have TYPE which
brings in a group of abilities that match that type. You'd need a method to "ADD" abilities to a
valid list. Which IMO is a whole new token at the very least and would work fine with
CHOOSE:ABILITYLIST.

Unless you want to reserve the name 'ABILITYLIST' on the fact it matches the name in the
ABILITYCATEGORY.

Or, if we don't want CHOOSE:ABILITYLIST, how bout CHOOSE:ABILITYGROUP?




TP.

--- In pcgen_experimental@..., Andrew <drew0500@...> wrote:
Hi,

*bump*

On 3/19/2012 9:54 AM, Andrew wrote:
In order to allow abilities to mimic feats correctly, we need the ability to take selection from
another ability with only the selection made.

This proposal has two parts -
CHOOSE:ABILITYSELECTION [Designed to mimic CHOOSE:FEAT]
CHOOSE:ABILITYLIST [Designed to mimic CHOOSE:FEATLIST]

####
CHOOSE:ABILITYSELECTION|w|x

Variables Used (w): Text (Category defined)
Variables Used (x): Text (Ability Name)

NOTE:This would duplicate the existing behavior we have in CHOOSE:FEAT (Example is Weapon
Specialization)

Example:
CHOOSE:ABILITYSELECTION|FEAT|Weapon Focus
- Would return any values weapon focus had taken


####
CHOOSE:ABILITYLIST|w|x|x

Variables Used (w): Text (Category defined)
Variables Used (x): Text (Name of abilities to list)
Variables Used (x): TYPE= (TYPE to list by)

NOTE: This would allow you to get a list of Abilities by name.

Example:
CHOOSE:ABILITYLIST|Special Ability|Finder Monkey|TYPE=Inspiring Tales

Would return a list of 'Finder Monkey' and any 'Special Ability' with the Type 'Inspiring Tales'

--
Andrew Maitland (LegacyKing)
Admin Silverback - PCGen Board of Directors
Data 2nd, Docs Tamarin, OS Lemur
Unique Title "Quick-Silverback Tracker Monkey"
Unique Title "The Torturer of PCGen"



------------------------------------

Yahoo! Groups Links



--
Andrew Maitland (LegacyKing)
Admin Silverback - PCGen Board of Directors
Data 2nd, Docs Tamarin, OS Lemur
Unique Title "Quick-Silverback Tracker Monkey"
Unique Title "The Torturer of PCGen"

Tom Parker
 

1)

ABILITYSELECTION is [...]
Understand - do we have "fixing" BONUS as a FREQ or NEWTAG somewhere?

I get bothered when we start with syntax and not the problem we are trying to solve. That's backwards.

I think the data team needs to focus more on capturing the actual problems of what we are trying to solve and let the proposal develop. That way, we can get at the underlying issue and also not get down the path of starting with a conflict as we did here with ABILITYLIST.

2)

No two choose subtokens should EVER have to select the same type of object. If there is CHOOSE:ABIL then there is no CHOOSE:ABILITY (barring deprecation to be removed and the transition et al). If for some reason someone feels that is necessary, then the root cause of the issue is in how the choices are processed, and we need to fix that issue, and the other tokens, not contort CHOOSE. This is another reason why it is important to know what we are actually trying to solve/trying to do vs evaluating a literal token proposal with no context.

3)

ABILITY, ABIL, ABILLIST, ABILGROUP, ABILITYLIST, and subtokens.

Let's talk philosophy on CHOOSE for a moment and on how we name the subtokens. (p.s. not interested in pre-5.17 CHOOSE tokens, interested in what we do now)

Terminology:

CHOOSE:FEAT|Feat1|Feat2|Qual1[TYPE=Type2]

CHOOSE is the token
FEAT is the subtoken (appears right after : and separated by a |)
Feat1, Feat2 and TYPE=Type2 are primitives
Qual1 is a Qualifier

This is (relatively) universal across CHOOSE (though some do not support qualifiers - see the docs)

Any time we are getting into changing a subtoken, we should think about reading the CHOOSE as a sentence (remembering PIPE is OR):

CHOOSE one or more FEAT objects from the possibilities which include Feat1 OR Feat2 OR Qual1[TYPE=Type2]

Therefore, let's try ABILLIST or ABILGROUP

CHOOSE one or more ABILLIST objects from the possibilities from CATEGORY Cat1 which include Feat1 OR Feat2 OR Qual1[TYPE=Type2]

Do you see what's wrong there? You aren't choosing one or more ability lists, you are choosing one or more abilities. No list is involved.

Why does this become a problem?

In Spells LST:
Spell1 <> CLASS:Wizard=1 <> ...

Let's now assume we get a CHOOSE for that.

CHOOSE:CLASSSPELLLIST|Wizard|Cleric

CHOOSE one or more CLASSSPELLLIST objects from the possibilities which include Wizard OR Cleric

Seems ok.

If write CHOOSE as you propose:

CHOOSE:ABILLIST|CATEGORY=Cat1|Abil1|Abil2|Qual1[TYPE=Type2]

...we have to rewrite the sentence to be:

CHOOSE ABIL objects to form a LIST, choosing from the possibilities from CATEGORY Cat1 which include Abil1 OR Abil2 OR Qual1[TYPE=Type2]

While that WORKS, it has two issues. (1) it's a different sentence than every other CHOOSE we have right now and (2) it creates confusion. Let me demonstrate #2 by showing what it would mean for ClassSpellList:

The sentence is:
CHOOSE CLASSSPELLLIST objects to form a LIST, choosing from the possibilities which include Wizard or Cleric

Thus:

CHOOSE:CLASSSPELLLISTLIST|Wizard|Cleric

The "LISTLIST" frightens me.

I also assert it can lead total confusion.

NEWTAG-77 defines a capability to put abilities into lists. Let's make up syntax for a moment:

LIST:ABILITY|CATEGORY=Cat1|AbilList1|Abil2|Abil3

This defines a new "AbilityList" called "AbilList1" that contains "Abil2" and "Abil3"

Assume we generate various ability lists, and then want to be able to choose them. Using the "LIST" sentence method, we get:

CHOOSE ABILITYLIST objects to form a LIST, choosing from the possibilities in CATEGORY Cat1 which include AbilList1 and AbilList2

Thus:

CHOOSE:ABILITYLISTLIST|AbilList1|AbilList2

...again with the "LISTLIST"

Thus with the ABILITYLIST from this proposal we have:
CHOOSE:ABILITYLIST (returns a list of abilities)
CHOOSE:ABILITYLISTLIST (returns a list of ability lists)

That to me is not good usability; It's downright confusing. I don't want to be the one to write documentation for it or otherwise desire in any way to want to support that syntax... Thus my proposal of CHOOSE:ABIL, which while an abbreviated form (like CHOOSE:LANG had to be), is at least consistent with the other CHOOSE subtokens.

p.s. I don't think it's better if we end up with "LISTGROUP" rather than "LISTLIST"

4)

As a Data Monkey, it's certainly a lot easier to program this:
BONUS:VAR|MonkeyFuBonus|2|PREABILITY:1,CATEGORY=Special
Ability,Chooser Ability(Choice)
as opposed to
BONUS:VAR|MonkeyFuBonus|2|PREABILITY:1,CATEGORY=Special
Ability,Chooser Ability(CATEGORY=Special Ability|Choice)

It is critical though to avoid ambiguity vs. save a few keystrokes. This is an even more subtle interaction with NEWTAG-77, so I will cover in a later note.

TP.