Search the Community

File Name: MDLOps File Submitter: Fair Strides File Submitted: 14 Jan 2016 File Category: Modding Tools ----------------------------------------------------------------- -->-- ----------------------------------------------------------------- ------------------------- -->-- ------------------------- ----------------- -->-- ----------------- This script is released under the GPL, see the included GPL.txt. ---------------- -->-- ---------------- MUCH MUCH MUCH thanks to Torlack for his NWN MDL info! Without his info this script could not exist! Thanks to my testers: T7nowhere Svosh Seprithro ChAiNz.2da Thanks to all at Holowan Laboratories for your input and support file browser dialog added by tk102 AABB, animations, lights and emitters, and speed-up by JDNoa Calculations of vertex and face normals by VP and Fair Strides 1.0 version by ndix UR, thanks to bead-v for inspiring many of the added features, figuring out a number of critical format algorithms, and sharing the journey ----------------------- -->-- ----------------------- This is a Perl script for converting Star Wars Knights of the Old Republic (kotor 1 for short) AND Star Wars Knights of the Old Republic, The Sith Lords (kotor 2 for short) binary models to ascii and back again. Binary models are converted to an ascii format compatible with NeverWinter Nights. It can also do some other operations on models, like renaming textures and replacing meshes. ------------------ -->-- ------------------ -Automatic detection of binary model version -Automatic detection of model type -node types supported: -trimesh -danglymesh -lightsaber -skin -emitter -light -reference -dummy -model properties supported: -diffuse -ambient -shadow -render -alpha -self illumination -many, many more -supports compile/decompile pwk/dwk/wok walkmesh files along with their associated models -when reading in a binary model a text file is created that lists all the textures the model uses. -replacer function lets you replace 1 tri-mesh in a binary model with another tri-mesh from an ascii model -renamer function lets you rename textures in a binary model read the tutorials "KotOR_Tutorial.txt" and "Quick_tutorial.txt" for an explanation of how to get your models into kotor ---------------------------- -->-- ---------------------------- ------------------- -->-- ------------------- ------------------------------------------- -->-- ------------------------------------------- -------------------------------------- -->-- -------------------------------------- ---------------------------------- -->-- ---------------------------------- This script may only be hosted from sites that do not claim ownership of files they host. In other words, any site that claims "All files submitted to this site become property of the site owner" can not host this script. You are free to host this script from your website as long as the distribution contains only the files listed below. You are free to submit this script to any public download site as long as the distribution contains all the files listed below. GPL.txt icon.bmp KotOR Tutorial.txt mdlops.exe mdlops.pl MDLOpsM.pm Quick_tutorial.txt readme_mdlops_1-0.txt replacer_tutorial.txt I also ask that if you do host or submit this script to a site send me an e-mail to let me know. My e-mail address is at the top of this file. Click here to download this file

Greetings, fellow Jedi! May the Force be with you. Along with the compiling-decompiling model attempt I have done recently, some discoveries were found regarding the end-result of using both MDLedit v1.0.3 and MDLOps v1.0.0. First, this comparison purpose is to give the potential user of both tools a preview of the compiled model using each of the tools mentioned. This also had no intention to show which tools are best and which are less; it's simply to share the discoveries been found. Here's a screenshot for details: Left image is TSL's n_quarren [Quarren's F model] model compiled using MDLedit v1.0.3 with tangentspace enabled by not ticking the bumpmap flag, but instead changing its value inside the ASCII file from 0 to 1 using a text editor. Right image is TSL's n_quarren [Quarren's F model] model compiled using MDLOps v1.0.0 with tangentspace enabled by changing its value inside the ASCII file from 0 to 1 using a text editor. As we can see there is a difference in the head part; which MDLOps version produce a noticeable line whilst MDLedit version isn't. This occurrence already emerging several times on my end; such with compiled TSL's n_commf model. I hope this discovery kind of helps with any future modding attempt, and gave an insight of what will and what won't regarding the implementation of the aforementioned method. Edit: Be advised that they had nothing to do with normal maps. It's a smoothing error, as informed by DarthParametric. The normal maps activation is just part of the compiling process.

First off, here's what I'm looking at. On your right, the stock star map and on your left, what I see when I add my modded files. Here's my process: Use KotOR Tools to grab plc_starmap.mdl and plc_starmap.mdx. Select plc_starmap.mdl in MDLOps 1.0.0, Extract Animations and Compute smoothgroup numbers is checked. Click Read and write model. It does its thing. Import plc_starmap-ascii.mdl in Blender, via KotORBlender. UV map some flarksnorzen, arms, legs, etc. Export edited file as plc_starmap_v2.mdl. Load plc_starmap_v2.mdl into MDLOps and hit Read and write model. I know have two new files: plc_starmap_v2-k1-bin.mdl and plc_starmap_v2-k1-bin.mdx. I place those in my Override folder and rename them to plc_starmap.mdl and plc_starmap.mdx. Open KotOR, open save just prior to entering room. Enter room, watch what happens. Animations all seem to be working fine, it's just that nearly ALL of the textures are not loading. Say "harrumph". Ask DS for help.

A lot of us are familiar with how MDLOPS functioned and of its limitations and workarounds. However, with the new update that just arrived this year, along with the inclusion of MDLEdit, all of the old tutorials and methods are likely outdated. So, I was wondering if the team behind these new tools had a guide (Like the one that comes packaged with TSPatcher) or was planning to create some tutorials on what the model modding process should look like.

