Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Item structure

All elements that can be bought for Nuyen use the item element. This is by far the most powerful and most complex XML definition you will encounter.

<item id="my_identifier" lang="en" type="SORT_TYPE" subtype="SORT_SUBTYPE" avail="" price="" modOnly="n" count="n">
  <choices>
    <choice ...>
    ...
  </choices>
  
  <requires>
  </requires>
  
  <!-- Definitions of single attributes>
  <attrdef .../>
  <attrdef .../>
  ...
  
  <!-- Shortcuts for ease of use -->
  <weapon ... />
  <armor .../>
  <matrix .../>
  
  <flag>...</flag>
  <flag>...</flag>
  ...
  
  <usage ...>
  <usage ...>
  ...
  
  <variant id="variant_id" ...>
  </variant>
  <variant id="variant_id" ...>
  </variant>
  ...
  
  <alternate>...</alternate>
  <alternate>...</alternate>
  ...
  
  <modifications>
  </modifications>
</item>

Let us have a look at the item attributes first

  • id - The identifier (required)
    The identifier must be unique for all gear definitions in the whole application.

  • lang - The language (optional)
    A ISO language code. If it is present, it marks this definition as only valid for a specific langauge.

  • type - The major sort category (required)
    This is used to help the user find the item and usually follows the categories from the rulebooks.
    There can only be one sort type per item.

  • subtype - A sort catgory within the major category (required)

More attributes are supported to allow being more compatible with old Genesis datafiles.

  • avail - A shortcut for a the items availability (optional)
    This shortcut definition cannot deal with formulas.

  • price - The cost in Nuyen (optional)
    This shortcut definition does not support formulas

  • modOnly - Modification Only (optional)
    A item with modOnly=”y” can not be selected directly by a user.
    Better use the RESTRICTED flag

  • count - Marks if the object should be countable (optional)
    Better use the COUNTABLE flag

Elements within an <item>

  • attrdef - Attribute Definition
    Used to define a value for a single item attribute.

  • choice(s) - Choices a user needs to make to configure the item.
    Usually this is the items rating, but some items require more decisions.

  • flag - Adds a flag to the item

  • modifications - A list of modifications this item provides to either the character or a parent item (in case of accessories)

  • requires - A list of requirements to use the item and even be able to put in in the inventory

  • usage - How should the item be used? Is it carried? Should it be embedded as an accessory? Or is it an Implant or a not easily reversed modification? In case of accessories, a slot (required) and a size value (optional) can be given.

  • armor, matrix, weapon… - Shortcut elements for easy data input and backward compatibility.

  • variant - List of possible variants of this item.
    For some items, like e.g. flare compensation, do exist multiple variants.

A very simple item

The very basic item

looks like this in XML

<item id="autopicker" subtype="BREAKING" type="ELECTRONICS"/>
  <attrdef id="AVAILABILITY" value="4L"/>
  <attrdef id="PRICE"        value="500"/>
</item>

If you choose the backward compatibility notation, it would be:

<item id="autopicker" avail="4L" price="500" subtype="BREAKING" type="ELECTRONICS"/>

Items with shortcuts

For ease of use and for backward compatibility with Genesis data, there are elements within an item, that replace attribute definitions.

would be written like this:

<item id="fichetti_tiffani_needler" type="WEAPON_FIREARMS" subtype="HOLDOUTS">
  <attrdef id="AVAILABILITY"  value="2"/>
  <attrdef id="PRICE"         value="435"/>
  <attrdef id="DAMAGE"        value="3P"/>
  <attrdef id="ATTACK_RATING" value="10,6,2,,"/>
  <attrdef id="FIREMODES"     value="SS"/>
  <attrdef id="AMMUNITION"    value="4(c)"/>
  <attrdef id="SKILL"         value="firearms"/>
  <attrdef id="SKILL_SPECIALIZATION"  value="firearms/holdouts"/>
</item>

With the use of the shortcuts elements and the <item>-line, this can be shortened to

<item id="fichetti_tiffani_needler" avail="2" price="435" type="WEAPON_FIREARMS" subtype="HOLDOUTS">
   <weapon dmg="3P" attack="10,6,2,," mode="SS" ammo="4(c)" skill="firearms" spec="firearms/holdouts"/>
</item>

Items with modifications

Some items have modifications that should be applied - to either the item itself, the parent item containing the defined item or the character. The most common example is defining slots for accessories

Like all light pistols, the Beretta supports Top or Barrel-mounted accessories

<item avail="2L" price="260" id="beretta_101T" type="WEAPON_FIREARMS" subtype="PISTOLS_LIGHT">
  <modifications>
    <itemmod type="HOOK" ref="TOP"/>
    <itemmod type="HOOK" ref="BARREL"/>
  </modifications>
  <weapon ammo="21(c)" dmg="2P" attack="9,8,6,," mode="SA" skill="firearms" spec="firearms/pistols_light"/>
</item>

The <itemmod> is they key element here - it says that it will modify/provide a Hook (meaning a slot for accessories) of a specific type. Note that both Hooks don’t require a capacity value.

ToDo: Modifications with capacity

Items with requirements

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 ) - this is where the <usage> element comes into play. 

<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.

   <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)

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.

<item avail="1" price="250" id="flare_compensation" type="ACCESSORY" subtype="VISION_ENHANCEMENT">
  <usage mode="EMBEDDED" slot="OPTICAL" size="1"/>
  <usage mode="EMBEDDED" slot="HELMET_ACCESORY" size="1"/>
  <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.

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.

<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.

  • No labels