Unify the annoyances with different versions of nwnnsscomp. Mainly this addresses:
Error: Couldn't initialize the NwnStdLoader
r'Unable to open the include file "([^"\n]*)"'
When compiling a script in the nss editor, we will prompt a user whether to use the built-in compiler or nwnnsscomp if on Windows. If the user chooses nwnnsscomp and they are not running the tslpatcher, we will temporarily create/set the registry key:
If the registry key already contained a value, we set it back immediately after the script is compiled. This way the toolset won't ever break a user's setup. God knows enough kotor tools do enough registry manipulation incorrectly already (looking at you, Kotor tool...)
If an include script could not be found (we parse the nwnnsscomp message), we show a qfilebrowser dialog asking the user where to find the include file, then copy it over to the extractPath (where our temporary nss script is sitting) to compile it.
This should unify all nwnnsscomp versions and make handling of nwnnsscomp very easy for end users.
Unify the annoyances with different versions of nwnnsscomp. Mainly this addresses:
Error: Couldn't initialize the NwnStdLoaderWhen compiling a script in the nss editor, we will prompt a user whether to use the built-in compiler or nwnnsscomp if on Windows. If the user chooses nwnnsscomp and they are not running the tslpatcher, we will temporarily create/set the registry key:
If the registry key already contained a value, we set it back immediately after the script is compiled. This way the toolset won't ever break a user's setup. God knows enough kotor tools do enough registry manipulation incorrectly already (looking at you, Kotor tool...)
If an include script could not be found (we parse the nwnnsscomp message), we show a qfilebrowser dialog asking the user where to find the include file, then copy it over to the extractPath (where our temporary nss script is sitting) to compile it.
This should unify all nwnnsscomp versions and make handling of nwnnsscomp very easy for end users.