User:Sunjammer/Item upgrades (draft)
Contents
Item Creation
Item creation (crafting) seems fairly straightforward: the Player collects "junk" from creature drops. The recipes are all in recipes.xls and I believe all we have to do is call the craft function from craft.nss (some how as I've not yet found what file it is included in).
Item Upgrades
Item upgrades seem a little ... um ... more involved.
We'll gloss over the terrible state of the data (since I've just submitted a lengthy bug report on that very subject) and move straight onto the upgrade options, of which there are several:
- item sets
- material types
- runes
- item properties (with corresponding item property power)
- on hit properties (with corresponding on hit power)
Item Sets
Looking at the sys_itemsets_h.nss library it might be that Item Sets are incomplete. Or it might be that I haven't found all the pieces yet. I'll continue assuming the latter since I can always make it my first scripting project ...
Item Sets can add up to two bonuses to any character wearing all the items in that set. The bonuses can be an effect, such as EFFECT_TYPE_FLANK_IMMUNITY, or a property modification such as PROPERTY_ATTRIBUTE_DAMAGE_BONUS. The biggest sets currently defined consist of 4 items.
Technically the "bonuses" could be penalties but that wouldn't be very nice now would it!
The Item Sets are defined in in itemsets.2da which contains the following columns:
ID int 1 Label string Griffon NameStrRef int 9 Slots int 9 Prop1 int 1050 Prop1Value float **** Prop2 int **** Prop2Value float **** Description comment Flank immunity
The Slots column contains a number representing the inventory slots, i.e. the different item types, needed to complete the set. It is a bit mask generated using the formula 2 ^ INVENTORY_SLOT_* for each inventory slot that is used by the set.
For example the Slots value for a set consisting of a helm, gloves and boots would be calculated as follows:
INVENTORY_SLOT_HEAD = 5;
INVENTORY_SLOT_BOOTS = 6;
INVENTORY_SLOT_GLOVES = 7;
Slots = 2^5 + 2^6 + 2^7
= 32 + 64 + 128
= 224
The Prop1 and Prop2 values contain the literal value of an EFFECT_TYPE_* or PROPERTY_* constant. If Prop1Value or Prop2Value is empty then the preceding value represents an effect otherwise it represents a property.
To indicate which item set (if any) an item belongs to there is an an ITEM_SET local variable (default –1) in the default Variables 2da file (var_item.2da). This is simply set to the item set's row number in itemsets.2da.
Material Types & Progression
In the toolset items have a MaterialType and a MaterialProgression property.
The MaterialType list is populated using the Label column in materialtypes.2da (contained in materialtypes.xls). The MaterialProgression list is populated using the Label column in TS_Material.2da (contained in TS_System.xls).
Material Types
It appears that the materialtypes.2da actually consists of two sets of data: the current material types data and the an old, confused version of material rules data.
I believe, based on the way the worksheet has been set up and the rows that have been populated, that we could remove all but the ID, Label, TNTFile, Material and Sound_MatType columns. This would leave us with just the information pertaining to the material types as follows:
ID int 3 Label string Armor, Silverite TINTFILE string T3_ARM_HST.tnt Material int 6 Sound_MatType int 13
I estimate there are about 66 valid material types (and several other old and presumably invalid ones).
In scripting the material type can be obtained using GetMaterialType and modified using SetMaterialType however there are no examples in resources in the current version of the toolset to confirm this. I believe that the missing MATERIAL_TYPE constants referred to in the help for SetMaterialType would, if they existed, point to the valid rows in this file.
In the toolset the only noticeable effect of changing the material type is a change of colours however doing so can also change the actual base Material which could have unintended in-game effects.
Materials
As mentioned above each Material Type has a base Material that determines the in-game effectiveness of that item. As the quality of the material increases it does more damage, offer better protection, improve the chance of critical hits, etc. This data is contained in materialrules.2da:
ID int 3 Label string Steel NameStrRef int 370975 LongNameStrRef int 391297 Damage float 1.2 Armor float 1.4 CritChanceModifier float 1.2 ArmorPenetration float 1.3 ShieldRating float 1.2 AbilityCostModifier float 1.1 ReqProp1Mod float 4 ReqProp2Mod float **** RuneCount int 1 CostMultiplier float 6 AbilityScoreModifier float 1.3 OptimumRange float 1.05 Spellpower float 3 MissileDeflection float 1.5
There are three groups of materials:
- Metals: Iron, Grey Iron, Steel, Veridium, Red Steel, Silverite, Dragonbone
- Woods: Elm, Ash, Yew, Whitewood, Ironbark, Sylvanwood, Dragonthorn
- Hides: Rough, Cured, Leather, Hardened, Reinforced, Inscribed, Drakeskin
Each group appears to follow a simple progression where each property either stays the same or improves as you ascend within the group.
It does not appear to be possible to set the material directly through scripting with the functions that are currently available.
Material Progression
Material Progression appears to be used the Treasure System for auto-scaling armour, shield and weapons for loot (as seen in sys_tressure_h.nss) however it could also be used as the basis for any item upgrade system.
It is important to note that an item's MaterialProgression property can only be set at design time (i.e. in the toolset) for while there is a GetItemMaterialProgression there is no corresponding SetItemMaterialProgression. Moreover the name is slightly misleading, as the property and function actually set and return the item's material type progression.
The MaterialProgression list in the toolset is populate using the Label column in TS_Material.2da (contained in TS_System.xls):
ID int 46 Label string Armor, All Metal Material1 int 1 Material2 int 2 Material3 int 8 Material4 int 4 Material5 int 5 Material6 int 3 Material7 int 6 Material8 int 6 Material9 int 6 Material11 int 6 Material12 int 6 Material13 int 6 Material14 int 6 Material15 int 6
The Material# columns are populated with references to material types from materialtypes.2da. It is presumably important to ensure that the progression is logical i.e. an armour progression only uses armour material types and that they ascend in line with the underlying base material.
The formula for determining which of these should be used by the auto-scaling system is basically (the player's level / 3) + a small random element. The player's level is essentially capped at 45 for this system.
Runes
Runes are a special type of item that can be installed, and subsequently uninstalled, from another item thereby granting additional benefits to that item. There are currently two types of rune defined in BITM_base.2da (contained in BITM_base.xls): one for weapons (including a mage's staff) and one for armour (including a shields).
Currently runes can only be installed in a weapon or armour however as this appears to be controlled through the RuneSlots column in BITM_base.2da it may be possible to simply create new types of runes that could be applied to other item types. The value entered into the RuneSlots column is based on the inventory slots constants and calculated in exactly the same way as discussed in the Item Sets section (above).
The number of runes that can be installed on an item is determined by the quality of the material used to construct it and range from 0 to 3 runes accordingly. The number of runes is for a material is defined in materialrules.2da (above).
Item's using the default Variables 2da file (var_item.2da) have a ITEM_RUNE_ENABLED local variable (default 0), which presumably allows an item to be excluded from the runes system regardless of its base material. The switch is randomly set in the ScaleStoreItems function in core_h.nss but no other references to it have been found in the Toolset Beta resources.
From the description of the GetItemProperties and GetItemPropertyPower functions it appears a rune's Item Properties (and possibly OnHit Effect) are included with those of the item they are installed in. The rune items are known as sub items and can accessed using the GetItemSubItems function.
There is a special Upgrade GUI which presumably allows the PC to install to or uninstall from an item. It can be displayed using the OpenItemUpgradeGUI function however there does not appear to be any way to set the item's sub items (i.e. install or uninstall runes) via scripting.
Item Properties & OnHit Properties
It is important to note that Item Properties have changed. The NWN-style item properties 2da files found in ItemProperties.xls in the seemingly important Rules directory are in fact a collection (presumably a shoal) of red herrings.
The new item property system has been significantly simplified compared to the old system and now uses effects as the basis for majority of item properties. Each item property is defined in itemprps.2da (contained in itemprps.xls):
ID int 6102 Label string Decrease Armor (3 per power) NameStrId int 380484 IPType int 1 Effect int 1012 Int0 int 11 Int1 int 0 Float0 float -3 Float1 float 0 ConditionScript resource VFX int 0 ScalingVector string Float0 Comment comment Reduces total armor per item power BaseCost int 0 IsNegative int 1 ProcChance float 1 BaseDuration float 0 ProjectileCrust int 0 AbilityId int 0
There are four types of Item Property which can be distinguished by their IPTypes:
- Abilities
- OnHit Effects
- Restrictions
- Specials
In the toolset Abilities, Restrictions and Specials are added using the Item Properties pop-up while an OnHit Effect can be selected from a drop-down list. An item is limited to a maximum of five Abilities and one OnHit Effect. There does not appear to be a limit on the number of Restrictions or Specials (other than the maximum number available).
In scripting all Item Properties are added using AddItemProperty by passing the item, item property id and power level. There are no specific item property constructors. It is not currently possible to determine if the limits seen in the toolset also apply to scripting.
Item Property Power
Many Abilities and OnHit Effects scale according to their associated power level. For example:
- OnHit: 1.0 points of Fire Damage per Power
- OnHit: 2.5 points of Fire Damage per Power
- Decrease Fire Resistance by 5.0 per Power
- Increase Fire Resistance by 1.0 per Power
- Increase Fire Resistance by 5.0 per Power
Going by the values that can be entered into the toolset the power level appears to a positive 32-bit signed integer value (i.e. in the range 0 to 2,147,483,647). The AddItemProperty function makes reference to POWER_LEVEL constants that might be more restrictive however no other references to those constants could be found.
Each item property that scales with power will have Int0, Int1, Float0 or Float1 in the ScalingVector column. It appears that these columns relate to indices in the effect's int and float arrays so some reverse engineering may be required to create new entries.
For example item property 1203 (Increase Melee Crit Chance) has Effect = 1012 (EFFECT_TYPE_MODIFY_PROPERTY); Int0 = 21 (Melee_Crit_Modifier) and Float0 = 1 (+1 per power level). When the item was equipped I believe, it would ultimately call the following function in effect_modify_ hit_cirtchance_h.nss:
int Effects_HandleApplyEffectModifyCritChance(effect eEffect) { int nProperty = GetEffectInteger(eEffect,0); float fChange = GetEffectFloat(eEffect,0); UpdateCreatureProperty(OBJECT_SELF,nProperty,fChange,PROPERTY_VALUE_MODIFIER); return TRUE; }
As you can see Int0 maps to nProperty and Float0 maps to fChange.
Item Property Scripts
Restrictions run a script, defined in the ConditionScript column, to control who or what can use the item. The scripts use the SetCanUseItem function to allow or prevent the owner from using the item. For example the ip_restrict_ohuman.nss script restricts item use to humans only.
