Topics

DATA question

markjmeans
 

Does anyone know how to make an ability category function as an ordered list of choices?

 

  1. An ability category of LIST OF ROGUE TALENTS.
  2. Abilities that can be added to that ability category are numbered abilities “#1”, “#2”, “#3”, etc.
  3. Initially only ability #1 is enabled. The others are red.
  4. Each # ability has a MULT:YES <> CHOOSE:NUMCHOICES=1 of, for example, rogue talents.
  5. As each # ability is added, regardless of which choice is made, the next # ability becomes enabled.

 

So for example from a new character, only #1 is enabled. The user chooses “#1 (Bleeding Attack)”. Then #2 becomes enabled. The user adds “#2 (Offensive Defense)” and #3 becomes enabled. Etc. The result is, for example:

 

LIST OF ROGUE TALENTS

- #1 (Bleeding Attack)

- #2 (Offensive Defense)

- #3 (Distracting Attack)

 

 

Andrew Maitland
 

I suppose so, but why? What rules construct is driving this design?

On 5/9/2019 11:25 PM, markjmeans wrote:

Does anyone know how to make an ability category function as an ordered list of choices?

�

  1. An ability category of LIST OF ROGUE TALENTS.
  2. Abilities that can be added to that ability category are numbered abilities �#1�, �#2�, �#3�, etc.
  3. Initially only ability #1 is enabled. The others are red.
  4. Each # ability has a MULT:YES <> CHOOSE:NUMCHOICES=1 of, for example, rogue talents.
  5. As each # ability is added, regardless of which choice is made, the next # ability becomes enabled.

�

So for example from a new character, only #1 is enabled. The user chooses �#1 (Bleeding Attack)�. Then #2 becomes enabled. The user adds �#2 (Offensive Defense)� and #3 becomes enabled. Etc. The result is, for example:

�

LIST OF ROGUE TALENTS

- #1 (Bleeding Attack)

- #2 (Offensive Defense)

- #3 (Distracting Attack)

�

�

mike55young@...
 

Sounds like he is trying to do dependencies in talents (or possibly in feats) a bit more efficiently? Only thing is that this idea assumes a single dependency which isn't always the case.

@Ferret_Dave
 

Have each ability have a PREVAR check, and have the appropriate prior ability increment the var?

markjmeans
 

PREVAR is interesting and would sort-of work right. However, the VAR is global and could be modified by something else. But it creates a weird effect when editing an entry that is not the last one. i.e. user has #1 through #10 already added and then discovers there was a mistake for #3. So removes #3 to make a change. With an incremented VAR implementation it would decrement the VAR which would make #10 invalid instead of #4. If each # ability had it’s own VAR or ABILITY tag with a hidden ability to PREABILITY on it increases memory usage.

 

I tried doing this with PREABILITY but either I have something wrong, or PREABILITY cannot determine if an ability with an unspecified CHOOSE has been selected.

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of ferret.griffin+io via Groups.Io
Sent: Friday, May 10, 2019 04:55
To: mike55young@...; main@pcgen.groups.io
Subject: Re: [pcgen] DATA question

 

Have each ability have a PREVAR check, and have the appropriate prior ability increment the var?

markjmeans
 

I’m not truing to modify any feats or talents, that was just an example. There is a situation in PFS that would benefit from an ordered list, but rather than getting bogged down in unimportant details, I asked in a more generic way. Plus a generic solution could be useful if any other situation arises that could benefit from an implementation of an ordered list.

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of mike55young@...
Sent: Friday, May 10, 2019 00:26
To: Andrew Maitland <drew0500@...>; main@pcgen.groups.io
Subject: Re: [pcgen] DATA question

 

Sounds like he is trying to do dependencies in talents (or possibly in feats) a bit more efficiently? Only thing is that this idea assumes a single dependency which isn't always the case.

Andrew Maitland
 

The solution is simple. No PREVAR, but a hard PREABILITY:1,CATEGORY=blah,Name of Ability Or TYPE with uniqueID

#1

    KEY:TheTracker_1

    CATEGORY:Special Ability

    TYPE:TheTracker_1

    CHOOSE:...

    MULT:YES

    STACK:NO

#2

    KEY:TheTracker_2

    CATEGORY:Special Ability

    PREABILITY:1,CATEGORY=Special Ability,TheTracker_1,TYPE.TheTracker_1

    CHOOSE:...

    MULT:YES

    STACK:NO


Easy peasy. You choose whether KEY or TYPE is your method so you aren't checking for 2 things to keep it clean, but that's the basic concept.

On 5/10/2019 7:37 AM, markjmeans wrote:

I’m not truing to modify any feats or talents, that was just an example. There is a situation in PFS that would benefit from an ordered list, but rather than getting bogged down in unimportant details, I asked in a more generic way. Plus a generic solution could be useful if any other situation arises that could benefit from an implementation of an ordered list.

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of mike55young@...
Sent: Friday, May 10, 2019 00:26
To: Andrew Maitland <drew0500@...>; main@pcgen.groups.io
Subject: Re: [pcgen] DATA question

 

Sounds like he is trying to do dependencies in talents (or possibly in feats) a bit more efficiently? Only thing is that this idea assumes a single dependency which isn't always the case.

@Ferret_Dave
 

and this is why Andrew rules the data ;-)