it just has to have to processing power to drive win7 64 - min dual core 1.6 or so gig each - i have a quad core at 2.6 each and i just run x86 for the toolset - but i have been thinking about upgrading my win7 to 64 - just reluctant to re install everything - why fix it if it ain't broke?
Crashing toolset
Débuté par
PJ156
, févr. 01 2014 08:12
Retour en haut
#27
Posté 04 février 2014 - 03:23
rjshae
-
- Members
- 4 478 messages
To me the most likely reasons to upgrade to 64-bit is if you want to add more memory to your system or if you need to run a 64-bit-only app. Otherwise, 64-bit applications are bigger and take more time to load, just from the fact that they handle larger memory addresses.
#28
Posté 04 février 2014 - 11:19
Tchos
-
- Members
- 5 030 messages
To add my info, I don't. I'm using Windows Vista, and I don't run the toolset in any kind of compatibility mode or other special mode.Claudius33 wrote...
Do you guys run all NWN2 executables including the toolset in Windows XP SP2 compatibility mode?
Actually, I'd say that if anything, Norton is the one using too much processor resources. It's a notorious resource hog.PJ156 wrote...
I often get the message from Norton that the toolset is using to much processor resource so i guess this is that issue.
Since I also have 32-bit Windows, does that mean I shouldn't bother with that 4GB exe patch, even though I have physically more than 4GB of RAM that I can't currently use?kamal_ wrote...
You have 32 bit windows, it can't make the whole 4 GB available even though you physically have it.
#29
Posté 04 février 2014 - 11:42
kamal_
-
- Members
- 5 238 messages
Unknown, as I was providing the reason to PJ. I'm personally leery of seemingly magic fixes as they may cause unforseen problems. MS's own 32 bit apps don't seem to take advantage of this for instance.Tchos wrote...
Since I also have 32-bit Windows, does that mean I shouldn't bother with that 4GB exe patch, even though I have physically more than 4GB of RAM that I can't currently use?kamal_ wrote...
You have 32 bit windows, it can't make the whole 4 GB available even though you physically have it.
#30
Posté 05 février 2014 - 05:09
Tchos
-
- Members
- 5 030 messages
I'm wary of them, too, but it would be nice.
#31
Posté 05 février 2014 - 10:34
Claudius33
-
- Members
- 256 messages
I always run the toolset and the game in XP SP2 compatibility mode. I did a couples modules of 16 Cygni using a laptop under Vista (core duo, 4 Gb). I hadn't that much troubles.
Although I am not able to explain why, it seems that the toolset is more stable when run on compatibility mode.
Although I am not able to explain why, it seems that the toolset is more stable when run on compatibility mode.
#32
Posté 15 février 2014 - 03:18
Lance Botelle
-
- Members
- 1 480 messages
Hi PJ156,
I have found that as my module has got bigger, the toolset has become more unstable as I try to work with more resources. My suspicion is a memory leak in the toolset itself that causes the crash. I have had the toolset crash "on exit" after a few sessions, which is most frustrating as it causes a memory dump, which prevents the module from being able to be loaded again, and resort to a backup.
As others have said, I also now try to keep my area opens to a minimum and if I suspect my usage of the toolset to have been quite "heavy" (i.e. I have been going backwards and forwards with various resources), I will save, shut down the toolset and reopen it before opening another area.
Saving and closing the toolset and reopening to continue is now a practice I try to keep to, to prevent the crash on exit scenario ... memory dump nightmare!
Bottom line, I am 99% sure a reinstall will not help you.
Cheers,
Lance.
EDIT: Bah! I just had an "exit crash" again! - Windows freezes and have to do a hard reboot! Thankfully, no memory dump this time, so no data loss.
I have found that as my module has got bigger, the toolset has become more unstable as I try to work with more resources. My suspicion is a memory leak in the toolset itself that causes the crash. I have had the toolset crash "on exit" after a few sessions, which is most frustrating as it causes a memory dump, which prevents the module from being able to be loaded again, and resort to a backup.
As others have said, I also now try to keep my area opens to a minimum and if I suspect my usage of the toolset to have been quite "heavy" (i.e. I have been going backwards and forwards with various resources), I will save, shut down the toolset and reopen it before opening another area.
Saving and closing the toolset and reopening to continue is now a practice I try to keep to, to prevent the crash on exit scenario ... memory dump nightmare!
Bottom line, I am 99% sure a reinstall will not help you.
Cheers,
Lance.
EDIT: Bah! I just had an "exit crash" again! - Windows freezes and have to do a hard reboot! Thankfully, no memory dump this time, so no data loss.
Modifié par Lance Botelle, 15 février 2014 - 03:29 .
#33
Posté 15 février 2014 - 03:43
PJ156
-
- Members
- 2 980 messages
Thanks Lance,
I have started to use the same strategy. The upside is, the more you open it, the quicker it opens. First time take 2 mins or more now I have all the placeables set up
Interesting thought on module size. I wonder if that influences this. Opening and closing it helps a lot though.
PJ
I have started to use the same strategy. The upside is, the more you open it, the quicker it opens. First time take 2 mins or more now I have all the placeables set up
Interesting thought on module size. I wonder if that influences this. Opening and closing it helps a lot though.
PJ
#34
Posté 15 février 2014 - 04:12
Lance Botelle
-
- Members
- 1 480 messages
PJ156 wrote...
Thanks Lance,
I have started to use the same strategy. The upside is, the more you open it, the quicker it opens. First time take 2 mins or more now I have all the placeables set up
Interesting thought on module size. I wonder if that influences this. Opening and closing it helps a lot though.
PJ
Hi PJ,
As another possible pointer, I have found that it is the blueprint references that seem to corrupt, so maybe any potential memory link has something to do with those.
I know what you mean about quicker opening though.
Cheers,
Lance.
#35
Posté 15 février 2014 - 04:55
Lance Botelle
-
- Members
- 1 480 messages
P.S. I have also noted the problem to be related to the "audiodg.exe" file in some way.
How NWN2 relates to this problematic file I do not know.
I am trying this possible solution. : http://technicallyea...high-cpu-usage/
Lance.
How NWN2 relates to this problematic file I do not know.
I am trying this possible solution. : http://technicallyea...high-cpu-usage/
Lance.
Modifié par Lance Botelle, 15 février 2014 - 04:58 .
#36
Posté 15 février 2014 - 05:08
andysks
-
- Members
- 1 645 messages
We talked once PJ, about our many gigs campaign folders. Could also be there. I was working on a module the other day, which was not added yet to the campaign. An exterior 16x16 I think was running smooth, even if it was loaded with lights and vfx. After adding the module to the campaign I have heavy lags on the same area.
Another thing I want to mention, from what Lance said. It is impossible to open a module, save, and open another module before first closing the toolset. It will crash 100% of the time. So the memory thing is there as well I guess.
Another thing I want to mention, from what Lance said. It is impossible to open a module, save, and open another module before first closing the toolset. It will crash 100% of the time. So the memory thing is there as well I guess.
#37
Posté 15 février 2014 - 08:11
Claudius33
-
- Members
- 256 messages
Weird, how much RAM do you have? I open a module, save it open another all the time without closing the toolset.
#38
Posté 16 février 2014 - 02:11
andysks
-
- Members
- 1 645 messages
Well, ram is 8gb. But my campaign folder is 5gb at the moment. It's because I have all the mdbs from kamal's tile project and PJ's placeables in there. Since I don't know yet which I will use by the time I am finished. Once I am done, these will go in hak, reducing the campaign folder size. But now, a module makes some time to open because of the huge blueprint list. I think this is why it crashes.
#39
Posté 16 février 2014 - 02:26
kamal_
-
- Members
- 5 238 messages
I have a campaign folder of those, plus my texture project and some other stuff and a shedload of blueprints. No crashing, but I do have 16gb ram.andysks wrote...
Well, ram is 8gb. But my campaign folder is 5gb at the moment. It's because I have all the mdbs from kamal's tile project and PJ's placeables in there. Since I don't know yet which I will use by the time I am finished. Once I am done, these will go in hak, reducing the campaign folder size. But now, a module makes some time to open because of the huge blueprint list. I think this is why it crashes.
Modifié par kamal_, 16 février 2014 - 02:27 .
#40
Posté 16 février 2014 - 02:56
Morbane
-
- Members
- 1 883 messages
Claudius33 wrote...
Weird, how much RAM do you have? I open a module, save it open another all the time without closing the toolset.
andysks wrote...
Well, ram is 8gb. But my campaign folder is 5gb at the moment. It's because I have all the mdbs from kamal's tile project and PJ's placeables in there. Since I don't know yet which I will use by the time I am finished. Once I am done, these will go in hak, reducing the campaign folder size. But now, a module makes some time to open because of the huge blueprint list. I think this is why it crashes.
i have only 2 gigs with 3 in a GT630 - no crashing - open close test open close every which way - and haks approaching 2gigs - and the textures pack in the override
Modifié par Morbane, 16 février 2014 - 02:59 .
#41
Posté 16 février 2014 - 03:04
andysks
-
- Members
- 1 645 messages
Then I guess it could easily be the generally forced PC. Installing Elder Scrolls Online beta took 50gb, taking nearly all my safe space. A full HD with a couple more programs running on the background could crash my toolset during opening new modules without restarting it I guess.
#42
Guest_Iveforgotmypassword_*
Posté 17 février 2014 - 02:12
Guest_Iveforgotmypassword_*
Guest_Iveforgotmypassword_*
-
- Guests
andysks.. You might have hit on something there because having a massive campaign folder that is affiliated with a module when you open it is bound to cause a "brain drain" on your computer because it's trying to look at the whole lot and 5gb is a bit ridiculous and larger than a lot of complete games you can buy with loads of content, graphics etc.
I just use the override then convert what I've used into a hak later, perhaps that way your PC is looking for only what it needs and that could save it some grief. I've made big modules on not powerful computers without crashes but hardly ever have I put things in the campaign folder intentionally it just fills up by itself with conversations, npcs, items, journals etc.
I just use the override then convert what I've used into a hak later, perhaps that way your PC is looking for only what it needs and that could save it some grief. I've made big modules on not powerful computers without crashes but hardly ever have I put things in the campaign folder intentionally it just fills up by itself with conversations, npcs, items, journals etc.
Modifié par Iveforgotmypassword, 17 février 2014 - 02:13 .
#43
Posté 17 février 2014 - 04:09
andysks
-
- Members
- 1 645 messages
My thing is that I also try to play some modules Tsongo. I know having things in the campaign folder is not ideal, but who knows what override will mess up? I mean, mdbs... should not cause problem from the override... it's not like having a journal file in there or something. These 5gbs, are mostly mdbs. These will all go into a hak once the work is finished and I know which ones I used. But for now it was nice to have all these as campaign resources. I don't think I will need any more custom content, only maybe things that come out now, which shouldn't cause that much of a size problem. But if I see that once the campaign gets bigger and bigger in modules, has more and more trouble to open areas I will try the override solution.
Now that I said that, I have no clue if the more the modules the heavier the pack generally. I know you especially release many modules. Did you ever see any particular troubles with them? I have 9 modules so far, and I haven't even finished my material plane yet... perhaps it's an issue for future Andy to keep an eye on?
Now that I said that, I have no clue if the more the modules the heavier the pack generally. I know you especially release many modules. Did you ever see any particular troubles with them? I have 9 modules so far, and I haven't even finished my material plane yet... perhaps it's an issue for future Andy to keep an eye on?
#44
Guest_Iveforgotmypassword_*
Posté 17 février 2014 - 07:31
Guest_Iveforgotmypassword_*
Guest_Iveforgotmypassword_*
-
- Guests
I've never had any problems with lots of modules in a campaign and all three computers I've made campaigns with have never opened things slowly or crashed opening etc. My original laptop had 1gb of ram, 256mb of shared graphics and something like a 1.5ghz processor ( below stats to even play the game ) and with that I opened two areas at once all the time because I used to link doors like that before I knew how to set them up with waypoints.
I think my last offering was 13 modules and is about 800mb when compressed. The modules I always keep in between about 150 and 200mb, the hak is about 500mb and the campaign folder something like 60.
Why not make a folder called my mod and put all your campaign custom content in it then stick it in your override ( override will open folders without a problem ) if it makes a difference leave it there and if you want to play another module then move it out to your documents. It wont take seconds to swap about and could save you loads of time
I think my last offering was 13 modules and is about 800mb when compressed. The modules I always keep in between about 150 and 200mb, the hak is about 500mb and the campaign folder something like 60.
Why not make a folder called my mod and put all your campaign custom content in it then stick it in your override ( override will open folders without a problem ) if it makes a difference leave it there and if you want to play another module then move it out to your documents. It wont take seconds to swap about and could save you loads of time
#45
Posté 17 février 2014 - 07:49
PJ156
-
- Members
- 2 980 messages
Interesting ideas, I hvae 4 gb RAM I would love more but hey. I think Lance has a good point. My first regular crask area had a lot of sound objects. That one only opened 50% of the time, sometimes less. If it did not open it crashed the toolset. Now I ahve several of those, it seems to be big areas with a nmber of sound objects?
PJ
PJ
Modifié par PJ156, 17 février 2014 - 07:50 .
#46
Guest_Iveforgotmypassword_*
Posté 17 février 2014 - 10:26
Guest_Iveforgotmypassword_*
Guest_Iveforgotmypassword_*
-
- Guests
Could be because I've only ever made a couple of areas with sounds in and they were just a few wolf howls made really big so you could hear them everywhere. I think unless you're going for spooky effects sounds don't really add much to this game because it's normally all viewed from a distance while you play.
#47
Posté 17 février 2014 - 10:30
Lance Botelle
-
- Members
- 1 480 messages
PJ156 wrote...
Interesting ideas, I hvae 4 gb RAM I would love more but hey. I think Lance has a good point. My first regular crask area had a lot of sound objects. That one only opened 50% of the time, sometimes less. If it did not open it crashed the toolset. Now I ahve several of those, it seems to be big areas with a nmber of sound objects?
PJ
Hi PJ,
Yes, I do think "sound" objects have something to do with the problem. You may have also noticed how the effects editor will also crash the toolset (when testing an effect) if an effect has some sounds attached to it.
Two things I reckon:-
1) Sounds. (*)
2) Blueprints.
Somehow or other, these two objects are memory inefficient (or bugged) and can cause toolset crashes on exit.
System: 8 GB memory. Maybe 16 GB gives a system enough overhead to help handle memory leaks in these areas.
(*) Since trying that "sound fix" I mention above, I have not yet had another toolset exit crash, but that may be because I have not tested it enough yet. (It does not always happen afterall.) Maybe others might want to try that and give some feedback.
Cheers, Lance.
#48
Posté 17 février 2014 - 10:41
kamal_
-
- Members
- 5 238 messages
Docks Ward in Crimmor uses 142 sound objects (I just checked), all custom sound. Other wards are in the 50-100 sound object range. No problems opening that.
#49
Posté 17 février 2014 - 10:44
rjshae
-
- Members
- 4 478 messages
My big overland map often crashes when I try to close it. That has a boatload of placeables and a number of sounds, but it is nothing like kamal_'s count. The problem is making me reconsider using smaller overland maps.
#50
Posté 18 février 2014 - 12:43
Lance Botelle
-
- Members
- 1 480 messages
Hi all,
I think the problem is a combination of things, but specifically, I noticed that the sound issue was related to a file in Windows, which not everybody may have installed (or have active) in their computer setup. Therefore, if your computer does not have this file, then you may not experience the crash on exit caused by that file interacting with a NWN toolset issue.
I found that I did have the file (and was setup to use sounds in a certain way) and it did appear to be the file causing the crash for my computer/NWN setup when I exited the toolset. I have now disabled the interaction of this file and am waiting to see the results over time. To date, this has helped as I have not had any more crashes on exit so far ... but it's still early days.
Kamal, maybe you can see if your computer has the file I mention above "active" when using the toolset. If your computer does not have it "active", then that may explain why sounds do not affect your situation.
EDIT (Taken from above post):
P.S. I have also noted the problem to be related to the "audiodg.exe" file in some way.
How NWN2 relates to this problematic file I do not know.
I am trying this possible solution. : http://technicallyea...high-cpu-usage/
Thanks,
Lance.
I think the problem is a combination of things, but specifically, I noticed that the sound issue was related to a file in Windows, which not everybody may have installed (or have active) in their computer setup. Therefore, if your computer does not have this file, then you may not experience the crash on exit caused by that file interacting with a NWN toolset issue.
I found that I did have the file (and was setup to use sounds in a certain way) and it did appear to be the file causing the crash for my computer/NWN setup when I exited the toolset. I have now disabled the interaction of this file and am waiting to see the results over time. To date, this has helped as I have not had any more crashes on exit so far ... but it's still early days.
Kamal, maybe you can see if your computer has the file I mention above "active" when using the toolset. If your computer does not have it "active", then that may explain why sounds do not affect your situation.
EDIT (Taken from above post):
P.S. I have also noted the problem to be related to the "audiodg.exe" file in some way.
How NWN2 relates to this problematic file I do not know.
I am trying this possible solution. : http://technicallyea...high-cpu-usage/
Thanks,
Lance.
Modifié par Lance Botelle, 18 février 2014 - 12:44 .
