UTI files in HAK

[Snowmane]

So I am trying my hand at modding and I have run into an issue. I extracted some UTI files from a test module and put them into a HAK (using NWNPacker). I then tried to use that HAK in another module, but I do not see the items in the toolset. I took the same set of UTI files and put them into an ERF and imported them into that same module with no problem.

Since you fellows have been involved in modding for a long, long time, I hoped you might be able to give me some insight. Is there some trick to adding items via a HAK or is that simply not doable? I suppose I can change my workflow to import the item from the ERF, but I was hoping to keep things a little more modular by keeping various blueprints in HAKs, since they are going to be used in multiple modules. Maybe the trick is to make them into a campaign resource?

Anyway, if someone could give me some pointers or give me a link, I would greatly appreciate it.

[Kirin]

Blueprints do not work in haks (at least for the toolset), so put them in your module directory.

[Saulus]

Or make a campaign, put them in the campaign directory under the NWN2 folder (your campaign name). And just associate your different mods you work on with that campaign via the toolset.

If you aren't sure how to setup/configure a campaign its fairly easy, just press F1 while in the toolset for the documentation which does a pretty good job of explaining it.

[Snowmane]

Well, looking into campaigns, they won't do what I want. My intention is to create a sort of instanced dungeon setup where one module is the "Lobby" where you form parties, then use NWNX to launch new server instances that load the "Dungeon" modules and transfer the players from the lobby server to the dungeon server when it is up and ready. I am also toying around with the idea of having a separate server instance to run an overland map of the world and each city is then it's own lobby.

Anyway, since the toolset does not handle updating instances from blueprints very well, I think I will use the following practices/workflow.

1. Give all creatures gear in their OnSpawn scripts. This at least will guarantee if an items blueprint changes, then the item will be updated. I can automate this by writing a plugin to the toolset that finds creature instances, iterates over their gear and generates a script to create those objects in onSpawn. (I've already written one plugin, so I am fairly confident I can do this quickly)

2. Keep all items in a dev module. When items are modified, export the items from the module to an ERF. Then reimport the ERF into all the modules, overwriting the existing module blueprints.

3. OnClientEnter, check the players gear and if any of the blueprints have changed, then destroy and recreate their gear from the new blueprints, preserving any additional item properties they may have added.

Looks like I am going to be busy

[Saulus]

I would say so, we don't even use server instancing yet. There's really no point unless you've hit the module size cap (which we haven't even hit yet). You're essentially just making a ton of work and splitting up players from playing/chatting in the same server for really no reason.

[Kirin]

Saulus is absolutely correct, there is no reason to split a server into multiple modules until you get really, really large (I believe the rule of thumb was about a 1GB server-side module?)

Keep in mind that is the module by itself, not counting haks, or the walkmesh (TRX) files which are handled client-side.

The only active server I know of that had a need to split to multiple servers was ALFA, and they have an enormous amount of areas built over many years.

[GodBeastX]

Area instancing works fine. You just can't delete the area instance without memory leaks AFAIK. So just instance and reuse instances of areas.