NWN2

The following is a complete list of features in the ACR2's spawn system.

Waypoints Just like NESS and other spawn systems, the ACR's spawn system uses waypoints as spawn points. These waypoints have a great deal of options on them, in the form of local variables which the builder can change to suit his needs. You'll find a base, blank template for a spawn waypoint in [add when we know what the NWN2 palette looks like]. For a guide on how to configure a normal spawn quickly, please see the quickstart guide?. (For information on what local variables are, and how to use them, go here: Using Local Variables in the NWN2 Toolset)

All of the parameters listed below are present on the template spawn point. The undertstanding of them is not required to produce a functioning spawn point. The template spawn point works if its local string variable ACR_SPAWN_RESNAME_1 is given a valid creature Resource Name. The default template spawn point is always active, always spawns what you tell it to, and will not respawn when its children are killed.

Array Parameters In computer lingo, an "array" is simply a list of some sort of data of the same type. The spawn system uses arrays to list the "resource names" of creatures or objects you want to spawn, and the scripts you may wish to attach to these creatures. Since the spawn system depends on local variables for configuration, the arrays are lists of local variables. For example, ACR_SPAWN_RESNAME_ is a local string which lists the resrefs of the creatures spawned. So ACR_SPAWN_RESNAME_1 would be the name of the local variable for the first resref, ACR_SPAWN_RESNAME_2 the second, ACR_SPAWN_RESNAME_3 the third, and so on. Never skip a entry in an array. If you do, the spawn system will think the array has stopped at the missing entry. Also, always start at 1, not 0.

Current Paramters ACR_SPAWN_TYPE (Local integer) This indicates the type of object which is being spawned. The default is 0, for a creature, but other types are available, as listed below:

• Creatures: 0
• Placables: 1
• Items: 2
• Store: 3
• Waypoint: 4
• Triggers: 5
• Encounters: 6
• Lights: 7

ACR_SPAWN_RESNAME_ (Local string array) This array lists Resource Names of objects which are always spawned by the spawn point. If the spawn point is activated, all the Resource Names in this array will be spawned. Resource Names listed more than once are spawned more than once. ex, leading to 2 badgers and a chicken each time: ACR_SPAWN_RESNAME_1 = "c_badger" ACR_SPAWN_RESNAME_2 = "c_badger" ACR_SPAWN_RESNAME_3 = "c_chicken"

ACR_SPAWN_RANDOM_RESNAME_ (Local string array) This array lists Resource Names of objects which are chosen at random to be spawned. The number of chosen Resource Names depends on the ACR_SPAWN_RESNAMES_MIN/MAX settings, see below. This array can have no more than 31 entries. Each time the spawns are chosen randomly from this list, ex, leading to 67% chicken and 33% badger: ACR_SPAWN_RANDOM_RESNAME_1 = "c_badger" ACR_SPAWN_RANDOM_RESNAME_2 = "c_chicken" ACR_SPAWN_RANDOM_RESNAME_3 = "c_chicken"

ACR_SPAWN_RESNAMES_MIN (Local integer) ACR_SPAWN_RESNAMES_MAX (Local integer) These are the maximum and minimum numbers of Resource Names spawned from the ACR_SPAWN_RANDOM_RESNAME_ array. The actual number spawned is determined randomly between these values. They can range between 0 and 31. To keep this value from being random, set both the min and max equal. Each one will be an independent pull from the RANDOM_RESNAME array described above, so if these are >1, you may end up with multiples of Resource Names from the RANDOM_RESNAME array: best to leave uniques like bosses to their own waypoint, or use the ACR_SPAWN_RESNAME_# option above for them.

ACR_SPAWN_RESPAWN_COUNT (Local integer) This local integer defines the number of times a spawn point will spawn, if all its children have been killed. The default is 1, which indicates a "single-life" spawn. Mod reset or scripts can bring the spawn back, and normal despawning due to time or inactivity will not permanently deactivate the spawn point, only death of all of it's spawned "children". Note that this relies on the spawned objects having the correct acf_ondeath() scripts in their OnDeath events. A setting of "-1" will lead to an infinitely respawning waypoint, which will always repopulate after being "cleared out". Similarly, setting this value to "5", would mean the spawn point would have to be killed off 5 separate times to deactivate "for good". Note that currently a mod reset still sets this counter back to it's original state, though we may tie this into persistent variables once they become available to us again.

