.CLEARALL Syntax

2008-09-03T19:44:56Z

Eddyanthony: New page: I'd really like a .CLEARALL (to remove everything) instead of .CLEAR in a number of instances... .CLEAR.<whatever directly after) makes sense as well. What I'd like to steer towards, idea...

I'd really like a .CLEARALL (to remove everything) instead of .CLEAR in a number of instances...

.CLEAR.<whatever directly after) makes sense as well. What I'd like to steer towards, ideally, is that if a tag has .CLEAR, that is _all_ it does. A second tag (following on the line) can then add in whatever is needed. Would make things much more intuitive, at least to me.

Future Development

2008-09-03T19:44:01Z

Eddyanthony:

ANY and ALL in Tokens

2008-09-03T01:42:29Z

Eddyanthony: New page: So as one of the cleanup items I'd like to do as I'm swapping out token code in 5.15 is to clean up the "ANY"/"ALL" confusion. It would really be nice to be consistent and only use one of ...

So as one of the cleanup items I'd like to do as I'm swapping out token code in 5.15 is to clean up the "ANY"/"ALL" confusion. It would really be nice to be consistent and only use one of those items (because it makes unparsing a LOT easier)

The question is: Which should we be using?

Just keep in mind that there are multiple types of tokens:

Primary tokens, e.g. Deity's DOMAINS
CHOOSE tokens
PRExxx tokens

It would be really nice to have all of those the same.

TP.

[http://tech.groups.yahoo.com/group/pcgen_experimental/message/10701 Link to the original post]

2008-08-12T19:24:11Z

Eddyanthony:

I was recently asked about how to configure a campaign setting dataset and I had some idea's on the subject so here they are. There are three separate idea's here, one is trackered already, one relates to data configuration and one is a gameMode tag proposal.

First a little background. Campaign setting can be put into two groups: Add-ons and Alters. An add-on setting uses the core material as is and just provides additional campaign specific material. In PCGen these are handled just like any other supplement, an example of this is the Murchad's Legacy Campaign Setting. The other group of campaign settings alters the core material in specific ways, examples of these are the Midnight setting (which has an alternate magic system) and the Players Guide to Arcanis (which alters many of the base classes). To accomplish these alterations both of these datasets load parts of the core data, leaving out what is not used in the setting or altering it as needed. One of the problems here is that is may not be intuitive to the user that the set should be loaded on it own and should not be loaded with the core data.

On to the first idea: 
[https://sourceforge.net/tracker/?func=detail&aid=1298910&group_id=25576&atid=384722 PRECAMPAIGN tag for .pcc files] 
This would allow datasets to require or prohibit other specific sets from being loaded with it.

Idea 2 provides a way to configure gameModes so that common supplements can be used. The example here is a Campaign setting which is different enough to require it's own gameMode but still has enough in common with the game it's based on to allow the use of other datasets with it. In that case you would want to see the other sets in that gameMode but not the core data since the campaign setting already loads it.

The way to do this is to simply change the GAMEMODE tags in the core datasets to something different and then configure the gameMode to see both.

I'll use Legends of Excalibur as an example (and assume you might want to load other datasets with it). First the RSRD sets would be changed to use GAMEMODE:35e_Core, next 35e miscinfo.lst would be changed to ALLOWEDMODES:35e|35e_Core, next the Legends of Excalibur gameMode would be changed to ALLOWEDMODES:LoE|35e

The result of this is when you are in the 35e gameMode you see everything you see now but when you are in Legends of Excalibur you see that set as well as all the 35e supplements but you don't see the RSRD core sets.

Idea 3 is way way to set specific sources to be in the right pane of the sources tab when you enter that gameMode. Two (optional) tags would be added to the miscinfo.lst file:

DEFAULTCAMPAIGN:x|x - specifies datasets which are recommended in this gameMode, the will appear in the right pane in the sources tab but can be removed by the user if not desired.

REQUIREDCAMPAIGN:x|x - specifies datasets which are required in this game Mode, it will appear in the right pane on the sources tab and cannot be removed.

I'm not sure code-wise if it would be better to set by the name (as set by the CAMPAIGN tag) or by file path, I'd go with which ever the CMs recommend.

This would help with new users as we could set the full RSRD set to default into the load pane making it just a little easier to get rolling. For a campaign setting gameMode you could then set the campaign setting as a required dataset which also lessens what the user needs to figure out.

This idea was proposed on pcgen_experimental [http://tech.groups.yahoo.com/group/pcgen_experimental/message/5413 in this thread]. 
Some of these ideas are currently being developed, PRECAMPAIGN has been implemented.

Handling campaign settings

2008-08-12T19:18:24Z

Eddyanthony: New page: I was recently asked about how to configure a campaign setting dataset and I had some idea's on the subject so here they are. There are three separate idea's here, one is trackered already...

LIST/CHOICE usage

2008-08-12T19:12:16Z

Eddyanthony: New page: After too many years, we need to work out the issue of LIST, %LIST, CHOICE and %CHOICE. Why do we need them, Where do we Need them and DO we need them. A) Can we condense these four into...

After too many years, we need to work out the issue of LIST, %LIST, CHOICE and %CHOICE.

Why do we need them, Where do we Need them and DO we need them.

A) Can we condense these four into two or even one tag? 
B) If we can't condense them down, can we understand the proper usage. 
C) If the code and Docs are contradicting we should hash out in a proper manner HOW we want them to work, Where they work, how they work.

