NWN2

The comment lines should cover most of what they do, but one that's enticingly hanging out in the open is this fellow:
 

So, firstly, the original author's line wherein caps lock is cruise control for cool covers why this one is dangerous. Particulrly-advanced coders, with familiarity with our database and such, shouldn't be afraid to use this, but should approach knowing that they'll be responsible for their own logs, and that Hialmar might make them upgrade the parser to provide results to less-technically-inclined people who may need to review them in the course of their work (knowing how to write SQL queries is not prerequisite for the PA position or for any PA staff positions, and we're in very big trouble as a community if it ever becomes one)

So, running down the others-- first example, we've reached a point in a conversation where we're providing a simple quest reward; we're not tracking this in a journal-- we didn't update any "quest states". This guy just has a standing thing in his conversation, like a gang rivalry-- the Jets will pay if you rough up any of the Sharks. They might even sing you a song:
 

Second example-- you've killed something that tried to kill you back. The ACR will be trying to catch all of these itself, and any creature killed by conventional combat should be so handled-- but if you have any special unique circumstances wherein a creature is being killed as part of a legitimate challenge, but the instrument of death wasn't in the core mechanics (systems that manage sea combat would be the standard example of this) you'd probably be looking at...
 

Third and fourth examples would be used in similar fashion-- and would be catch-alls for things that give XP but don't fit into any other possible category in the ACR. They award XP as if you killed a creature of fCR, with the difference being in how they're logged (lethal challenge or nonlethal challenge)-- so this can be used for things that highbies shouldn't get much reward for: that DC 20 trap is hair raising for a level 1, but a level 15? Deserves 1 xp, if any.
 

Naming Conventions The following conventions will need to be used in naming creature blueprints to avoid any conflicts with other blueprints and to ensure that all content works properly with scripts:

Localized Name Creature names should not be revealed to players in-game, unless a sufficiently unique creature or equipment model does not exist for the creature being created. In such cases, choose a one or two word descriptive name, but be sure you reveal as little of the meta information about the creature as possible. Size based descriptive words are not necessary since creatues can be scaled in NWN2 to properly reflect their size.

Putting creature names inside {} will make them visible only to builders. This will help builders distinguish between multiple blueprints of the same type and convey important reference information at a glance without revealing any of the information to players in the game. Generally, a creatures name or race, social role or class, gender (if applicable), and challenge rating are useful characteristics to record within {}.

Ex: Larger Kobold {Chieftain CR1} or Male Human {Barbarian CR3}

Template ResRef/Resource Name/Tag The primary purpose of tag and resref naming conventions is to prevent any naming conflicts. A secondary purpose is to describe the creature in some way. All global creature blueprints must begin with the "abr_cr" prefix to designate them as global blueprints. Server specific blueprints should begin with a 3 digit server number in place of the "abr", so "001_cr" for example. For every subcategory, add a two letter acronym delimited with underscores followed lastly by a descriptive name for the creature itself. This helps to quickly locate blueprints when all we have is its resref. To illustrate, here are a few examples:

A global humanoid creature blueprint: abr_cr_hu_koboldchieftain A server NPC blueprint on server 01: 001_cr_np_zhents_fzoul

Comments To identify and track blueprint versions, it's best to write your name and the date you modified the blueprint in the comments area. Ex: Created By: John Doe, Date Modified: 2006/12/20

For global blueprints, you should also include a link to this wiki page so builders that are unfamiliar with conventions or configuration options can easily find them.

Setting Event Handlers The default basemod creatures should already have these handlers in place, so if you are copying an existing blueprint, you probably don't need to do anything here. To start off with, make sure the creature's event scripts are all set correctly. The default scripts are:

• acf_cre_onphysicallyattacked
• acf_cre_ondamaged
• acf_cre_ondeath
• acf_cre_onconversation
• acf_cre_oninventorydisturbed
• acf_cre_onendcombatround
• acf_cre_onheartbeat
• acf_cre_onblocked
• acf_cre_onperception
• acf_cre_onrested
• acf_cre_onspawnin
• acf_cre_onspellcastat
• acf_cre_onuserdefined