ACR_RESPAWN_DELAY_MIN (Local float) ACR_RESPAWN_DELAY_MAX (Local float) This is the random period of time a spawn spends "recharging" after its children have all been killed (see above). This value is in game hours, and is chosen randomly between the mininum and maximum. To keep this value from being random, set both the min and max equal. In practical terms, the respawn will happen at the next spawn pseudoheartbest after the timer expires, so the "accuracy" of the respawn delay will be somewhat dependent on the refresh rate of the system. Also note that setting respawn delay to "0.0" means the respawn will still be delayed until the next pseudoheartbeat, so respawns are never instantaneous (though if a spawn is killed just before a heartbeat, it may appear so).

ACR_SPAWN_CHANCE (Local float) This value, from 0 to 100, represents the chance a spawn has of spawning. This chance is computed once every game day. The % chance applies per day for the waypoint collectively, so it is an all-or-nothing situation.

ACR_SPAWN_RANDOM_RADIUS (Local float) This, if nonzero, specifies a maximum distance from the chosen spawn point location at which the spawn child may appear, in a random direction. This is calculated separately (distance and direction) for each spawned child, so for a multiple spawn, you can imagine it to describe the tightness of the "scatter" of the spawned children around the spawn point target. A small value will give a closely-spaced group, while a large one will give the illusion of entirely separate spawns, even though they are all children of the same waypoint.

ACR_SPAWN_RANDOM_RANGE (Local float) This, if nonzero, specifies a range (in a random direction) from the actual location of the waypoint to the target/centerpoint of the spawning- 0.0 will always center the spawn right on top of the waypoint, while an arbitrarily large value could place the spawn anywhere in the area. Note that when spawning a single child, this parameter is functionally equivalent to ACR_SPAWN_RANDOM_RADIUS, but when used with multiple children, it can place a mob of creatures, placeables, or items in a less predictable position, either in a closely knit group, or a broad spread.

ACR_SPAWN_IN_VFX (Local int) This integer indicates the visual effect number of a visual effect which is played on every object this spawn point spawns. It is commonly used to represent teleporting or summoned monsters.

ACR_SPAWN_VFX (Local int) This integer indicates the visual effect number of a visual effect which is played on the spawn point itself as it activates. It is commonly used to represent groups of teleporting or summoned monsters.

ACR_SPAWN_IN_SFX (Local string) This is the sound effect file which is played on each object spawned at this spawn point. (not yet tested, but should work)

ACR_SPAWN_SFX (Local string) This is the sound effect file which is played on the spawn point itself as it activates. (not yet tested, but should work)

ACR_SPAWN_ANIMATION (Local string) This is the animation performed by all creatures spawned from this spawn point, as they spawn. (not yet tested, but should work)

ACR_SPAWN_IN_HOUR (Local int) ACR_SPAWN_OUT_HOUR (Local int) This is the hour of the day the spawn starts to spawn in and spawns out at. If the current hour is between these values, the spawn can be active. If the two values are equal (such as zero, the default), the hour of the day has no effect on whether or not the spawn activates. Valid values are between 0 and 23. This also works for "circular" cases, such as Night-only spaws, ex here for spawning in at 18:00, and spawning back out every 06:00: ACR_SPAWN_IN_HOUR = "18" ACR_SPAWN_OUT_HOUR = "6"

ACR_SPAWN_IN_DAY (Local int) ACR_SPAWN_OUT_DAY (Local int) This is the day of the month (28 days in the Fearunian month) in which the spawn will spawn in and spawn out. These should also work in a circular fashion similar to the hours above, though that behaviour has not been stringently tested.

ACR_SPAWN_IN_MONTH (Local int) ACR_SPAWN_OUT_MONTH (Local int) This is the month of the year (12 months in the Faerunian year) the spawn starts to spawn in and spawns out at. If the current month is between these values, the spawn can be active. If the two values are equal (such as zero, the default), the month of the year has no effect on whether or not the spawn activates. Valid values are between 1 and 12.

ACR_SPAWN_IN_PC_SIGHT (Local int) If nonzero, the spawn will spawn with a PC in sight of it. This is disabled to keep spawns from suddenly appearing in front of a PC in an OOC fashion. (not tested, should work)

ACR_SPAWN_ONLY_WHEN_NO_PC_IN_AREA (Local int) If nonzero, this spawn will not respawn or activate at all if a PC is already in the area when it tries to do so. This is used to prevent creatures from re-appearing where they were after a PC just killed them, or something similar. (not tested, should work)

ACR_SPAWN_WITH_ANIMATION (Local int) If nonzero, this setting makes the spawn appear with its default spawn-in animation. This is usually a "fly-down" effect for most creatures, and a "climb down" effect for spiders. (not tested, should work)

