I cannot get the PRC to work with EE
omacron
Member Posts: 6
Hey there,
Both the installer EXE and the utility included in the .rar to patch to modules don't work with the freshly released NWN Enhanced Editions. Both utilities look for a Neverwinter Nights install, which NWN EE isn't, and so the utilities shut down before doing anything. Is there any way to force the utilities to recognize the EE or any hope of them being patched to better play along with the EE?
Thank you!
Both the installer EXE and the utility included in the .rar to patch to modules don't work with the freshly released NWN Enhanced Editions. Both utilities look for a Neverwinter Nights install, which NWN EE isn't, and so the utilities shut down before doing anything. Is there any way to force the utilities to recognize the EE or any hope of them being patched to better play along with the EE?
Thank you!
0
Comments
If anyone has any way of jury rigging it to work with the EE I'd love to hear it
firstly, i find it great, that the PRC ist being updated to the EE version! The missing PRC is the ONLY reason, which keeps me and a friend of mine from using the EE version! We simply love the PRC stuff, especially the news skills like jump, cllimb, craft poison etc. more than the ee-versions´s graphic update.
The possibility of the new poisons is absolutely great! And while the crafting of poisons works, I'd like to draw attention to a BUG, which occurs with self crafted poisons and ALWAYS applies the Nightshade poison to a weapon, even if I used a different poison on the weapon:
Example:
1) I craft "giant bee" poison via the PRC-craft item menu -->The Poison appears in the inventory.
2) I apply giant bee poison to a weapon --> there is no check roll and the message in the feedback window reads: "You have coated your weapon in NIGHTSHADE."
3) I attack an enemy--> the enemy saves vs Fortitude DC: 10, which ist NIGHTSHADE, though I applied "Giant Bee poison" on the weapon.
I guess, that theres an script or Index error concerning the poisons indices, when applying the poison.
I used the PRC 3.5 and called the "Module updater". I tried it in the original campain and XPs and always got the same result.
I was hoping, that this bug might get fixed in the EE update, for the poison use is one of the things, among the cool rogue skills like jump and climb (which offer totally new tactics as we found out!!), which makes
the rogue classes (assassins, etc) even more interesting!
With kind regards
Steve
EDIT:
btw: I use the 1.69 Diamond version with critical rebuild and PRC 3.5. With the community patch 1.72 I got the same "poison bug". Maybe one could reproduce this bug or give me a hint?
I have a couple of fixed spells, abilities, psionic powers (for example Crisis of Breath has been bugged for mind spell immune creatures that aren't vermin, undead or constructs where they automatically are inflicted 9999 damage without save) that I could submit for a new PRC release if you are interested.
I've got as far as getting scripts to compile by swapping out the nss compiler with this and fixing up the make templates to use it. I hate doing build scripts and tooling so I'm starting to run out of steam a little.
I'm working off of master from SVN http://svn.code.sf.net/p/daprc/code/nwn/nwnprc/trunk/
Code is available here: https://bitbucket.org/SpitefulBerk/nwn_ee_prc. Yes, it's git rather than SVN. No, I'm not sorry - I hate SVN with a passion. It's on bitbucket rather than github because apparently I'm locked out of my github account.
It spits out a heap of warnings because I've changed the compiler to the one in my last post and it picks up bugs in NWN's own .nss scripts (ticket open here).
There's also a few errors I've fixed in the PRC code to do with function prototypes and implementations having different default arguments. I've put the implementation versions into the prototypes to fix this - I'm now suspecting that this may be the wrong way around but I currently have no way to test this.
My config.make is the following:
NWN_DIR =C:/Users/User/Documents/Neverwinter Nights/ EE_INSTALL_DIR =C:/Games/00785 PRC_VERSION = 33g PRC_INSTALLVERSION = 3.3g NSSCOMPILER = tools\nwnscReplace the directories with appropriate paths.
--EDIT--
Replaced the support ticket with a redmine link. Turns out I don't know how to report bugs. Herp derp.
It's in the source if anyone is interested under tools/HakInstaller/
The good:
Each directory path the program uses (e.g. $install_dir/modules/, $install_dir/haks) is a seperate method so only this file needs to be updated to affect the whole program.
While the code makes assumptions about there only being one of each directory (bad), it isn't actually a problem. The modules would be a problem but thankfully it's is split into two methods - NWMPath (for campaigns/premium modules) and ModulesPath (for custom modules). You could just have one read from the game install and the other read from your Documents/Neverwinter Nights/ directory.
The bad:
It's a singleton - aka a set of global functions that can't be mocked, extended or composed. Making it work with both standard NWN and EE will either be if/else spaghetti or gutting the class into a useless wrapper for an actual Object Oriented Programming solution (like having a seperate class for standard NWN and EE).
As previously mentioned, it's a VS 2005 C#.net 2.0 project. Getting it to even compile will be fun (in the dwarf fortress sense of the word).
There's one key question I need answering before I can really crack on with it; how do you work out the NWN EE install directory? I can find no mention of it in either the Windows registry or the .ini files inside My Documents.
Also, whats the story with setting up the prc on non-windows systems? As far as I can tell the module patcher is very much windows only. Are people running it in wine or are they using an alternative module patcher or what? Theoretically the HakPatcher could be ported to Mono or .net core and be made to work on Linux/Mac by someone who knows what they're doing (not me).
It currently makes the .hak files that make up the PRC but doesn't let you attach them to NWN modules. That's because the program that attaches them still needs updating. I'm working on it, however I'm currently blocked because I don't know how to work out where the EE is installed.
- It's multithreaded
- It has multithreading bugs (the absolute worst kind of bugs)
- Most of them are in the error handling code
- I'm hitting the error handling code a lot
- Apparently no one else has ever reached the error handling code (it requires a command line switch to override the directories it pulls from the windows registry to ever get here)
- I'm not having fun
I wrote a long, seething rant about these and a few other things but decided against posting it. It's really not on to attack the people who made it - they've clearly put a lot of time and effort into this and older versions of Visual Studio should not have allowed these to be.Anyway, what I actually came to post about; the hak patcher uses a binary that's in the standard edition NWN but not the EE: clcompile.exe. I'm going to move it over to the same compiler I'm using for the rest of the PRC, but figured I should mention this is a thing because other projects probably depend on it.
class ThreadSafeProgressForm : IHakInstallProgress { private InstallProgressForm form; public ThreadSafeProgressForm(InstallProgressForm f) { form = f; } //forEach(method in IHakInstallProgress) public void SetMessage(string message, params object[] args) { if (form.InvokeRequired) { form.Invoke(new MethodInvoker(delegate { form.SetMessage(message, args); })); } else { form.SetMessage(message, args); } } //end forEach }To any programmer that may have to work with this in future; I'm so sorry.
My changes so far are up on the bitbucket account under the branch ee_hakinstall_upgrade. I'm currently working by hardcoding the paths I need into NWNInfo.cs (I've not committed this). It still doesn't work because the compiler needs swapping out.
Now to open another redmine bug...
--EDIT--
Bug report available here: https://support.baldursgate.com/issues/36509
I've still got to actually make the patcher work without hard coded paths which is actually looking like a decent chunk of work. There appears to be no way to programatically work out where the EE is installed so I'll have to code up a GUI to select the EE install path. I've also still yet to touch the command line version of the patcher, which I would imagine has a few bugs now.
Regardless of whether you're using the GUI or CLI you'll need this program to be in the same directory as the patcher.
All work so far is in ee_hakinstall_upgrade branch. You'll need to edit NWNInfo.cs to provide hard coded paths if you want to play with this. With that, I am goddamn done for the day.
Is that GUI understandable to people (ignore Visual Studio in the screenshot backgrounds)? I've still got to hook it up to the rest of the program, which is more complicated than it sounds.
It will auto-search for whatever directories it can find and populate itself, validate that any directories actually are NWN installation directory (just looks for appropriate nwm folders currently) and will auto-fill the NWN documents directory with $current_user/(My )Documents/Neverwinter Nights. If the selected installation is a standard NWN installation it won't ask for the documents folder.
Also, the program now requires .net 3.5 instead of 1.0 because I'm too lazy to write code to filter duplicates from a list. The only way to get .net 1.0, 2.0 and 3.5 is via the .net 3.5 installer from Microsoft so I doubt this will be a problem. Also, .net 3.5 is 11 years old and available for all versions of Windows from XP onwards.
I know it's written in Java (yet another programming toolchain to set up... urgh...), but does anyone know if the source code has a home anywhere? By virtue of it being a .jar file I can run it through winzip and get the source code but it would be nice to push my changes upstream.
If anyone feels like tackling it then by all means please do so. There's a copy of it in the PRC's source code in the tools directory. Just throw the .jar at winzip and poke around the .java files. How you get those .java files back into a working .jar is beyond my knowledge at present, but I'm sure google will provide.
Oh, and the license in docs/LICENSE.txt says its ok to update the program and distribute it's source code so long as you don't try and claim you made the program or remove the license.