Difference between revisions of "Race Racial Trait Swapping"
Tom Parker (talk | contribs) (→Filler Object) |
Tom Parker (talk | contribs) (→Considerations) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 35: | Line 35: | ||
Let's assume we have a Racial Trait "Super" that replaces "Good" and "Lucky". | Let's assume we have a Racial Trait "Super" that replaces "Good" and "Lucky". | ||
| + | |||
| + | This presumes we have done: | ||
| + | <pre> | ||
| + | DYNAMICSCOPE:RACEFEATURE | ||
| + | </pre> | ||
| + | |||
| + | In VARIABLE file: | ||
| + | <pre> | ||
| + | LOCAL:RACE|RACEFEATURE=Feature_Lucky | ||
| + | LOCAL:RACE|RACEFEATURE=Feature_Good | ||
| + | </pre> | ||
So on our race we had: | So on our race we had: | ||
| Line 60: | Line 71: | ||
==Array== | ==Array== | ||
| − | One possible alternative would be to have an ARRAY[ | + | One possible alternative would be to have an ARRAY[RACEFEATURE] that contains all of the traits for a given level. |
| − | So on our | + | In VARIABLE file: |
| + | <pre> | ||
| + | LOCAL:RACE|ARRAY[RACEFEATURE]=Features | ||
| + | </pre> | ||
| + | |||
| + | So on our race we had: | ||
<pre> | <pre> | ||
| − | MODIFY: | + | MODIFY:Features|ADD|Default_Feature_Lucky+Default_Feature_Good |
</pre> | </pre> | ||
On our Trait we can do: | On our Trait we can do: | ||
<pre> | <pre> | ||
| − | MODIFYOTHER: | + | MODIFYOTHER:RACE|Elf|Features|SET|SuperFeature|PRIORITY=400 |
</pre> | </pre> | ||
===Considerations=== | ===Considerations=== | ||
| − | In this case, we need to look at what it would be like for a class to replace only one of the | + | In this case, we need to look at what it would be like for a class to replace only one of the features. |
On our Trait we can do: | On our Trait we can do: | ||
<pre> | <pre> | ||
| − | MODIFYOTHER: | + | MODIFYOTHER:RACE|Elf|Features|SET|value()-Default_Feature_Good+Default_Feature_Better|PRIORITY=400 |
</pre> | </pre> | ||
or alternatively: | or alternatively: | ||
<pre> | <pre> | ||
| − | MODIFYOTHER: | + | MODIFYOTHER:RACE|Elf|Features|ADD|Default_Feature_Better|PRIORITY=400 |
| − | MODIFYOTHER: | + | MODIFYOTHER:RACE|Elf|Features|REMOVE|Default_Feature_Good|PRIORITY=400 |
</pre> | </pre> | ||
| Line 90: | Line 106: | ||
# We have avoided adding an empty shell to the PC | # We have avoided adding an empty shell to the PC | ||
# We are making (risky?) assumptions of what we are replacing | # We are making (risky?) assumptions of what we are replacing | ||
| − | # We start to get into order of operations problems between Archetypes that | + | # We start to get into order of operations problems between features that touch different features (think of this more broadly in terms of Archetypes that can impact different items at the same level both being usable together), so it increases the cross-data interaction |
In general, I think this is a bad idea due to the built-in assumptions. | In general, I think this is a bad idea due to the built-in assumptions. | ||
Latest revision as of 03:22, 9 March 2018
Background
Note that the basics for Replacing Archetype Controls is available
Challenge
Race is granted 'default' traits as a standard. Paizo has introduced two systems of concern:
- "Race Package" where a race is granted specific non-default traits
- "Race Package" where a race if granted a choice between two or more additional choices
- Racial Trait that is chosen by the player actually removes 2 or more existing default traits
Potential Solutions Challenge #1
This seems straight-forward to me. The Race Package can simply have:
MODIFYOTHER:RACE|Elf|Feature_Good|SET|DifferentFeature|PRIORITY=400
The variable assignments are very similar to what is shown in Replacing Archetype Controls.
Potential Solutions Challenge #2
This involves a choice, thus interacts with SELECTION - A CHOOSE Replacement. This section is deferred until some changes and clarifications are made on that page with respect to how instances will work (there are multiple methods of causing instances and that is not currently clear).
Potential Solutions Challenge #3
I'm not sure there are multiple possible solutions here. I think this is straightforward.
Filler Object
Let's assume we have a Racial Trait "Super" that replaces "Good" and "Lucky".
This presumes we have done:
DYNAMICSCOPE:RACEFEATURE
In VARIABLE file:
LOCAL:RACE|RACEFEATURE=Feature_Lucky LOCAL:RACE|RACEFEATURE=Feature_Good
So on our race we had:
MODIFY:Feature_Lucky|SET|Default_Feature_Lucky MODIFY:Feature_Good|SET|Default_Feature_Good
On our Trait we can do:
MODIFYOTHER:RACE|Elf|Feature_Good|SET|SuperFeature|PRIORITY=400
Then we need to remove Default_L3_Feature_Lucky. I would probably recommend something like:
MODIFYOTHER:RACE|Elf|Feature_Lucky|SET|EmptyFeature|PRIORITY=400
EmptyFeature would then be an object with nothing in it.
Justification
Keep in mind if we have a DYNAMIC of RACEFEATURE (which Default_Feature_Lucky is one implementation) then we need a default value for that object type. So it's already likely that we have an "EmptyFeature" set up to be the default value for a variable of the RACEFEATURE FORMAT.
Array
One possible alternative would be to have an ARRAY[RACEFEATURE] that contains all of the traits for a given level.
In VARIABLE file:
LOCAL:RACE|ARRAY[RACEFEATURE]=Features
So on our race we had:
MODIFY:Features|ADD|Default_Feature_Lucky+Default_Feature_Good
On our Trait we can do:
MODIFYOTHER:RACE|Elf|Features|SET|SuperFeature|PRIORITY=400
Considerations
In this case, we need to look at what it would be like for a class to replace only one of the features.
On our Trait we can do:
MODIFYOTHER:RACE|Elf|Features|SET|value()-Default_Feature_Good+Default_Feature_Better|PRIORITY=400
or alternatively:
MODIFYOTHER:RACE|Elf|Features|ADD|Default_Feature_Better|PRIORITY=400 MODIFYOTHER:RACE|Elf|Features|REMOVE|Default_Feature_Good|PRIORITY=400
Considerations:
- We have avoided adding an empty shell to the PC
- We are making (risky?) assumptions of what we are replacing
- We start to get into order of operations problems between features that touch different features (think of this more broadly in terms of Archetypes that can impact different items at the same level both being usable together), so it increases the cross-data interaction
In general, I think this is a bad idea due to the built-in assumptions.