ACR_SPAWN_IS_DISABLED (Local int) If nonzero, this spawn is disabled and will not spawn unless enabled by some other script or DM tool.

ACR_SPAWN_RANDOM_FACING (Local int) If nonzero, the spawn's facing is random, instead of facing the direction of the spawn waypoint.

ACR_SPAWN_IN_STEALTH (Local int) If nonzero, the spawn spawns in stealth mode.

ACR_SPAWN_IN_DETECT (Local int) If nonzero, the spawn spawns in detect mode.

ACR_SPAWN_BUFFED (Local int) If nonzero, spawned creatures spawn with all hour per level (or longer) buffs cast on itself in a semi-intelligent fashion (evil creatures cast protection from good, multiple magic vestimates or magic weapons are distributed over different items, etc). (not tested, should work)

Custom Script Parameters The spawn system allows custom scripts to be run when a spawn activates, for scripters to use how they wish. In order to use the functions listed here, be sure and include the spawn system's source file with the line: #include "acr_spawn_i" at the top of your script.

ACR_SPAWN_IN_SCRIPT_ (Local string array) This array defines custom scripts which are run on each object spawned by the spawn point. Each script is executed on each spawned object once, with OBJECT_SELF pointing to the spawned object. These scripts can have any name.

ACR_SPAWN_SCRIPT_ (Local string array) This array defines custom scripts which are run on the spawn point after it activates and spawns children. Each script is executed once, with OBJECT_SELF pointing to the spawn waypoint itself. If you wish to spawn additional objects from this script, use the function ACR_SpawnObject(). These scripts can have any name.

ACR_SPAWN_IS_ACTIVE_SCRIPT (Local string) This variable defines a single custom which is run whenever the spawn system looks at the spawn point and tries to decide whether or not to spawn it. It allows custom logic to be used to decide whether or not the point should spawn, overriding the spawn point's normal behavior. In this script, OBJECT_SELF points to the spawn waypoint itself. If you wish the point to spawn, call ACR_ForceSpawn(). If you wish to keep it from spawning, call ACR_DisallowSpawn(). If you don't call either of these functions, the spawn point behaves as it normally would. If for some reason you call both, ACR_ForceSpawn() takes precedence and the spawn activates. (not yet tested)

System Configuration In addition to the options of each spawn point, there are a few settings which you can use to globally configure ALFA's spawn system. These are constants located in the script acf_spawn_i. Like all ACF files (click here for an explaination), it is never updated in an ACR update. So any settings here will always be preserved, though server staff may be asked to add options to this file in the future as the ACR evolves.

_SPAWN_AREA_DESPAWN_DELAY This is the delay between when an area becomes empty of PCs, and when the spawn system despawns its children within it. Larger values here may lead to increased CPU usage as more creatures stay spawned at once.

_SPAWN_REFRESH_DELAY This is the "heartbeat" of the spawn system. Larger values here reduce CPU usage, but make the spawn system react slower.

_SPAWN_PRESPAWN_SEAMLESS This controls whether the spawn system will take cues from PCs entering seamless ATs in adjacent areas. If active, it should ensure all spawns are in place before the PC actually ATs. It may be disabled to keep memory use down, as it may lead to areas being population without PCs actually entering them (if the PC backs out of the AT trigger instead of continuing)

_SPAWN_PRESPAWN_PREDICTION This controls whether the spawn system will take into account the predicted arrival point of an ATing PC, when deciding whether to spawn a group intended to be out of sight.

Planned Parameters These parameters do not currently function, but are included for builders to use as an interface until they are completed. Builders should count on them functioning the way they are recorded here when ALFA2 goes live. So, you can go ahead and build spawns with these parameters.

ACR_SPAWN_IN_WAYPOINT (Local string) ACR_SPAWN_OUT_WAYPOINT (Local string) These strings represent tags of waypoints where the creature spawns in at, and despawns at. Once spawned, the creature will move towards the spawn point's location. For example, a peasant could spawn at his house door at 8:00 in the morning, move to the location of the spawn point in a field of oats, then despawn at a tavern door at 17:00. All waypoints must be in the same area as the spawn point. If more than one waypoint with the same tag is placed, the closest one to the spawn point is used.

ACR_SPAWN_WHEN_PC_NEARS (Local float) This parameter keeps the spawn point from activating unless a PC nears it within a certain range. Distances are in meters.

