So I want to start to gradually integrate hackpacks into my PW, meaning that I’ll add them over time.
Should I:
Compile them into one big hackpak every time I add a hak file?
Compile them into several big hakpacks every X GB’s?
Simply add them one by one (even if it’s 227 different hak files)
Is it important to have a naming convention or should I keep the same name as it had when I downloaded it from the vault?
Builders frequently copy other’s hakpaks and integrate them in own companions to their module(s). Naming convention should therefore follow your module. It’s easier for players to manage 5 haks with similar names (so they sort next to each other on the drive) than 50 haks with different names. It also allows you to avoid (perhaps fatal) filename clashes.
The utmost importance is that you credit everybody you’re borrowing files from, at least in your main readme. It might also be nice to keep original hak’s readmes in your haks. Or even txt tables connecting original hak paks with files from them (though this might be an overkill).
You should think of yourself first - the builder. Assuming you’ll be modifying the project a few times (or a lot, it depends), you want a streamlined development with least hassle, i.e. minimum hak repacking / reuploading.
This is why some authors split their content thematically: 2DAs & scripting libraries in one hak, 2d art in second hak, phenos in third hak, tilesets in fourth, sfx / music in fifth, and so on. If the changes between versions are small, you can put new / modified files in a “patch” / “top” hak above all the others and integrate it into the mainstream only with a major release. Naturally, this approach makes most sense when you already have most of your hak content prepared.
No player will ever download 227 haks for one module.
Agreed.
It’s a matter of finding the right balance. Broadly speaking, putting everything into a module-specific hak is convenient for both builders and players.
However, there is a limit of 16K files per hak, so very large PWs may need more than one.
Also, most players already have CEP 2 and the more popular custom tilesets, so you can save a lot of time and energy by using the original haks in those cases. You’ll find that a great deal of the custom content you admire is already in CEP 2.
You hit a limit of the number of haks in a module at like 54. If I recall the failure mode is that beyond that they just silently get ignored which can lead to all sorts of issues. It may just be the client. At least on Linux with 1.69. I don’t know if it was fixed in EE or different on windows.
Generally you are adding a hak that is currently being developed or by an active member it is best to add that hak stand alone. Tilesets often.
Many people do a module specific top hak, an initially empty patch hak, some custom haks , then any common ones, you can usually put tilesets at the bottom as long as you make sure to have any merged 2das in your top hak.
You will be updating your tophak often if you are adding to the haks but if you keep to mostly the 2das it will be small and easy to download.
If you are keeping a hak the same as what’s on the vault then you should name it the same, and ideally provide a pointer to that download page. I know some PW people prefer to provide it all in one download but people still do look at their download counts. If allowed and you are pulling it into a hak of yours then of course you will name it something module specific. You don’t want to be making “new” versions of other people’s unchanged work by different names.
The patch hak allows you to provide a temporary fix or update in a small download. You can then later move such fixes into the bigger haks when you refresh the whole pile.
my 2 cps anyway…
Compiled scripts can go in haks but I’d advise against it. It’s a real pain if you ever have to change something. Script source is pretty useless in a hak (unless I suppose when using the patch.ini method?).
This can make sense when you’re using a scripting libraries you don’t plan to modify (or there will be trouble). Frees up the list in toolset. Not sure about loading time change, though.
EDIT BELOW THIS LINE
Us script librarians often have little luxury in this matter (since our work is integrated directly into the modules), so dear reader don’t forget to test our demo modules when possible 
Fair enough. But still since they are likely not bug free (nothing ever is) you will still need to modify them at some point.
I find it much easier to use an out-of-box compiler, and so prefer all my scripts, except the game provided ones, to be in one directory so the compiler can find them. If you are doing it all in the toolset then that location issue would not matter.
Personally I like to move all the blueprints to a hak once they are pretty much finalized to clear up space. I can edit them outside the toolset when they need to be fixed up. I end up with areas and scripts in the module mostly.
Have you ever tried integrating nwsnsscomp with an external IDE? Think: edit 
compile inject into module test launch workflow?
What sucks the most is (correct me if I’m wrong) that when you edit a script that was pulled from a hak file and save it under the same name in module, the game will insist on loading the one from hak file even if you try to edit the one from module…
I often didn’t have the game handy when I was doing a lot of scripting. I usually edit compile, edit compile, then load into a subsystem module to test at some later point. I use sublime text for nwn 'cause it’s pretty. But I just use the shell for compiling and such. I never got into full IDEs. I had to quit using eclipse when it kept doing what it thought I wanted, which was not what I wanted, back when I was doing java professionally. That’s over thankfully. Usually I just use a text editor and a shell.
Yes, the script in the hak overrides what’s in the module. That’s part of why I don’t do that 
@Val Are you playing NWN1 or NWN:EE. Also, is it a module for upload to the vault, or is it to be played like a PW?
For the record: NWN:EE , PW (is there a way to put a signature in this forum?)
“No player will ever download 227 haks for one module.”
Well that’s why you have installers
But I like NWShacker’s reply best; to divide the haks based on category. I assume compiling haks is easy.
Theoretical question: say I have 4 tilesets, I make them to one hakpack. Easy, right? But let’s say over the coming months I add 50 more tilesets and now I want to remove one of the first tilesets I added. Will it cause an error?
PS. CEP2 is nice but I won’t use like 98% of it, so I prefer to download what I need instead.
SO! NWSync is your friend. Players don’t have to download ANY haks. They’ll download the individual assets you put in your NWSync files. That leaves you and your developers to organize your HAKs in the way that makes the most sense for you (most likely NWShackers method).
If you haven’t looked into NWSync, I can explain more (as I understand it) as we are currently using it and it’s great.
I’d love to hear an explanation. But, I haven’t compiled any haks yet, so NWSync seems like an advanced material, right? I should probably go ahead and see how I compile haks first.
Me and “my developers”… hah! I’m doing everything by myself! 
Well, at some point you might bring somebody in to help you. And at that point, you can share HAKs with them.
NWSync takes all the files from your HAKs (all the individual assets that you compile into them) and puts them into SQL datafiles. It’s pretty awesome. The user downloads all the files, then when you make changes and updates, they only have to download the changes/updates. It doesn’t matter how big they get (as far as I know).
Now I’m on the phone with my brother, so my attention is too divided, so if that doesn’t explain I’ll explain more later
To avoid problems, I suggest the usual workflow:
The last step can be automated since nwhak accepts command line parameters:
nwhak my_file.hak /path/to/folder/with/files/to/import
Just make a shell script to run this.
EDIT BELOW THIS LINE
Apologies, I forgot to answer your question. Deletion from hak file won’t cause any trouble if the resource being removed is unused (by the model or other resources).
Okay, so I should be safe Thank you