Jaysyn/NWNDS
Jaysyn/NWNDS
1
1
Fork 0
Code Issues 155 Pull Requests Packages Projects Releases Wiki Activity
Page: BESIE Random Encounter System
Pages
Area Switches for PRC Teleport System Armor Rezref Conventions BESIE Random Encounter System Creature Appearances: Aberrations Creature Appearances: Constructs Creature Appearances: Dragons Creature Appearances: Plants Creature Appearances: Aberrations Creature Appearances: Constructs Creature Appearances: Dragons Creature Appearances: Plants Home Item Rezref Conventions NESS Intro & Examples NESS Spawner System NPC Behaviour Variables NWN Dark Sun Available Animal Companions NWN Dark Sun Available Race List NWN Dark Sun Availible Class List NWNDS Damage Reduction Weapon Rezref Conventions Zunath's Structure System
Clone
2
BESIE Random Encounter System
Jaysyn904 edited this page 2021-09-06 01:23:27 -04:00
Unescape Escape
This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

The BESIE Random Encounter System

For NeverWinter Nights

V1.82

Table of Contents: INTRODUCTION INSTALLATION FUNCTIONALITY I - Tools BESIE Random Encounter Spawner (BESIE RES) Persistent World Random Encounter Spawner (PW RES) BESIE MMORPG Style Spawner (MMORPG Spawner) Persistent World Respawner (PW Respawner) Commoner Spawner Placeable Spawner BESIE DM’s Widget II - Scripting Functions RandomEncounter() function CleanHouse() function SetRndEncProperties() function GetRndEncProperties() function III - Advanced Usage Switches Scripts Custom Encounter Tables Custom Treasure Tables IV - Credits and Thanks

INTRODUCTION:

Introducing BESIE. BESIE stands for (B)est (E)ncounter (S)pawner (I)n (E)xistance. Whether that is actually true or not is, of course, entirely a matter of opinion. It was simply the first witty acronym I could come up with.

I got the idea for BESIE shortly after purchasing NWN and realizing that there were no scripting commands or toolset utilities to yield good old fashioned, old school, random encounters. Seeing as how most (if not all) classic modules have random encounter tables, and one of the things that I dreamed of doing was converting classic modules to NWN, I really wanted this functionality. Also, it seems that many people are very interested in running MMORPG style persistent worlds using the NWN engine and toolset. There are no tools included with the toolset to populate a persistent world with completely random, level appropriate MOBs. BESIE provides this functionality as well.

I wanted a vast amount of control over every aspect of my random encounters. I realized, however, when designing BESIE, that more control often equates to more complexity and many people want neither. Many people just want simplicity. BESIE is designed to be very friendly and easy to use for those who do not have a great deal of scripting ability or do not care to deal with a lot of parameters to "fine tune" things, yet very powerful to give the advanced scripter almost complete control over all the nuances of his/her random encounters.

Along with this Documentation is a demo module. This module is meant to supplement, not replace, the documentation herein. BESIE is a very versatile system that can be configured and used many different ways. The Demo module shows some of the more common uses and configurations and can be dissected and used as a guide and learning tool.

BESIE comes with six tools that are designed to provide highly configurable random encounter functionality with absolutely no scripting ability required: The BESIE Random Encounter Spawner (BESIE RES). The Persistent World Random Encounter Spawner (PW RES). The Massively Multiplayer On-line Role Playing Game Style Spawner (MMORPG Spawner). The Persistent World Respawner (PW Respawner). The Commoner Spawner The Placeable Spawner

BESIE also adds the following functions to the NWN scripting language: object RandomEncounter(float fChanceOfEncounter = 100.00, object oEncounterObject = OBJECT_SELF, string sTemplate = "random", int iMinNumberOfCreatures = 0, int iMaxNumberOfCreatures = 0, int iMinEncounterDistance = 1, int iMaxEncounterDistance = 15, int iOrientation = 360, int iTolerance = 0, int iCheckDistance = 0, int iLevelOverride = 0, int iDifficulty = 0)

void CleanHouse(int bDestroyPlotItems = FALSE, object oArea = OBJECT_SELF, int iSpawnOverride = 0, int iItemOverride = 0, int iBodyBagOverride = 0)

void SetRndEncProperties(object oObject = OBJECT_SELF, int iDifficulty = 3, int bConsiderCR = TRUE, string sCreatureTable = "re_ceghimpub", int iLifeTime = 180, int iMph = 2, int iEncounterType = ENCOUNTER_TYPE_TOTALPARTYLEVELS, int bConflict = FALSE, int iChanceOnRest = 20, int bLOSCheck = FALSE)

struct RndEncProperties GetRndEncProperties(object oEncounterObject = OBJECT_SELF)

INSTALLATION:

  • Unzip the BESIE package into any temporary directory.

  • Place the following files in the nwn\scripttemplates folder: BESIE custom encounter table.txt BESIE custom commoner table.txt BESIE custom treasure table 1.txt BESIE custom treasure table 2.txt

  • Place the following files in the nwn\override folder: re_demo.2da re_template.2da

  • Place the file “DEMO – BESIE Random Encounter System v181.mod” into your nwn\modules folder.

  • Open the NWN toolset then open the module in which you wish to use BESIE.

  • Select "Import" from the "File" menu.

  • Navigate to the directory into which you extracted BESIE.

  • Select BESIE18.erf.

  • Disregard the message concerning these missing files: re_table.ncs re_rndenc.ncs

  • You should now have the following scripts listed under the "Scripts" section of your "Module Contents" Interface Panel: re_common_spawn re_commoner0 re_commonspwnrhb re_levspawnerhb re_mmorpghb re_modulehb re_oncliententer re_onload re_onrest re_onunacquire re_or re_placespawnhb re_pwrespawnerhb re_rndenc re_sc_dialogue1 through re_sc_dialogue10 re_spawnerhb re_table re_treasure0

  • Under Conversations you should have: re_cv_commoner

  • Under the Miscellaneous section of your custom placeables you should have: BESIE RES Commoner Spawner MMORPG Spawner Placeable Spawner PW RES PW Respawner

  • Under Custom Creatures – Special – Custom5 you should have 14 instances of: Commoner

  • Under Custom Items – Armor – NPC Clothing you should have 10 instances of: Commoner’s Outfit

  • Under the Waypoints section of your custom waypoints you should have: Spawn Point

  • Place the appropriate scripts in their appropriate handlers for full functionality. See the heading Scripts for instructions on how to do this.

  • If you wish to use the BESIE DM’s Widget in your module import the file BESIE181Widget.erf into your module, again by selecting “Import” from the “File” menu. (See the heading BESIE DM’s Widget in the Tools section below)

  • If you do this you will find, under scripts you should have: re_widget1 through re_widget25 re_onactivate

  • Under Conversations you should have: re_widget

  • Under Custom Items – Special – Custom 1 you should have: BESIE Widget

  • In order to use the Widget you must incorporate the script “re_onactivate” into your module, and it is highly recommended that you incorporate “re_oncliententer”. See the heading Scripts under in the Advanced Usage section for instructions on how to do this.

FUNCTIONALITY:

I - THE TOOLS


	The BESIE Random Encounter Spawner:

I realized when designing BESIE that many people who enjoy using the NWN Toolset to design game worlds have no scripting ability and no desire to undertake the daunting task of learning the C-like scripting language of the Toolset. For this reason I have included with this package the BESIE Random Encounter Spawner or BESIE RES.

