Hi there,
For scripting reasons I’d like to have better resrefs for my areas than the “area001” and etc made by the area creation wizard. Is there a way to rename them? The toolset does not allow me to.
- May
You can change that as you create them I believe. But since this is after the fact you will need use other methods.
The NWN nim tools will unpack your module. The GFF files will be converted to json. You can then rename them and fix the resref in the list of areas in the module.ifo file (also converted to json).
There are three files, area001.git, area001.gic and area001.are which need to be renamed together.
Then there are two places that refer to the resref which need to be changed. One is in the area001.are file and the other is in the module.ifo file. Change those fields to the same name you gave to the area001.* files. Then convert them back and repack your module.
I use an older set of tools that convert to and from yaml format in ruby that Niv also wrote. But the theory is the same.
The nim tools should be here GitHub - niv/neverwinter.nim: CLI tools and nim library used in Neverwinter Nights: Enhanced Edition development
The ruby tools are nwn-lib and you can pull then in with gem.
1 Like
You can right click the área in the toolset and create a copy.
First thing you are asked is the ResRef. The deleite the original.
1 Like
Aha, that’s probably the quickest way, I assumed it would just autoset it like the creation wizard does, but I was wrong!
Thanks!
I wish I could put both of these as solutions because they both will work for this!
No worries. I do as much work as possible outside the toolset so this part is easy for me. Didn’t even think about copying it in toolset. If you aren’t already using any of these conversion tools then the copy solution is much simpler 
But they may be worth looking into for you someday. It also allows to you keep the whole module in version control in a meaningful way.
2 Likes
Yeah, I’m going to have to attack that at some point, because it would be great to have the module in git.
Okay, since renaming them in the editor it doesn’t want to load the module in the game so I suspect I’ll have to fall back onto doing so with the tools. Do you mind explaining how I can unpack the module? Not finding the documentation on the git repository page easy to follow.
Simple. Create a copy of the area (toolset) and a dialog to save it under a new name will appear. Then remove the original. I use this often. Never had an issue with that.
- Drag the module file and drop it over an icon of the hak editor
- Alternative: Open the module in the toolset. look for a directory “temp0” in the modules folder.
Method 2 could be used to rename an area (3 Files) in temp0 and save the mod afterwards with the Toolset. It seems to work, but this is NOT tested thouroughly.
This method definitely works. I just re-tested it.
I wonder whether this is the same module in which you’re experiencing corruption issues?
In which case, copying the area is not the root cause, just a random trigger.
As far as I can see, all the methods which depend on unpacking the files are flawed, because the game will crash unless the area resrefs match the list held in module.ifo.
You can rename the area files, edit the resref field in the .are file, and edit the area list in module.ifo, but for some reason I find that even that crashes the game.
Possibly it might work if you did all of those things to an unpacked version of the module (without using the toolset at all) but simply copying in the toolset is so much easier.
Right, copying in the toolset is the way to go.
With all due respect, “works for me” is a sentiment which doesn’t much help me fix the problem I am encountering.
Did the original worked fine?
Yes, the copy of the module before anything that was renamed works fine.
The copy of the module where things were renamed loads just fine in the Aurora editor, but does not load into the game.
You can try this.
New module, New área with same tileset than the one that fails. Same ResRef as the original. Save, export the área. (or better copy the 3 área files to another folder)
Exit
Back up the non working module (same name.Old), open the failing module in nwhak, inserte and overwrite those áreas you create. Save and test.
(remember to make the bkp up first)
1 Like
So wait
You have to have some kind of message why it doesnt load in the logs.
Are you using some kind of persistence system that looks for the last área the PC was in?
Yes, you would want to do it outside of the toolset. If you have a workflow that already unpacks the module then it’s trivial to make the changes. And yes, my instructions included fixing the .are and module.ifo files. So no, the unpacking method is not flawed.
The toolset remember doesn’t run natively on Linux either so I have to use wine for that (which works pretty well most of the time but is not perfect.)