AuroraExt is a collection of tools to overcome cerain limitations of the original Neverwinter Nights (NWN) Aurora Toolset and the NWN module development process.
http://sourceforge.net/projects/auroraext/
If you have any questions not covered here don't hestitate to contact me directly: prwo -AT- gmx -DOT- net
Probably the most handy tool is the dialog compiler (dlgc). A dialog can be written down as a simple text file (.dlgsrc) using your favourite text editor and then compiled it into a real dialog. This allows you to use automated spelling correction, text compare or version control (e.g. SVN) tools on your dialogs. Using the later multiple people may simultaneously work on dialogs and thus module in a collaborative way. It comes together with the watcher, a tool that monitors a certain folder for changes in .*src files and automatically compiles them into the temp0. So saving your changes to the .*src will result in the file to be recompiled to NWN.
Example:
: Start
. Hello!
>> ?no_name Who are you?
... !say_name I an an NPC.
>>>> Thank you. Now that we know each other, I want to ask you something... -> SubDialog
>> I want to ask you something... -> SubDialog
>> [Stand back.]
: SubDialog
. What do you want to ask me?
>> Something.
>> Nothing.
The dialog compiler also issues warnings and errors about certain situations that might cause problems later. E.g. if you specified a script that doesn't exist. These warnings and errors appear in the form "WARNING in line 1234:" or "ERROR in line 1234:", so you can easily find the line where something went wrong.
Just like dialog files can be written down in plain text so can GFF (Generic File Format) files too. Almost all NWN files are in GFF, most notably the Aurora templates (.ut?) for creatures (.utc) and items (.uti). Now you can edit them using your favourite text editor and compile them using the GFF Compiler (gffc). In contrast to dialog binaries, GFF files can easily be disassembled from binary to textual form. This allows you to convert existing templates into text files, modify them and later compile them back.
Example (shortened):
Appearance_Head = 13
BodyPart_Belt = 0
BodyPart_LBicep = 1
BodyPart_LFArm = 1
[...]
ItemList/[0]/InventoryRes = nw_wbwxl001
ItemList/[0]/Repos_PosX = 0
ItemList/[0]/Repos_Posy = 0
ItemList/[1]/InventoryRes = nw_it_torch001
ItemList/[1]/Repos_PosX = 2
ItemList/[1]/Repos_Posy = 0
[...]
ScriptAttacked = x2_def_attacked
ScriptDamaged = x2_def_ondamage
ScriptDeath = x2_def_ondeath
ScriptDialogue = x2_def_onconv
Another format that utilizes GFF is the journal file (.jrl). While it could fully be represented by gffsrc already, the jrlsrc text format simplifies the notation of journal files. It comes with an own Compiler and Disassembler specialized in journal sources (.jrlsrc).
Example:
: Category
Name = My Journal Category
Tag = The_Tag_of_this_Category
Priority = MEDIUM
XP = 1000
+ Entry
ID = 1
Text = This is the first entry within this category.
+ Entry
ID = 2
Text = This is the second entry marked as End.
End = 1
Another handy tool is the HAK assembler (hakasm). It allows you to assemble a new HAK file out of several existing ones. Collisions between objects can be avoided by transforming commands. E.g. if you want to use the hak files hak_a and hak_b in your module, but both have a pfh0_chest001 inside, which you want to use both, you can transform these into pfh0_chest100 and pfh0_chest101 with little effort automatically and without having to manually edit the corresponding 2da.
Example assembly file:
output: example.hak
title: My Title
url: http://my.url.org
description: My multi-line description\nSecond line\nThird line
load hak_a.hak
load hak_b.hak
trafo hak_a.pfh0_chest 1 100
trafo hak_b.pfh0_chest 1 101
strreplace pfh0_chest100.mdl "pfh0_chest001" "pfh0_chest100"
strreplace pfh0_chest101.mdl "pfh0_chest001" "pfh0_chest101"
cp nwn.ipf_chest001.plt ipf_chest100.plt
cp nwn.ipf_chest001.plt ipf_chest101.plt
cp hak_a.pfh0.*
add my_file.2da
Subprojects:
To be done...