The BESIE RES is an invisible object which you can simply plop down in an area in your NWN mod/world to receive the benefits of the added random encounter functionality. The parameters of the Random Encounters can be tweaked simply by changing parameters on the object such as Reflex and Will saves. This allows you to include great "old school" random encounters in your mods without ever writing the first line of code!

To use the BESIE RES simply place it in the area in which you want the random encounters to take place. It doesn't really matter where you place it. I usually put it in a corner. The parameters of the invisible object affect the random encounters in that area as follows:

Hit Points = Chance of Encounter. This is the chance that an encounter will take place each heartbeat. IMPORTANT NOTE: This number is representative of a floating point number with an accuracy of two decimal places. Therefore, if you wish a 10 percent chance of an encounter each heartbeat then this number should be a 1000, which represents 10.00. The chance of an encounter each heartbeat can be from 1 which is a .01 percent chance to 10000 which is a 100.00 percent chance.

A heartbeat in NWN corresponds to a combat round which is six seconds long. Therefore if you wish an encounter to take place on an average of once every minute this number should be a 1000, because a 10 percent chance of an encounter every 6 seconds would give you an average of one every 60 seconds. Every 2 minutes would be a 500 for a 5 percent chance, every 3 minutes a 333 for a 3.33 percent chance and so on. Keep in mind that this is only the odds or chance that an encounter will take place. If you set this value at 1000, your players might get, for example, several encounters in quick succession and then not see one for quite a while.

Also of note; this chance is the chance of an encounter for each party in the area. You do not have to increase this number to compensate for PCs that are not partied up or for multiple parties.

Fortitude Save = Difficulty Level. This sets the difficulty level of the random encounters based on the total character levels of the PCs in the party receiving the encounter. Range from 1 to 10. A value of 1 is laughably easy and not very practical. A value of 10 is so hard that it is silly and again not very practical for a random encounter, though there may well be instances where you find use for these two extremes. A value of 0 will cause the difficulty level of the random encounters to match the difficulty setting of the game (from 1 to 5 X2). The value defaults to a level of 5, which is a relatively easy encounter that could reasonably burn from 5 to 20 percent of a party’s resources.

NOTE: Optionally you can have the difficulty of the encounters generated by the BESIE RES tool auto adjust to the average PC level of the party that spawned the encounter, or to any of the other supported “encounter types.” To accomplish this you must have a very basic understanding of scripting. Use the SetRndEncProperties() function to set the encounter type on the area. (See Scripting Functions below)

Reflex Save = Check Distance. This represents the distance, in meters, that a PC must travel before a random encounter check is made. Remember, for reference, that 10 meters represents one square on the grid in the toolset. (NOTE: Prior to v1.5, this parameter represented the chance of an encounter spawning behind the PC).

Will Save = Encounter Distance. The maximum distance, in meters, at which a random encounter can spawn. Set this number lower for small or cramped interior spaces, higher for large outdoor areas. The maximum distance a character can see in NWN is 35 meters so it should never be set much higher than that.

Note: If you want your encounters to always be at the same distance, click on the scripting tab and open up the heartbeat script for BESIE RES. At the very top you will see a RandomDistance variable that is set to TRUE. Change it to FALSE, and your encounters will always be at the distance set by the Will Save parameter.

Tag - The tag that you assign to the BESIE RES will tell it what type of encounter to spawn. It should take the form: "re_***", where *** is a string of letter and/or numbers to indicate to the tool what type of creatures to spawn. They are as follows: a - animals c - construct d - dragon e - elemental g - giant h - humanoid i - insect m - magical beast / miscellaneous n - aberration p - planar u - undead b - bandit x# - This is for custom encounter tables (see Custom Encounter Tables) t# - This is for treasure tables (see Custom Treasure Tables)

So, for example, a value of "re_cgupx1x3x4t0" would select an encounter randomly from the default construct, giant, undead, and planar tables and also from the custom table numbers 1, 3 and 4. Treasure would then be assigned to the spawn according to treasure table number 0. (For more information on Custom Encounter Tables and Treasure Tables see the heading “Advanced Usage”).

NOTE: There is another element to the tag that can cause the BESIE RES tool (or the other tools) to pick an encounter from a special custom table consisting of a 2da file. For instructions on how to build and use these custom tables, please see “Custom Encounter Tables” under section III “Advanced Usage ”.

If you do not assign a tag that begins with "re_" then encounters will be chosen from the full set of standard NWN creatures, or from the random encounter table set by the SetRndEncProperties() function, if you choose to use it. (See BESIE scripting functions).

Don't worry about littering your area or bogging down your AI. If no PCs encounter the random spawns for a period of 3 minutes, they disappear. If the PCs kill a random spawn, but don't pick up the loot, it will also disappear after five minutes.

The Persistent World Random Encounter Spawner (PW RES)

The PW RES is identical to the BESIE RES tool covered above with one important difference. The fortitude saving throw of the tool represents the Encounter Level, not the Difficulty Rating as it does in the BESIE RES tool. This small difference makes for a completely different use for these two tools. The PW RES tool spawns encounters only for a specific level range and is therefore more conducive to persistent worlds where you have an area that is intended for characters of a certain level.

For instance, if you have an area that you want to be appropriately challenging for 5 PC levels, then you would set the fortitude saving throw on this tool to 5, and it will only spawn creatures around that level range, regardless of the level of the PCs in the area. The random encounters in this area would be too difficult for a single level 1 PC, and it would be a cakewalk for a PC of level 12. It would be just right for a party of 5 level 1 PCs, or a single level 5 PC.

	The BESIE MMORPG Style Spawner

For those of you who wish to run MMORPG (Massively Multiply Online Role Playing Game) style servers, ala EverQuest, and need a way to populate large areas with wandering MOBs for your players to kill, I have included the BESIE MMORPG Style Spawner. This tool, like the BESIE RES, requires absolutely no scripting ability whatsoever.

NOTE: In this section I will often refer to randomly spawned creatures as MOBs, since this is a term often associated with MMORPGs. The term actually stands for (Mobile or Movable Object Block and has roots that long predate MMORPGs).

Again, the tool itself consists of an invisible object which you place in your area, and adjust parameters to affect the types of encounters it generates. Place the BESIE MMORPG Style Spawner as close to the center of the area you want populated as possible, then set the parameters of the object. The parameters affect the encounters as follows:

Hit Points - Chance to random walk. This is the chance that each MOB generated by the spawner will perform a random walk action each six second heartbeat. The higher you set this number the busier your MOBs will be. Set it from 1 to 101. This represents a percentage chance offset by 1, so a 1 will be a zero percent chance and your mobs will stand right where they are until they decay or until they perceive a PC and enter combat. A value of 101 means they will perform a random walk every heartbeat.

Fortitude Save - Spawn diameter in 10 meter increments. This is the diameter of the area in which the spawner will randomly place MOBs. The Spawner itself is the center of this area. So, for example, if you put the spawner in the center of a 10 meter tile and set this value to 1 it will generate mobs in a circle that exactly fits into that tile.

Reflex Save - The difficulty level of the MOBs to spawn. There is some tolerance so that there will be some easier and some harder MOBs but this is the level around which the difficulty will center. It should be representative of the character level for which you most intend an area. Setting this value to 0 will cause the spawner to examine all of the PCs presently in the area, total the levels of each party, and then average the parties. This results in MOBs that are powerful enough for the highest level players to kill solo and for the lower level ones to kill in a group. This feature can generate a balanced playing field, provided the players group up in this way. Be careful using it though. It only works if players group up and form the ideal situation of groups of low level players and solo high level players. Rarely will players corporate in such a fashion.