Basically, this should be part of the effort to clean up the Code, Data and Docs and understand in all three areas EXACTLY what is intended, expected and will result in the usage of the tag(s)

2008-07-15T18:55:03Z

Eddyanthony:

This specifically addresses the need to model powers in 4e with ability objects. Powers use a format with a number of structured elements not unlike spells, such as Duration, Range, Attack, Hit, Miss, Sustain, etc.. The problem being that Ability Objects don't have tags to hold these stat values, other than maybe cramming them all in the DESC.

Rather than creating a number of specific tags for this purpose I propose we create one tag that has the versatility to hold all the stats. Basically all these stats need the same thing (hold a text string). This is conceptually similar to the QUALITY tag we made for use in equipment

----

Tag Name: ASPECT:x|y|z|z

Variables Used (x): Text (Name of the aspect) 
Variables Used (y): Text (Value of the aspect) 
Variables Used (z): Number or formula (Optional, values to replace % in y)

What it does:

Determines that the feat or ability has the aspect and sets it's value in that feat or ability.
 Can be used multiple times within an ability but each time it should be a new aspect (name).
 The text in the y variable can use %z for replacing numerical values set by the z variable, %1 is replaced by the first z, %2 is replaced by the second z, etc..
 The y text can also use other special variables, also usable in the DESC tag:

:%CHOICE - Will replace the first associated choice in the object. 
:%LIST - Will substitute all choices comma separated into that parameter. 
:%NAME - The OUTPUTNAME or name of the object this DESC tag is in.

ASPECT tags can be modified by .MODing the feat or ability and inserting a
new ASPECT tag, Since each aspect name can hold only one value per ability
.MODing a new ASPECT tag will overwrite the only value of the aspect by that
name in the feat

Examples:

:<tt>ASPECT:Action Type|Standard Action 
:ASPECT:Attack Type|Melee weapon 
:ASPECT:Target|One creature 
:ASPECT:Attack|Strength vs. AC</tt>

And using variable substitution:

:<tt>ASPECT:Attack Type|Ranged %1|PowerRange 
:ASPECT:Effect|Double damage to %CHOICE creatures</tt>

Here's how the Lance of Faith cleric power could be modeled:

<tt>
:Lance of Faith 
:PREVARGTEQ:ClericLevel,1 
:DESC:A brilliant ray of light sears your foe with golden radiance 
:DEFINE:LanceofFaithDamageDie|1 
:DEFINE:LanceofFaithRange|5 
:BONUS:VAR|LanceofFaithDamageDie|1|PRELEVEL:MIN=21 
:CATEGORY:Power 
:TYPE:At-Will.Divine.Implement.Radiant 
:ASPECT:Action Type|Standard Action 
:ASPECT:Attack Type|Ranged %1|LanceofFaithRange 
:ASPECT:Target|One creature 
:ASPECT:Attack|Wisdom vs. Reflex 
:ASPECT:Hit|1%d8 + 2% radiant damage, and one ally you can see gains a +2 power bonus to his or her next attack roll against the target|LanceofFaithDamageDie|WIS</tt>