Hi, Mdlops seems to have a hard time compiling files which are too heavy. So, if I try to compile a .mdl heavier than say 1500 vertices, it throws an "Out of memory" error or just crashes. I tested it on some computers with good memory and CPU and the result is the same. Is it normal? And are there good alternatives to use?

This thread is for discussing and retaining technical details of the Kotor MDL/MDX binary formats, with the goal of cracking the meaning of some of the remaining unknowns. In implementing a substantially improved MDLOps, I have been extensively leaning on the technical work of cchargin (original author of MDLOps) and MagnusII (original author of KAurora?), who are serious heroes. State of Knowledge and Tools: Many people point to the kotor/mdl_info document of cchargin as a source of reference. We need to produce something better than this. It has certain information which is completely vital that I have found nowhere else, but we really need to produce a redone version, maybe distributed as a PDF modding resource or something, that incorporates MagnusII's info from the KAurora source. All I was able to find (thanks DarthSapiens for code post in a forum article on bump mapping) of the KAurora source so far is the trimesh header structure from the bump mapping thread, and it is much more nuanced and correct than the original cchargin info. Differentiation between signed and unsigned can actually matter, especially in the byte & short types. My MDLOps is using the improved data layout (for the mesh header) and accuracy has gone up. Background, relation to NWN: Currently, the way I understand modeling to work is like this: Kotor modelers basically rely on tools developed for working with NWN. NWN modelers have life fairly easy, because they can actually work with text/ascii models and the game will compile them on the fly to its own binary format. So, in essence, Kotor models get decompiled/recompiled in order to be compatible with NWN text-based modeling tools. There are a couple important/interesting points to note here. 1) There is no 'official' text format for Kotor models. Such a thing never existed, and has only been agreed upon by the modding community. 2) The binary formats and capabilities of NWN and Kotor are substantially different. They are far from directly compatible. What this also means is that a lot of things the NWN tools put into ascii models just don't exist in Kotor, and a lot of things that Kotor can do are totally unknown to NWN toolsets. Kotor Model Unknowns: Big Caveat: I won't know the full extent of what is still unknown until I can access KAurora's source, if someone can get me that, this list will improve a lot. I have some suspicions though, based on extensive reading online. I am starting the list with the question marks that I can tell remain in MagnusII's work. I want to expand it to an exhaustive list once I actually get a handle on the full scope from KAurora... Small Caveat: It is important to realize that some of these 'unknown's may turn out to be just useless padding. Padding is regularly used in binary formats for various reasons. (Animation) Controller 240 Common Mesh header unknowns: an array of 3 signed integers [ -1, -1, 0 ], an unknown 'Rotation' (4 floats?), an unknown uint16 (probably a flag of some kind), an unknown UInt32 = 0, and 2 unknown UInt32's specific to Kotor2:TSL. Unknown Struct in MDX: there is an undeciphered structure in the MDX files pointed to in the common mesh header. TO BE CONTINUED... Methodology: I have been developing a number of personal use dev tools for following in the footsteps of cchargin and MagnusII. One of the main necessities for reverse-engineering this stuff is being able to easily compare and analyze across the entire corpus of models present in both games. To this end, I have made a couple interesting things that I am happy to use to generate reports for people in the process of tracking down the meaning of some of these things... My core goal is to make it so that decompiling with MDLOps and recompiling will produce byte-for-byte identical results, or as close as reasonably possible. To this end, I have a test script that operates on all models, decompiling them, recompiling them, and then doing a byte-wise comparison of the resulting MDL and MDX files, measuring the error/difference (in actual bytes as well as as a ratio against the total bytes). So, when I casually said earlier that 'accuracy is up' in my MDLOps, it's actually verifiably true. Of course, that being said ... I have only *just* fixed MDLOps enough to be able to decompile/recompile every model without going into infinite recursion or loops on a few problem children, so I don't have a *lot* of accuracy data yet. In case you're wondering, the numbers are approximate and the verification takes hours. The best I could come up with for purely accurate verification would take weeks to run, the approximation is fine though because it is mainly being compared with itself as a means of knowing whether I'm moving in the right direction or not. I can use these tools on small numbers of models basically instantaneously, which I also do. I have another tool that generates some statistics and compares (currently only) 2 model features. This is in my effort to understand Animation Controller 240. For instance, I can tell you that whatever 240 does, everywhere it appears as an animation controller, birthrate is also being animated. There is a comment in MDLOps.pm mentioning that the author thought it might be life expectancy, but now thinks lifeExp is 120. Whatever it is, it is related. I can also produce a text file with the controller 240 values (and their key animation values) for every model in the game, with comparison to the birthrate numbers. (Produce as in, I have this file already). So, my medium term agenda here is to produce a 'debug mode' for MDLOps. What it is going to do is put *all* of the non-derived values into your ascii decompiled files, and then make sure that everything it puts into ascii files gets back into (debug mode) compiled files. This will make it a lot easier I think for people to certain modifications on large numbers of models, making it more likely that they can maybe figure out what these things are doing. Up to now I've just been making MDLOps able to handle all the things that are actually known (haslightmap aka lightmapping, shininess, sparkle). A slight time-sink issue is that I am also modifying NWN toolset components to not mess up all the things I am adding, and that is more of a challenge. So yeah, I hope that we can engage in a productive technically focused discussion here and maybe eventually shed some new light on aspects of the model format that have gone dark in recent years. I know some of you guys know a *lot* on this topic with your hex editing mad(awesome)ness, and also I know that some of you have KAurora source access and I hope that you'll pass that along via PM so I can flesh this out (I'm not about posting it ... or even working on it (probably), but I would love to save the knowledge represented therein).