Will Save - The maximum number of creatures to spawn into an area. A good rule of thumb is one for every 6 to 8 square meters of area. In an area that is 32 meters by 32 meters I set this number to about 18 to 24 (28 would be 1 per 6X6 square). The trick is to ensure that your players are challenged enough without the area becoming too difficult. If your players are getting board, try turning this number up, or just increasing the difficulty level, or turn it down if they are getting overwhelmed.

Tag - This works exactly the same way as the BESIE Random Encounter Spawner covered earlier. Refer to that section for an explanation of this parameter.

The rate at which MOBs spawn in is influenced by the number of PCs present. The BESIE MMORPG Spawner will not spawn mobs when there are no PCs present. This prevents your system from being overburdened with MOBs that would not be seen by any PCs anyway. When there are PCs present and 0 MOBs as when the module first loads then there is a 100 percent chance that a MOB will spawn on the first heartbeat. With every spawn after that, this chance decreases. The rate at which it decreases is inversely proportional to the number of PCs such that when there is only 1 PC present and the area is almost at capacity, there is only a very small chance of spawning a MOB. When the Number of PCs reaches 1/4 the maximum number of spawns, then the chance of spawning a MOB each heartbeat will remain at 100 percent so long as the MOBs are not at the area capacity. This helps ensure that there are always enough MOBs to fight when your server is busy, but helps prevent characters from being overwhelmed when it is not.

Also, MOBS generated by the BESIE MMORPG Style Spawner will decay (disappear) after 15 minutes if they are not in killed, presently in combat with a PC, or possessed by a DM. This will ensure that your areas don't become filled with MOBs that might for some reason rest on inaccessible parts of your map. This time is 7 1/2 minutes if you set the encounter level to zero (this helps to get the levels of the MOBs to something appropriate when players of different levels enter and leave the game/map).

The Persistent World Respawner (PW Respawner)

This tool is used to respawn specific creatures in a persistent environment such as plot specific creatures, camp creatures etc. It can be used to create such things as the infamous "camps" in EverQuest and DAOC. Orc camps, gypsy camps, bandit camps... Also, it can be used to respawn plot specific creatures, bosses, guards, merchants or any other important NPC/MOB in your persistent world that might inadvertently or intentionally be killed or despawned.

Like the other tools, this tool is an invisible object on which you set parameters to control the various options. However, the PW Respawner requires another element. Each creature you want to spawn requires a corresponding waypoint. Once BESIE is installed this waypoint can be found in the toolset palette under Custom Waypoints. Its title is “Spawn Point” and will be referred to as such. Each spawn point must have a tag which corresponds to the relevant PW Respawner (See “Will Save” below):

Hit Points - This is the chance that a mob will spawn at any particular spawn point each heartbeat after the allotted respawn time (see “Reflex Save” below). Like the BESIE RES tool, this number is representative of a floating point decimal with an accuracy of two decimal places, so 10000 corresponds to a 100.00 percent chance. (See The BESIE Random Encounter Spawner above).

Fortitude Save - Sets the difficulty level for this MOB, if the MOB is to be chosen from a table rather than a specific creature. Set this parameter to zero to ignore the challenge rating and randomly choose the MOB from all creatures in the table.

Reflex Save - The reset time (in minutes) before a MOB can respawn at any particular spawn point. This time must elapse before the chance of a MOB spawning can be considered. For example if you have this parameter set at 10, and the Hit Point parameter set at 500, then when a MOB is killed, ten minutes must elapse after which there will be a 5 percent chance of that MOB respawning every 6 second heartbeat.

Will Save - PW Respawner number. This parameter is a designator for this particular PW Respawner tool. It is used to determine which Spawn Points are associated with which PW Respawner tool. This enables multiple Respawners to be used in the same area (See Spawn Points below).

Tag - This works almost exactly the same way as the BESIE Random Encounter Spawner covered earlier (Including the use of the 2DA custom tables. Refer to that section for an explanation of this parameter). There is one very important difference, however. With the PW Respawner, the tag can represent the specific ResRef of a creature. If you want the PW Respawner to spawn one particular creature, do not include the “re_” designator at the beginning of the tag and assign it a tag that exactly matches the BluePrint ResRef of the creature you want to spawn. You will probably find that it is much more common, with the PW Respawner, to have the tag represent a specific creature or a custom table with a few weighted (see custom encounter tables for an explanation of “weighted”) creatures to choose from, than to use the standard encounter tables.

Spawn Points - Once you have painted down your PW Respawner, you must also paint down Spawn Points where you want it to spawn creatures. Look under your waypoint palette in the toolset under custom waypoints and select the waypoint called “Spawn Point”. You will notice that this Spawn Point has a default tag of PWS00. Each spawn point tag must begin with PWS followed by two digits. These digits represent the PW Respawner that will spawn a creature here as designated by the PW Respawner’s Will Save parameter (see Will Save above). So a spawn point with the tag PWS00 is associated with the PW Respawner whose Will Save parameter is set to 0. PWS01 corresponds to the PW Respawner whose Will save parameter is set to 1, PWS19 corresponds to the Will Save Parameter of 19 and so on. You can associate as many Spawn Points with a PW Respawner as you like. Each MOB’s location and facing will correspond directly with each spawn point. The physical location and orientation of the PW Respawner tool is irrelevant. Since it is a static invisible object, it can be placed anywhere with no effect on game play. If there are a cluster of spawn points associated with a particular tool such as a “camp” of MOBs, I suggest placing the tool in the midst of those spawn points, so it is easy to keep track of what tool spawns what.

NOTE: PW Respawner designators must only be unique to an area. In other words, you can have multiple PW Respawners with their Will Save parameters set to one (or whatever), so long as they are in different areas. The Spawn Points only correspond to PW Respawners in the same area.

By default a mob will spawn at its spawn point and stand there until it perceives an enemy at which point it will engage in combat. When not in combat the creature will move back to its spawn point, face the proper direction, and quickly regenerate lost hit points.

Each spawn point has modifiers associated with it to control the behavior of the MOB that spawns there. The modifiers are activated by placing a lowercase letter followed by a number to designate the behavior of the modifier after the “PWS##” in the tag.

There are different kinds of modifiers designated by different letters. At this point there are only two. They are designated by the lowercase letter ‘s’ and the lowercase letter ‘t’. ‘s’ designates a “switch” that can be either on or off. For example, to activate switch number one on a Spawn Point associated with PW Spawner number zero the tag of the spawn point would look like this: “PWS00s1”. To activate switches one and four on a spawn point associated with PW Spawner number three the tag would look like this: “PWS03s1s4”. The switches modify default behavior in the following ways:

Switch 1 – Do not return to the spawn point. If the creature moves from its original spawn point for any reason it will not go back. This switch should be used if you have waypoints for this creature to walk or a post for this creature. This will prevent it from trying to return to its spawn point after going to its post or walking its waypoints.

Switch 2 – Random Walk. This causes the creature to wander about in the vicinity of its original spawn point instead of standing still. When using this switch the creature will not return to its original spawn point until it has wandered a distance of at least 20 meters from it. It can be used in conjunction with switch #1, in which case the creature will wander about whatever location it happens to be in when it finishes what it is doing.

Switch 3 – Sit. Instead of standing, the creature will sit on the ground in its location. (Note: Not all creatures have sitting animations).