----

Output: In the GUI when selecting an ability all the aspects are displayed
in a string in the information pane. For example, here is how the first 4
examples above might appear in the info pane:

:Aspects: Action Type: Standard Action, Attack Type: Melee weapon, Target:
One creature, Attack: Strength vs. AC

On the OS we'll need some new tokens to support this tag. There are a number
of feat and ability tokens which use the same format but target different
groups of abilities. This is the list of tokens which will need to be revised:

:ABILITY 
:ABILITYALL 
:ABILITYAUTO 
:FEAT 
:FEATALL 
:FEATAUTO 
:VABILITY 
:VFEAT

These tokens all have DESC as a variable, the new variables will be used in the same location in the token that DESC is used. Each will have the following additions:

ASPECT - Will output a text string of all the aspects associated with the
ability in the same format as the GUI uses as described above.

ASPECT.<number> - Will output the name/value of the aspect of that number on
a 0 based index.

ASPECT.<text> - Will output the value of the named aspect.

ASPECTCOUNT - Outputs the total number of Aspects associated with the ability.

HASASPECT.<text> - Reports a Boolean result on the named aspect.

Examples using the Lance of Faith example from above:

:<tt>ABILITY.Power.0.ASPECT</tt> 
Outputs: "Action Type: Standard Action, Attack Type: Ranged 5, Target: One
creature, Attack: Wisdom vs. Reflex, Hit: 2d8 + 4 radiant damage, and one
ally you can see gains a +2 power bonus to his or her next attack roll
against the target"

:<tt>ABILITY.Power.0.ASPECT.0</tt> 
Outputs: "ActionType: Standard Action"

:<tt>ABILITY.Power.0.ASPECT.Attack Type</tt> 
Outputs: "Ranged 5"

:<tt>ABILITY.Power.0.ASPECTCOUNT</tt> 
Outputs: "5"

:<tt>ABILITY.Power.0.HASASPECT.Miss</tt> 
Outputs: "N"

Additional Weapon Damage

2008-07-15T18:05:27Z

Eddyanthony:

Additional Weapon Damage

2008-07-15T18:03:56Z

Eddyanthony:

Additional Weapon Damage

2008-07-15T18:02:08Z

Eddyanthony:

Here's something simple that PCGen can't currently handle, some weapons
deal additional damage beyond the standard damage roll. Flaming swords
do fire damage, many monsters attacks inject poison. This is displayed
in most stat blocks right inline with the normal damage, examples:

1d8 plus 1d6 fire 
1d6 plus poison

Currently we put this data in the equipments SPROP or an SAB tag if it's
a monster. I would like to see a way to do this in PCGen, we need
something in addition to SPROP as that tag is a dumping ground for many
things besides just additional damage. I think it can be a text string
as there are not many cases where there is something that modifies the
secondary damage value. In those rare cases where that may be needed we
could make the new tag accept variable substitution like SPROP and SAB do.

ADDITIONALDAMAGE:x 
x = Text (Additional damage the weapon deals) 
This would be a short string (like "1d6 Acid damage") leaving any longer
descriptions and details to an SPROP or ability DESC.

Examples:

:<tt>ADDITIONALDAMAGE:Poison 
:ADDITIONALDAMAGE:1d6 Cold 
:ADDITIONALDAMAGE:%d4 Sonic|TL</tt>

We may also need a parallel tag for double weapons: 
:<tt>ALTADDITIONALDAMAGE:x</tt>

Now we need a way to add this property to natural weapons, I propose we
add an additional optional variable to NATURALATTACKS at the end where
the text can be added, example:

:<tt>NATURALATTACKS:Claw,Weapon.Natural.Melee.Slashing,*2, 1d4,1d6 Acid</tt>

The new variable for NATURALATTACKS will accept a single entry and no variable substitution.

Next we need a new sub token for the WEAPON OS token, ADDITIONALDAMAGE
which outputs the value of ADDITIONALDAMAGE for that weapon.

EQMOD's can have ADDITIONALDAMAGE tags to add these properties to weapons. ADDITIONALDAMAGE is additive in the same way that SPROP is (multiple tags are grouped into a single, comma separated string). This tag is pretty much identical to SPROP except for it's name and the additional ability to add this property to NATURALATTACKS.