Workflow question: Compiling scripts for inclusion in HAK

This is sort of a workflow question…

I want to edit and compile a bunch of NSS scripts that will go into a HAK that’s part of a module. The module (of course) uses some Bioware/Beamdog default include scripts, some that are in the module, and some that are in the module’s other HAK files. I need some advice on how to set this up so that I can compile outside the Toolset, but still have the compiler use the includes and so on that the module would use. Is there a good way to do this?

Why am I asking this? If I were doing this using the in-Toolset compiler, I would open my script, edit it, compile it, add it to the my scripts HAK using NWHAK, then start the module to test it. Or, I could delay putting the script into my scripts HAK until I have it working, then put it in my scripts HAK and delete it from the module. Of course, that’s great except that I am often not done with a script when I first think I am done with it. And, either of those approaches can be a tedious process if I am dealing with lots of script files, especially since it’s easy to forget that I have modified a script in the Toolset, but it won’t actually be used at runtime if there is an older version in my scripts HAK.

What I am hoping for is some way to keep a folder of my eventually-to-go-in-my-scripts-HAK scripts that I can edit. Then, when I am ready to test, I call a compiler to recompile all of those scripts (the compiler would have to know which module they are in so that it can use module includes when needed and use HAK includes when needed), then pop them into my scripts HAK for testing.

Is there a way to do this?

Have you considered putting the scripts into the development folder and editing them there until it comes time to put them in your hak? Note, I haven’t actually tried this myself but it should (at least in theory) work as anything in the development folder overrides everything including what’s in haks.

TR

1 Like

That seems like a possibility. Do you have a link on how to use the development folder? I have seen it sitting there, but never used it.

Also, any recommendations on a compiler to use for the scripts in the development folder? Or, does the Toolset look in that folder for scripts and put the NCS files there when it compiles them?

You simply treat it as you would the override folder. Put stuff in there. Try an experiment. Create a simple script nss file, put it in there and see if it appears in a placeables event scripts when you click the ‘…’ button next to an individual event. If it does, you should be good to go. Just make sure the script is only in the development folder and nowhere else.

TR

Out of interest why are you putting scripts in a hakpack? EE no longer has a item limit and scripts are not going to make a module file hit the 2GB file limit either. Scripts in hakpacks should be avoided since as per your example its a pain!

1 Like

FWIW I tend to agree with @Jasperre here but for a different reason. If you put the scripts in a compiled form into a hak, you basically remove peoples ability to learn from them because there is no source code to examine. What about de-compilation? Possibly but not everyone is going to know how to do that and the code produced will in all probability be in an obscured state. Any variable will likely not match the names of the original variables.

TR

Probably the last remaining reason to put scripts in a hak is decluttering.

For example, a legacy tailor or forge system might have dozens - even hundreds - of scripts. If they’re in the module, that’s a long, long list to wade through in the left-hand palette every time you want to find some other script.

Time was, it also brought the toolset to a halt. Maybe that’s no longer true, haven’t tried it.

Of course, most script systems written from scratch for EE can be parameterised (actually that was always possible using local vars), but we’re rarely in the happy position of starting over.

1 Like

no that wasn’t possible, not generally, there was a possiibility to use local var on a creature for such scripts, but this was only possible when such creature conversation used this just once. For something like dynamic convo system or a conversation that had dozen of choices for example of items you can buy with different ammount of gold, you always needed ton of scripts to handle it

I had local-vars based quest scripts and sure this way I saved tons of scripts, but this only worked for npcs that offered just one script, once the said npc offered two or more, another set of scripts would have to be created which in the end didn’t save much.

Now under EE using script params, I need only 3 scripts for this no matter how many quests the npc conversation offers. In fact I am using 5 scripts, but that is just for convenience reasons. The old variable based system I used still required over 20 scripts, one to check each quest state value and one to set each quest value, and that required to tailor the quest system to be united and use only values 1-10 with 10 reserved as quest end.

z-dialog and friends do this fine. You can reduce your tailor scripts down to one (plus the 15 or so for the system but that gets amortized). I still have not bothered to rewrite everything to use the EE parameters. Too much of a pain for stuff that already works :slight_smile:

Scripts in haks, eww …

Okay. I learned my NWScripting on 1.69 and my thought of keeping the scripts in HAKs was maybe old-school thinking, based on organization (not having a thousand scripts dumped into the module file with no real categorization), a sluggish Toolset, and the old limits on module resources.

Organization is still a concern to me, but if it’s the only reason nowadays, then maybe it isn’t a good enough one. I appreciate everyone’s feedback on this. Whether I go the HAK route or possibly modernize/clutter my approach, I am glad to know that both are workable options.

BTW, I am loving the convo script parameters! I just finished some scripting that would have required dozens of scripts that were 90% variations on the functionality of just two or three. Now the whole convo uses 5 scripts and 3 of them are ones I anticipate re-using elsewhere.

1 Like

TR, the plan had been to include both the NCS and the NSS files in the HAK. In the past, I have seen and been frustrated by packages (for instance spell HAKs) that only included the compiled files. Not only an impediment to learning, but very difficult to fix when something doesn’t work properly.

1 Like

Yeah script params are amazing. Cuts down so much.

I’d highly recommend if you are encountering “too many scripts” to start to use VSCode to edit your scripts. A tutorial on setting up the environment - which you just run at the same time temp0 (or the folder named the same as your module) - I wrote here: NWN:EE Script Editing Tutorial - NWN Lexicon

This allows you to do mass compilation, proper find, replace, formatting, and able to edit while other things are open and so on.

There’s also a new NWN Language Server for vscode which is being worked on you might want to use instead of the suggested highlighter and NSS snippits; nwscript-ee-language-server - Visual Studio Marketplace (it’s still in alpha though, so works but has some issues).

1 Like

I personally use notepad++ with an NwN 2 script highlighter with autocomplete (this one I think, can’t remember precisely). notepad++ has a large number of plugins including NWScript Tools v1.0.3.1950 which says it can -

View, edit and compile Bioware’s NWScript files with this plugin. Use customized color-syntax for your personalized tokens and also for engine-defined ones. Can disassemble compiled scripts and build makefile dependencies. Also has a feature to process files in configurable batches.

I only just discovered it while looking for NppExec which allows you to use an external compiler.

TR

https://neverwintervault.org/project/nwn2/other/tool/nwscript-language-notepad
Are you referring to this?

Thanks. I think that’s the one (but then again I could have sworn I linked to that project page but obviously didn’t :scream_cat:).

TR

Absolutely, plus if you don’t do that, you keep it backwards compatible - this of course doesn’t matter for PW unless you got sick of EE regressions and decided to revert back into 1.69 which not even I am considering, but it might be very important for single player module makers.

SP module using script parameters won’t work properly under 1.69 even if you can change the version of the module and make it open-able with 1.69.

On the other hand, I spent that work and reworked most of the conversation scripts into script params and it cleaned up a module a lot. So many legacy scripts with weird names that did simple gold or item checks are gone and it speed up toolset a bit too. If anyone is interested in this, I can share my script-param scripts, there are very few and they handle 90% of the stuff in conversation that I ever needed.

Make a project of it. It will not only be useful but also educational and scripts in a thread can very quickly scroll away out of people’s memory.

TR

1 Like