I don’t have time to write it all up. But I use the erf utility to unpack and then the ruby nwn-lib tools to convert all the files.
Take a look at GitHub - squattingmonk/nasher: A build tool for Neverwinter Nights projects
Squattingmonk has a framework using the nim tools to do this. My workflow pre-dates this so I don’t use this one but it should work.
All it tells me is that the module might be corrupt, unfortunately.
[edit] This is loading the module at all to be clear, not during play.
Looking at the module.ifo in a normal text area the list of areas does not seem to properly line up with the actual areas we have. Most of them line up but where I have area002 is my still not relabelled OOC area for the PW, it has it as area004 in the module.ifo
That is interesting to say the least since that’s the one area I didn’t relabel right now. Is there an editor for the .ifo file to correct that? Just editing it in plaintext seems to make things explode.
What I would try is the following:
Extract the new areas using nwhak (the 3 files of each area).
Open the last working module (the one one that loads ok in the game). Copy all the areas to the temp folder. Make a full build and save the module with a new name.
Test it.
Yeah if it was just new areas I was trying to relabel it would be a lot easier, unfortunately it is not. I will try seeing if I export them onto a new module with the same hakpaks if that works though.
Editing the .ifo probably should work but I don’t know what editor to use; it doesn’t like me doing it with just the text editor (game freezes loading the module if I do this but hey its a new problem at least?)
The safer and faster would be to start again from the last working instance.
I backup my work on a daily basis (sometimes twice). I do a lot of editing at work 
and test it at home, so I there are a lot of changes in my repo.
I back it up by exporting everything in seperate erfs, so a script erf, a creatures erf, etc in each version, so its not terrible to me to plonk them all into a blank module.
It’s a binary gff file so yes, editing it raw with a text editor will probably not have the desired results. I think there is a gff editor for windows which might do it directly. Or as I said before, convert it to json or yaml, edit that text file and then convert it back.
Area confusion is one of the common ways to get the module is corrupt issues. Non-existent areas (listed in module.ifo but no files in module archive) is one common cause I have seen in cases I’ve looked at for people.
Yeah, that seems to be what happened here. There’s specifically two areas that it has incorrect references for in the .ifo file for that are mispointed - one instance where the toolset appeared to rename the three files from area007 to zbh1_dawnguard but not update the .ifo, and another where it’s just straight up hallucinated the tag for the ooc area (there was never an area004 in the module to my knowledge, but it has area004 where my ooc area is area002)
[edit]: Yeah, it just straight up doesn’t like that module.ifo but will accept previous version’s, so what’s happened here is it’s derped the ifo, for sure.
The gffeditor ships with the game installation at util\win32.
So I was able to do this successfully, basically using a variation of @meaglyn 's method, just with different tools.
What I did is I exported the area to have the resref renamed into an erf:
Then I opened the erf and dumped the three area files and the ExportInfo using the Hak editor:
I renamed the files appropriately, and then changed the Top resref in the ExportInfo using the GffEditor that comes with EE:
Finally I deleted the four old versions of the files, and imported them into the hak editor:
That gave me a resource stub I could import into the module that had the relabelled area, import that one, delete the old one, bish bosh away you go.
This method seems stable across doing it for several areas now, so not the quick way, but it doesn’t seem to run into any weirdness, which is good seeing as I appear to have a propensity for running into weirdness.
[edit]: One little “gotcha”: the hakpak editor locks the erf while it’s in use, so you must exit the hakpak editor before you try to import or you will get a “file is in use” error.
