Just a ghost wrote...
Couldn't you turn this idea around and make multiple set files all referencing the same common batch of tiles?
Say... you want to work with the DOA rural/city stuff with all it's expansions, but you don't need the city tiles for a certain area. And you just need city and fields (and not forest, swamp, and coast) for another area. You could make three SET files. One with everything in it, one without the city tiles, and one without the forest, swamp, and coast stuff.
As far as I remember tiles are referenced by their file name in the SET file, so I don't see why that couldn't work. No programming involved, although you could ask yourself if the task of making the separate SETs is worth the gain...
Right and wrong at the same time.
a .set file is scanned (read by the engine) by number first, then finds the tilename located at that number. So, renumbering doesn't work. You can't build the area with a tile that is physically the same tile name but in a different location (number) in the .set file wihtout crashing the toolset and game. (Note, that you CAN reference the same tile name in more than one location, so it can have a different number and work, BUT, if you are adding new numbers to an already overly large tileset, you are defeating the stated purpose) So, if you make the set smaller, by removing tiles, then they are renumbered to match their new locations in the .set file. Once that occurs, you can't switch back and forth between the two different .set files.
Your idea is the exact thing he asked. The answer remains the same. The game engine can only use a MAXIMUM of 100 .SET files, regardless of the tiles used in those sets. When you consider that NWN by default provides 26 .SET files as part of the main game resources, you are left with 74 expansion sets that you can use. Why would you want to waste those on re-using the same basic tileset over and over again?
Your better option would just be to build with smaller sets to begin with. A huge tileset, with over 1200 tiles, is just a waste. Most especially for a PW. Since by engine constraints, you are better off with 16x16 areas or smaller, having to choose between 2000+ tiles for a maximum paint of 256 of those, you are obviously wasting by a factor of 8-10 already. Granted, in a large tileset, a large number of tiles are not "chosen" by group/feature choice, but are needed to make the various terrains work together (terrains and crosser combinations etc), you still have a large number of groups/features that never, or seldom get used anyway.
Having a very large tileset only serves one real purpose, and that is to reduce the total number of haks required to get the tiles in use. But, since you can combine multiple tilesets into the same .hak file, then it truly serves no real purpose and having a single .set file with 2000+ tiles only slows the engine down. The HAK size doesn't make that much of a difference, as the game resources come in huge .BIF files anyway. The issue occurs when reading the .set to find the tile(s) referenced in the area, then finding the associated .WOK file (server side) to send to the client. This was a special request made by server admins, to prevent folks from having custom haks on their own pc's that would allow folks to walk through walls, doors, etc, by having a custom tlle with it's own locally loaded .wok that would allow such behaviour. It has plusses in that it prevents folks from corrupting a walkable/non-walkable area, but it does require that the server spend a lot of time searching for, then sending, the wok data to the client.
Servers are the ONLY reason to have a separate .WOK file, as a SP mod, doesn't neeed the .wok file, it can actually build the wok on the fly when it loads the tile mdl file. It will read a .WOK if it exists(this will override the one included in the mdl, but downside is that there is no way to compile a wok, so it actually has to load the mdl (complete with compiled built in wok, then read a txt file wok and compile it which is another slowdown), but it can also build it on the fly, EXCEPT in a client/server instance. For that, the server MUST send the wok to the client.