Switch 4 – No Regeneration. If this switch is active, the creature will not regenerate hit points if it is wounded. Note that the creature will still regenerate if it has natural regeneration ability or an item or spell that gives it this ability.

Switch 5 – Only spawn in daytime (includes dawn).

Switch 6 – Only spawn at nighttime (includes dusk).

The lowercase letter ‘t’ designates a “territory” for the MOB. The number following the ‘t’ represent a distance in meters. A circle with the Spawn Point at its center and a radius designated by ‘t’ is the MOB’s “territory”. Note, that if the ‘t’ modifier is used, then this territory must be at least 30 meters. If it is less than 30 meters then it will default to 30. If a mob chases an enemy outside of this territory it will disappear and reappear back at its spawn point. This modifier is useful if you want the mob to guard some particular area or thing.

	The Commoner Spawner

As the name implies, the Commoner Spawner is used to fill areas such as Inns, Towns, Cities, Villages etc. with randomly dressed common folk. The commoners will wander around the area at random and each will face the nearest commoner to them to give them a realistic feel. To create the randomly dressed commoners, the Commoner Spawner uses Mayseth Aalikor’s “Random Cloth Commoners” package which can be found here (or could at the time of this writing): http://nwvault.ign.com/Files/creatures/data/1029105602051.shtml

The parameters of this tool control its behavior in the following ways:

Hit Points – Chance to Random Walk. This parameter is identical in function to the hit points parameter of the MMORPG Spawner above.

Fortitude Save – Spawn Diameter. This parameter is identical in function to the fortitude save parameter of the MMORPG Spawner above.

Reflex Save – Table Number. Unlike the other tools, the table used for commoner encounters is not determined by the tag, but rather by this parameter. Commoner tables are built from the script template “BESIE custom commoner table” the same way that custom encounter tables are built from the script template “BESIE custom encounter table”. They should all follow the naming convention of “re_commoner#” where # is the number of the table. This number should match this Reflex Save parameter. i.e. if this parameter is set at 5, this commoner spawner will draw its random commoners from the table “re_commoner5”. The default table “re_commoner0” is included with the package.

Will Save – Max Spawns. This parameter is identical in function to the will save parameter of the MMORPG Spawner above. You may wish to set this number higher for the Commoner Spawner as townsfolk, inn patrons etc. may well be much more common than hostile creatures would.

Tag – Unlike the other tools, the tag of the Commoner Spawner does not designate an encounter table. Rather it is used to tell the Spawner what time to turn itself on and off. This is done with the naming convention “re_b#e#” where the # following the ‘b’ tells the spawner what time in game hours to begin spawning commoners, and the # following the ‘e’ tells the spawner what time in game hours to end its spawning cycle and despawn the commoners. i.e. “re_b18e6” will have this spawner begin spawning commoners at 18 hours (6 pm) and end at 6 hours (6 am).

The commoners have a default conversation file with 10 one liners that are chosen at random when the commoner is spawned. This conversation, “re_cv_commoner”, can easily be edited to change the commoners’ one liners.

Note: When there are no PCs present in the area the Commoner spawner will despawn all of the commoners to conserve system resources. It will spawn them in again when a PC enters the area. There will often be a short period of time, up to six seconds, when the first PC enters an area before the spawner fills it with commoners. This is because, for ease of installation and use, the commoner spawner works on the area heartbeat.

	The Placeable Spawner

This tool is used to spawn placeable object in and out at certain times and to respawn them when they are destroyed. It is an invisible object that marks the location of the placeable it is to spawn. This tool is useful if you wish to have placeables in your PW that your players can destroy. Also it is good for such things as respawning PW chests which despawn themselves after closing. The Placeable Spawner works in accordance with the following parameters:

Hit Points – Chance to Respawn. This is the percentage chance that the placeable will respawn here each heartbeat after it is destroyed or despawned.

Fortitude Save – Spawn In Time. Time, in game hours, to spawn the placeable in.

Reflex Save – Spawn Out Time. Time, in game hours, to spawn the placeable out (despawn).

Will Save – ID. The placeable Spawner sets a local variable “re_iID” on the placeable when it spawns it in, and assigns it this value. This can be used as reference by other scripts. If you are not a scripter it is not important. In fact, it probably isn’t important if you are a scripter. I just had a parameter left over so I decided to use it this way. You might find a use for this local.

Tag – Placeable ResRef. This is the blueprint ResRef of the placeable that you wish this Spawner to spawn. Remember that it is case sensitive.

	The BESIE DM’s Widget

The DM’s Widget is an optional tool that will allow a Dungeon Master to control certain aspects of BESIE from within the game. The widget is installed separately. See Installation above. When the widget is installed a DM can use it to enable or disable BESIE completely, enable or disable random encounters for certain players, including himself. He can turn individual tools on and off, generate an encounter spontaneously according to the properties set on the area he is in or view the properties of the area, among other things. The tool is relatively self explanatory. For the widget to function the script “re_onActivate” must either be in your modules OnActivateItem handler or be incorporated into your existing OnActivateItem script. To have DMs automatically receive the tool when they enter the module, place the script “re_oncliententer” into the module’s OnClientEnter handler or incorporate it into your existing script. See ‘scripts’ under the Advanced Usage section below.

II THE SCRIPTING FUNCTIONS

For those of you who are scripters, BESIE adds much more flexibility than can be provided by the tools mentioned above. Place the command #include "re_rndenc" at the beginning of any script in which you wish to use the added BESIE scripting functions. Remember to rebuild the module any time you make a change to a script such as the custom encounter tables. This is always good practice but particularly important when using BESIE. Read on for a complete explanation of the scripting functions that BESIE provides.

	The RandomEncounter() function:

object RandomEncounter(float fChanceOfEncounter = 100.00, object oEncounterObject = OBJECT_SELF, string sTemplate = "random", int iMinNumberOfCreatures = 0, int iMaxNumberOfCreatures = 0, int iMinEncounterDistance = 1, int iMaxEncounterDistance = 15, int iOrientation = 360, int iTolerance = 0, int iCheckDistance = 0, int iLevelOverride = 0, int iDifficulty = 0)

As you can see, every parameter has a default, so in its simplest iteration the RandomEncounter() function can be called with no parameters and it will choose from the default table an appropriately challenging random encounter for the object calling the function (if this is an area object, a random PC in that area will be chosen, likewise for the module object), and randomly place the encounter in a radius from 1 to 15 meters from the object of the encounter.

There is a safeguard built into this function to protect against a random encounter spawning if any PC within a 35m radius of the Encounter Object is in a conversation. The beauty of random encounters is that they can happen anytime, anywhere, and can catch the players completely off guard or ill prepared. However, given the mechanics of conversations in NWN, I thought it best to make an exception for them, as random encounters popping up in the middle of an important conversation with an NPC would be much more frustrating than it would be fun.

This function was designed primarily to be placed in the area OnHeartbeat Handler, but there are many other potential uses. It can be called from an invisible object with a very wide radius and used as a MMORPG style creature generator, populating areas with monsters to fight (such as in the BESIE MMORPG Style Spawner), or it can be called from a chest or some other placeable to act as a trap, or it could be placed on a custom object such as a genie lamp or some such. I'm sure there are many uses that I have not yet thought of.

Note: Although this function returns an object which is the creature that was spawned (or OBJECT_INVALID if no creature was spawned), it can only return one object. Therefore if multiple creatures are spawned for an encounter with one function call, only one of them (the last one created) will be returned. Still this is useful information as it can be used by your scripts to determine if an encounter was indeed spawned by the function call and what kinds of creatures they are.

