PCGen :: An RPG Character Generator

[ http://jira.pcgen.org/browse/NEWTAG-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11822#action_11822 ] 

Andrew Maitland commented on NEWTAG-246:
----------------------------------------

Forbidden VARLIST/VARTYPE would be 'PC', 'LIST' and anything else that is a MAGIC word used in the CHOOSERs.

> DEFINE - Add 'VARLIST=' or 'VARTYPE' 
> -------------------------------------
>
>                 Key: NEWTAG-246
>                 URL: http://jira.pcgen.org/browse/NEWTAG-246
>             Project: New Tag
>          Issue Type: Modify Token
>          Components: LST Tag
>            Reporter: Andrew Maitland
>
> After reviewing the NEWTAG proposals 90 and 91, it would seem prudent to add more to keep the list manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.
> Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?
> I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.
> DEFINE:VARLIST=x.x|y|z
> x = Text (Defines the LIST/TYPE this Var belongs to)
> z = Text (Defines the Variable Name)
> z = numerical or formula (Defines the starting Variable Number or Formula)
> Example:
> DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
>   Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list
> DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
>   Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.
> Usage for the New Choose Proposal would:
>    CHOOSE:VARIABLE|VARLIST=AbilityDC
>       Would return any Variable listed as 'AbilityDC'
> BONUS:VAR|%LIST|2
>   Would add 2 to the Chosen Variable Name.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.pcgen.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.pcgen.org/browse/NEWTAG-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Maitland updated NEWTAG-246:
-----------------------------------

    Description: 
After reviewing the NEWTAG proposals 90 and 91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.

Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?

I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.

DEFINE:VARLIST=x.x|y|z

x = Text (Defines the LIST/TYPE this Var belongs to)
z = Text (Defines the Variable Name)
z = numerical or formula (Defines the starting Variable Number or Formula)

Example:

DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
  Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list

DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
  Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.

Usage for the New Choose Proposal would:
   CHOOSE:VARIABLE|VARLIST=AbilityDC
      Would return any Variable listed as 'AbilityDC'

BONUS:VAR|%LIST|2
  Would add 2 to the Chosen Variable Name.

NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.

  was:
After reviewing the NEWTAG proposals 90 and 91, it would seem prudent to add more to keep the list manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.

Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?

I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.

DEFINE:VARLIST=x.x|y|z

x = Text (Defines the LIST/TYPE this Var belongs to)
z = Text (Defines the Variable Name)
z = numerical or formula (Defines the starting Variable Number or Formula)

Example:

DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
  Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list

DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
  Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.

Usage for the New Choose Proposal would:
   CHOOSE:VARIABLE|VARLIST=AbilityDC
      Would return any Variable listed as 'AbilityDC'

BONUS:VAR|%LIST|2
  Would add 2 to the Chosen Variable Name.


> DEFINE - Add 'VARLIST=' or 'VARTYPE' 
> -------------------------------------
>
>                 Key: NEWTAG-246
>                 URL: http://jira.pcgen.org/browse/NEWTAG-246
>             Project: New Tag
>          Issue Type: Modify Token
>          Components: LST Tag
>            Reporter: Andrew Maitland
>
> After reviewing the NEWTAG proposals 90 and 91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.
> Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?
> I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.
> DEFINE:VARLIST=x.x|y|z
> x = Text (Defines the LIST/TYPE this Var belongs to)
> z = Text (Defines the Variable Name)
> z = numerical or formula (Defines the starting Variable Number or Formula)
> Example:
> DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
>   Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list
> DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
>   Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.
> Usage for the New Choose Proposal would:
>    CHOOSE:VARIABLE|VARLIST=AbilityDC
>       Would return any Variable listed as 'AbilityDC'
> BONUS:VAR|%LIST|2
>   Would add 2 to the Chosen Variable Name.
> NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.pcgen.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.pcgen.org/browse/NEWTAG-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Dempsey updated NEWTAG-246:
---------------------------------

    Description: 
After reviewing the proposals NEWTAG-90 and NEWTAG 91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.

Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?

I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.

DEFINE:VARLIST=x.x|y|z

x = Text (Defines the LIST/TYPE this Var belongs to)
z = Text (Defines the Variable Name)
z = numerical or formula (Defines the starting Variable Number or Formula)

Example:

DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
  Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list

DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
  Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.

Usage for the New Choose Proposal would:
   CHOOSE:VARIABLE|VARLIST=AbilityDC
      Would return any Variable listed as 'AbilityDC'

BONUS:VAR|%LIST|2
  Would add 2 to the Chosen Variable Name.

NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.

  was:
After reviewing the NEWTAG proposals 90 and 91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.

Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?

I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.

DEFINE:VARLIST=x.x|y|z

x = Text (Defines the LIST/TYPE this Var belongs to)
z = Text (Defines the Variable Name)
z = numerical or formula (Defines the starting Variable Number or Formula)

Example:

DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
  Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list

DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
  Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.

Usage for the New Choose Proposal would:
   CHOOSE:VARIABLE|VARLIST=AbilityDC
      Would return any Variable listed as 'AbilityDC'

BONUS:VAR|%LIST|2
  Would add 2 to the Chosen Variable Name.

NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.


> DEFINE - Add 'VARLIST=' or 'VARTYPE' 
> -------------------------------------
>
>                 Key: NEWTAG-246
>                 URL: http://jira.pcgen.org/browse/NEWTAG-246
>             Project: New Tag
>          Issue Type: Modify Token
>          Components: LST Tag
>            Reporter: Andrew Maitland
>
> After reviewing the proposals NEWTAG-90 and NEWTAG 91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.
> Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?
> I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.
> DEFINE:VARLIST=x.x|y|z
> x = Text (Defines the LIST/TYPE this Var belongs to)
> z = Text (Defines the Variable Name)
> z = numerical or formula (Defines the starting Variable Number or Formula)
> Example:
> DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
>   Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list
> DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
>   Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.
> Usage for the New Choose Proposal would:
>    CHOOSE:VARIABLE|VARLIST=AbilityDC
>       Would return any Variable listed as 'AbilityDC'
> BONUS:VAR|%LIST|2
>   Would add 2 to the Chosen Variable Name.
> NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.pcgen.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.pcgen.org/browse/NEWTAG-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Dempsey updated NEWTAG-246:
---------------------------------

    Description: 
After reviewing the proposals NEWTAG-90 and NEWTAG-91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.

Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?

I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.

DEFINE:VARLIST=x.x|y|z

x = Text (Defines the LIST/TYPE this Var belongs to)
z = Text (Defines the Variable Name)
z = numerical or formula (Defines the starting Variable Number or Formula)

Example:

DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
  Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list

DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
  Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.

Usage for the New Choose Proposal would:
   CHOOSE:VARIABLE|VARLIST=AbilityDC
      Would return any Variable listed as 'AbilityDC'

BONUS:VAR|%LIST|2
  Would add 2 to the Chosen Variable Name.

NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.

  was:
After reviewing the proposals NEWTAG-90 and NEWTAG 91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.

Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?

I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.

DEFINE:VARLIST=x.x|y|z

x = Text (Defines the LIST/TYPE this Var belongs to)
z = Text (Defines the Variable Name)
z = numerical or formula (Defines the starting Variable Number or Formula)

Example:

DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
  Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list

DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
  Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.

Usage for the New Choose Proposal would:
   CHOOSE:VARIABLE|VARLIST=AbilityDC
      Would return any Variable listed as 'AbilityDC'

BONUS:VAR|%LIST|2
  Would add 2 to the Chosen Variable Name.

NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.


> DEFINE - Add 'VARLIST=' or 'VARTYPE' 
> -------------------------------------
>
>                 Key: NEWTAG-246
>                 URL: http://jira.pcgen.org/browse/NEWTAG-246
>             Project: New Tag
>          Issue Type: Modify Token
>          Components: LST Tag
>            Reporter: Andrew Maitland
>
> After reviewing the proposals NEWTAG-90 and NEWTAG-91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.
> Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?
> I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.
> DEFINE:VARLIST=x.x|y|z
> x = Text (Defines the LIST/TYPE this Var belongs to)
> z = Text (Defines the Variable Name)
> z = numerical or formula (Defines the starting Variable Number or Formula)
> Example:
> DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
>   Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list
> DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
>   Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.
> Usage for the New Choose Proposal would:
>    CHOOSE:VARIABLE|VARLIST=AbilityDC
>       Would return any Variable listed as 'AbilityDC'
> BONUS:VAR|%LIST|2
>   Would add 2 to the Chosen Variable Name.
> NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.pcgen.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.pcgen.org/browse/NEWTAG-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11827#action_11827 ] 

James Dempsey commented on NEWTAG-246:
--------------------------------------

We should keep the grouping of variables separate from defining the variable. This allows variable lists to be created at any time, not just when the variable is created. In that case you would not want to use DEFINE as the tag, but maybe just VARLIST. The word type should not occur in the syntax.

While this would make proposals like the variable choosers neater, I don't think it will do much to stop the wrong variables being bonused etc. 

> DEFINE - Add 'VARLIST=' or 'VARTYPE' 
> -------------------------------------
>
>                 Key: NEWTAG-246
>                 URL: http://jira.pcgen.org/browse/NEWTAG-246
>             Project: New Tag
>          Issue Type: Modify Token
>          Components: LST Tag
>            Reporter: Andrew Maitland
>
> After reviewing the proposals NEWTAG-90 and NEWTAG-91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.
> Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?
> I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.
> DEFINE:VARLIST=x.x|y|z
> x = Text (Defines the LIST/TYPE this Var belongs to)
> z = Text (Defines the Variable Name)
> z = numerical or formula (Defines the starting Variable Number or Formula)
> Example:
> DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
>   Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list
> DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
>   Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.
> Usage for the New Choose Proposal would:
>    CHOOSE:VARIABLE|VARLIST=AbilityDC
>       Would return any Variable listed as 'AbilityDC'
> BONUS:VAR|%LIST|2
>   Would add 2 to the Chosen Variable Name.
> NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.pcgen.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.pcgen.org/browse/NEWTAG-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11828#action_11828 ] 

Andrew Maitland commented on NEWTAG-246:
----------------------------------------

In discussion with James this is the updated proposal:

Summary:
DEFINE will add an optional add on called 'ALIAS' that will display in the Chooser UI Box instead of the original Variable Name.
This is backwards compatible, no tag means the default display is the variable name.

A new standalone Tag will be would created called 'VARLIST' which will add the Vars to "lists" that can be referenced in choosers.

The New Tags would appear as such:

DEFINE:x|y|z="a"

x = Text [Variable Name]
y = Number or Formula
z = ALIAS (Optional)
a = Alias Name to be displayed

DEFINE:VarName|0|ALIAS="Var Name in a Chooser"


VARLIST:x|y|y

x = Text [Existing Variable Name]
y = Text [ListName to be created or added to]


VARLIST:DodgeMonkey|Special Abilities|MonsterDC

Would add/create the lists "Special Abilities" and "MonsterDC" to the variable 'DodgeMonkey'



> DEFINE - Add 'VARLIST=' or 'VARTYPE' 
> -------------------------------------
>
>                 Key: NEWTAG-246
>                 URL: http://jira.pcgen.org/browse/NEWTAG-246
>             Project: New Tag
>          Issue Type: Modify Token
>          Components: LST Tag
>            Reporter: Andrew Maitland
>
> After reviewing the proposals NEWTAG-90 and NEWTAG-91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.
> Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?
> I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.
> DEFINE:VARLIST=x.x|y|z
> x = Text (Defines the LIST/TYPE this Var belongs to)
> z = Text (Defines the Variable Name)
> z = numerical or formula (Defines the starting Variable Number or Formula)
> Example:
> DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
>   Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list
> DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
>   Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.
> Usage for the New Choose Proposal would:
>    CHOOSE:VARIABLE|VARLIST=AbilityDC
>       Would return any Variable listed as 'AbilityDC'
> BONUS:VAR|%LIST|2
>   Would add 2 to the Chosen Variable Name.
> NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.pcgen.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.pcgen.org/browse/NEWTAG-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Maitland updated NEWTAG-246:
-----------------------------------

    Summary: Proposal Master - Expand DEFINE and add new tag 'VARLIST'  (was: DEFINE - Add 'VARLIST=' or 'VARTYPE' )

> Proposal Master - Expand DEFINE and add new tag 'VARLIST'
> ---------------------------------------------------------
>
>                 Key: NEWTAG-246
>                 URL: http://jira.pcgen.org/browse/NEWTAG-246
>             Project: New Tag
>          Issue Type: Modify Token
>          Components: LST Tag
>            Reporter: Andrew Maitland
>
> After reviewing the proposals NEWTAG-90 and NEWTAG-91, it would seem prudent to add more functionality to keep the list of vars returned manageable and prevent accidental bonusing and really drive the Help Desk monkeys crazy.
> Today - 'DEFINE:Blah|0'  is the standard, but perhaps 'DEFINE:VARLIST=x|Blah|0' might be a better idea. It would mean redefining several vars, but it would prevent the wrong vars from getting touched, things that would throw many variable numbers we rely on being precise out of whack. Since I know it will happen, we should include the ability to define multiple lists, I think period separated is acceptable in this instance?
> I like VARLIST but VARTYPE is also acceptable to me. I'll use VARLIST in the following examples for now.
> DEFINE:VARLIST=x.x|y|z
> x = Text (Defines the LIST/TYPE this Var belongs to)
> z = Text (Defines the Variable Name)
> z = numerical or formula (Defines the starting Variable Number or Formula)
> Example:
> DEFINE:VARLIST=AbilityDC|BigBadMonsterDC|0
>   Sets the BigBadMonster DC to 0 and assigns it to the 'AbilityDC' list
> DEFINE:VARLIST=AbilityDC.MonsterAbilityDC|SecondBigBadMonsterDC|0
>   Sets the SecondBigBadMonster DC to 0, and assigns it to the 'AbilityDC' and 'MonsterAbilityDC' lists.
> Usage for the New Choose Proposal would:
>    CHOOSE:VARIABLE|VARLIST=AbilityDC
>       Would return any Variable listed as 'AbilityDC'
> BONUS:VAR|%LIST|2
>   Would add 2 to the Chosen Variable Name.
> NOTE: Backwards compatibility would be maintained as 'VARLIST=' is an optional tag.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.pcgen.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira