NWN2

See here for the updated pricing documentation:

https://www.alandfaraway.info/wiki/Pricing_Documentation

In order to create a new C# script, it's recommended to make a copy of the 'ACR_EmptyScript' project (an empty template/base script), make small alterations to the project file, and begin adding new code. The following checklist describes the necessary steps to get started (assumed to be using the ACR build system from a git checkout):

1) Pick a name for the new script, like ACR_MyScript.

2) Make a directory under alfa2_acr.hak named off of your script. In this case, ACR_MyScript.

3) Copy *.cs and *.csproj from ACR_EmptyScript into your new directory.

4) Rename ACR_EmptyScript.cs to ACR_MyScript.cs, and rename ACR_EmptyScript.csproj to ACR_MyScript.cs.

5) Edit StandardEntrypoints.cs, replace all instances of ACR_EmptyScript with ACR_MyScript.

6) Edit ACR_MyScript.cs, replace all instances of ACR_EmptyScript.

7) Edit ACR_MyScript.csproj, replace all instances of ACR_EmptyScript with ACR_MyScript.

8) Generate a new GUID in registry form and replace the existing GUID in the tag within ACR_MyScript.csproj. GUID Generator (guidgen.exe, ships with Visual Studio and the .NET 4 SDK) is recommended. This step isn't strictly required, but highly recommended. Ask for help in from a tech department member (or the ACR/tech forum) if you don't have these tools and someone should be able to help out.

9) Edit AssemblyInfo.cs, replace all instances of ACR_EmptyScript with ACR_MyScript.

10) Generate another new GUID in C# attribute form and replace instances of the previous GUID in AssemblyInfo.cs with the new one. This step is highly recommended but isn't strictly required.

11) Edit the makefile in the alfa2_acr.hak directory and add the new script in the following sections:

- CLRSCRIPT_OBJECTS= (don't forget to add a trailing \ for the previous line!)

- makeclrscripts:

- clean:

Just follow the format of the existing entries; this step should be relatively straightforward.

12) Optionally, add the script to the Visual Studio workspace (solution) under alfa2_acr.hak\ACR_ManagedScripts\ACR_ManagedScripts.sln. This isn't required to make the script build, but it makes it easier to use the Visual Studio IDE as your source code editor.

An example git commit showing what should be touched for adding a new script can be found here:

https://github.com/ALandFarAway/ALFA-Base-Resources/commit/3f4e75cc53095...

Note that if you want to link a library source file (in the repository root\CLRScript directory), it's recommended to edit the script program's .csproj project file by hand. If you add the file within the Visual Studio IDE, the editor creates a private copy of the library file, which means that you won't get bug fixes or future changes made to the common file. The example ACR_EmptyScript references several of the common library source files.

If you want to pass arguments to the ScriptMain() of the C# script, add the types to the ScriptParameterTypes[] array in ACR_MyScript.cs. Note that you can only pass in int (Int32), float (Single), or string (String) types as arguments to ScriptMain().

Only the class containing the ScriptMain() can directly call NWScript APIs. You can pass the current working instance around to functions in other classes if needed. Use caution when it comes to saving a reference to a main class instance in a global or static variable; a DelayCommand (or other 'action' continuation) initiated from such an instance won't work properly.

It is only possible to call NWScript APIs if you are within a context that has been called back by the engine first, i.e. ultimately called by ScriptMain() or by a DelayCommand or AssignCommand (or other 'action' type) continuation. Other threads can't call NWScript APIs directly, and the main thread can't call them unless entered by the engine (so don't call NWScript APIs from a window procedure or other non-engine callbacks on the game's main thread). One way to work around these limitations is to have a periodically scheduled engine script callback on the main thread that checks for work to do on behalf of other threads; the ACR_ServerCommunicator project demonstrates this.

A DelayCommand continuation can be started like this:

DelayCommand(1.0f, delegate()
{
PrintString("In a delay command");
});

Just like in NWScript, you can use variables in the 'containing' function within the DelayCommand.

If you want to attach complicated state to a game object, one option is to use a Dictionary that indexes on the game object id (the 'object' in NWScript). Be sure to decide how to handle the underlying game object dying or getting cleaned up.

It is possible to access functionality written in NWScript source code from a C# script with some limitations. This can be useful in some cases where complex functionality is already written in NWScript and it's desirable to avoid duplicating code. The ALFA.Database library class (CLRScript\ALFADatabase.cs) demonstrates the use of NWScript interop to project some of the acr_db_persist_i library functions (such as those for SQL queries) into C# for use by C# scripts. If you're going to add a wrapper for a NWScript-language function, you should reuse the same IGeneratedScriptProgram object that ALFA.Database uses. Otherwise, if the NWScript-language function uses a DelayCommand or AssignCommand (or other 'action' wrappers), they won't fire properly.

There are two main options for calling a C# script. You can either directly assign the C# script as the event handler for a script event for an object, or you can call it explicitly from NWScript using ExecuteScript/ExecuteScriptEnhanced. The latter is usually how we interface with C# scripts today; for example, check out acr_server_misc_i or acr_server_ipc_i. These headers create NWScript-language wrappers around ExecuteScriptEnhanced to pass some data to the ScriptMain() of a C# script.

Like much of our ruleset, ALFA's crafting system tries to be as faithful as is reasonable to the 3.5 D&D ruleset. Currently, only magical crafting is implemented, and of that only consumable crafting is fully automated.

Costs are not discussed here. To compute the costs of items, in GP or XP, see ALFA's other documentaion.

Player's Guide:

Magical crafing requires several things:

• A crafting project. This is an item signifying a work in progress. Consumable crafting projects can be created by players with the appropriate consumable crafting feats. Other projects must be DM-created.
• A quiet work area. In ALFA this means PCs can only work on crafting projects in places where they'd ordinarily be able to rest comfortably (inside rest triggers). Tents out in the wilderness do not cut it.
• The necissary feat (Craft Wand, Brew Potion, Scribe Scroll, Craft Arms and Armor, etc.).
• The proper spells imbued into the item. In the case of consumables, the needed spell is always the spell cast by the consumable. In the case of permanent magic items, the needed spells (if any) are automatically picked by the crafting system and depend on the nature of the item. These spells can come from anything: a scroll, wand, another PC, etc.
• Gold. The cost to create consumables is paid for up-front, though other crafting projects are pay-as-you-go.
• Experience. Crafting is a drain on experience. A PC loses experience as they craft, though they cannot lose a level doing so. If their XP total would drop below their last level, crafting becomes impossible.
• Magic power. The person doing the crafting work (not imbuing the spell) must have a caster level equal to or exceeding the minimum caster level required to craft the item.

To examine the costs, needed spells, and minimum caster level of a crafting project, simply examine it.

Creating Crafting Projects

Players can "purchase" consumable crafting projects by using the appropriate feat (Brew Potion, Scribe Scroll, Craft Wand). This will open a store allowing the player to purchase any item they have a high enough caster level to create. Note the store includes items the character may not have the ability to imbue with the proper spells - this is intentional, as the character may wish to create something which needs the hepl of others.

Purchasing something from the "store" represents the character gathering the necissary ingredients to create the purchased item, and should be roleplayed as such. There are no refunds, so chose wisely.

Experimental:

DMs can create crafting projects out of any item. To do this, they simply use their Craft feat (in the same manner a player would) on an item. This turns it into a crafting project, which can be worked on like any other. Note that if a DM saves a crafting project on their avatar, the project will be ruined due to technical limitations. The game will worn a DM acquiring a crafting project. They should be left in the hands of PCs.

DMs can complete a crafting projects by using the Craft feat from their avatar on it. Note this will destroy any saved progress made by PCs.

Doing the Work:

To craft:

1. Examine the item to see what spells are needed (if any).
2. Cast those spell(s) on the item.
3. Acquire the necissary GP and XP.
4. Use the 'Craft' feat (which all characters have; it can be dragged onto a toolbar slot from the feats list in the character window) on the item while inside a rest zone. 
5. Repeat as necissary to complete the item. Crafting projects can be progressed only once per day.

Known Issues:

• Many consumable prices are a few percent off, due to the annoying way NWN2 calculates item prices. I'm looking into this.
• In the case of oddball crafters (rangers, paladins, bards, sometimes even clerics or druids) the price of some consubles will be off. Because we are limited in how many different combinations of items, prices and caster levels we can represent, we have to make best guesses on who will be crafting what. This means guessing the most common spell level, and going with it.
• DMs cannot convert stacks of items into crafting projects.
• Trying to "use" an unfinished project will make a potion unusable until resting. It will also deplete charges of an ability which consumes multiple charges per use. Don't use unfinished projects. They don't work anyhow.
• Long descriptions on crafted items are sometimes destroyed. I'm looking into this one.
• Projects saved into DM or local-vault character files will be made uncraftable and unusable.

This document records the changes and the state at the time of documentation accompanying the release, on April 28th when it was released.

Change Log

New Systems:

• Servers that are under significant load are now capable of adjusting the object update timers on logged in players, in order to recover performance when the server is very busy. The object update timer will now range from once every 200ms to once every 600ms, depending upon the current load of the server.
• It is now possible to tool regions in game where swimming is possible, with correct mechanics and animations, both with and without breathable air above. Players are encouraged to use caution when going through such areas-- it is very possible to drown, and very possible to die while attempting to rescue dive.
• When a DM attempts to open the Player List (default pressing P), they will now receive a report of players logged onto the same server. More verbose notes of its function below.
• ALFA now provides a system for the automated crafting of magic consumable items. The player-facing documentation exists here, and the state of the documentation at the time of this rollout is copied below.

 Fixed Systems:

• The chat list GUI will be more accurate when deciding whether to display /t or #t before a given character's name in the list box.
• "Players" and "DMs" in the chat list box read "Local Players," "Remote Players," "Local DMs," and "Remote DMs" when expanded, and include the number of people in each group in parenthesis.
• If a player logs out with the chat list expanded, that player will no longer be missing lists of remote players and DMs upon returning.
• Our systems for detecting the Client Extender will now refresh every time a player logs in, and players can expect to more-consistently see functionality that best uses their chosen client.
• Log file entries are now written when a PC is saved from death by the damage cap.
• Treants are now huge, not medium, creatures.
• Corpses now decay in 20 days, instead of 55.
• Players who are healed from negative to positive hit points are capable of again being saved from death by the damage cap immediately.
• Players who are struck multiple times within a flurry will be saved from death by the damage cap for that flurry, and will again be made killable during the next.
• People who speak drow can understand both drow and elven, and vice versa.
• Custom loading screens introduced in ACR v1.84 are again visible and functional
• Custom loading screens introduced in ACR v1.84 are now visible to DMs who are jumping through areas by use of functionality like the chooser.
• The spell preparation GUI associated with offline rests will no longer claim that you've created a bug when double clicked.
• Paladins and Rangers need to be level 4 to prompt the offline resting spell preparation functionality.
• Divine Spellcasters can no longer get a second spell preparation on their first day online.
• NPCs who are attacking characters who are incorrectly labeled as flat-footed (either because of not being actively engaged in combat at the moment or because they have uncanny dodge) will receive a penalty to attack which will require them to roll the same number on their d20 to hit their target as if the engine had not counted them as flat-footed. This fix does not (yet) prevent sneak attacks made on characters who are incorrectly seen as flat-footed.
• The chat commands #hideremoteplayers on and #hideremoteplayers off can be used to make the chat list GUI not display players from other servers.
• Fatigue when resting follows the SRD guidelines: resting in medium or heavy armor will always restult in fatigue, and resting in light armor will never result in fatigue.
• New copies of the DMFI tool will be weightless
• Walkmesh helpers are now deleted as part of a module's startup event-- while leaving the walkmeshes they created intact. The effect of this change will be fewer objects present in any given area and fewer visual artifacts, such as red sparkles on the ground or black blocks in the air.
• KEMO chairs will be much more adamant about restoring typical collision calculation after moving away from them. It remains an exploit to use KEMO chairs to subvert collisions, and attempting to do so outside of the context of supervised testing can expect censure.

New Models

• Half-Elf and Drow Male heads 42, 44, 45
• Jaeson's tapestry pack of placeables.

New Feats

• A series of placeholder feats for skill foci in ALFA's custom skills have been added. They are presently non-functional, and only represent a place to sink the feat if it was intended to be spent as such.

Known, But Not Fixed