Optional Parameters:
  • fChanceOfEncounter - This is the chance that the encounter will actually take place when the function is called. It is a floating point value with a precision of two decimal places. In other words the chance that the function will actually produce an encounter when called can be from 0.01 percent to 100.00 percent.
  • oEncounterObject - This is the object of the encounter, around which the encounter will spawn. If the oEncounterObject is an area object or the module object then a random PC will be selected from within that area or module to be the object of the encounter. This parameter should be an Area, Module, or PC object. It should work with NPC objects as well, though I haven't tested this. Lastly it can be used with a placeable object, as it is in the included MMORPG style encounter spawner, but I wouldn't recommend it. This functionality has not been fully implemented for the end user, and the results may be kludgy.
  • sTemplate - A string value to tell the function what type of encounter to spawn. The sTemplate value can take three forms.
  1. A specific creature ResRef ie. "NW_GOBLINA" will spawn the NWN Goblin(A) creature. This is case sensitive. IMPORTANT NOTE: If you use a custom creature vice a standard NWN creature you MUST use the BluePrint ResRef of the creature instead of its tag. The BluePrint ResRef can be found under the “advanced” tab of the “creature properties” window. 2) "random" - When the value "random" is passed then the encounter table will default to the encounter table that was set with the SetRndEncProperties command (See the heading "The SetRndEncProperties() function"). This value is not case sensitive. 3) "re_***" - where *** is a string of letter and/or numbers to indicate to the function what type of creatures to spawn. They are as follows: a - animals c - construct d - dragon e - elemental g - giant h - humanoid i - insect m - magical beast / miscellaneous n - aberration p - planar u - undead b - bandit x# - These are for custom encounter tables (see the section, Advanced Usage) t# - These are for custom treasure tables (See the section, Advanced Usage) 2da - see the NOTE below.

So, for example, a value of "re_cgupx1x3x4" would select an encounter randomly from the default construct, giant, undead, and planar tables and also from the custom table numbers 1, 3 and 4.

NOTE: There is another element to the sTemplate parameter that can cause the function to pick an encounter from a special custom table consisting of a 2da file. For instructions on how to build and use these custom tables, please see “Custom Encounter Tables” under section III “Advanced Usage ”.

  • iMinNumberOfCreatures / iMaxNumberOfCreatures - Sets the minimum and maximum number of creatures to randomly spawn.
    NOTE: If iMinNumberOfCreatures is set to 0 and iMaxNumberOfCreatures is greater than 0 then the function will always spawn a number of creatures equal to iMaxNumberOfCreatures.
    FURTHERMORE: If iMinNumberOfCreatures and iMaxNumberOfCreatures are both set to 0 then the function will consider the levels of the PCs involved (see the iEncounterType parameter under the heading "The SetRndEncProperties() Function") and spawn a number of creatures to yield an appropriate challenge according to the difficulty level (see the iDifficulty parameter under the heading "The SetRndEncProperties Function").
    Also, leave these parameters at zero when using a custom encounter table with minimum and maximum creature values set. Otherwise the values you pass here will override the ones in your custom encounter table. (See "Custom Encounter Tables" in the section Advanced Usage).

  • iMinEncounterDistance / iMaxEncounterDistance - Sets the minimum and maximum distance in meters from the Encounter Object to randomly spawn the encounter. NOTE: If iMinEncounter distance is set to 0 then the encounter will always spawn at a distance equal to iMaxEncounterDistance. iMaxEncounterDistance will always be considered to be at least 1 meter.

  • iOrientation - The number of degrees, counterclockwise, to spawn the encounter from the direction the encounter object is facing. ie. A value of 0 will spawn the encounter directly in front of the Encounter Object. A value of 180 will spawn the encounter directly behind the Encounter Object. A value of 270 will spawn the encounter directly to the Object's right etc. NOTE: A value of 360 will cause the object to be placed at a random angle offset.

  • iTolerance - This nifty little parameter causes a random "tolerance" for the iOrientation of the spawn. The tolerance is the number of degrees the spawn can randomly be off from the defined iOrientation. So if you choose an iOrientation value of 0 and an iTolerance value of 90 the encounter will spawn randomly within a 90 degree arc from 45 degrees to the objects left to 45 degrees to its right. As a further example an iOrientation value of 180 and an iTolerance value of 180 will cause the encounter to spawn somewhere within the 180 degree arc behind the object.

  • iCheckDistance - The distance a PC has to move before a Random Encounter check can be made against him. If the PC has not covered this much distance, then a call to the RandomEncounter() function for this PC will yield OBJECT_INVALID. This distance is figured from one call to the function to the next.

  • iLevelOverride - This parameter can be used to override the PC levels considered when selecting an appropriately challenging encounter. When set to zero, this parameter will be ignored.

  • iDifficulty - When not equal to zero (the default), this parameter will override the difficulty setting established by the SetRndEncProperties() function.

      The CleanHouse() function:

void CleanHouse(int bDestroyPlotItems = FALSE, object oArea = OBJECT_SELF, int iSpawnOverride = 0, int iItemOverride = 0, int iBodyBagOverride = 0)

This function is used to "clean up" an area that has become littered by random encounters. If an encounter is spawned but evaded or avoided by the PCs or defeats the PCs it will destroy the randomly generated creatures if they exist for more than a set amount of time (see heading "The SetRndEncProperties() Function") without encountering any more PCs. When the PCs kill random encounters, if they choose not to pick up the loot that was dropped by them it will destroy this loot after 5 minutes. NOTE: this function will also destroy loot dropped by other encounters in your module areas where it is called. Remember to take this into consideration when using this function. Lastly, when this command is used in conjunction with the included "re_onunacquire" script (placed in the module OnUnacquireItem handler. See heading Advanced Usage) it will destroy objects dropped by PCs if they are left on the ground unclaimed for 30 minutes.

NOTE: To delete body bags (loot dropped by monsters), this function must be called at least twice. The first time it is called it will find all body bags in the area from which it is called that are not marked for decay and mark them. Any body bags that have existed for more than 5 minutes (or the override value) since being marked, not since being dropped, will decay. Keep in mind that this function was designed to be called from the Area OnHeartbeat handler, and if it is then this won’t be an issue.

When a BESIE RES, PW RES, or MMORPG Spawner is placed in an area, those tools call the CleanHouse function themselves. There is no need to place a call to this function in the OnHeartbeat handler of an area which has one of these tools present. In fact, to do so would be redundant.

When the “re_modulehb” script is placed in the Module OnHeartbeat handler, this function is automatically called on relevant areas (i.e. Areas in which there are currently PCs present) each heartbeat. So, when using this script, it isn’t necessary to place calls to this function in your area heartbeats. (See Advanced Usage)

Optional Parameters:
  • bDestroyPlotItems - Tells the function whether or not to destroy items with their plot flags set. If set to TRUE, plot items will be destroyed just like any other item.
  • oArea - The area to clean up.
  • iSpawnOverride - Overrides the default (set by the SetRndEncProperties() function) time to destroy random encounter creatures who are not engaged by PCs.
  • iItemOverride - Overrides the default time of 30 minutes after which to destroy items dropped by PCs (Must be used with "re_moditemdrop" script. See USAGE.).
  • iBodyBagOverride - Overrides the default time of 5 minutes after which to destroy loot that was dropped by creatures who were killed.

