...
ToDo: assault rifles with strength
Accessories -
...
“usage”
Sometimes items are not intended to be used on their own, but added into a slot of an existing item (see #modifications ) Modifications ) - this is where the <usage> element comes into play.
Code Block | ||
---|---|---|
| ||
<usage mode="EMBEDDED" slot="OPTICAL" size="3"/> |
This signals that the item is to be embedded into the optical slot of an item and requires 3 points of capacity.
You can have more than one <usage> element inside an item.
Code Block | ||
---|---|---|
| ||
<item avail="3" price="1400" id="gyro_mount" type="ACCESSORY" subtype="WEAPON_ACCESSORY">
<usage mode="EMBEDDED" slot="UNDER"/>
<usage mode="EMBEDDED" slot="CYBERLIMB_IMPLANT" size="8"/>
</item> |
There are 3 valid usage modes:
CARRIED (this one is implicit, if no <usage> is definied )
EMBEDDED - for all kinds of accessories (requires slot= and supports size= attributes)
IMPLANTED - for all bodyware (items costing essence)
Info |
---|
If no |
Items with variants
Variants are different versions of the same item. If an item has variants, it copies all attributes from the main item and allows you to override those attributes or even add new ones.
A good example is the “Flare Compensation” in Shadowrun 6. This is a visual enhancement that can be added as an accessory to OPTICAL slots (contacts, glasses …) or as an helmet accessory.
...
You will note that the the cyberware version is significantly expensive and has a different availability. Also both versions are considered augmentations and are subject to cost changes e.g. for Deltaware - which does not apply to the regular version.
We decide to consider the normal visual enhancement the “regular” version with two use cases (OPTICAL slot or HELMET_ACCESSORY slot). We than need two different versions for the cyberware - one that costs capacity and one that costs essence.
Code Block | ||
---|---|---|
| ||
<item avail="1" price="250" id="flare_compensation" type="ACCESSORY" subtype="VISION_ENHANCEMENT"> <usage mode="EMBEDDED" slot="OPTICAL" size="1"/> <variant id="helmet"> <usage mode="EMBEDDED" slot="HELMET_ACCESORY" size="1"/> </variant> <variant id="cybereye"> <usage mode="EMBEDDED" slot="CYBEREYE_IMPLANT" size="1"/> <attrdef id="PRICE" value="1000"/> <attrdef id="AVAILABILITY" value="2"/> <flag>AUGMENTATION</flag> </variant> <variant id="bodyware"> <usage mode="IMPLANTED" /> <attrdef id="PRICE" value="1000"/> <attrdef id="AVAILABILITY" value="2"/> <attrdef id="ESSENCECOST" value="0.1"/> <flag>AUGMENTATION</flag> </variant> </item> |
Now we have an item with a variant “cybereye” and one called “bodyware”. The <flag> line is specific to this case and flags the items to be subject to cost changes due to augmentation grades.
Variants can have attrdef
, usage
and flags
on their own. They also support the shortcuts like weapon
, armor
…
Dynamic Items: Choices and Formulas
Not all items are simple with static values. Often you have to make a decision (e.g. the rating) when adding the item and have values that depend on that decisions (like Cost = Rating * 100). This is where <choices> will help you.
...
Code Block | ||
---|---|---|
| ||
<item id="bow" price="100" type="WEAPON_RANGED" subtype="BOWS">
<choices>
<choice
uuid="adeb159c-6ca3-407b-8641-c76f9b29a49c"
type="ITEM_ATTRIBUTE"
ref="RATING"
options="1,2,3,4,5,6,7,8,9,10,11,12,13,14"/>
</choices>
<requires>
<valuereq type="ATTRIBUTE" ref="STRENGTH" min="$RATING"/>
</requires>
<modifications>
<itemmod type="HOOK" ref="TOP"/>
<itemmod type="HOOK" ref="UNDER"/>
</modifications>
<attrdef id="PRICE" value="$RATING*10 +100" />
<attrdef id="DAMAGE" value="$RATING/2 P" />
<attrdef id="ATTACK_RATING" value="$RATING/2,$RATING,$RATING/4,," />
<attrdef id="AVAILABILITY" value="$RATING/3 L" />
<weapon skill="athletics" spec="athletics/archery" />
</item> |
The choices
block defines one choice (there can be more choices) that will let you decide an item attribute (those you define via attrdef ), specifically that or the RATING. You can choose the ratings from 1-14. The UUID given is to store your decision in the character.
You can access item attributes in attrdef
and modifications and requirements using the $ infront of it. So $RATING
will be replaced with the rating - or in this case the rating decision.
It is possible to build VERY simple formulas with basic operations (Addition, Substraction, Division, Multiplication).
The application will ensure that decisions are made all present when an item is added to the character.
Dynamic table lookups
Sometimes values depending on a (rating) choice cannot be expressed in a formula.
...
In the example above, the essence can be expressed in a formula, but the other attributes cannot. For this case the attrdef
element has an optional table attribute, which is used after the value attribute has been calculated.
Code Block | ||
---|---|---|
| ||
<item id="cybereye" type="CYBERWARE" subtype="CYBER_EYEWARE">
<choices>
<choice uuid="fcc63c09-5af7-4f00-a2d9-d7c0972597d2" type="ITEM_ATTRIBUTE" ref="RATING" options="1,2,3,4,5"/>
</choices>
<usage mode="IMPLANTED"/>
<attrdef id="ESSENCECOST" value="$RATING*0.1" />
<attrdef id="PRICE" value="$RATING" table="1000,4000,6000,10000,16000"/>
<attrdef id="AVAILABILITY" value="$RATING" table="2,2,3,3,3"/>
<modifications>
<valmod type="HOOK" ref="CYBEREYE_IMPLANT" value="$RATING" table="1,4,8,12,16"/>
<embed type="GEAR" ref="image_link" intoType="HOOK" intoRef="INTERNAL" included="true"/>
</modifications>
</item> |
The $RATING has a range from 1-5. It is used to look up in the table and use that result instead.
Info |
---|
The result of the formula in the |
Note that the table can be used in the attrdef
element as well as in the valmod
modification element.