How close are we to creating new modules?

[Thor the Bassis]

Just wanted to ask if anyone recons that a group mod effort could lead to a decent module editing program or whether its just impossible. Having check out some of the stuff on bioware, Neverwinter nights (nwn uses a game engine which is almost the same - if not exactly the same) has tools for making new modules. I've been having a go by creating a new set of .git .are .ifo .mdl .mdx and .lyt files but the game freezes when i warp there and its trying to load the area. The other problem i have is the models created in 3ds max for a really simple landing pad but i suspect the game doesn't like how its done. This is another reason for getting a decent module editor as max is good for character models but sucks for maps.

 

The other major boundary is how the game sources the module and area file (I think this is simply by filename?) and how these files source the area model files.

 

Clarification: This is a pooling of knowledge on modules so we can see if we can fit together the puzzle that is their construction.

 

So here's what i think is right (not actually got the files infront of me so trying to remember atm will correct anything soon):

 

A module (.mod file) contains a .git file contains info on where everything is in the module. It also contains an .are file containing the area info as to what rooms are in the module (this also sources the room models). And it contains the module.ifo file - cant remember atm.

 

The model files are .mdl the main model file containing model info. .mdx is some kind of extension file to .mdl and is only needed when its in the binary version (so not the acsii version). The wok file dictates where the person can walk in each area. The pwk and dwk i haven't figured out yet.

 

These area models are placed together by the .lyt file (layout file) which has info on where each of these area models have to be placed.

 

Anyone know anything about this?

[southern_fox]

Enormous stride in building custom modules is being made here:

 

http://www.lucasforums.com/showthread.php?t=180922

 

There is a project I'm working with that focuses around creating new modules to resemble areas cut from the game. Many 'cut' modules are actually in existence and limited circulation, culled from the Xbox version files or who knows where. These modules only need certain adjustments/additions to really add them into the game.

 

http://www.lucasforums.com/showthread.php?t=176037&page=3&pp=40

[magnusll]

Your analysis is pretty much spot on, except a few bits of info missing here or there.

 

The main module file is a .rim (or a .mod) containing the .are, .git and .ifo files. These are the three main files which drive everything else; as you noticed, for example, you can find a list of rooms for the module in the .are, and so on. We can currently build these with KotorTool and Kgff; the latter is the current best shot at working with gff files (of which .are, .git and .ifo are variants), while KotorTool will easily let you assemble the separate files into a .mod.

 

Along with these, you'll usually find another .rim used by the module, containing a variable amount of other game resources, like placeables, sounds, dialogs etc; all sourced from the main three files. In a custom-made module these will be included into the one .mod file. We're currently able to modify most, if not all, of these.

 

The .wok files are used for area walkmeshes, and determine where you can walk and where you can't. I recently almost completed cracking the wok format (I still have to figure out one field in the file, but it doesn't seem to affect the walkmesh functionality so I zero it at the moment); the current (0.1) version of KAuroraEditor is able to import/export them, but it has a couple of bugs and a couple of spots where it could be more precise; I corrected those and the next version will be able to produce binary woks which are nearly identical to the ones produced by whatever tool Bioware originally used. So I think we can assume walkmeshes are now done.

 

The one missing format was the lightmap, but while working on improving the current .mdl functionalities (the current state of the art is mdlops) I realized that those are essentially just another texture added to the model. So, if you give me a lightmap file (i.e. a .tga) produced by some 3d rendering program, and a set of UV coordinates in a format which I know and can read, I can include the lightmap in the binary .mdl (and mdx) file. The .mdx stores a variety of additional data related to the nodes (i.e. the objects) you find into his .mdl; most notably, it stores a duplicate of the vertices, the vertex normals, and zero to two set of UV coordinates for the textures you might have in the node.

 

Up until now, it was believed lightmaps were needed for the engine to render the room models; but I noticed several models in the game which do not have any lightmap and I now believe they're not necessary for scratch-built areas; they just make the room look better, if done properly.

 

I'm currently working on the 0.2 version of KAuroraEditor which will have the capabilities to import/export .mdl, .mdx and .wok files; I can even make all three in one go, provided you give me a valid ascii .mdl file containing both the area model and its walkmesh. The .mdl binary importer will feature some improvements over the current mdlops state of the art, and I believe it will be the best shot at an actual module editor. Because right now, when I try to create a scratch-built module, I can have a properly working walkmesh but not a properly working .mdl. Something is missing and I'm trying to fill in the gaps. Note also that mdlops does not have the ability to properly import every type of node into a binary .mdl; the bones used in animations and some info on the saber nodes are still unknown. I've decoded a few additional bits, but not yet enough to write a complete binary importer, unfortunately.

 