NOTE: A value of 0 assigned to the override parameters will cause the function to ignore them and use defaults.

	The SetRndEncProperties() function:

SetRndEncProperties(object oObject = OBJECT_SELF, int iDifficulty = 3, int bConsiderCR = TRUE, string sCreatureTable = "re_ceghimpub", int iLifeTime = 180, int iMph = 2, int iEncounterType = ENCOUNTER_TYPE_TOTALPARTYLEVELS, int bConflict = FALSE, int iChanceOnRest = 20, int bLOSCheck = FALSE)

The purpose of this function is to set certain properties for your random encounters that are likely to seldom change. As you can see, it also has defaults for all its parameters. If the RandomEncounter() function is called before the SetRndEncProperties() function then these values will be set on the module object with their defaults.

These values can be set on the object of the encounter itself, the area, and/or the module and they will be prioritized in that order. It is not a good idea to set these properties on the PC object because they will override the properties set on your area or module and they will “follow” the PC from area to area. In most instances you will want to stick to placing encounter properties on areas and the module object and avoid placing them on the actual object of the encounter. The exception would be if you wanted to use a placeable or some object type other than the PC as the object of your encounter. For instance if you were using the RandomEncounter function as a trap that is triggered by a placeable object and that object is the object of the encounter, you might wish to set different properties on it than are on your area or module. However, keep in mind, that objects other than PCs as encounter objects might produce undesired results, as this is not a fully implemented, fully tested feature.

The best place to call this function is from the Module OnLoad handler. Write an OnLoad script that sets the random encounter properties on your module and all of your areas at once. This way, they are all together in once place for easy reference and editing.

Optional Parameters:

  • oObject - The object onto which these properties will be placed. When a random encounter is called from an object these parameters are checked in the following hierarchy: The object’s properties are used. If there are no properties on the object, then the area’s properties are used. If there are no properties on the area, then the module’s properties are used. If there are no properties on the module, then the module is set with the default properties and they are used.

  • iDifficulty - The difficulty level of the random encounters based on the character levels of the PCs and henchmen involved (see the iEncounterType Parameter). Range from 1 to 10. A value of 1 is laughably easy and not very practical. A value of 10 is so hard that it is silly and again not very practical for a random encounter, though there may well be instances where you may find use for these two extremes. A value of 0 will cause the difficulty level of the random encounters to match the difficulty setting of the game (from 1 to 5 X 2). The value defaults to a level of 4, which is a relatively easy encounter that could reasonably burn from 5 to 20 percent of an individual's resources. Keep in mind, that random encounters should not be very difficult encounters. They have other factors that add to their difficulty level. Remember that they can happen anytime; when a party is preparing or examining equipment, wounded, resting, or otherwise completely off guard. A well rested, well equipped, well prepared party should be able to very easily handle any random encounter. Unfortunate is the adventurer who stumbles upon a random encounter immediately after loosing 80% of his/her hitpoints to a deadly trap, or who is wounded and out of spells after a deadly encounter. You get the drift. It is bad form to make your random encounters too difficult. Save that for your custom encounters which offer big rewards.

  • bConsiderCR - A value of TRUE causes the RandomEncounter() function to consider the Challenge Rating of the creatures in its random encounter table when choosing a creature to spawn. When using the default encounter tables (as opposed to custom tables) this value should be left at TRUE because there are creatures of a wide range of Challenge Ratings in those tables and you will very likely end up spawning a creature much too difficult (or easy) for your party. If this value is set to FALSE, the creature is picked completely at random and the difficulty rating will not stop the spawning of a creature too powerful for the party. This value might be set to FALSE when using custom creature tables and you know that you want all creatures in that table to be considered for random encounters, such as when converting a classic AD&D module with its own random encounter table to NWN.

  • sCreatureTable - This parameter takes the form of the sTemplate parameter in the RandomEncounter() function. ie. "re_***" (see RandomEncounter() function). It is used to set a default encounter table so that one need not be specified by the RandomEncounter() function itself. Once this value is set, then no sTemplate parameter or an sTemplate parameter of "random" passed to the RandomEncounter() function will use this default.

  • iLifeTime - Used to determine the default time a random encounter will exist when not engaged by PCs. (See Cleanhouse() function).

  • iMph - Stands for Minutes Per Hour. If you change the default minutes per hour setting in your Module Properties, you MUST change this value! Otherwise all of the time based functions of your random encounters will be erratic and/or erroneous. Minutes per hour in a new module defaults to 2, so unless you change it, this can be left at default.

  • iEncounterType - Defaults to ENCOUNTER_TYPE_TOTALPARTYLEVELS. Note: as of v1.6 the default has been changed from ENCOUNTER_TYPE_PARTY to ENCOUNTER_TYPE_TOTAL PARTY LEVELS. ENCOUNTER_TYPE_TOTALPARTYLEVELS – Takes into consideration the total of all the levels of the party of the PC when choosing an encounter of appropriate difficulty level. Only party members who are in the same area as the PC are considered. ENCOUNTER_TYPE_PARTY - Takes into consideration the average level of the entire party of the PC who is to receive the encounter when choosing an encounter of appropriate difficulty level. ENCOUNTER_TYPE_AREA - Takes into consideration the levels off all PCs and henchmen within a 20m radius of the PC who is to receive the encounter. ENCOUNTER_TYPE_IND - Takes into consideration only the levels of the individual PC who is to receive the encounter.

  • bConflict - If TRUE then random encounters can occur during combat. Otherwise a call to BESIE will return OBJECT_INVALID if the oEncounterObject is in combat or if the encounter object is an area or module and the creature selected at random is in combat. Note that fleeing from an enemy is not considered being in combat.

  • iChanceOnRest - The chance of a random encounter occurring when a PC rests (only matters on Area or Module Object and the "re_onrest" script must be placed in PlayerOnRest handler of the module object. See Advanced Usage).

  • bLOSCheck - When this parameter is set to TRUE the RandomEncounter() function will ensure that the encounter is in Line of Sight of the object of the encounter. If it is not possible to spawn an encounter that is within line of sight of the encounter object, given the restrictions of the RandomEncounter() parameters, ie. iMinEncounterDistance, iOrientation etc. then the encounter will not take place. For example if the iMinEncounter distance parameter is set to 10 meters and the Object of the Encounter is a PC who is resting in the center of a 10 meter by 10 meter room with the door closed, then it is not possible to spawn the encounter inside the room and stay within the restrictions of the iMinEncounterDistance parameter, so the PC is "safe" from random encounters while in that room. This parameter when set to TRUE will also prevent random encounters from being spawned inside of adjacent rooms. Unfortunately this parameter does not function at the moment because the line of sight check in Bioware's Get**ObjectInShape function does not work. If and when Bioware fixes this function, I will release a version of BESIE with this functionality.

      The GetRndEncProperties() function:

struct RndEncProperties GetRndEncProperties(object oEncounterObject = OBJECT_SELF)

Returns the structure RndEncProperties, with fields representing the elements of the random encounter properties on oEncounterObject as set by the SetRndEncProperties function.

Fields:

  • bInitialized - This is TRUE if the random encounter properties have been set on this object via the SetRndEncProperties function.

  • iDifficulty

  • bConsiderCR

  • sCreatureTable

  • iLifeTime

  • iMph

  • iEncounterType

  • bConflict

  • iChanceOnRest

  • bLOSCheck

    III ADVANCED USAGE

Switches

The following local variables, when set on the module object, act as switches to control the operation of BESIE:

