Player Resource Consortium
Neverwinter Nights => Builders => Topic started by: DoiganDoRight on August 27, 2012, 11:08:13 PM
-
I am trying to upgrade a module that uses PRC 3.3g to the PRC 3.5 version. The module is the LOTR - Finding Smeagol PW at http://nwvault.ign.com/View.php?view=Modules.Detail&id=6096
What I tried was to upgrade my version of NWN to PRC 3.5, then open the module in the toolset and recompile the scripts using the PRC compiler. Everything worked fine and the module seems to work fine with PRC 3.5.
Except, a tester created a Scout in the PRC Character Creator and played it on the module up to level 12 (Scout-6 & Bowman-6). He then exited and came back the next day to continue. As soon as he selects that character, the server crashes. However, if we load up the level 1 character, we can use DM to level it back to 12 and it plays fine.
But if he exits and tries to load the re-levelled character again, it will crash the server again.
I converted a leveller module (Halls of Epic Training) to PRC 3.5 using PRCModuleUpdater and it can load the same character without crashing.
So I am starting to suspect that the PW module has not been properly upgraded to PRC 3.5.
Anybody have any thoughts?
-
Have you looked at the server logs?
-
Just a bit of background - I have very little experience running a server or working in the toolset. I thought upgrading this module would be relatively straightforward and solve a number of problems that we were having with PRC3.3g.
Server log says:
[Tue Aug 28 09:55:35] Loading Module: LOTR-FS-169-CEP169-PRC35-05
[Tue Aug 28 09:55:52] Removing old PRC version databases
[Tue Aug 28 09:55:53] Module 2da cache fingerprint: LOTR - Finding Smeagol_72_1629337002
[Tue Aug 28 09:55:53] Starting to load 2da cache object from prc_datac1
[Tue Aug 28 09:55:53] WARNING: Unable to load 2da cache object (CacheChest) from prc_datac1
Connection Attempt made by Algran Firog
[Tue Aug 28 09:56:33] Algran Firog Joined as Player 1
Then the server crashes. The server is running on Linux, and in the system log it says:
[ 3768.761270] show_signal_msg: 48 callbacks suppressed
[ 3768.761273] nwserver[3450]: segfault at 158 ip 00000000081ec961 sp 00000000ffad8510 error 4 in nwserver[8048000+2e7000]
Thanks.
-
In nwnplayer.ini, I set:
Enable Logging=1
and the server log now has a bunch more information. The last few lines are:
[1] Object: 7ffffffd, Running Script: prc_onhb_indiv
[2] Object: 7ffffffd, Running Script: race_hb
[2] Object: 7ffffffd, Running Script: prc_scout
- Object: 0, Running Script: hif_onacquireite
[1] Object: 0, Running Script: acquireditem_tag
- Object: 0, Running Script: hif_onacquireite
[1] Object: 0, Running Script: acquireditem_tag
Which seems to indicate to me that it is failing somewhere in the prc_scout script. I took a look at that script in the editor and noticed there are DEBUG statements.
How do I turn on PRC DEBUG to get more information dumped into the Log?
Thanks
-
Set PRC_DEBUG to 1 in your module variables.
Look in prc_inc_switch.nss for more info.
-
OK I loaded that character with PRC_DEBUG set to 1 - the log is attached.
One other data point is that I created a fighter in that module and played to level 2 where I selected Scout as the class. I then exited the module and loaded up that character without any problems. I exited again and re-started the server. I then tried to load that character again and it crashed the server.
So the server has to be restarted for it to crash when the Scout is reloaded.
I hope someone can figure this out.
-
OK I loaded that character with PRC_DEBUG set to 1 - the log is attached.
One other data point is that I created a fighter in that module and played to level 2 where I selected Scout as the class. I then exited the module and loaded up that character without any problems. I exited again and re-started the server. I then tried to load that character again and it crashed the server.
So the server has to be restarted for it to crash when the Scout is reloaded.
I hope someone can figure this out.
What DB are you using?
Also, do you mind trying an older version of nwnx_funct.dll? The one with the latest server pack has been causing odd issues. (My PW won't even start with the current dll).
-
Thanks,
I think it is just using the standard NWN DB - I don't have MySQL or anything like that running.
The server is running on Linux, so it is not using nwnx_funct.dll, and I did not install the PRC Server Pack.
And I don't have a Windows box handy that I could use to test it. I might be able to round one up eventually, but I don't see why that would make a difference - all the other class characters we have tried so far don't crash the server - only Scouts so far.
-
Thanks,
I think it is just using the standard NWN DB - I don't have MySQL or anything like that running.
The server is running on Linux, so it is not using nwnx_funct.dll, and I did not install the PRC Server Pack.
And I don't have a Windows box handy that I could use to test it. I might be able to round one up eventually, but I don't see why that would make a difference - all the other class characters we have tried so far don't crash the server - only Scouts so far.
I didn't know you could even run the PRC on a standalone server without using NWNx2.
-
I didn't know you could even run the PRC on a standalone server without using NWNx2.
My group has been running this module with PRC and no NWNx2 as a private server on and off for the past 6 years or so. Seems to work fine (except for this pesky Scout situation).
It might become a performance issue if you're running it for a large number of players, but for 4 - 6 players it works fine.
Have you had a chance to look at the log? Does it give any hints as to what may be going on?
Thanks
-
Have you had a chance to look at the log? Does it give any hints as to what may be going on?
Yes I did & no I didn't see anything that stood out to me. Is there an ODBC log?
-
Yes I did & no I didn't see anything that stood out to me. Is there an ODBC log?
There is no ODBC log - ODBC is not being used - it is just the default dbf files being used.
Can we go back to the beginning for a moment? Is the method that I used to upgrade the module from PRC 3.3g to PRC 3.5 the correct way to do it?
To recap, I have a module that was setup and working with CEP1 and PRC 3.3g with just the default Bioware database being used and no NWNx2 being used.
I then upgraded my installation to use PRC 3.5 files (including prcc1.hak). I opened the module in the toolset and Saved As a different name. I then ran the PRC compiler and all files rebuilt without any errors. I then saved the module and started running it as a standalone server.
Is that the correct method to upgrade from PRC 3.3g to PRC 3.5?
Thanks
-
There is no ODBC log - ODBC is not being used - it is just the default dbf files being used.
Can we go back to the beginning for a moment? Is the method that I used to upgrade the module from PRC 3.3g to PRC 3.5 the correct way to do it?
To recap, I have a module that was setup and working with CEP1 and PRC 3.3g with just the default Bioware database being used and no NWNx2 being used.
I then upgraded my installation to use PRC 3.5 files (including prcc1.hak). I opened the module in the toolset and Saved As a different name. I then ran the PRC compiler and all files rebuilt without any errors. I then saved the module and started running it as a standalone server.
Is that the correct method to upgrade from PRC 3.3g to PRC 3.5?
Thanks
Looks right. Did you remerge the 2da files in your top hak, if any?
-
Looks right. Did you remerge the 2da files in your top hak, if any?
Oh-oh. :o
There is a "top merge hak" from the last time I upgraded the module (to PRC 3.3g), but this time around I did not remerge 2da files into it. Frankly because I have forgotten what I actually did a number of years ago to create that "top merge hak" and everything seemed to be working - well until this Scout crash happened. :(
So .....
If you would be so kind as to jog my memory of what I actually need to do to upgrade the "top merge hak", I'd be most appreciative - and maybe we can solve this pesky Scout situation.
If it helps at all, I have been doing some more debugging, and I had come to the conclusion that the module crashes when trying to determine if the Scout has moved in the last round in order to determine whether Skirmish bonuses are deemed or not (this seems to be an EventHook that is added dynamically and executed onHeartbeat). When the module crashes, the hif_onenter script has already been completed.
Thanks
-
If you would be so kind as to jog my memory of what I actually need to do to upgrade the "top merge hak", I'd be most appreciative - and maybe we can solve this pesky Scout situation.
Here is how I do it.
1.) Make a backup of your original 3.3 top hak.
2.) Make a folder & extract your 3.3 top hak into it, using NWHak.
3.) Make another folder & extract the PRC 3.5 2da files into it.
4.) Make a 3rd folder that will contain the merged 2da files.
5.) Figure out which files are in both folders, these will be the ones that need merging.
6.) Using Excimer's 2DA Combinulator (http://nwvault.ign.com/View.php?view=other.detail&id=1099), open each paired 2da file, merge them & write a new 2DA file to the 3rd folder. I use the beta version.
7.) When you are done, put the contents of the 3rd folder into your top hak, overwriting any old files.
8.) I usually recompile my module at this point, but I'm not sure if it's 100% necessary.
Hope that helps!
-
My group has been running this module with PRC and no NWNx2 as a private server on and off for the past 6 years or so. Seems to work fine (except for this pesky Scout situation).
Are you running the module in the graphical client or the stand alone server?
-
Here is how I do it.
1.) Make a backup of your original 3.3 top hak.
2.) Make a folder & extract your 3.3 top hak into it, using NWHak.
3.) Make another folder & extract the PRC 3.5 2da files into it.
4.) Make a 3rd folder that will contain the merged 2da files.
5.) Figure out which files are in both folders, these will be the ones that need merging.
6.) Using Excimer's 2DA Combinulator (http://nwvault.ign.com/View.php?view=other.detail&id=1099), open each paired 2da file, merge them & write a new 2DA file to the 3rd folder. I use the beta version.
7.) When you are done, put the contents of the 3rd folder into your top hak, overwriting any old files.
8.) I usually recompile my module at this point, but I'm not sure if it's 100% necessary.
Hope that helps!
;D
Thanks for the detailed instructions - I'll give it a shot over the next couple of days.
-
Are you running the module in the graphical client or the stand alone server?
We are running it in the stand alone server. (the LINUX stand alone server).
But I do seem to remember that once we had hardware problems on the Linux box and one of the other guys ran it on his Windows standalone server as a temporary measure, until we got the hardware fixed.
Over the years we've done campaigns to play through various modules, but we always end up back on this module.
Unfortunately none of us has the time or skills to host it as a public server - it'd be great if someone would host it as a public server again.
-
Does the game crashes right after this log entry is made?:
[Thu Aug 30 11:58:52] prc_scout: Scout WP for 'Anna Farrunner' - '' - '' - 7ffffffd didn't exist, creating. Tag: PRC_ScoutWP_Anna Farrunner
Could you try if your module works without recompiling all scripts (with just prc haks updated)?
-
Does the game crashes right after this log entry is made?:
Could you try if your module works without recompiling all scripts (with just prc haks updated)?
Yes the game crashes after that log entry is made.
I tried just opening the PRC 3.3g module in the toolset with PRC 3.5 installed and saving it. I did not recompile scripts. The game still crashes when the Scout character is loaded.
I have not updated the top merge hak as of yet. Working on that now.
Thanks
-
:(
I have upgraded the top merge hak as described above (thanks for the instructions), but the module still crashes when the Scout character is loaded.
I went back to my PRC 3.3g installation and created a Fighter, then gained a level & took Scout. Exiting and reloading the character was fine. Restarting the server and reloading the character was fine. I was also able to load up the Scout-6/Bowman-6 character where we originally found the problem. So PRC 3.3g works fine with a Scout, PRC 3.5 does not.
Here is the latest log file from PRC 3.5 - much the same as the other one, except I added in debug statements in the hif_onenter script and around the on_heartbeat script. You can see that it executes hif_onenter, then executes prc_onenter, then finishes hif_onenter. Then it crashes. From my inspection of the prc_scout code, it looks like it is doing the calculation for Skirmish bonuses when it fails, but I've pretty well reached the limits of my expertise as far as understanding the coding.
The only other thing I can think of is that the module's onenter script does do a location move on the character that is entering, but it did that with PRC 3.3 as well, so I don't understand why it would make a difference with PRC 3.5, when checking for the Skirmish bonuses.
I don't know what else to try - as far as I know, the Scout is the only class with the Skirmish ability.
If anyone else has the time to look at this, the PRC3.3-version of the module is available to be downloaded from the vault at http://nwvault.ign.com/View.php?view=Modules.Detail&id=6096. Just open it in a PRC 3.5 toolset, and resave it after recompiling the scripts. The top Merge hak doesn't seem to make a difference to this situation.
Create a Fighter, talk to Barliman in the Inn, do the quest for Hamfast and that will get you enough XP for level 2. (or just use a leveller module or DM). Choose Scout as your second level. Exit the module & reload the character. It works.
Exit the module, restart the server & reload the character - it should fail.
Any other suggestions are welcome.
-
When I encounter a bug like this I usually try to find out which script is causing it. The attached file is from PRC 3.3 - could you add it to your top hak and check if the server still crashes when loading scout character, please?
-
When I encounter a bug like this I usually try to find out which script is causing it. The attached file is from PRC 3.3 - could you add it to your top hak and check if the server still crashes when loading scout character, please?
I added the prc_scout.ncs file to the top merge hak using nwhak.exe - is that the correct way to do it?
It doesn't seem to make any difference - the server crashes when the scout character is loaded and the log file looks the same to me.
I've attached the latest log file - is there a way to tell if the prc_scout.ncs file was executed or not?
-
If it's in the top hak, than the log says it was executed. Maybe it's something in onenter script?
Could you test which hak is causing crashes? Just update PRC haks one by one - update prc_2das.hak - load the module and check your character, update prc_* etc. At some point the game will crash - this will tell us which hak is causing this.
-
If it's in the top hak, than the log says it was executed.
I am not sure that I added it to the top hak properly. The 2 server logs are identical as far as I can see (with and without prc_scout in the top hak). Both logs say that prc_scout is being executed but the logs don't distinguish between the 3.3 prc_scout and the 3.5 prc_scout routines. Let me re-phrase the question:
Is there a way to tell if the prc_scout.ncs file that you sent (the 3.3 one) was executed or I screwed up adding it to the top hak with the result that the prc_scout 3.5 routine was run?
Maybe it's something in onenter script?
The onenter script is already finished by the time the crash occurs. I put my own debug statements in the hif_onenter routine. Here's the tail-end of the log showing them - ("starting onenter", "starting prc_onenter" and "finished onenter" are mine):
[Tue Sep 4 15:51:49] starting onenter
[Tue Sep 4 15:51:49] starting prc_onenter
[Tue Sep 4 15:51:49] Deleting composite bonus list 'PRC_ComAttBon' on 'Anna Farrunner' - '' - '' - 7ffffffd
[Tue Sep 4 15:51:49] Deleting composite bonus list 'PRC_CBon' on 'base_prc_skin' - 'base_prc_skin' - 'base_prc_skin' - 594e
[Tue Sep 4 15:51:49] Clearing class flags
[Tue Sep 4 15:51:49] prc_inc_sneak: Rogue Sneak Dice: 2
[Tue Sep 4 15:51:49] prc_inc_sneak: Blackguard Sneak Dice: 0
[Tue Sep 4 15:51:49] prc_inc_sneak: Assassin Sneak Dice: 0
[Tue Sep 4 15:51:49] prc_inc_sneak: Epic Sneak Dice: 0
[Tue Sep 4 15:51:49] finished onenter
[Tue Sep 4 15:51:49] prc_scout running, event: 6
[Tue Sep 4 15:51:49] prc_scout: Scout WP for 'Anna Farrunner' - '' - '' - 7ffffffd didn't exist, creating. Tag: PRC_ScoutWP_Anna Farrunner
Could you test which hak is causing crashes? Just update PRC haks one by one - update prc_2das.hak - load the module and check your character, update prc_* etc. At some point the game will crash - this will tell us which hak is causing this.
??? I don't know what you mean update PRC haks
Do you mean replace 3.5 haks with the corresponding 3.3 haks one at a time in the hak folder or do you mean generate a .ncs file like you did with the 3.3 prc_scout.ncs? I have no idea how to generate a .ncs file from a PRC hak.
-
??? I don't know what you mean Do you mean replace 3.5 haks with the corresponding 3.3 haks one at a time in the hak folder
Replace 3.3 haks with corresponging 3.5 haks one at a time, yes.
To make sure that 3.3 version of prc_scout.nsc is executed delete (using nwhak.exe) prc_scout.nsc from prc_scripts.hak (so there will be only one version in the top hak). Both uncompiled scripts are almost identical - I thought that maybe some includes were changed.
-
Replace 3.3 haks with corresponging 3.5 haks one at a time, yes.
To make sure that 3.3 version of prc_scout.nsc is executed delete (using nwhak.exe) prc_scout.nsc from prc_scripts.hak (so there will be only one version in the top hak). Both uncompiled scripts are almost identical - I thought that maybe some includes were changed.
OK, I reran the test with the 3.3 version of prc_scout in the top merge hak and with prc_scout deleted from prc_scripts.hak. The server crashed as before when the scout was loaded. The log looks exactly the same as before.
I did discover that NWN will also crash when loading the module as a local game in the client-only and loading the scout character. This will make it easier to test replacing the 3.3 haks one-by-one, which may have to wait for the weekend.
Stay tuned...
-
I did discover that NWN will also crash when loading the module as a local game in the client-only and loading the scout character. This will make it easier to test replacing the 3.3 haks one-by-one, which may have to wait for the weekend.
Stay tuned...
OK, being able to test it as a local game in the client-only significantly sped up the testing.
In all cases, I loaded the PRC 3.3 version of the module and selected the scout-6/bowman-6 character.
In the pure-PRC 3.3 environment the module loads the character successfully. That is the first attached Log file "nwclientLog1-worked.txt".
Through trial & error, I discovered that I had to use PRC 3.5 versions of two files to get the module to crash: prc_2das.hak and prc_scripts.hak. Using just one or the other did not cause the module to crash - I had to use both together. That is the second attached log file "nwclientLog1-failed.txt".
I really hope this gives you the info you need to track it down.
-
Success!!
I found this code in the module's 00_oncliententer script:
object oPC = GetEnteringObject();
object oWaypoint = GetWaypointByTag("WP_The_Begining");
location lWaypoint = GetLocation(oWaypoint);
if (!GetIsPC(oPC))
return;
AssignCommand(oPC, ClearAllActions());
AssignCommand(oPC, JumpToLocation(lWaypoint));
After I removed the above code, I was able to load the Scout character without it crashing the server. I have no idea why the original authors had this code in there, but everything seems to still work.
I suspect it is interacting badly with the way PRC 3.5 is checking the Skirmish ability - the Skirmish checking code must have changed from PRC3.3, but I have no idea how that code works.
Thanks to everyone who helped!
I'll be uploading the PRC 3.5 version of the module to the vault in the next day or two.