I have been playing with the toolset for a while, but its stability concerns me. The most frustrating issue is with testing. I simply cannot keep the toolset open while testing (whether through the “Test Module” option in the toolset, or simply fire up the game manually) – the moment the game quits, the toolset goes into a perpetual freeze. So far the safest way is to close the Toolset and launch the game manually.
Is there a fix somewhere targeting it? Or if I have to, is there a faster way to reach the module in game? I already disabled movies and such, but I still need to pick the module, pick a character and load it.
I’m using an integrated video card if it helps – but it’s a good one and have no trouble playing the game itself. It can play more demanding games as well.
Thanks!
I think there is a shortcut passing an argument to the client to cause it to load the specified module and uses the first PC. My notes from the conversation:
“ It uses the first in the alphabetical order in the local vault. You can throw an underscore at the beginning of the filename that you want to test with.
All that said, judging by the pushback, I don’t think my “remove F9 option” was properly understood. I most certainly didn’t suggest you should load the game and click through to start your module manually, that would definitely be a massive blow to productivity. The way toolset F9 feature works is that it just starts nwmain.exe with a given parameter. You can do this yourself:
- nwmain.exe +TestNewModule “My module name without extension”
- This behaves like the toolset and will start the mod with the first available character
- nwmain.exe +LoadNewModule “My module name without extension”
- This is similar but it will stop at the character select screen and let you pick a character
(no need for "s if module name is a single word)
These parameters work fine, it’s just that if it’s the toolset (32bit compat app) that starts nwmain as a child process the issues appear.
Since most people are working on one module at a time, you can just make a shortcut with these parameters (tutorial for windows: https://www.digitalcitizen.life/shortcut-arguments-parameters-windows/) and put in the quickbar or bind to a hotkey or whatever.You can also make a script that will look at which module the toolset has open (or whichever .mod file was modified last) and pass that as an argument if you frequently change the module you are working on.”
1 Like
Thanks, the shortcut works. However when I closed the game, the toolset went into freeze (white screen with a loading cursor). Is there anything I can do to fix this without closing the toolset before testing?
For most people, Build > Test Module in the toolset works fine, and does not freeze the toolset.
So the real question here is why your toolset is freezing.
You could try running as adminstrator, with toolset and game as AV exceptions.
Otherwise, I don’t have an answer, but maybe someone else does, if you give more details of your setup.
1 Like
I have seen similar issues with toolset on very low cpu/ram laptop. It is sad that EE increased requirements so much because I was working in toolset in ~2008 on a cheap end laptop and it was smooth and stable, but it is as it is.
Maybe you can build in 1.69. EE toolset only allows:
- placeable scaling (which can be scripted using variable on a placeable)
- dynamic conversations using string tokens
- area tabs in toolset (which is needless and leads to data loss very often thanks to another EE toolset feature of crashing)
The new tilesets, creatures and such can be shown in 1.69 toolset, although it will be hard to dig that from EE bif files.
Or just buy better computer…
1 Like
You probably need to close the module, I know some of the NWN tools don’t like sharing haks for instance.
Simply put I haven’t found any shortcut to opening a test module in the client with the module open.
The vault discord probably has more pointers for builders, but my notes above probably cover it. The only trick I can think of is to have more than one set of haks, but the NWN.ini is read by both the toolset and the client. IF it’s the hak file access issue I think it is, then tricking the client to use a different set of haks might solve this issue. I’ll ask around just in case there is a method.
Actually, there is am method to point the nwserver to a different set of files (for reasons of two nwserver instances not clobbering each other’s memory or something.
People tend to use Nasher and some other dev tools for building and scripting and leveraging Git, and using WSL if your running windows. You update the module and restart the server.
I suppose if you can isolate their files then you could leave it in the toolset, but you’d still need to save it to your WSL modules directory and restart the server.
EDITED TO ADD: A note from a quick convo on this topic;
“ I don’t know about “best” practices, but the usual WSL setup worked well for me. For the fastest way to test, it won’t be faster than the server restart (if you’re using nwserver). For local installs, you can just drop the stuff you’ve changed into the development folder - this is usually the way for testing stuff that are far into the plot line of the module”
1 Like
I figured it could be the integrated video card issue – although it does run the game perfectly. Maybe I can buy a low end gaming laptop and see what happens.