These locals can be set using the BESIE DM’s Widget: “re_” on the module object, when set to TRUE, will prevent BESIE from spawning any random encounters on this player. If the RandomEncounter function is called with this player as the encounter object, it will return OBJECT_INVALID. This local is set to TRUE on the DM by the re_oncliententer script when it is places in the module’s OnClientEnter handler.

“re_disable” on the module object, when set to TRUE, will disable the RandomEncounter() function altogether. No new encounters will spawn.

Any individual tool can be disabled by setting the local Integer “re_disable” on the tool itself.

These locals can not be accessed by the BESIE DM’s Widget. If you want to set any of these at runtime you will have to do it through the “setmodulevarint” command on the command line: “re_disableMMORPG”, “re_disableBESIERES”, “re_disablePWRES”, “re_disableCommonerSpawner”, “re_disablePWRespawner”, and “re_disablePlaceableSpawner” can all be set on the module object to disable the respective spawner type globally or can be set on an area object to disable the respective spawner type within that area. “re_iBegin”, and “re_iEnd” can be set on the MMORPG Spawner, BESIE RES, or PW RES tools to give them start times and stop times.

At the heading of the MMORPG Spawner, BESIE RES, and PW RES heartbeat scripts are two user definable variables called “StartTime” and “StopTime”. You can set these variables then save the script under a different name in order to create a spawner that will start and stop at preset times.

Scripts

BESIE includes several scripts that are intended to be placed in various event handlers in your module to facilitate the use of BESIE and to add functionality. These scripts are completely optional, but to use BESIE to its full potential they should be implemented. If you are using another add on, or have written scripts for these handlers yourself, you can simply incorporate these scripts into the existing ones:

  • re_onunacquire – This script is designed to go in the Module OnUnacquire handler. Its purpose is to mark items dropped by the PCs so that they can be destroyed by the CleanHouse function. The CleanHouse() function will always cause body bags (loot bags dropped by dead creatures) and evaded or avoided random encounters to decay, but without this script, if a PC picks up an item then drops it, it will never decay.
  • re_modulehb – This script goes in the Module OnHeartbeat handler. It runs the CleanHouse() function with default parameters on every area in the module in which there is presently a PC.
  • re_oncliententer – Goes in the Module OnClientEnter handler. This short script will check to see if a player is coming into the game as the DM. If so, it will stick a local variable on him to prevent BESIE from spawning encounters on him when he possesses a creature and it will give him a BESIE Widget, if he doesn’t already have one.
  • re_onrest – This should be put in the Module OnPlayerRest handler. It handles encounters that take place while a player is resting. Also it determines the time that a player must wait between rests, and places some visual effects on resting players. The chance of an encounter taking place while resting is determined by the iChanceOnRest parameter of the SetRndEncProperties() function. However, this parameter serves no purpose if the “re_onrest” script is not in place. The darkness effect, and the time a player waits between rests are easily modifiable by opening and examining the script. The variables that affect these things are clearly marked.
  • re_onactivate – If you wish to use a BESIE DM’s Widget in your module you must incorporate this script into your module’s OnActivateItem handler. This is the script that enables widget and passes control to the widget conversation file.
  • re_onload – The onload handler is the best place to set the random encounter properties for each of your areas. This script just gives you a starting place and some guidelines.

Custom Encounter Tables

There are two types of Custom Encounter Tables supported by BESIE. The newest type, introduced in BESIE v1.8 is in the form of a 2da file. This type of custom encounter table is much more simple to create but also less powerful. Both Types are covered below:

Type I (2da files)

2da files are simply text files in the form of a table. They must have the extension .2da and must exist either in either your “override” folder or in a hak pack in your “hak” folder under your main NWN install folder. In order for BESIE to use a 2da encounter table, the file itself must be named as follows: “re_.2da”.

Like all tables, 2da files consist of rows and columns. The columns of a 2da custom encounter table for BESIE consist of the following elements, and their headings must be exactly as follows:

  • ResRef – This is the blueprint ResRef of each creature in the table.
  • Minimum – The minimum number of this type of creature to spawn when encountered. (note: If this number is set to 0, the result will always be a number of creatures equal to the ‘Maximum’ value)
  • Maximum – The maximum number of this type of creature to spawn when encountered. (note: When used with the MMORPG spawner, these numbers, although they must be present, are irrelevant)
  • Treasure – The treasure tables to use for this creature. Each table number must be preceded by a lowercase letter ‘t’ exactly as it would be in the tag for the BESIE RES tool. See Custom Treasure Tables below.
  • TableLength – This should be the only element of row zero of your table and row zero should be the only place where it resides. This integer must exactly match the number of rows in your encounter table. If it does not, BESIE will return an error when a tool or function tries to pull an encounter from this table.

Each 2da file must begin with the heading “2DA V2.0”. This must be the very first thing in the file. The following is an example of a BESIE custom encounter table consisting of a 2da file it contains 3 goblins and 3 orcs. Each will spawn in groups of 1 to 5. This file can be found in the BESIE zip file. It’s file name is “re_example.2da”.

2DA V2.0

  ResRef			Minimum	Maximum	Treasure	TableLength

0 **** **** **** **** 6 1 NW_GOBLINA 1 5 t0 2 NW_GOBLINBOSS 1 5 t0 3 NW_GOBCHIEFA 1 5 t0 4 NW_ORCA 1 5 t0 5 NW_OrcChiefA 1 5 t0 6 nw_orcboss 1 5 t0

In order for your tool or function to call a 2da encounter table the tag of the tool must be in the following format: “re_2da_”. The name of the table should not include the .2da extension of the actual file name. So, if you have a custom encounter table called “re_MyTable.2da” and you want to use it with a BESIE RES tool, the tag of the tool should be “re_2da_MyTable”.

Imporant Note: NeverWinter Nights 2da files can only have file names of 16 characters. Three of those are used by the “re_” prefix. If your 2da filenames are too long, your encounter table will be invalid and you will receive an error when a tool or function tries to call an encounter from it.

Type II (Custom Encounter Scripts)

The second type of Custom Encounter Table supported by BESIE is a little more complex, but much more powerful. These custom encounter scripts allow you to build custom tables in which the Challenge Rating of the creatures can be considered when spawning an encounter (just like in the standard tables), and they also allow you to “weight” the chances of particular creatures spawning.

After importing BESIE into your module you will notice there is a script template with the title "BESIE custom encounter table". This is the template for a script designed to be modified by you for the purpose of creating your own custom random encounter tables to be used with the RandomEncounter() function (See the sTemplate parameter under the heading "The RandomEncounter() Function"). There are portions of this script that are not meant to be modified. The script is clearly marked as to what should and should not be changed for normal functionality. Here is an example of a portion of the custom random encounter table:

                case 0:sChoice = "";// Creature ResRef goes between the " marks.
                fCR = 0.0;          // Set this to the challenge rating of the creature as shown on the creature palette.
                iMinNum = 0;        //
                iMaxNum = 0;        // If these are left at zero then an appropriate number of creatures will be spawned based on the CR.
                iWeight = 1;        // This is the number of times this mob should be considered for the likelihood of appearing.
                break;

                case 1:sChoice = "";
                fCR = 0.0;
                iMinNum = 0;
                iMaxNum = 0;
                iWeight = 1;
                break;

                case 2:sChoice = "";
                fCR = 0.0;
                iMinNum = 0;
                iMaxNum = 0;
                iWeight = 1;
                break;
  • sChoice - Should be set to a creature ResRef. Remember, this value is case sensitive.
    IMPORTANT NOTE: For a custom creature you MUST use the BluePrint ResRef of the creature. The BluePrint ResRef can be found under the “advanced” tab of the “creature properties” window. If you use the tag, BESIE will NOT recognize the creature as a legitimate creature.
  • fCR - Should be set to equal the challenge rating as shown on the creature palette. fCR is only used in deciding whether or not to consider this creature for an encounter based on the difficulty level set by SetRndEncProperties(). If the parameter bConsiderCR is set to FALSE by the SetRndEncProperties() function then fCR will not be used, however it is still good practice to include this value.
  • iMinNum/iMaxNum - The minimum and maximum number of these creatures to randomly spawn. These values are overridden by the iMinNumberOfCreatures and iMaxNumberOfCreatures parameters in the RandomEncounter() function. If you want these values to be considered then use zeros in the RandomEncounter() function. If you want the number of creatures spawned to be based upon the level of the PCs involved in the encounter then leave both of these values at zero both here and in the RandomEncounter() function.
  • iWeight - The purpose of this variable is to lend a "weight" to the chances of this creature being spawned. A creature is considered a number of times equal to this value. A creature with a weight value of 2 is considered twice, 3 is considered 3 times and so on.