ACR_MIN_SPAWN_DURATION (Local float) ACR_MAX_SPAWN_DURATION (Local float) A random value is chosen between these two values to determine how long a spawn remains spawned in game hours. After this time is up, the spawn despawns noramally, and can respawn again when the respawn delay is up (see below). To keep this value from being random, set both the min and max equal. If you want the spawn to remain spawned indefinitely, just leave these set to zero. After this counter is up, the spawn will despawn itself, and it will try to respawn itself as soon as its respawn delay counter is up (see below).

ACR_SPAWN_RANDOM_POSITION_BORDER (Local int) If nonzero, this setting prevents any spawn from spawning in within visible range of the map edge. This is used to prevent PCs from ATing into monsters, who prompty eat them before the player can react.

Tenative Paramters These are parameters we hope to have working in NWN2, but we aren't entirely sure if we will be able to.

ACR_SPAWN_FACTION (Local string) This parameter sets the spawned object's faction. If the name of the faction is invalid, it does nothing.

Disabled until future NWN2 updates: Until some of the base functions in NWN2 are fixed by Obsidian patches, we won't be able to dynamically rename spawns on the fly.

ACR_SPAWN_NAME_PREFIX (Local string) This is the string added to the beginning of the spawned object's name. Spaces are not included, so be sure to add one if you need it. For example, setting this to "Black Lance " (without quotes) would cause all creatures spawned from the point to take that prefix, ie "Black Lance Orc" would be spawned.

ACR_SPAWN_NAME_SUFFIX (Local string) This is the string added to the end of the spawned object's name. Spaces are not included, so be sure to add one if you need it. For example, setting this to " Archer" (without quotes) would cause all creatures spawned from the point to take that prefix, ie "Orc Archer" would be spawned.

ACR_SPAWN_NAME_FIRST (Local string) This string, if set, completely replaces the first name of the spawn. If for some reason you have prefixes and suffixes set as well, they will also be included.

ACR_SPAWN_NAME_LAST (Local string) This string, if set, completely replaces the last name of the spawn. If for some reason you have prefixes and suffixes set as well, they will also be included.

ACR_SPAWN_RANDOM_NAME (Local integer) If nonzero, this setting will assign a randomly-generated name to each spawned creature, based on the creature's gender and racial type.

ACR_SPAWN_WEATHER_CLEAR (Local int) ACR_SPAWN_WEATHER_RAIN_WEAK (Local int) ACR_SPAWN_WEATHER_RAIN_LIGHT (Local int) ACR_SPAWN_WEATHER_RAIN_MEDIUM (Local int) ACR_SPAWN_WEATHER_RAIN_HEAVY (Local int) ACR_SPAWN_WEATHER_RAIN_STORMY (Local int) ACR_SPAWN_WEATHER_SNOWN_WEAK (Local int) ACR_SPAWN_WEATHER_SNOW_LIGHT (Local int) ACR_SPAWN_WEATHER_SNOW_MEDIUM (Local int) ACR_SPAWN_WEATHER_SNOW_HEAVY (Local int) ACR_SPAWN_WEATHER_SNOW_STORMY (Local int) ACR_SPAWN_WEATHER_LIGHTNING_WEAK (Local int) ACR_SPAWN_WEATHER_LIGHTNING_LIGHT (Local int) ACR_SPAWN_WEATHER_LIGHTNING_MEDIUM (Local int) ACR_SPAWN_WEATHER_LIGHTNING_HEAVY (Local int) ACR_SPAWN_WEATHER_LIGHTNING_STORMY (Local int) If set to 1, each of these integers allow the spawn to spawn in under the indicated conditions. If set to 0, the spawn does not spawn under those weather conditions. Disabled until we have a working weather system.

ACR_SPAWN_IN_COLD_DAMAGING_WEATHER (Local int) ACR_SPAWN_IN_HEAT_DAMAGING_WEATHER (Local int) If nonzero, this spawn will activate in dangerous weather which causes heat or cold damage. Disabled until we have a working weather system.

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

DM Bonus XP

Bonus XP operates outside of the context of criteria-based Quest XP. It takes the form of a small one-off rewards of 10 XP, and can be triggered by anything from a particularly clever idea, to a perfect piece of role-play representing a PC’s personality, to anything that significantly adds to the general enjoyment of the other players – and DMs. Bonus awards should be made sparingly, but often enough to provide general encouragement for players. Bonus awards are made via the ALFA XP Bonus Cookie Widget.

Combat XP

