Basically wondering if its possible to include scripts through haks or some other method.
The problem I’m already starting to run up against in the toolset is that the scripts list is a mile long; so if it’s possible to do something like that I’d like to slowly rotate out the code that’s mature.
If not I’ll deal but trying to grapple a little with the editing environment.
You can put scripts in haks.
Best reserved for very stable script sets, because you can’t edit hak scripts in the toolset. The original scripts need to be in a module for editing, then exported to the hak.
I have some for instance from CEP erfs that I probably will never change, like the zep_ scripts, those seem safe to do that with.
Ever tried to put an area into a hak? I tried, but got only crashes. Maybe there is a trick?
Problem is, areas are also listed in module.ifo.
Goodness knows why.
Difference between the area list and the actual area files is a major cause of crashes.
If I had to guess, probably for the DM Client.
putting scripts into a script hak does wonders for organisation. a nice approach is to have two instances of the same hak – one server-side, w/all your files, and the other one client-side, which remains empty. since the two haks have the same name, you’ll need to take care where you put them, so mind your source tree or your players will end up w/the wrong copy and learn all of your secrets… 
. you can also put templates in there, which may end up saving you a lot of space in the end if you’re a prolific designer. [in fact, i think the cep2_custom.hak was designed for just this sort of thing.]
TOUD is entirely open source under CC-BY-SA excepting for the fact that some models are licensed assets, so I’m not too worried about anyone learning my secrets. In fact, one of my projects is currently abstracting out the stuff useful for PWs so that people can use it as a framework/starting point for PW projects. I was mostly concerned with organization, I prefer to keep my workspace uncluttered.
yes, of course. but when i mentioned your players learning your secrets, i was referring to plot elements and exploits. if you’re checking for a specific item to advance the plot of a certain quest, for example, you don’t want to give that away; anyone w/even basic knowledge of nwn scripting would be able to glean enormous amounts of information about your campaigns just by reading your scripts. even worse, a player could read your scripts and find a way to turn the game to his/her unfair advantage.
This thread reads like 2005 era bioboards; none of this is false, it’s just hardly relevant anymore. The tooling has continuously improved in the last 20 years so anyone that doesn’t adapt is leaving a lot of productivity on the table.
In a nutshell:
ResManGetFileContents() and then compile them with CompileScript().development/ (override/ in 1.69) as raw files. This will allow for fast iteration because you can quickly change and test things while the module is running.GetScriptParam() for all your conversation scripts, and GetCurrentlyRunningEvent() to group things logically into single NSS files. What used to be a “system” with 100 NSS files in 1.69 can now be implemented much cleaner in 5x fewer lines of code and in 1-3 script files only.I’m fine with “leaving productivity on the table” to edit things the way I find efficient to actually edit them.
[edit]
To expand a little, too, the Toolset is the one supported means to edit these things; if I have problems with any third party tool I or anyone else editing using them are SOL and on our own; so I don’t find it a helpful suggestion to be telling people to use third-party toolchains.
Moreover, I feel the energy spent on those third-party toolchains would be better-spent improving the Toolset. Goodness knows it needs it.
I’m not sure what “unsupported” even means in this context. Two out of three projects I linked are actively maintained by the nwn:ee dev team; while the toolset is not. The level of support for toolset is roughly “we’ll try not to break it, but if we do here’s how to roll back to old version”
In my case I’m developing a PW, so the plot elements would be in DM plots. Worthy of consideration for people developing single-player campaigns or … for lack of a better terminology … more traditional multiplayer campaigns, however.
Hm… and yet you said recently
Can you understand why that could be alarming to some of us?
When was this discussed with the community?
I think the philosophy is that changes to the toolset are risky and can cause issues for everyone, while extending the toolchain externally mitigates that risk, and allows other features that the toolset does not support anyway.
The linked external compiler is the official compiler. It is exactly the same code as in the game, just open sourced and provided as a standalone executable. If you look at the changes made to it you’ll see exactly one commit made by someone who is not a member of the dev team; and those changes were licensed in a way that they can be integrated back into the game/toolset as well. This is very much first party, not third party.
The hope behind some of these initiatives was to involve the community some more, because it is not feasible to increase the dev team size. But if portions of the ecosystem can also be worked on by people not under contract, then everyone wins. In theory. Looking at the history, I’m not sure the effort to open source it was worth it.
Yes, I can understand. There is not much to discuss though; we are simply not in a position to make any non-trivial changes to the toolset. The effort needed to make changes to the toolset is orders of magnitude higher than the game. It is an extremely tedious and unpleasant process that no one wants to do for free. In fact, it actually costs a fair bit of money just to get the license necessary to build it. Unless “the community” wants to pool together a few hundred thousand dollars - and yes, that is the right order of magnitude - (EDIT: probably for an external contractor, I don’t think anyone on the current dev team would agree even then) there is nothing to be done here. And if you do manage to magic such funding into existence, it would be much better spent on a new, open source, community maintained toolset instead. There are several such projects underway already.