There are ten creature "slots" in the custom encounter table, but more slots can easily be added by simply copying an existing one verbatim and changing the case number to an incremental value. The script is designed to accommodate this sort of change. If you have less than ten creatures to place in the table, simply leave the other slots as they are.

After you finish modifying the table, save the script with the filename “re_custom#” where # is the number of the custom encounter table. For example if you have a very large module or a persistent world with 12 custom encounter tables then they would have the file names “re_custom1” through “re_custom12”. You must use this naming convention in order for the functions and tools to access these encounter tables.

	Custom Treasure Tables

After importing BESIE into your module you will notice there are two script templates with the titles "BESIE custom treasure table #". These scripts are designed to be modified by you for the purpose of creating your own custom treasure tables to be used with the BESIE tools or the RandomEncounter() function (See the sTemplate parameter under the heading "The RandomEncounter() Function"). There are portions of this script that are not meant to be modified. The script is clearly marked as to what should and should not be changed for normal functionality.

Please note that these script templates are only guides to help you write treasure scripts. You do not need to use these templates. You can write your own treasure scripts from scratch. Advanced Scripters, it is not, by any means, necessary to follow the convention set forth in the “BESIE custom treasure table #” template. The “re_treasure#” scripts are called by an ExecuteScript() function within body of the RandomEncounter() function. They are actually executed by the creatures themselves i.e. ExecuteScript(“re_treasure” + sScriptNumber, oCreature). So OBJECT_SELF will be the creature who is to receive the treasure. You can script your own treasure tables to divvy out treasure in any way that your imagination and scripting ability see fit.

Before writing treasure scripts or even modifying the included templates you must be a somewhat proficient scripter. An in depth explanation of these templates or how to write treasure scripts from scratch is beyond the scope of this document.

IMPORTANT NOTES:
Table number 0 is already used by the standard treasure table that is included with BESIE. “re_treasure0” does not follow the standard convention and should only be modified by advanced scripters.

You may notice that when “re_table0” is used, and creatures drop a bag containing money it will always contain an additional item. This item is meat for most creatures, a small piece of quartz for elemental and planar creatures, and rags for undead. If you have the CleanHouse function implemented or the random encounter was called from one of the tools then this item will disappear on the very next heartbeat. There is a solid functional reason for this: For some reason (almost certainly a bug) the Neverwinter Nights engine will not allow a creature to drop only gold as treasure. If the creature possesses only gold, he will not drop it when he dies. If he possesses gold and at least one other item, he will drop both the gold and that item. This additional item is very nearly worthless. If you are scripting the random encounters yourself, remember to either place the “re_modulehb” script on the Module OnHeartbeat handler (see “the scripts” elsewhere in this section) or to call the CleanHouse() function on a heartbeat handler to clean up the bags.

When writing your own treasure scripts if you want to endow your creatures with gold and only gold you will find it necessary to include an additional item yourself, unless you find some other work around in which case I hope you let me know . If you want the CleanHouse() function to immediately decay this additional item as it does with the default table then set a local int on this item like so: SetLocalInt(oItem, “bItemForGold”, TRUE).

Here is an example of a portion of the “BESIE custom treasure table 2” script. This short explanation is designed to help get you started:

                case 0:sChoice = "";// Treasure resref goes between the " marks.
                sIfIs = "";         // Only give this treasure to a creature with this TAG (TAG not RESREF).
                fMinCR = 0.0;       // Only give this treasure to a creature whose challenge rating is between these two values.
                fMaxCR = 0.0;       // Leave them at 0.0 if you wish them not to be considered.
                fChance = 0.0;      // Set this to the percentage chance of the creature having this item.  This is accurate to one one hundredth (0.01).
                iMinNum = 1;        //
                iMaxNum = 1;        // The minimum and maximum numbers of this treasure item to randomly give.
                break;

                case 1:sChoice = "";
                sIfIs = "";
                fMinCR = 0.0;
                fMaxCR = 0.0;
                fChance = 0.0;
                iMinNum = 1;
                iMaxNum = 1;
                break;

                case 2:sChoice = "";
                sIfIs = "";
                fMinCR = 0.0;
                fMaxCR = 0.0;
                fChance = 0.0;
                iMinNum = 1;
                iMaxNum = 1;
                break;
  • sChoice - Should be set to an item ResRef. Remember, this value is case sensitive.
    IMPORTANT NOTE: For a custom item you MUST use the BluePrint ResRef of the item. The BluePrint ResRef can be found under the “advanced” tab of the “item properties” window. If you use the tag, BESIE will NOT recognize the item as a legitimate item.
  • sIfIs - If this variable is set to a creature tag, then only a creature with this tag will have this item. This is useful if you have a certain plot creature in your random encounter tables who is to be the only creature to carry a specific plot item. If this variable is not set, it will be ignored.
  • fMinCR & fMaxCR - This is the minimum and maximum challenge rating of a creature who is to have this item. This is useful to ensure that creatures do not possess treasure that is inappropriate for their level of difficulty. If these numbers are left at 0.0, they will be ignored.
  • fChance - If all other criteria are met, this is the chance that this item will appear on a creature. It is accurate to one one hundredth (0.01) percent. So the odds of a creature having an item can range from 1 in 10,000 (0.01 percent) to 100 percent of the time.
  • iMinNum & iMaxNum - If an item is a stackable item, such as potions or scrolls, these two variables determine a minimum and maximum number to randomly appear.

There are ten "slots" in this table, but more slots can easily be added by simply copying an existing one verbatim and changing the case number to an incremental value. The script is designed to accommodate this sort of change. If you have less than ten items to place in the treasure table, simply leave the other slots as they are.

After you finish modifying the table, save the script with the filename “re_treasure#” where # is the number of the custom table. You can have as many custom tables as you like and assign them any number but they must always use the standard naming convention of “re_treasure#” in order for the functions and tools to access these encounter tables.

Creature Appearances Aberrations, Constructs, Dragons, Plants

Area Teleport Switches

Armor Resref Convention

BESIE Random Encounter System

Item Resref Convention

NESS Intro & Examples

NESS Spawner System

NPC Behavior Variables

NWNDS Animal Companions

NWNDS Player Races

NWNDS Player Classes

NWNDS Damage Reduction

Weapon Resref Convention

Zunath's Structure System