Creating the creature Assuming the creature does need to be created, go ahead and do so as you normally would in the toolset. A few things are different in ALFA, however. Most of this just applies to creatures which are statically spawned, but its probably a good read for any builder.

General Guidelines Creatures are expected to follow canon specifications as closely as the toolset allows. If you must deviate on the basis of game mechanics, play-testing should be used to make sure the altered creature's CR is set properly. Always post any deviations from canon specifications on our NWN2 tech forums so that others may comment or follow them for consistency's sake. When setting clerical domains and alignment, be sure to base things off of the most popular deity for the creature type. When setting spells and equipment, be sure and follow FR's lore and canon if at all possible. Our first priority is game balance, and then following FR lore.

Remember the lower-level creatures of a given race are always vastly more numerous than their higher-level bretheren. Make more versions of them, especially the level 1 warriors, with different sorts of appearances and equipment.

Descriptions A creature's description should be the PHYSICAL description in the creature's sourcebook entry, plus anything important a PC should notice specifically about the creature that isn't obvious by looking at it in-game.

Behavior, Tactics, Society Behavioral information for each creature should be present on the creature in the form of a non-droppable, non-pickpocketable blank scroll named after the creature or its race/organization. The tag and resref of the item should be abr_it_cd_{description}. Put as much information here as you can stand, but it should all come from canon sources. You'd typically only need one information scroll per race or organization (only one for goblins, one for kobolds, one for Zhentarim, etc), unless the creature is unique.