• Occasionally, a character's spell book GUI will appear empty as part of the triggering of the offline resting functionality. We believe that this is caused by a race condition (that is, the particular order of events of information received from the server relative to the particular speed at which events are processed by the client), which has proven to be rare. We, thus, have not been able to create a reliable fix for this bug, but we are aware that the downstream effects are serious. If anyone can reliably reproduce this bug, it would help enormously in getting these systems functioning well; until then, players who see a spellbook appear as inappropriately empty should relog.
   

 1.86 Hotfix
We also resolved a few issues with this release in a hotfix, namely:

• Bad logic in the player reports, resulting in many unnecessary invalid textures
• An inadvertently-killed self-check in the IPC code, causing cross-server tells to function uncommonly-slowly (roughly 5x slower, in fact)
• Some performance and logic issues on the Phat Lewt system.

Crafting:

Magical crafting requires several things:

• A crafting project. This is an item signifying a work in progress. Consumable crafting projects can be created by players with the appropriate consumable crafting feats. Other projects must be DM-created.
• A quiet work area. In ALFA this means PCs can only work on crafting projects in places where they'd ordinarily be able to rest comfortably (inside rest triggers). Tents out in the wilderness do not cut it.
• The necissary feat (Craft Wand, Brew Potion, Scribe Scroll, Craft Arms and Armor, etc.).
• The proper spells imbued into the item. In the case of consumables, the needed spell is always the spell cast by the consumable. In the case of permanent magic items, the needed spells (if any) are automatically picked by the crafting system and depend on the nature of the item. These spells can come from anything: a scroll, wand, another PC, etc.
• Gold. The cost to create consumables is paid for up-front, though other crafting projects are pay-as-you-go.
• Experience. Crafting is a drain on experience. A PC loses experience as they craft, though they cannot lose a level doing so. If their XP total would drop below their last level, crafting becomes impossible.
• Magic power. The person doing the crafting work (not imbuing the spell) must have a caster level equal to or exceeding the minimum caster level required to craft the item.

To examine the costs, needed spells, and minimum caster level of a crafting project, simply examine it.

Creating Crafting Projects

Players can "purchase" consumable crafting projects by using the appropriate feat (Brew Potion, Scribe Scroll, Craft Wand). This will open a store allowing the player to purchase any item they have a high enough caster level to create. Note the store includes items the character may not have the ability to imbue with the proper spells - this is intentional, as the character may wish to create something which needs the hepl of others.

Purchasing something from the "store" represents the character gathering the necissary ingredients to create the purchased item, and should be roleplayed as such. There are no refunds, so chose wisely.

Experimental:

DMs can create crafting projects out of any item. To do this, they simply use their Craft feat (in the same manner a player would) on an item. This turns it into a crafting project, which can be worked on like any other. Note that if a DM saves a crafting project on their avatar, the project will be ruined due to technical limitations. The game will worn a DM acquiring a crafting project. They should be left in the hands of PCs.

DMs can complete a crafting projects by using the Craft feat from their avatar on it. Note this will destroy any saved progress made by PCs.

Doing the Work:

To craft:

1. Examine the item to see what spells are needed (if any).
2. Cast those spell(s) on the item.
3. Acquire the necissary GP and XP.
4. Use the 'Craft' feat (which all characters have; it can be dragged onto a toolbar slot from the feats list in the character window) on the item while inside a rest zone. 
5. Repeat as necissary to complete the item.

Known Issues:

• Many consumable prices are a few percent off, due to the annoying way NWN2 calculates item prices. I'm looking into this.
• In the case of oddball crafters (rangers, paladins, bards, sometimes even clerics or druids) the price of some consubles will be off. Because we are limited in how many different combinations of items, prices and caster levels we can represent, we have to make best guesses on who will be crafting what. This means guessing the most common spell level, and going with it.
• DMs cannot convert stacks of items into crafting projects.
• Trying to "use" an unfinished project will make a potion unusable until resting. It will also deplete charges of an ability which consumes multiple charges per use. Don't use unfinished projects. They don't work anyhow.
• The description of crafted items is often destroyed. I'm looking into this one.
• Projects saved into DM or local-vault character files will be made uncraftable and unusable.
• Turning an unidentified item into a crafting project will make that project completely free.

Player Report

