@RoiDesCreoles_NWn Did you try it? Considering what they have said about changing the OC, it's very much possible that they were touched so little that you could just add the prc into your old NWN OC .nmws, backup your EE .nmws and copy the PRC-installed .nmws into your EE folder.
@RoiDesCreoles_NWn Someone on the Steam forums tried that; they installed the PRC into their old NWN install and then manually copied across all their mods/haks to their EE install. It crashes the EE. Unfortunately, as I mentioned earlier, the EE also crashes when you use a PRC that has been built against it.
Even if it didn't crash, you probably wouldn't want to do what that guy did anyway. The PRC scripts include a few very core nss scripts from the game. As far as I'm aware, the include macro in nwscript literally copies and pastes into the script just before it's compiled. That means the scripts the game uses will be using one version of these files and the PRC will be using an older one. This is probably bad.
Regardless, until this issue gets fixed, you won't be able to use the PRC in EE. Trust me, that's going to be the thing blocking you from using it; I'll have the tooling all upgraded and ready to go long before that gets out of beta. You'll just have to be patient, I'm afraid.
is there a version that is compatible if i use my old nwn install to patch the files. or opened them in Aurora and added the PRC related haks and tlk into the modules by hand? or would that not work?
I have heard people have gotten the PRC to work with EE, Not sure exactly how but I do believe it is posted by someone on this forum. If I come across an answer I will post it here.
I know Plok has been busy working on updating the different outside tools for the PRC so I am sure in time he will release the fixed versions.
... I want everyone reading this who does/wants to do programming to promise me that they'll never ever, ever use Singletons.
This NWNInfo class needs to be taken out back and shot in order for, the EE updates to work. This code just magically grabs the NWN installation so behaves like it's own almost invisible program. Now the user has to select the directory, this is a problem.
public class NWNInfo
{
private NWNInfo()
{
//Read the NWNDir from the registry, do lots of stuff
//then store it in singleton.installPath
}
public static string InstallPath
{
get
{
return singleton.installPath;
}
}
}
NWNInfo.InstallPath turns up everywhere in the program. Everytime it turns up, I need to remove it and add NWNDirectory dir as an extra argument to the function that contains it (and any functions that call those functions).
//internal means this class doesnt exist outside the file it's in
internal class Key
{
public Key(string name)
{
....
string fileName = Path.Combine(NWN.NWNInfo.InstallPath, name);
...
}
}
However, sometimes this is easier said than done, the above function is called by the new Key() bit below
public class KeyCollection
{
//private here means that only the code inside the { above and the } at the bottom
//can call this. This is the bit of code that HAS to be called when making a new
//KeyCollection object. This being private is called the Singleton pattern. This class
//is the only thing that can make instances of itself.
private KeyCollection()
{
//Lots of stuff
foreach (string file in files)
{
Key key = new Key(file);
keys.Add(key);
}
}
//This gets called whenever Singleton.something is written down
//it cannot take an argument
private static KeyCollection Singleton
{
get
{
//It is impossible to pass any arguments here
if (null == singleton) singleton = new KeyCollection();
return singleton;
}
}
//This is the only thing in the whole file that the rest of the program
//can see. The bit above prevents me from adding directory to the
//arguments for this
public static Stream GetFile(string file)
{
foreach(Key key in Singleton.keys){
//stuff
}
}
}
This is going to take a while longer, sorry everyone. It seems the idea of only ever having 1 nwn install directory that's easily obtainable via registry is a very, very core assumption this program makes.
[ee_hakinstall_upgrade 366dd250] More work on the Hak Installer - in progress
19 files changed, 549 insertions(+), 583 deletions(-)
delete mode 100644 tools/HakInstaller/NWNInfo.cs
There's two things I like about this commit; firstly there's fewer lines of code than I started with and secondly the NWNInfo.cs file no longer exists. Unfortunately, there's also two things I don't like about this commit: firstly 19 files were changed and secondly if you asked me to explain what I did in detail I'd just look at my shoes. Real quality work this - I'm sure it will be 100% free of bugs.
I'm at the last hurdle now - the program works correctly up to the point of actually patching the modules. It ain't working because the program creates a bunch of temporary directories to decompile the modules its patching into and some bits of the program are getting one path and some bits are getting another. I've totally inflicted this on myself; I decided to change the temp path from the modules directory inside your NWN installation to the temp directory inside your user directory (it's inside the hidden AppData folder on Win 7). The problem is that the program builds the path for the temporary directory in several places and I haven't found them all yet. Some of them are also helpfully called filename.
It seems that I'm going to be getting very familiar with Visual Studio 2017's debugger.
Annnd now we're getting somewhere. I've now got it working start to finish with the EE install without having to hard code any paths. Turns out it was the .mod file backup code that was screwing me over. I didn't even know this was a thing until about half an hour ago.
While the program is working with the EE, I'm not providing a binary at present because I've still got testing to do and I don't want to be hoisting untested crap at the vault. Also it's not like there's much point because the EE just crashes when loading the PRC. If you want to play with it, it's in the ee_hakinstall_upgrade branch on the bitbucket repository I linked earlier in the thread.
Here's the stuff left to do:
I still need to test the command line app.
I still need to test it with .nwn files (the main campaigns)
I still need to test it with the .mod files that live inside the EE installation folder
I still need to test that it doesn't break in standard NWN (I'll have to dig my CDs out because I uninstalled it like a chump when I got the EE)
I need to fix the steam installation directory search because Windows does black magic when a 32-bit program tries to read registry values set by 64-bit programs (which Steam is).
I'm planning on making it make an ini file to store the last used directory. I really should have done this earlier as it would have made testing a lot less repetitive.
There's also a thing I need to fix in how the source code is put together with all these programs. At present, all the binaries used to make the PRC are in the source code repository. I'm not sure how SVN handles it but git HATES that. However I really do like the fact you can just clone the repository, type two directories into a config file and you're good to go. So I'm going to look into git-lfs and git-annex, which is how you're supposed to do this.
P.S: Anyone who uses the pattern...
try{
//huge stack of code that calls into functions across several files
}
catch (Exception e) {
MessageBox.Show(e.toString());
} ... can you please wrap the catch-all Exception in a !DEBUG macro so the call stack doesn't get eaten when people like me try to debug your code? Kthx.
The program now stores previously used directories in an xml config file that sits in the same directory as the program (.net seems to hate ini files so I fell back on xml). I prioritised this to make testing things less tedious - manually selecting the EE install directory every time when you're debugging gets old quick.
Got the command line interface working. This took a depressingly long time due to me forgetting something really stupid - I forgot to give the installation directory to the bit of the program that actually patches things when run from the CLI (this is why you shouldn't make code by copying, pasting then modifying).
Rewrote how the program parses command line options - turns out it was horribly broken and the only reason it ever worked is because it would fall back on scanning registry entries. Since that's no longer an option I had to rewrite it all. I'm actually prouder of the parser than I have any right to be. It worked perfectly first time. That never, ever happens when you write parsers.
Things left to do:
Port my command line argument parser to the GUI version (yes, it takes command line arguments)
Test patching haks with the classic NWN
Test patching nwm campaigns in classic and EE
Test patching modules in the EE install directory
Fixing the auto-detection of steam EE installs (this may require upgrading to .net 4.0)
I've also had an exploratory poke at the Character Creator. I was hoping it would just be a case of fixing up a few sanity checks and changing a few directories but there's a bit more to it than that. There's some stuff to do with the .key files that's looking a bit scary to deal with. Beamdog got rid of all the key files from NWN and replaced them with nwn_base.key and nwn_base_loc.key.
I'm hoping I don't come across as being mean by saying this, but the code has a serious copy and paste problem. It's not just blocks of code being copied and pasted; scores of files are copied, pasted and have like 2 lines changed. It does not fill me with confidence.
Oh, by the way, I've never had to set up a Java development environment before. Extra fun.
I rarely see someone post so much detail on a project they're undertaking. Very interesting to see how the actual debug/update process unfolds. I hope the .key issues don't prove to daunting. Well, at any rate: thank you for taking up this mantle and all the effort that entails.
@syptis Depends what you mean by close. If you mean "am I going to be able to install the PRC on EE?" then yes; in fact you can do it now if you compile the code yourself (Visual Studio community edition is free). If you mean "am I going to be able play the PRC on EE?" then no. Beamdog need to fix this bug before you can do that.
I've had a few ideas about how to narrow down what's actually causing the crash and hopefully work around it/provide more info to Beamdog to get it fixed. I'm going to finish what I'm working on before I try these.
@scotfo@Mordosskul Yeah, it's just sort of become a thing. I started doing it as "I said I was nearly done, but my list of things to do just got bigger - I should probably explain that to people". It just seems like basic expectation management to me; if you say "any day now!" and then 2 weeks later nothing has happened people get annoyed.
If people are enjoying reading my updates I can keep them up through fixing up the character creator. Writing about them is a "here's what I did today" thing and are a useful bit of rubber ducking.
So, I've just tested the hak patcher with the standard NWN and it's working fine. There was one bug where the detected standard edition NWN installation was flagged as being an EE install. Why was that?
Yeah... stubbing that function and not putting a todo comment was a dumb thing to do.
Anyway, what's interesting about this is I can actually test this inside NWN. It's all working as expected, which is great. But... what if I try loading the hak files that are generated for the EE? It might be buggy but if that crashes the standard edition then that means there's a problem in the code I've got in front of me (which means I can fix it).
Sadly, loading the EE haks in the standard edition worked perfectly. That means the problem is definitely in the EE. Guess we gotta wait for Beamdog to fix it.
Interesting. It seems EE only crashes if you start playing after creating a character with the PRC installed. If you select an already created character or load a save then it works. I just discovered this while trying out a PRC-installed OC in the EE.
Note the post-processing effect:
I'll go update the ticket.
--EDIT--
AHAH! It's the Packages selection. That's where the bug is. You can cancel out of character creation until you open the package selection section and then canceling crashes the game.
OK, tested all other cases; it's now working in standard and EE for patching user modules, campaign modules (.nwm) and the small modules that sit inside the EE install directory.
I've had to do a horrendous hack to get that last one working; the program stores the modules its supposed to patch as a string of the filename and updating the whole program to change it to be something that can store metadata looks really daunting.
I've hacked around it for now by storing a list of the files inside $ee_installation/data/mod/ and, upon seeing one of them in the list of things to be patched, updating it to use the correct path. If you have two files with the same name inside your Documents/Neverwinter Nights/modules/ and $ee_installation/data/mod folders, you won't be able to select your documents version. I'll probably have to fix this properly when Premium Modules become editable, but for now I'm making do with a hack.
Right anyway, I think I'm now at the point where I can inflict this on the rest of you. Steam installation scanning still isn't working yet (because windows black magic) but the patcher is in a state where it can patch modules in both the EE and standard edition.
I'm not going to put these on the vault until they're done, but it would still be nice to have some people try these out. Have these to play with:
All files are compressed with 7zip. All modern archive managers (e.g. not the one inside windows explorer) can work with these.
The PRC files go inside your Documents/Neverwinter Nights/ folder The Hakpatcher goes wherever you feel like.
I suck at testing and I don't understand half of the patcher so you might want to back up stuff before playing with it.
--EDIT--
Forgot to mention, the patcher has all the debugging stuff in it, so it'll scream at you if it breaks. I am very interested in what it's screaming about. If you are concerned about privacy (because your windows user directory contains your name), please PM them to me or redact them yourself.
Sorry for the noobish question but where is the error file so I can post it? Downloaded the PRC and put it where you said and then tried to run the hakpatcher but it first ran for a second and then stopped working. Now immediately stops working as soon as I open it. I checked and I already have NET 3.5 installed.
I decided to start with a clean install of NWN EE, so no other HAK's or Overrides. Copied the files from the EE PRC into the appropriate folders in the Documents/Neverwinter Nights/ folder and unzipped the hakpatcher onto my desktop. I started the hakpatcher, selected the install directory (the steamapps/common/Neverwinter Nights one) and proceeded to the screen where it list the two options of "PRC Pack" and "prc_ocfix".
I selected the "PRC Pack" and selected the "Neverwinter Original Campaign". Clicked "Install" and it proceeded to "Setting module properties for Prelude.nwm" with a progrees bar. It almost immediately fails displaying a new message box stating: "HakIntraller has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
No other info is displayed about what type of error and no error code given. I would then re-open the patcher and attempted to update all the other modules (one at a time) and received the same results each time.
I then attempted the same process for "prc_ocfix" and it updated each module without issue. I have to admit I'm not sure what "prc_ocfix" is in relation to the "PRC Pack" option but it seemed to do whatever it was supposed to do.
I re-attempted the "PRC Pack" option in case I was supposed to run the "prc_ocfix" first, but ran into the same issue.
I test-ran NWN to see if there were any changes after this process. Everything appears stable and my saved games started without issue, but there was no changes to the game itself which is what I expected, but thought I would just note this in case "prc_ocfix" was actually supposed to make any changes.
@scotfo: Think I've fixed this. New patcher here. TLDR version; wasn't passing the install directory into the script compiler properly. Dunno how the heck it worked for me.
Also, depending on where it's installed, you might have to run the program as an administrator in order to patch things in the install directory (like campaigns). I'll add a check for it this evening.
@Kyrin_Fireheart: There's no error log file. What do you think this is? Competently developed software!?
Details please. Do you get a popup window with some text, a .net exception window or "This program has stopped responding"? If it's either of the first two, what does it say (you might need to click details if it's a .net error window).
Also, try deleting your config.xml file. That's the only bit of persistent state between uses. It might let you get back to the original error.
@fasthd97 yup. Noticed that before I wrote a single line of code. It only turned out to really be a problem for patching the modules inside the $ee_install/data/mod directory.
The code accounts for all this. I gone dun some of that thar polymorphism.
I was pretty sure you did, I was more curious if they were ignoring the old hak files or just giving the new ones higher precedence. My apologies if it came across as offensive.
No offence taken. My comment was intended to be taken as being silly - sorry if it came across as shirty. Turns out dumb voices don't translate in the media of online text comments.
Can you elaborate on what you mean by old hak files? There really shouldn't be anything that requires precedence. There's PRC hak files in your documents folder, the patcher finds them, attaches them to a mod/nwm. It doesn't really care about other haks at all.
The only thing it really explicitly checks for is whether a nss file in the PRC exists in the module and if any module events are registered. If there's an nss file already in existence, it asks you if it can overwrite them. If a module event is registered, it silently generates a new nss file that calls the PRC's events and the events already attached to the module and then attaches that to the module events (this is the sole reason a script compiler is needed).
If you've got the PRC files inside the correct subdirectories of Documents/Neverwinter Nights/ and the modules have been patched to attach the hak files then it should just work.
I had a lot of files all over the place(Steam,C:Pre ee edition,beamdog install ). I deleted everything so I could start with a fresh install. The new prc patched files and everything worked fine but upon game startup only the usual classes(Non PRC) were available. My understanding of the prc was due to the way nwn loads that its best make a level 1 and then after module loads add fun classes. Using debug mode it still only shows vanilla nwn. My best guess is the haks are not being seen or loaded because maybe the new modules that got updated are not the ones being loaded so I deleted everything and only reinstalled steam version in case my old files were overriding the new patched versions. I thought this would solve all issues but I manually deleted Documents/Neverwinter Nights/* .
The updater after a fresh install(steam) sees the files in modules and updates the prc ocfix just fine. However when I load it isnt using the prc files which are located in Documents/User/Neverwinter Nights in the /hak and /erf files.There is a copy of the tlk file in tlk and in the Neverwinter Nights directory. Main reason I was asking about hk files was I thought perhaps if I moved the hak files there it would solve the issue.I have several steam workshop items,I dont think those are interfering but I dont know what else could be the issue.
I've made some progress in getting it to work with your stuff, Plok.
After patching with your files I couldn't create a new character in the original campaign as the game would crash as soon as it loaded into the character creation screen. I tried loading an existing game from before patching and used console commands to add experience, checked the level screen but saw none of the PRC classes.
I doublechecked the prelude in the game editor and did see the haks associated with it so I knew the patching had to have worked.
I reinstalled my old copy of NWN off GOG and installed the PRC on that which let me use the PRC Character Creator without running into the Chitin.key issue. Copied the character file over to the localvault for NWN EE, tried to start a new game with a premade character and it crashed just like when creating a character.
So I went back to the original game, used my premade character and started a new game. Saved as soon as it loaded the prelude. Copied the save game to the NWN EE save directory. It recognized it and was able to load the game.
I now have a level 1 Ogre Brawler in NWN EE. I haven't played yet to see if I run into any issues but I did use console commands to add experience and check the level screen. All of the PRC classes are there for selection.
I finished the prelude and the game crashed when transitioning to Chapter 1.
I tried to reverse what I did before - copy the save game back to NWN original to transition, but it wouldn't let me load it due to game version differences.
I was able to proceed by saving the character, not the game, and then importing the character back into NWN original starting a new game at the beginning of chapter 1. Then I copied the saved game back to NWN EE and it loaded fine.
@Yeargh I can't really do anything much about EE crashing, I'm afraid.
Something I could do - were circumstances different - is search through the history of the PRC and compile it over and over again and see if it crashes. Eventually I'll be able to narrow down which changes make the game crash and work around them. Using a binary search algorithm to pick the commits to try, I should be able to find where a crash started in less than a dozen compiles (log n operations for computer science nerds).
However, I can't do that because the PRC source code has an incomplete history. It seems it's been moved from CVS, to SVN, to Git. When I moved it from SVN to Git, I made sure to preserve the history, unfortunately the guy who moved it from CVS to SVN didn't. There's a lot of missing history, so there's not much point trying this.
@fasthd97 Maybeeee I should add some logging. The original program didn't seem to do any so I didn't really bother with it.
One diagnostic thing you could try is opening the .nwm files inside the toolset (you'll need to make a copy and change the file extension to .mod). If the PRC is installed you'll see an area called "Mordenkainen's Magnificent Mansion" (IIRC there's several copies so multiple people can have their own MMM at the same time). If that's there, the PRC has installed into the module correctly and the problem is something else.
--EDIT--
I should point out, that there is another thing I could try to narrow down the crashes, but I am not going to do it due to how tedious it is. I could swap out the .hak files with empty versions until I find out which hak causes a crash. Depending on which hak it is, I then have to pick an appropriate strategy to narrow down what's causing it.
For scripts, it'll involve removing as many scripts as possible until it stops crashing and adding them back in. If the problem is in the include scripts, it'll involve manually going into them all and replacing functions with versions that do nothing.
For 2das, it'll involve first removing 2da files to find out which one causes crashes, then removing lines from the 2da files until I find the particular lines that cause crashes. Again, binary searching to reduce the number of tries needed.
I really, really don't want to do all that. Especially not while the EE seems to be having stability problems which introduce false positives into the mix. Nope, nope nope nope nope nope nope.
There is one thing that I'm pretty confident is causing the character creation to crash; none of the new classes have Packages defined. By the sounds of what you're saying @Yeargh there's other things causing the EE to crash on top of this.
Character creation, selecting a premade character, and chapter transitioning all work. You just have to be patient. If you even so much as click your mouse during the loading with the PRC installed it will crash the game. But if you exercise patience and wait for the game to do it's thing, it all works. You'll know it's ok to proceed with character creation/selection when the swirly background starts moving again. Transitions will eventually load.
Of course, you can't select a custom race in the in-game character creator. All of the PRC classes show up for me, though. You can select a pre-made character made using the PRC character creation tool but as it stands right now we'll need a working version of that program for people without access to the original NWN1.
My understanding is that even in the GOG Diamond version, you had to use an external character creator if you wished to to start off with any of the PRC only races, classes, and/or feats, then save the character and then start and select the newly created character in what ever module you are playing.
Comments
Did you try it? Considering what they have said about changing the OC, it's very much possible that they were touched so little that you could just add the prc into your old NWN OC .nmws, backup your EE .nmws and copy the PRC-installed .nmws into your EE folder.
Even if it didn't crash, you probably wouldn't want to do what that guy did anyway. The PRC scripts include a few very core nss scripts from the game. As far as I'm aware, the include macro in nwscript literally copies and pastes into the script just before it's compiled. That means the scripts the game uses will be using one version of these files and the PRC will be using an older one. This is probably bad.
Regardless, until this issue gets fixed, you won't be able to use the PRC in EE. Trust me, that's going to be the thing blocking you from using it; I'll have the tooling all upgraded and ready to go long before that gets out of beta. You'll just have to be patient, I'm afraid.
I know Plok has been busy working on updating the different outside tools for the PRC so I am sure in time he will release the fixed versions.
This NWNInfo class needs to be taken out back and shot in order for, the EE updates to work. This code just magically grabs the NWN installation so behaves like it's own almost invisible program. Now the user has to select the directory, this is a problem.
public class NWNInfo { private NWNInfo() { //Read the NWNDir from the registry, do lots of stuff //then store it in singleton.installPath } public static string InstallPath { get { return singleton.installPath; } } }NWNInfo.InstallPath turns up everywhere in the program. Everytime it turns up, I need to remove it and add NWNDirectory dir as an extra argument to the function that contains it (and any functions that call those functions).
//internal means this class doesnt exist outside the file it's in internal class Key { public Key(string name) { .... string fileName = Path.Combine(NWN.NWNInfo.InstallPath, name); ... } }However, sometimes this is easier said than done, the above function is called by the new Key() bit below
public class KeyCollection { //private here means that only the code inside the { above and the } at the bottom //can call this. This is the bit of code that HAS to be called when making a new //KeyCollection object. This being private is called the Singleton pattern. This class //is the only thing that can make instances of itself. private KeyCollection() { //Lots of stuff foreach (string file in files) { Key key = new Key(file); keys.Add(key); } } //This gets called whenever Singleton.something is written down //it cannot take an argument private static KeyCollection Singleton { get { //It is impossible to pass any arguments here if (null == singleton) singleton = new KeyCollection(); return singleton; } } //This is the only thing in the whole file that the rest of the program //can see. The bit above prevents me from adding directory to the //arguments for this public static Stream GetFile(string file) { foreach(Key key in Singleton.keys){ //stuff } } }This is going to take a while longer, sorry everyone. It seems the idea of only ever having 1 nwn install directory that's easily obtainable via registry is a very, very core assumption this program makes.
I'm at the last hurdle now - the program works correctly up to the point of actually patching the modules. It ain't working because the program creates a bunch of temporary directories to decompile the modules its patching into and some bits of the program are getting one path and some bits are getting another. I've totally inflicted this on myself; I decided to change the temp path from the modules directory inside your NWN installation to the temp directory inside your user directory (it's inside the hidden AppData folder on Win 7). The problem is that the program builds the path for the temporary directory in several places and I haven't found them all yet. Some of them are also helpfully called filename.
It seems that I'm going to be getting very familiar with Visual Studio 2017's debugger.
While the program is working with the EE, I'm not providing a binary at present because I've still got testing to do and I don't want to be hoisting untested crap at the vault. Also it's not like there's much point because the EE just crashes when loading the PRC.
Here's the stuff left to do:
- I still need to test the command line app.
- I still need to test it with .nwn files (the main campaigns)
- I still need to test it with the .mod files that live inside the EE installation folder
- I still need to test that it doesn't break in standard NWN (I'll have to dig my CDs out because I uninstalled it like a chump when I got the EE)
- I need to fix the steam installation directory search because Windows does black magic when a 32-bit program tries to read registry values set by 64-bit programs (which Steam is).
- I'm planning on making it make an ini file to store the last used directory. I really should have done this earlier as it would have made testing a lot less repetitive.
There's also a thing I need to fix in how the source code is put together with all these programs. At present, all the binaries used to make the PRC are in the source code repository. I'm not sure how SVN handles it but git HATES that. However I really do like the fact you can just clone the repository, type two directories into a config file and you're good to go. So I'm going to look into git-lfs and git-annex, which is how you're supposed to do this.P.S: Anyone who uses the pattern...
try{ //huge stack of code that calls into functions across several files } catch (Exception e) { MessageBox.Show(e.toString()); }... can you please wrap the catch-all Exception in a !DEBUG macro so the call stack doesn't get eaten when people like me try to debug your code? Kthx.
- The program now stores previously used directories in an xml config file that sits in the same directory as the program (.net seems to hate ini files so I fell back on xml). I prioritised this to make testing things less tedious - manually selecting the EE install directory every time when you're debugging gets old quick.
- Got the command line interface working. This took a depressingly long time due to me forgetting something really stupid - I forgot to give the installation directory to the bit of the program that actually patches things when run from the CLI (this is why you shouldn't make code by copying, pasting then modifying).
- Rewrote how the program parses command line options - turns out it was horribly broken and the only reason it ever worked is because it would fall back on scanning registry entries. Since that's no longer an option I had to rewrite it all. I'm actually prouder of the parser than I have any right to be. It worked perfectly first time. That never, ever happens when you write parsers.
Things left to do:I've also had an exploratory poke at the Character Creator. I was hoping it would just be a case of fixing up a few sanity checks and changing a few directories but there's a bit more to it than that. There's some stuff to do with the .key files that's looking a bit scary to deal with. Beamdog got rid of all the key files from NWN and replaced them with nwn_base.key and nwn_base_loc.key.
I'm hoping I don't come across as being mean by saying this, but the code has a serious copy and paste problem. It's not just blocks of code being copied and pasted; scores of files are copied, pasted and have like 2 lines changed. It does not fill me with confidence.
Oh, by the way, I've never had to set up a Java development environment before. Extra fun.
I've had a few ideas about how to narrow down what's actually causing the crash and hopefully work around it/provide more info to Beamdog to get it fixed. I'm going to finish what I'm working on before I try these.
@scotfo @Mordosskul Yeah, it's just sort of become a thing. I started doing it as "I said I was nearly done, but my list of things to do just got bigger - I should probably explain that to people". It just seems like basic expectation management to me; if you say "any day now!" and then 2 weeks later nothing has happened people get annoyed.
If people are enjoying reading my updates I can keep them up through fixing up the character creator. Writing about them is a "here's what I did today" thing and are a useful bit of rubber ducking.
private static bool isEnhancedInstallPath(string path) { return true; }Yeah... stubbing that function and not putting a todo comment was a dumb thing to do.Anyway, what's interesting about this is I can actually test this inside NWN. It's all working as expected, which is great. But... what if I try loading the hak files that are generated for the EE? It might be buggy but if that crashes the standard edition then that means there's a problem in the code I've got in front of me (which means I can fix it).
Sadly, loading the EE haks in the standard edition worked perfectly. That means the problem is definitely in the EE. Guess we gotta wait for Beamdog to fix it.
Note the post-processing effect:
I'll go update the ticket.
--EDIT--
AHAH! It's the Packages selection. That's where the bug is. You can cancel out of character creation until you open the package selection section and then canceling crashes the game.
I've had to do a horrendous hack to get that last one working; the program stores the modules its supposed to patch as a string of the filename and updating the whole program to change it to be something that can store metadata looks really daunting.
I've hacked around it for now by storing a list of the files inside $ee_installation/data/mod/ and, upon seeing one of them in the list of things to be patched, updating it to use the correct path. If you have two files with the same name inside your Documents/Neverwinter Nights/modules/ and $ee_installation/data/mod folders, you won't be able to select your documents version. I'll probably have to fix this properly when Premium Modules become editable, but for now I'm making do with a hack.
Right anyway, I think I'm now at the point where I can inflict this on the rest of you. Steam installation scanning still isn't working yet (because windows black magic) but the patcher is in a state where it can patch modules in both the EE and standard edition.
I'm not going to put these on the vault until they're done, but it would still be nice to have some people try these out. Have these to play with:
Patcher (GUI version): http://www.mediafire.com/file/tsz4l1ty4acbzlt/hakpatcher%20EE.7z
EE PRC: http://www.mediafire.com/file/hatqataj684laac/PRC%20EE.7z
.net 3.5 (required library for the patcher): https://www.microsoft.com/en-us/download/details.aspx?id=21
Source code for my work is available at: https://bitbucket.org/SpitefulBerk/nwn_ee_prc (under the branch ee_hakinstall_upgrade).
All files are compressed with 7zip. All modern archive managers (e.g. not the one inside windows explorer) can work with these.
The PRC files go inside your Documents/Neverwinter Nights/ folder
The Hakpatcher goes wherever you feel like.
I suck at testing and I don't understand half of the patcher so you might want to back up stuff before playing with it.
--EDIT--
Forgot to mention, the patcher has all the debugging stuff in it, so it'll scream at you if it breaks. I am very interested in what it's screaming about. If you are concerned about privacy (because your windows user directory contains your name), please PM them to me or redact them yourself.
I decided to start with a clean install of NWN EE, so no other HAK's or Overrides. Copied the files from the EE PRC into the appropriate folders in the Documents/Neverwinter Nights/ folder and unzipped the hakpatcher onto my desktop. I started the hakpatcher, selected the install directory (the steamapps/common/Neverwinter Nights one) and proceeded to the screen where it list the two options of "PRC Pack" and "prc_ocfix".
I selected the "PRC Pack" and selected the "Neverwinter Original Campaign". Clicked "Install" and it proceeded to "Setting module properties for Prelude.nwm" with a progrees bar. It almost immediately fails displaying a new message box stating: "HakIntraller has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
No other info is displayed about what type of error and no error code given. I would then re-open the patcher and attempted to update all the other modules (one at a time) and received the same results each time.
I then attempted the same process for "prc_ocfix" and it updated each module without issue. I have to admit I'm not sure what "prc_ocfix" is in relation to the "PRC Pack" option but it seemed to do whatever it was supposed to do.
I re-attempted the "PRC Pack" option in case I was supposed to run the "prc_ocfix" first, but ran into the same issue.
I test-ran NWN to see if there were any changes after this process. Everything appears stable and my saved games started without issue, but there was no changes to the game itself which is what I expected, but thought I would just note this in case "prc_ocfix" was actually supposed to make any changes.
Hope this info can be of some use.
Also, depending on where it's installed, you might have to run the program as an administrator in order to patch things in the install directory (like campaigns). I'll add a check for it this evening.
@Kyrin_Fireheart: There's no error log file. What do you think this is? Competently developed software!?
Details please. Do you get a popup window with some text, a .net exception window or "This program has stopped responding"? If it's either of the first two, what does it say (you might need to click details if it's a .net error window).
Also, try deleting your config.xml file. That's the only bit of persistent state between uses. It might let you get back to the original error.
The code accounts for all this. I gone dun some of that thar polymorphism.
Can you elaborate on what you mean by old hak files? There really shouldn't be anything that requires precedence. There's PRC hak files in your documents folder, the patcher finds them, attaches them to a mod/nwm. It doesn't really care about other haks at all.
The only thing it really explicitly checks for is whether a nss file in the PRC exists in the module and if any module events are registered. If there's an nss file already in existence, it asks you if it can overwrite them. If a module event is registered, it silently generates a new nss file that calls the PRC's events and the events already attached to the module and then attaches that to the module events (this is the sole reason a script compiler is needed).
If you've got the PRC files inside the correct subdirectories of Documents/Neverwinter Nights/ and the modules have been patched to attach the hak files then it should just work.
in the /hak and /erf files.There is a copy of the tlk file in tlk and in the Neverwinter Nights directory.
Main reason I was asking about hk files was I thought perhaps if I moved the hak files there it would solve the issue.I have several steam workshop items,I dont think those are interfering but I dont know what else could be the issue.
After patching with your files I couldn't create a new character in the original campaign as the game would crash as soon as it loaded into the character creation screen. I tried loading an existing game from before patching and used console commands to add experience, checked the level screen but saw none of the PRC classes.
I doublechecked the prelude in the game editor and did see the haks associated with it so I knew the patching had to have worked.
I reinstalled my old copy of NWN off GOG and installed the PRC on that which let me use the PRC Character Creator without running into the Chitin.key issue. Copied the character file over to the localvault for NWN EE, tried to start a new game with a premade character and it crashed just like when creating a character.
So I went back to the original game, used my premade character and started a new game. Saved as soon as it loaded the prelude. Copied the save game to the NWN EE save directory. It recognized it and was able to load the game.
I now have a level 1 Ogre Brawler in NWN EE. I haven't played yet to see if I run into any issues but I did use console commands to add experience and check the level screen. All of the PRC classes are there for selection.
I finished the prelude and the game crashed when transitioning to Chapter 1.
I tried to reverse what I did before - copy the save game back to NWN original to transition, but it wouldn't let me load it due to game version differences.
I was able to proceed by saving the character, not the game, and then importing the character back into NWN original starting a new game at the beginning of chapter 1. Then I copied the saved game back to NWN EE and it loaded fine.
Something I could do - were circumstances different - is search through the history of the PRC and compile it over and over again and see if it crashes. Eventually I'll be able to narrow down which changes make the game crash and work around them. Using a binary search algorithm to pick the commits to try, I should be able to find where a crash started in less than a dozen compiles (log n operations for computer science nerds).
However, I can't do that because the PRC source code has an incomplete history. It seems it's been moved from CVS, to SVN, to Git. When I moved it from SVN to Git, I made sure to preserve the history, unfortunately the guy who moved it from CVS to SVN didn't. There's a lot of missing history, so there's not much point trying this.
Gotta wait for Beamdog it seems. If you could open some more tickets with Beamdog at https://support.baldursgate.com/projects/external-bugs/issues that would be a helpful thing to do. (EDIT: make sure to read https://forums.beamdog.com/discussion/49845/how-to-report-bugs/p1 before doing so)
@fasthd97 Maybeeee I should add some logging. The original program didn't seem to do any so I didn't really bother with it.
One diagnostic thing you could try is opening the .nwm files inside the toolset (you'll need to make a copy and change the file extension to .mod). If the PRC is installed you'll see an area called "Mordenkainen's Magnificent Mansion" (IIRC there's several copies so multiple people can have their own MMM at the same time). If that's there, the PRC has installed into the module correctly and the problem is something else.
--EDIT--
I should point out, that there is another thing I could try to narrow down the crashes, but I am not going to do it due to how tedious it is. I could swap out the .hak files with empty versions until I find out which hak causes a crash. Depending on which hak it is, I then have to pick an appropriate strategy to narrow down what's causing it.
For scripts, it'll involve removing as many scripts as possible until it stops crashing and adding them back in. If the problem is in the include scripts, it'll involve manually going into them all and replacing functions with versions that do nothing.
For 2das, it'll involve first removing 2da files to find out which one causes crashes, then removing lines from the 2da files until I find the particular lines that cause crashes. Again, binary searching to reduce the number of tries needed.
I really, really don't want to do all that. Especially not while the EE seems to be having stability problems which introduce false positives into the mix. Nope, nope nope nope nope nope nope.
There is one thing that I'm pretty confident is causing the character creation to crash; none of the new classes have Packages defined. By the sounds of what you're saying @Yeargh there's other things causing the EE to crash on top of this.
Character creation, selecting a premade character, and chapter transitioning all work. You just have to be patient. If you even so much as click your mouse during the loading with the PRC installed it will crash the game. But if you exercise patience and wait for the game to do it's thing, it all works. You'll know it's ok to proceed with character creation/selection when the swirly background starts moving again. Transitions will eventually load.
Of course, you can't select a custom race in the in-game character creator. All of the PRC classes show up for me, though. You can select a pre-made character made using the PRC character creation tool but as it stands right now we'll need a working version of that program for people without access to the original NWN1.