Equipment A few things should be kept in mind when creating a creature's equipment. The first thing is, what drops? Generally its best if a creature drops all of its non-armor equipment, for realism's sake if nothing else. However, in many cases its best not to drop armor with a creature, especially if that creature is going to be used as a static spawn. Armor is heavy and expensive, so it presents stronger PCs with ways of gaining income while preventing weaker PCs from doing so, creating a wealth gap. Furthermore, its price means it sometimes adds significantly to the wealth of a spawns drop, possibly making the spawn drop more wealth than it should. Also, its rather logical that killing a creature will damage its armor reasonably often. Finally, removing armor from a corpse would be a time-consuming afair, and carrying it would not be easy. This would not be something done often (unless the armor is especially valuable or magical, which it shouldn't be anyway in the case of a static spawn).

Now, about spawn drops. The good news is in most circumstances, you don't have to add loot to a creature for static spawns! If the value of the equipment the creature uses is reasonable, you probably don't have to think about loot at all. Loot is created automatically with scripts, based on many variables in an attempt to match up believable loot (if any) to your creature. The value of the loot is based off of the value of the creature's dropped equipment and its CR, so setting the CR correctly is vital. If the creature is a static spawn, please try to use this built-in loot system unless there is very good reason not to. If a spawn does not use this loot system, it may need to be updated if ALFA's wealth standards for static spawns change in the future.

To disable the loot system, set the ACR_LOOT_DISABLE local integer variable on the creature to a value of 1. If you want to modify the amount of loot droped, set the ACR_LOOT_CR_MOD local float variable to the desired value. This alters the creature's CR for the purposes of calculating loot drops (whether it is positive or negative). Setting it to 1.0 would produce loot as if the creature had a CR of 1 higher than it does, and setting it to -1.0 would produce the opposite effect, loot as if the creature was 1 CR point lower.

Always set "Leave Lootable Corpse" to true, and "No Permanent Death" to true. Set the corpse decay time to 7200000.

(For information on what local variables are, and how to use them, go here: Using Local Variables in the NWN2 Toolset)

Note that regardless of these settings, all creatures always drop the items in their inventory which are flagged droppable. The loot system never actually removes items from any creature.

Note that if the amount of wealth a creature drops (as set by the builder) exceeds the amount a static spawn of its CR should drop, a warning is printed out in the server's log file. Naturally if the creature isn't a static spawn, this can be ignored.

Challenge Rating Also known as "CR", this is vital. Fortunately NWN2 usually gets a creature's CR close to what it should be on its own. Sometimes it doesn't however, so be sure to understand the concept of CR before proceding further.

A creature's of a certain CR should roughly be as powerful as other creatures of the same CR included in ALFA's base creatures. Even if the creature is not spawned statically, the CR must be set correctly for DMs to be able to tell its relatively balance in a fight, and for XP to be awarded properly. If the creature is spawned statically, its loot will be generated based on its CR. If you don't think you know what a creatures CR should be, do some testing for yourself, or ask someone! A good way to test is to use some of your PCs (either controlled by their players or by yourself with their character files locally on your machine).

Do NOT lower a creatures CR because you want to prevent farming abuse, or to lower a PC's rewards for slaying it. If PCs are gaining too much from a spawn of some sort which has its CR set correctly, the problem is in the way the spawn is set up and not the creature itself. Artificially lowered CRs are not only a good way to under-reward PCs for risking their lives, but sometimes lead to accidental PC deaths if the DM spawning the creatures doesn't know the true strength of the creature (until his PCs are face down in their own blood).

Perception Range If the creature's perception range is less than the PC's (ie less than "long") by any meaningful margin, the exploitability of the spawn increases dramatically. For this reason, its generally best to set a creature's percept range to "long". The "long" range has been adjusted to be slightly less than a PC's, allowing the PC to react to the monster without the computer having an advantage in reaction time.

Behavior Types: If the creature is expected to fight at any point, determining how we expect the creature to behave in a fight is also important. Create a local string on the creature named ACR_CREATURE_BEHAVIOR, and set the value of that string to...
BEHAVIOR_TYPE_TANK if you wish your creature to move to the front line and try to hold it. In narrow passages, tanks will attempt to clog the passage. In open fields, tanks will fan out to try to keep as many enemies as possible "covered" as evenly as possible.
BEHAVIOR_TYPE_FLANK if you wish your creature to actively seek people who are fighting others, and to strike them in melee from behind.
BEHAVIOR_TYPE_SHOCK if you wish your creature to run in past the front line with reckless abandon, prioritizing "soft" enemy targets.
BEHAVIOR_TYPE_BUFFS if you wish your creature to focus on support magic for allies. Or, opportunistically, healing.
BEHAVIOR_TYPE_MEDIC if you wish your creature to focus on healing magic for allies. Or, opportunistically, support magic.
BEHAVIOR_TYPE_SKIRMISH if you wish your creature to fight at range until enemies close, and then switching to melee.
BEHAVIOR_TYPE_ARCHER if you wish your creature to only fight at range.
BEHAVIOR_TYPE_CONTROL if you wish your creature to focus on special powers that alter the battlefield, attempting to use things like grease, entangle, and summon monster to stop enemies from getting around.
BEHAVIOR_TYPE_NUKE if you wish your creature to use its strongest magical abilities to repeatedly hit the strongest enemy it can find.
BEHAVIOR_TYPE_MINDLESS if your creature is mindless, and fights fearlessly without strategy or concern for personal safety.
BEHAVIOR_TYPE_ANIMAL if your creature is an animal, and fights without strategy (but still doesn't want to die).
BEHAVIOR_TYPE_COWARD if your creature is a coward, and runs away from conflict.

Other considerations

• Set the creature's CR accurately.
• Unless there is a very good reason to, don't create static spawns with "save or die" spells or abilities. The most obvious of these are instant death spells or petrifications, but holdings, sleep spells, fear and confusion often qualify as well. ALFA has much slower advancement than the d20 rules were ment for, and with a 5% chance to fail any saving throw, "save or die" abilities can too-easily kill even powerful PCs with weak creatures.
• The above isn't so critical if static spawns with "save or die" abilities are avoidable. For example, basilisks can turn a creature to stone with a failed fort save. But they are also slow, lazy creatures, so often times anyone approaching within range of the basilisk's petrification attack is asking for it, and deserves no mercy.
• Unless there is good reason to, try not to make creatures who's power deviates too significantly from creatures of the same type in ALFA's standard pallet. Not only does this harm the believablity and immersion in the world, but it causes some disgruntled PC deaths ("looked like a normal kobold to me, but it had an AB of +12?").
• If you do make creatures with a significally different power level from others of their type, make sure they have some visual difference from their kin so as to not surprise that party of PC1s with those nasty +12 AB kobolds.
• Did I mention the CR must be set correctly?
• When in doubt, play test your creations! Its really all about play balance, and keeping the ALFA experience as consistant as possible between all our different builders with their own assumptions about how to build.
• For more tips on setting up static spawns, go here?.

Custom Scripting Most people can skip this. If you're not using the standard AI scripts ALFA uses on creatures, you'll need to make sure you include ALFA's code into your scripts. You do this by including the file "acr_cre_events_i", and calling a different function for each event type. These functions are:

• ACR_OnCreatureSpawn()
• ACR_OnCreatureSpellCastAt()
• ACR_OnCreaturePhysicalAttacked()
• ACR_OnCreatureDamaged()
• ACR_OnCreatureDeath()
• ACR_OnCreatureBlockedByDoor()
• ACR_OnCreatureCombatRoundEnd()
• ACR_OnCreatureConversation()
• ACR_OnCreatureDisturbed()
• ACR_OnCreatureHeartBeat()
• ACR_OnCreatureRested()
• ACR_OnCreaturePerception()
• ACR_OnCreatureUserDefined()

Its absolutely vital to the functioning of ALFA that these scripts are called on each of their events! So make sure they are in there.

Configuration Options These are the additional cofiguration options allowed by the ACR. They are edited by changing local variables on the creature's blueprint. (For information on what local variables are, and how to edit them, go here: Using Local Variables in the NWN2 Toolset)

ACR_LOOT_DISABLE (integer) If set to a nonzero value, the creature is not given any loot drops by the loot system at all. If unset, it is.

ACR_LOOT_CR_MOD (float) This value modifies the creatures CR for the purposes of calculating the amount of loot dropped. If positive, it adds to the CR and increases the value of the loot dropped. If negative, it substracts from the CR.

ACR_CRE_RANDOM_ABILITIES (integer) If set to a nonzero value, the creature is spawned with randomized ability scores. The blueprint is treated as the "average" for the resulting scores.

ACR_CRE_RANDOM_ALIGNMENT (integer) If set to a nonzero value, the creature is spawned with randomized alignment. The blueprint is treated as the "average" for this, and alignment will never differ from the blueprint by more than one step.

ACR_CRE_ISUNDEAD (integer) If set to a nonzero value, this creature will be considered undead for all scripting purposes. It will still need undead creature properties assigned.

ACR_CRE_SPAWN_DAMAGED (integer) If set to a nonzero value, the creature will not heal to full health upon spawn-in. This variable allows you to equip your monsters with creature items/equipment that provides health bonuses without them spawning harmed.

1. THIS PAGE IS SERIOUSLY OUT OF DATE REFER TO https://www.alandfaraway.info/wiki/Basic_Host_Requirements FOR MORE CURRENT INSTRUCTIONS
2. Download and extract the following NWNX4 files from the link below to a dedicated folder on your host machine (eg. C:\NWNX4):
3. 
   NWNX4_Controller.exe
   NWNX4_GUI.exe
   
   madCHook.dll
   NWNX4_Hook.dll
   xp_mysql.dll
   xp_time.dll
   
   nwnx.ini
   xp_mysql.ini
   
   http://nwnx.org/index.php?id=nwnx4
    
4. Copy the madCHook.dll file to your Neverwinter Nights 2 game folder (where the game installed itself).
    
5. You will need to configure nwnx.ini with your module and game information. The most important line is the parameters entry:
   
   parameters = -module "My Module" -servervault 1 -publicserver 1
   
   If you prefer to launch your module in directory mode, use the -moduledir paramater in place of -module.
    
6. You will need to configure xp_mysql.ini with the correct connection details for the remote database server. Please contact the IA, TA, or DMA for that information.
    
7. Once you have the file configured, you can launch your server using the NWNX4_GUI.exe program (NOT nwn2server.exe as you normally would). It will automatically launch nwn2server for you.
   
   Alternatively, you can install NWNX4 as a service on your host machine by issuing the following commands in your NWNX4 folder (only recommended for advanced users):
   
   NWNX4_Controller.exe -installservice
   NWNX4_Controller.exe -startservice
   
   NWNX4 will show up as a Windows service, which can be started and stopped like any other service on your machine (via Services in Administrative Tools). You can enable the nwn2server dialog window by navigating to the NWNX4 service, clicking on its properties, selecting the "Log On" tab, and checking the "Desktop Interaction" box.
   
   Other service commands you can issue using NWNX4_Controller.exe:
   
   -serviceno Specify service instance number
   -stopservice Stop the NWNX service
   -uninstallservice Uninstall the NWNX service
   -interactive Start in interactive mode
    
8. Note: NWNX logs are recorded in the nwnx.txt file, and MySQL logs are recorded in the xp_mysql.txt file in the install folder. These will help you identify any configuration or run time sql problems (like bad queries).

While the basemod contains every door listed in the DMG with appropriate settings, builders may wish to create their own doors. ALFA has scripts which provide a number of mechanics not ordinarily found in NWN, and every door has an extra set of options because of this.

As with creating new creatures, items, and so forth, the easiest way to make a new door is to copy/edit an existing one. For information on editing the settings of an existing door, skip the next section.

Creating a new door. If you aren't editing an existing door, you will have to configure a number of options. To start off with, you'll need to make sure all of the door's event scripts are set correctly. ALFA's event scripts for doors are as follows: // Update for longer NWN2 file names

• acf_door_onclosed
• acf_door_onconversation
• acf_door_ondamaged
• acf_door_ondeath
• acf_door_ondisarm
• acf_door_onheartbeat
• acf_door_onlock
• acf_door_onmeleeattacked
• acf_door_onopen
• acf_door_onspellcastat
• acf_door_ontraptriggered
• acf_door_onunlock
• acf_door_onused
• acf_door_onuserdefined
• acf_door_onclick
• acf_door_onfailtoopen

If you want to add custom event scripts to your doors, you can of course do so. Just make sure each event script includes the file acr_door_i, and calls the appropriate function for that event, listed here.

• ACR_DoorOnClosed()
• ACR_DoorOnConversation()
• ACR_DoorOnDamaged()
• ACR_DoorOnDeath()
• ACR_DoorOnDisarm()
• ACR_DoorOnHeartbeat()
• ACR_DoorOnLock()
• ACR_DoorOnMeleeAttacked()
• ACR_DoorOnOpen()
• ACR_DoorOnSpellCastAt()
• ACR_DoorOnTrapTriggered()
• ACR_DoorOnUnlock()
• ACR_DoorOnUsed()
• ACR_DoorOnUserDefined()
• ACR_DoorOnClick()
• ACR_DoorOnFailToOpen()

Again, the easiest way to do this is to edit an existing acr_door_* file and save it under a different name. Failure to properly call ALFA's door scripts can break multiple systems of the ACR. So make sure you've got them in there.

Editing a door's settings: Aside from the standard NWN options of doors, we've provided a few more to give PCs and builders more options. These options can be accessed by editing the door's local variables. They are as follows: (For information on what local variables are, and how to edit them, go here: Using Local Variables in the NWN2 Toolset)

ACR_DOOR_CLOSE_DELAY (float) The number of seconds a door will stay open before automatically closing itself. If set to zero or less than zero, the door will not close itself automatically.

ACR_DOOR_CLOSE_NEAR_PCS (integer) If set to 1, the door will auto-close regardless of any nearby PCs. If set to 0 (the default), the door will wait until PCs are out of visual range before closing itself.

ACR_DOOR_STUCK_DC (integer) If non-zero, the door is considered "stuck", and therefore cannot be opened unless forced. The value defined is the strength-check DC to "un-stick" the door. If someone tries to force a locked and stuck door open, the strength DC used is the higher of this value and ACR_DOOR_BREAK_DC. The default value is 0.

ACR_DOOR_BREAK_DC (integer) The DC to break open this door, as per DMG rules. Breaking open a door does not destroy it like doing damage to it would in NWN, but it does keep the door from being able to be locked again. If this value is zero, the door cannot be forced open. Valid values are from 0 to 255.

ACR_DOOR_FAIL_OPEN_MESSAGE (string) This is a custom message sent to PCs who try to open the door and fail. This can be used in conjunction with ACR_DOOR_UNLOCK_PASSWORD to setup doors that require a spoken password to access (even useful for door riddles).

ACR_DOOR_OPEN_MESSAGE (string) This message is "spoken" by the door when it is opened. It is usually used to give the PCs a description of the area beyond an AT, if any.

ACR_DOOR_UNLOCK_HOUR (integer) This is the time of day (in hours) the door unlocks itself. Generally used for shops and things which are only open during certain hours of the day. It will only unlock once, so if something else locks it afterwards, it will remain locked until either another creature unlocks it, or its next unlock time. Valid values are 0 to 23. If you don't wish the door locking or unlocking itself automatically, leave both this variable and ACR_DOOR_LOCK_HOUR set to 0 (the default value).

ACR_DOOR_LOCK_HOUR (integer) This is the time of day (in hours) the door locks itself. Generally used for shops and things which are only open during certain hours of the day. It will only lock once, so if something else unlocks it afterwards, it will remain unlocked until either another creature locks it, or its next lock time. Valid values are 0 to 23. If you don't wish the door locking or unlocking itself automatically, leave both this variable and ACR_DOOR_UNLOCK_HOUR set to 0 (the default value).

ACR_DOOR_UNLOCK_SPELLID (int) This is the Spell ID for doors that require a specific spell to unlock. This will only work for spell IDs greater than 0. Be sure to set the door's default lock status to locked.

ACR_DOOR_UNLOCK_PASSWORD (string) This is what a player must speak to gain access to a password protected door. Leave this empty to require no password. Otherwise, be sure to set the door's default lock status to locked.

ACR_DOOR_AUTO_LOCK (integer) If non-zero, the door will automatically lock itself each time it is shut.

ACR_DOOR_LISTEN_DC_MOD (integer) This modifier is applied to creatures trying to listen to conversations occuring behind a closed doors. The DMG lists this a +5 for every door, but some customization is allowed for different door types. If undefined or set to 0, the door cannot be listened through.

ACR_DOOR_KNOCK_IMMUNE (integer) If nonzero, this door is immune to the spell knock. If zero, it is not immune.

ACR_DOOR_UNMOVABLE (integer) If nonzero, the door cannot be opened or closed by a non-DM creature, even if unlocked. Scripts can still open or close it, however. This setting is often used to represent large doors which a PC could not realistically close on their own even if they were unlocked, like the huge gates on castles and other fortifications.

ACR_AT_SIZE (integer) If nonzero, this setting specifies the maximum sized creature which can fit through this doorway. Anything large will be given a message saying it is too large to fit inside. Valid values are as follows:

• 1 = Fine
• 2 = Diminutive
• 3 = Tiny
• 4 = Small
• 5 = Medium
• 6 = Large
• 7 = Huge
• 8 = Gargantuan
• 9 = Colossal

Note that currently, NWN2 does not support creature sizes of fine, diminutive, gargantuan or colossal. These values are provided here for future compatibility.

Note that if none of these variables are defined, they default to zero. So a door without them would never close or lock itself, wouldn't be stuck or barred at all, would not be able to be forced open, and wouldn't have any sort of a custom message printed if a PC failed to open it.

All items should be priced according to 3.5 edition canon (Player's Hand Book, Dungeon Master's Guide, etc), and to the ALFA specific exceptions set forth by ALFA Standards. DO NOT MAKE ITEMS WORTH LESS THAN 1 GP YET! Our currency system for silver and copper pieces is not yet ready, and we may not know how it will work until we have the client in our hands.

Premise: An item should be identifiable from it's tag/resref.

<prefix>_it_<type>_<description>_<ID>

<prefix> is either "abr" (minus the quotes) for default ALFA items, or a three digit code of the server.

<type> is a three-letter abbreviation describing the slot occupied by the item.

<description> is the number of fields necessary to describe any additional properties on the item.

<ID> is an optional two-digit number used to distinguish items with identical properties. Leave the <ID> off of tags - it goes on resrefs only.

Item tags should NEVER be longer than 28 characters. The game allows 32, so don't use them all.

Scripting: For information on how to script items, go here.

Examples: A standard longsword would be, Tag: abr_it_wpn_longsword ResRef: abr_it_wpn_longword_01

TYPE

Ammunition amm Armor arm (includes shields) Boots boo Cloaks clk Gloves glv Helmets hlm Weapons wpn

DESCRIPTIONS

Materials

• Abyssal Bloodiron ay
• Adamantine ad
• Alchemical Silver sa
• Arandur aa
• Astral Driftmetal as
• Aurorum au
• Bluewood bw
• Cold Iron ci
• Copper co
• Darksteel dk
• Darkwood (Zalantar) za
• Dlarun dl
• Dragonbone db
• Dragonfang df
• Dragonhide dh
• Dragonscale ds
• Duskwood du
• Fever Iron fr
• Fiendbone fb
• Frystalline fy
• Gold go
• Hide hi
• Hizagkuur hz
• Laminated Steel ls
• Living Metal lm
• Mithral mi
• Obsidian ob
• Pandemonic Silver ps
• Platinum pt
• Serren se
• Silver sv
• Solarian Truesteel tr
• Sondarr so
• Suzailian Chainweave ch
• Weirwood ww
• Ysgardian Heartwire ys

Quality

• Arcane Spell Failure -10% asf1
• Drowcraft dc
• Masterwork mw
• Plus one e1
• Poor po
• Armour Class +1 ac1
• Bonus Spell, Level 0 sb0
• Bonus Spell, Levels 0, 1, 2 sb012
• Damage Resistance 1 dr1
• Damage Resistance 5/magic dr5m
• Damage Resistance Fire 5 drf5
• Feat: Alertness fale
• Feat: Ambidexterity famb
• Feat: Combat Casting fcca
• Feat: Darkvision fdar
• Feat: Dodge fdod
• Feat: Extra Turning fext
• Feat: Mobility fmob
• Feat: Spell Focus (One) fsf1
• Feat: Spell Penetration fpen
• Feat: Two Weapon Fighting ftwf
• Feat: Weapon Finesse fwfi
• Spell Immunity, Level 0 si0
• Spell Resistance 12 sr12
• Freedom of Movement fom
• Immunity: Death Magic ide
• Immunity: Disease idi
• Immunity: Drain idr
• Immunity: Fear ife
• Immunity: Gas iga
• Immunity: Magic Missle imm
• Immunity: Paralysis ipa
• Immunity: Poison ipo
• Save, Acid +1 sac1
• Save, Cold +1 sco1
• Save, Death +1 sde1
• Save, Disease +1 sds1
• Save, Fear +1 sfe1
• Save, Fire +1 sfi1
• Save, Fort +1 sfo1
• Save, Mind +1 smi1
• Save, Negative +1 sne1
• Save, Poison +1 spo1
• Save, Reflex +1 sre1
• Save, Sonic +1 sso1
• Save, Universal +1 sa1
• Save, Will +1 swi1
• Hide +1 hi1
• Damage, Acid +1 da1
• Damage, Bludgeoning +1 db1
• Damage, Cold +1 dc1
• Damage, Divine +1 dd1
• Damage, Fire +1 df1
• Damage, Magic +1 dm1
• Damage, Negative +1 dn1
• Damage, Piercing +1 dp1
• Damage, Slashing +1 ds1
• Damage, Sonic +1 do1
• Feat: Cleave fcle
• Feat: Disarm fdis
• Feat: Improved Critical ficr
• Feat: Point Blank Shot fpbs
• Feat: Rapid Shot frap
• Feat: Weapon Specialisation fwsp
• Keen ke
• Massive Criticals +1 mc1
• Mighty +1 m1
• Sure Striking sst
• Vampiric +1 dv1
• Wounding +1 dw1

CLASSIFICATION This is added in the toolset with a string seperated by the '|' character for each category. The HDMs of every server are free to make their own rules as too where items should be placed, but be aware the DM client cannot see more than one step "deep" into the category tree.