Beginning with this version, DMs who open the Player List (by default, "P" is mapped to this GUI) will only briefly see the default Player List, while our scripts verify (for security reasons) that they are indeed DMs logged in as DMs before it is replaced by the ALFA Player Report. This report is more directed toward DMs, and focuses on player groups and tracking, and has removed the player-facing functionality for character vs. character hostility management, joining parties, and managing party leadership.

As such, the interface reads differently:
Party Membership is color coded on the Player Report. These colors are assigned and re-assigned to parties at the moment the Player Report is opened, so this will only be consistent between DMs if it is opened by both DMs with no players logging in or out in between the instances of color assignments. There are seven "teams" that the Player Report is capable of displaying: blue, cyan, red, magenta, green, brown, and grey.
Character Alignment is represented by the default NWN2 icons, in a column next to the character name.
Character Deity is represented by the deity's holy symbol-- or blank, if none-- in a column beside the character's alignment
Character Primary Class is represented by the class' default icon. If the character has a prestige class, it will display that icon; if the character is multiclassed without a prestige class, it will display the higher-level class' icon. If all class selections are equal, it will display the one taken at level 1.
Character Wealth Level is represented by new icons: an out-turned pocket represents characters who have less than half of their target wealth (and thus desparately need loot). A stack of copper coins represents characters who have more than half of their target wealth, but less than target (and thus need loot). A stack of gold coins represents characters who have at least their target wealth, but less than 150% of their target wealth (and thus can advance some before anyone has to worry about loot). A pile of gold coins and bars represents a character who has more than 150%, but less than 200%, of their target wealth (and thus could stand to waste or give away some money, and should probably actively have their rewards reduced). A money bag with an exclamation point represents a character who has more than 200% of their target wealth (and is thus ineligible for any wealth-related drops, and should likely have their items evaluated for appropriateness and Standards/ guidelines compliance).
Player Play Style is not yet implemented. In the future, it will contain icons representing a suit of cards representing play style, by Bartle's taxonomy (clubs for killers; spades for explorers; diamonds for achievers; hearts for socialites) and colored by the GNR theory (red for gamist; green for simulationist; blue for narrativist). For instance, a green spade would represent a cliche tech person.

In addition:
Double Clicking a character on this list will teleport the DM avatar to the character, if that character is far away. Double Clicking again, or when the character is nearby initially, will cause the DM avatar to autofollow the chosen character.

In addition, there are buttons associated with the new display. By selecting a player row and clicking the button, different acts can be accomplished:
Allow Rest overrides the resting restrictions placed on characters in game, allowing them to immediately take perform a typical rest.
Allow Study overrides the study and prayer restrictons placed on characters in game, allowing them to immediately prepare spells.
View Inventory opens the Inventory Report (below) for the selected player.
Boot Player functions as the one on the Player Report, excepting that the player receives a message indicating who did the booting, and the event is logged.

Inventory Report

Beginning with this version, an inventory report is available and can be accessed through the Player Report, above. It is designed to be more-focused on the concerns and items monitored inside of ALFA than the DMFI tool currently presented. With this release, the DMFI Inventory Tool is still supported in ALFA, as the Inventory Report does not replace all of its functionality.

When the report first opens, it displays all of the player's equipped items in a table format with four columns:
Item Icon is the icon used to represent the item in the player's inventory.
Item Name is the assigned name of the item, as it will appear through the typical inventory interface and the logs.
Item Value is the assigned gold-piece value of the item.
Item Level is the lowest level at which the item would be considered an appropriate drop.

Equipped Items appear at the top of the list, and are tinted gold.
Cursed Items appear with violet text, which is brighter when equipped.
Stolen Items appear with green text, which is brighter when equipped.
Plot Items appear with cyan text, which is brighter when equipped.

In addition:
Double Clicking an item will take that item from the character.
Clicking and Dragging an item from your inventory, provided that item was in your inventory when your avatar logged in or has moved since you acquired it, will give that item to the character.

The bar immediately above the table presents the character's current wealth, on the far left, followed by how far off they are from the nearest milestone presuming a push toward target wealth. For example, a character who has less than 50% of target wealth (which was 30,000 gold), by 1500 gold, the line would read:
"13,500 | 1500 below Low End (15,000)" -- presumably this would be more useful for characters whose wealth is in an "emergency" status (that is: how much must this change for us to no longer define the situation as extreme?) while still providing useful feedback about typical characters (that is: how far off the mark is this character and in what direction?)