Combat XP is calculated from the CR of defeated creatures, adjusted by the relative strength of the combatants (the ‘Danger Factor’) and is handled entirely by the ACR. For information purposes, the calculation is as follows:

• XP = ( 20 * ( CR ^ 0.6 ) ) * DF

The ‘Danger Factor’ calculation is:

This table is presented for informational purposes only, as the awarding of combat XP is handled mechanically by the platform.

DM Quest XP

DM Quest XP awards take two main factors into account:

• the challenge faced by the PCs; and,
• the success of the PCs in overcoming that challenge.

The same quest can present a significantly different challenge to differently constituted parties. Cleric-heavy parties will find defeating undead a lot easier than others, while Rogue-heavy parties are a lot less susceptible to ambush and a lot more capable of overcoming trap-laden dungeons. PCs should not be over-rewarded for overcoming challenges that are inherently easy for them; but nor should they be penalized for facing challenges that they are necessarily unprepared for. PCs should also not be unduly penalized for being effective: if a particular tactic surprises a DM and neutralizes a significant part of the challenge that the players are facing, it may be appropriate to reduce the ‘Challenge’ element – but increase the ‘Success’ element for the overall quest. Effectively, when one or another element is significantly increased or decreased, it is appropriate to increase or decrease the level of the award by a single band.

Awards are made for fixed amounts, by selecting the correct option on the ALFA XP Wand.

• Easy (20 XP / RL hour):
  the PCs should be able to overcome the challenge without any difficulty;
  the PCs should be able to overcome the challenge using only their key strengths;
  there is no significant chance of death or other plot-related failure;
  significant outlay of resources is not required;
  the PCs should be able to proceed directly on to another immediately.
   
• Normal (40 XP / RL hour):
  the PCs should be able to overcome the challenge without significant difficulty;
  the PCs should be able to overcome the challenge using their key strengths;
  there is no significant chance of death or other plot-related failure;
  significant outlay of resources is not required;
  the PCs should be able to proceed directly on to another quest with minimal recovery.
   
• Serious (60 XP / RL hour):
   
  the PCs should have some difficulty in overcoming the challenge;
  the PCs should have to prepare and plan properly to overcome the challenge;
  the PCs will be required to use skills and abilities other than their key strengths in order to succeed;
  there is a chance of death, or other significant plot-related failure;
  some outlay of resources is required, including temporary items;
  some recovery and restocking will be necessary before the PCs can proceed further.
   
• Exceptional (80 XP / RL hour):
  failure is a realistic possibility;
  the PCs will have to prepare and plan thoroughly in order to overcome the challenge;
  the PCs will be required to use skills and abilities that are the opposite of their key strengths in order to succeed;
  death or other significant plot-related failure is a realistic possibility;
  significant outlay of resources is required, including temporary items;
  a significant period of recovery and restocking will be necessary before the PCs can proceed further.

Example: Our party spend several IG days planning their raid on an orc camp, including making some specific tactical purchases – a Wand of Sleep and a half-dozen Antidote Potions – to exploit the weakness of the orc barbarians and counter one of their strengths (poisoned weapons). Our party is a traditional Fighter/Fighter/Cleric/Wizard/Rogue combination, but in order to make their approach to the orc camp undetected, they are required to be as stealthy as possible – not a key strength for the fighters and clerics and available only for the wizard by magical means. Their plan works and they successfully raid the camp, their stealthy approach and Wand of Sleep allowing them to neutralise the outlying guards before they can sound the alarm. They free a human slave, although they have to use several Antidote Potions, various healing abilities and potions, and several charges on the Wand of Sleep. Our party has successfully overcome a significant challenge by good use of their abilities and good planning. This quest would be properly assessed as ‘Serious’.

Example: Situation as above, but our party consists of three Fighters and two Clerics and their approach is to buff and slaughter. They fail to neutralise the outlying guards and the camp is alerted to their presence. They narrowly succeed in winning the ensuing mass melee and freeing the human slave. Although the final result may be similar, their approach has been significantly less successful than our first example, so it could be properly assessed as ‘Normal’.

Example: Situation as above, but this time our party consists of three Rogues and two Rangers, and their approach is to use stealth. They carefully reconnoitre the orc camp and are able to sneak in, assassinate the orc leader and liberate the slave, whose escape they facilitate with a series of Potions of Invisibility. While they may have arguably been the most successful of the three parties, they have not been significantly challenged: they have made use of a single set of abilities, key to their classes, that the orcs have been unable to counter. Again, this quest could be properly assessed as of ‘Normal’ difficulty.