Further improvements would then be mainly in adding gff-format file editing capabilities, as these would mean automatic generation of several fields in the three main files. The KAurora version I'm working on also has area-rendering capabilities [the work in progress I'm using on my PC can render the area models correctly applying textures and lightmaps; it automatically goes looking for them into the treenode resource structure and convert tpcs to tgas on the fly before passing them to the Direct3D engine], so it wouldn't be too difficult to add moving capabilities to the camera (right now I only put in a step movement in 25m increments in the six directions, with no rotation possible); this would allow the creator to walk within its model and look at a pretty close approximation of the in-game rendition. From there, with gff editing in, it's trivial to add capabilities like e.g. double clicking to add a placeable in the spot you just clicked.

 

Further formats you forgot to mention:

 

.txi (extra texture info) --> a plain text file containing opengl instructions on what to do with textures; only used for lightmaps in Kotor, and most of them are pretty standard

.vis --> plain text file containing a list of which rooms can be seen from which other rooms. Presumably used to help the rendering engine during the culling process - no sense in working on rooms you can't see. Editing them manually is pretty trivial, as it can be done with notepad. I have no clue how you can automatically compute them, though; it is probably some pretty advanced capability of 3d modeling programs.

 

pwk = placeable walkmeshes, dwk = door walkmeshes; I didn't work on them as KotorTool was already able to produce those. They are essentially little walkmeshes which get superimposed on the area one to avoid the PC walking over objects or doors. IIRC they are a subset of area walkmeshes, so I'll add them in KAurora sooner or later.

 

.pth are path files used with waypoints. Text files, IIRC; not much is known on them. They will have to be further analyzed, but they are hardly essential to the area itself; they're mainly useful for advanced NPC functions.

[stoffe]

.pth are path files used with waypoints. Text files, IIRC; not much is known on them. They will have to be further analyzed, but they are hardly essential to the area itself; they're mainly useful for advanced NPC functions.

 

To my knowledge PTH files are GFF format files that are used for pathfinding, forming a path node network which tells the game where NPCs can move when they are told to move about the area.

 

(I.e. if a script tells an NPC "Go to waypoint A" then the PTH file defines how the NPC can move to reach Waypoint A. Waypoints are just placeholder objects that are stored in the WaypointList in the GIT file and are not related to the PTH file.)

 

I was taking a quick look at them in this thread but didn't reach any conclusion about if my theory was correct or not.

[Thor the Bassis]

The whole thing to me seems possible at the moment apart from the actual modelling of the new area as max is just too broad a program to have the specialist data needed in objects placed in a map - something i've found with its animations. I think the best way to get a map is create the basic geometry in max then export it and then, using a unmade program, add objects paths and other data which is specialised to kotor. The neverwinter nights toolset doesn't work on my max (aparently lots of modders have got it to work but i dunno..) Maybe kotor tools module editor could be modified in a later release to load the info from a set of mod/mdl/mdx etc files so you can put the objects in

 

I'm also gonna have a play with the aurora module editor released for neverwinter nights as this can load mod files so that might sort out the mod file i've made simply by loading and saving.

 

Unfortunately I'm good with computers but i can't code (never really tried learning) so file editing consists of taking an original file and cutting bits out, sticking bits in and renaming stuff. But it usually works ok. So far i've taken many of the files (like the git, ifo and are) and deleted what looks like extra rooms and objects (hoping to make it bare of unnecessary items) renamed the room id to the one for the liv_m99ab_01a so it should make a module with one room but it starts loading (warp liv_m99ab) and then freezes - surpose it means i've made something even though it doesn't work - my gut says its the model.

[magnusll]

To my knowledge PTH files are GFF format files that are used for pathfinding, forming a path node network which tells the game where NPCs can move when they are told to move about the area.

 

(I.e. if a script tells an NPC "Go to waypoint A" then the PTH file defines how the NPC can move to reach Waypoint A. Waypoints are just placeholder objects that are stored in the WaypointList in the GIT file and are not related to the PTH file.)

 

I was taking a quick look at them in this thread but didn't reach any conclusion about if my theory was correct or not.

 

You're right, I misremembered their format. I've taken a look at the m46aa.pth (the now infamous rakatan mind prison). It mostly looks like they store a set of connections and a set of points; each point tells you the index of the first element of the connection array, and how many of them, they use. So basically you have a list of points, and each point is connected to X other points (where X = the value of "Conections") by way of paths, starting with the one at index = ""First_Conection". In each path you simply find the index of the destination point. Pretty simple really, shouldn't be too difficult to automate pathbuilding too, by way of successive clicks in the area model. Now if only the rest of the undiscovered .mdl info was so easy....