There are also three buttons along the top of the UI which clarify the status of the selected item and allow one to toggle certain features:
(Un)Curse is represented by the Bestow Curse (if the item is not currently cursed) or Remove Curse (if it is) icon. Clicking will toggle the cursed status of the selected item.
(Un)Stolen is represented by the Pick Pockets icon (if the item is not stolen) or the Pick Pockets icon surrounded by the blue circle typically used to indicate removal (if the item is stolen). Clicking will toggle the stolen status of the selected item.
(Un)Plot is represented by the Neverwinter Nights icon, which changes color based on the plot status of the item. Clicking will toggle the plot status of the selected item.

Swimming

This release, ALFA adds automated support for swimming. Areas that are capable of handling swimming are added by builders, and no watery area follows swimming rules until the build team has had a chance to convert the areas.

Players should be aware that mobility while swimming is extremely restricted for PCs who wear armor, and for PCs who are encumbered-- and that both is certain death in water too deep to stand in. By default, Water Genasi are able to breathe under water indefinitely and move with their swim speed (30'/ rd) without checks. Other characters must succeed at a swim check to move at 50% speed. Characters can hold their breath for their constitution score * 12 seconds (for example, a character with 12 constitution gets 2 minutes and 24 seconds) before making constitution checks of escalating difficulty. Failure on a constitution check will cripple the character that round, place the character into negative hit points in the next round, and kill them on the final round. Magic healing, if provided, can slowly and awkwardly stave this effect off, but it does not provide breathable air, and the character will still be suffocating. Spells which stop a character's metabolism (Living Undeath, Stone Body, Iron Body) will halt suffocation, but it will begin again where it left off once the spell expires, and movement restrictions imposed (such as by Stone Body or Iron Body) stack with movement restrictions imposed by the water.

Water breathing, as the spell, is not yet implemented.

Builders may tool areas as this by placing a walkmesh 1.15 meters below the surface of the water and laying a water trigger down (if the expectation is that the character will be swimming on top of the water) with the specification that breathable air -is- available. If the expectation is that characters are swimming under water, such as under a flooded tunnel or to escape some hazard on the surface of the water, place the walkmesh more than 2 meters below the surface of the water and use a swimming trigger with the specification that there is -not- breathable air available.

Why We Have Releases

It seems appropriate to start any section on ALFA's core content with explaining why we need it. ALFA's mission statement is, quite simply, incompatible with everything that exists by default. We cannot provide an immersive and persistent world designed for role playing and the Dungeons and Dragons game system in the canonical presentation of Forgotten Realms with any game right out of the box.

Neverwinter Nights and Neverwinter Nights 2 get us pretty close, and happen to be customizable: in Neverwinter Nights 2, "ALFA2" as we often call our project in it, we use of modules and hak packs, and these define the majority of ALFA's ruleset. In addition, the different nature of building and maintaining a world in Neverwinter Nights 2 meant that effectively maintaining a project with multiple servers would require modifications to the engine, which we achieve mostly through NWNx4, which is a program that runs alongside the server software and modifies it while it's running, mostly to create functionality which did not exist in Neverwinter Nights 2 by default-- such as changing subraces of creatures-- and allowing communication between our servers.

Separating these into discrete versions has a number of benefits to ALFA technically, mostly in that it means we can assume that, in any given version of the ALFA ruleset, everyone will be using the same version of the ruleset, and that reduces the time we have to spend working on our upgrades: which is incredibly valuable in an all-volunteer team.

Why Releases Are On This Schedule

Releases represent a lot of work for our individual servers, and typically means that the person primarily responsible for maintaining each server has to spend a day getting the server up to date and correcting any issues that core content upgrades revealed, and then must add the work of a typical module-level update at the end. We, similarly, need to give people who work on our core content enough time to work on larger projects and reduce the problems presented by people rushing projects through short releases.

What Players Need To Do During a Release

The only thing that players need to be aware of is that releases are often large downloads, as this will be when you download nearly every graphical adjustment that ALFA makes, and these are typically very large files. When logging in after a release, try to connect to your server earlier than any scheduled events, to allow time to download.

What Servers Need To Do During a Release

The process of updating a server is a little bit more involved. Typically, these are the steps required of whoever is responsible for maintaining the module:
 

1. Download a copy of the new haks and place them in a folder other than the one your live server uses on your host.
2. Acquire the latest Advanced Script Compiler from nwvault.
3. Download a copy of the new alfa2_acr.hak onto whatever machine you use to compile your server's scripts, replacing your old alfa2_acr.hak, and then open the module.
4. Reference the list of scripts to be deleted from modules, posted by the release's coordinator, and remove them from your module.
5. Compile all scripts in the module.
6. Stage any changes you've made to your module recently, as you typically would for a module update.
7. Save the module and close the toolset.
8. Open servers.xml with a text editor and update the download path for your haks to the new one posted by the release's coordinator.
9. Open moduledownloadresources.xml with a text editor and update the resource elements to the values posted by the release's coordinator.
10. Download the updated module to your host.
11. Download the updated NWNx4 plugins to your host.
12.  Ask all players on to log off, and if any remain after a reasonable delay kick remaining players off.
13. Shut down the live module's NWNx4 and nwn2server.
14. Copy the downloaded haks and prepared module to the live server folders.
15. Configure any new plugins; copy any updated plugins.
16. Start the server again.
17. Log in with a test PC and verify:
    1. The autodownloader works
    2. Logging in works, and PCs are appropriately validated
    3. Performance is reasonable.
18. Inform the release coodinator that the module is updated or modify your module's info text file to list the new hak version.
    1. This is usually a good time to review the other things on your module's info page. If you've absorbed new areas into the module or the description has somehow meaningfully changed, that should be updated.

Ideally, servers should upgrade during the weekend of the release, though ALFA's release procedure offers limited support for staggered rollouts. If it is to be more than a few days' delay, it may become necessary to disable the server's portals until the upgrade is possible, as a way to reduce burden on the download mirrors.

What a Release's Coordinator Needs to do During a Release

The process of preparing a release must, for the most part, be done beforehand. Typically, these are the steps that must be performed the the person who has called the release:

1. Post, with at least two weeks' warning, when the release cut will be taken and when the release is expected to take place in the Technical Staff forum.
2. Bump the thread, with at least one week's warning, to verify that vital projects will be done on time.
3. If any projects are not in minimum releasable condition, and would affect existing content, create a release branch and roll back the unfinished projects on it.
4. Prepare release notes from the changelog in the repository
5. Take a diff from the alfa2_acr.hak of the previous and new releases. Post the list of added .nss files as potential conflicts with module resources (separate original .nss files from copied ones).
6. Compile the haks, and correct any compile errors.
7. Update the versioning text files, and push them and the compile fixes to the repository, tagged for the release.
8. Recompile the haks with the final contents.
9. Compile a live module against the new haks, and investigate errors.
10. Stage the haks, and upload them to the download servers.
11. Post the new download path for the haks and the resource elements from the staging for the modules' reference.
12. Update the mirror.
13. Provide accessibly-compressed versions of the haks via the DM FTP (under /NWN2/HAK/<version number>) for access by builders and hosts.
14. Include a text file which lists the modifications required to the server's XML files in the same directory as the haks provided on the DM FTP.
15.  Find the updated talk table (stored on the repository under /tlk/ ) and upload it to the DM FTP in the same place.
16. Check for new NWNx4 plugins and provide them for the hosts via the same method.
17. When modules update, ensure that the module info text files are updated

Typically, it is best for the coordinator and the tech team to remain available to support the servers as they upgrade to the haks.

This page exists only to document the results of GetEffectInteger when called on various effects, to be used by others for whatever development desired. It is not pretty; it's really meant for people who have some development experience.

EffectACIncrease()
Int 0 = The AC Type, reference the AC_*_BONUS constants.
Int 1 = The strength of the effect
Int 5 = The damage type resisted
Int 6 = Whether or not the effect is vs. spirits only

EffectACDecrease()
Int 0 = The AC Type, reference the AC_*_BONUS constants.
Int 1 = The strength of the effect
Int 5 = The damage type resisted