ndix UR

Interesting. Can I ask what level you are seeing this in? Is it something testable on my end? I can upload another simplified model without the extra geometry (I forget if I also made it bump mappable, but if so I will take that out too) to test also. Probably tomorrow sometime.

Here's a glowing eyes version of the model for anyone to use as they see fit. It can also be bump-mapped, if you're so inclined. I did one for mine. C_ForDrd-model-only.7z In case anyone looks at it in detail, you may notice that there's a new head2_g mesh in addition to the new eyes_g mesh. If you've done a fair bit of modeling, you may have seen this weird thing where some part of a model's shadow seems to extend to infinity (often towards the center of the screen)... I started to get that when I made the eyes mesh a child of the head_g mesh (necessary to get eyes_g tracking w/ the head in all the animations). The only solution I could come up with was to make a full copy of head_g (head2_g) and make it also a child of head_g (position 0,0,0). Then I made head_g render 1 shadow 0, while making head2_g render 0 shadow 1. That worked. Yay. I actually used the vanilla head_g mesh for head2_g, instead of the 'eyeless' head_g mesh from this model. I tried a number of other things that didn't help at all, including leaving the head_g mesh pure vanilla. The problem definitely came from adding a rendered child to head_g. Maybe someone will figure out what makes that happen sometime... I assume we will one day be able to fix the compiler to avoid that workaround, but it works for now (I think). Actually, while I'm here, feel free to use my proto-height-map for anything you want as well. I've done about 20 normal maps for this model (none of which I'm that happy with), generally using this one as an input: https://imgur.com/ncIDAsf

I could only find it using archive.org and knowledge of the specific filename. I hope it works. Good luck. https://web.archive.org/web/20150320131234/http://starwarsknights.com/mtools/whereami206.zip

C_ForDrd is mostly trimesh but contains 3 skin nodes. C_DrdProt is just trimesh. (both contain dummy nodes also, technically)

Here are some screens of a 1K upscale effort: http://imgur.com/a/dAkAe I had been planning to work on a new vanilla-upscale pack for all the droid textures, starting with the protocol droids (because I throw up in my mouth a little bit every time I have to talk to one), but since this request came in I figured I'd start there. It also gave me an excuse to develop/use a new (to me) technique, which is using 3d modeling software to bake an ambient occlusion map (in my case the software is blender), and using that map as a shading layer for the diffuse texture (since KotOR doesn't actually have direct AO map support). It works incredibly well on droid textures. On skinned models, it is less helpful, but can still add a little bit of realism (if you use a high opacity on it it makes the model look dirty/wrong, but a little bit goes a long way). At least in Blender, with KotOR models, there's a bit of art even to getting the maps baked properly, so I hope to write a tutorial out before too long ... Anyway, hopefully people like it, let me know! I'll start a WIP thread if I start to make real progress on other droids.

I've put together a small package of newly-bump-mappable models for people to play around with. It also includes textures and TXI's that should all just work when dropped in Override. @DP thanks! That is quite a helpful little test package you've put together. I've included a normal-mappable recompiled version of the pyramid model in this test package. bump-testing2.7z Package contents: DP Test Pyramid recompiled (download package in above post, install, then replace model & textures w/ this package's contents) Darth Sion (n_darthsion) Gammorean Cleaver (w_waraxe_003) I went through some excruciating difficulty to get a rig set up that lets me at least see the bump-mapping effect, so I can confirm that it should be working for at least the axe... Bump mapped weapons seem to work, and seem to have a lot of potential... I was able to test the 'blue/usual' 8-bit color TGA normal maps vs. the 'red/swizzled' 8-bit color TGA normal maps, and it seems to me like the 'red/swizzled' is definitely what the game is looking for (just visual inspection, no glintercept confirmation or anything). That said, I haven't figured out a workflow to produce color normal maps that work as well as grayscale ones yet. My color normal maps come out with artifacting around the bump features that don't happen when I use grayscale. If any of the models seem busted, or people notice any visual discontinuities in them related to bump mapping, feel free to pm me or post screens or whatever. Sorry for not posting screenshots, but my bump map test machine is all kinds of terrible.

Not exactly progress. Basically each time I work on it I am figuring out more and more things that don't work. I have not been able to change the hotspot behavior whatsoever yet. That said, I have probably only put in 3-5 days of testing this since my initial successes, because I've been busy with a few other modding priorities. Everytime I go into K1 though ... it really irks me. I certainly am still planning to go back to this, probably in 2-3 weeks I will be trying to get more serious about it. I'm even wondering if maybe it *does* have something to do with the bizarre gui mdl files that xander referred to above (similar to a walkmesh kind of situation). My main issue with that theory is that the main menu stuff works fine when scaled up ... Thanks for the interest, maybe we'll get lucky and someone else will figure it out, otherwise I'll be sure to post if I'm able to achieve this.

Hey all, first off I just want to say how inspiring and important everything in this thread has been. Big shout out to DarthSapiens and OldTimeRadio for their work on this in the worlds of KotOR and NWN. Also to DarthParametric and Dastardly, whose posts I wish I would have read roughly one day sooner than I did Also sorry about this seriously massive wall of text. TLDR I figured out the numbers, I'm working on this actively, still a *couple* kinks causing K2 to crash on certain newly-bump-mapped models, K1 yet to see any success, going to take a bit of further study it seems. Some numbers are still coming out pretty far from vanilla, but how much they are affecting things visually is TBD, I have been recompiling vanillas that originally did and didn't have bumpmapping without seeing any crashing for about a day now (6 models "tested", half originally non-bumpmapped). The Good I can tell you what the 9-float vertex Tangent Space is and the algorithm to calculate the 3 vectors per vertex in 95+% of cases. As DarthParametric theorized, they are the 3 components of a Tangent Space, to figure this out I used the info here: http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-13-normal-mapping/ Because I used that info, I call the 'binormal' vector a 'bitangent', but either way, let's just call them T, B, and N for Tangent, Bitangent, and Normal (all are 3-space vectors). So, the 9 floats in order are [ Bx By Bz Tx Ty Tz Nx Ny Nz ]. These are vertex vectors, distinct from face vectors, with the distinction being that vertex vectors are 'averaged' with all of their adjacent face vectors. I'm not going to go into details that are covered in the opengl-tutorial article, and mdlops already contains the vertex normal calculations, but I do want to write out the oddities of calculating the vertex BT vectors etc. In many ways it works just like calculating the vertex normals. Here is the abbreviated algorithm: Put it into BTN order, and there's your data. For skinned models like c_malbeast in k2, this produces a high number of nearly exact matches compared with the vanilla numbers. I tried a number of other things that don't seem to be right (although I might try some of them again now that I have it working), such as orthogonalizing, deriving B as TxN, not normalizing everywhere, and of course making the system right handed. It all kind of makes sense in hind-sight but damned if it wasn't tricky to figure out. Fun note: comparing the skinned results to the trimesh results, there seems to be a crease angle test that the vanilla compiler did, but only for non-skin. The Bad All of the droid models I have attempted this on have at least one mesh that has overlapping texture vertices in a face, which makes the r factor in the tutorial's vector calculations into a divide by zero. I have not yet figured out if/what dummy data to use in this case that will produce models that don't crash the game on load. Luckily this is true of vanilla bump-mapped models such as g0t0. But... there is definitely some kind of crease angle calculation that comes into play in a big way on droid models (sigh ... it's def not smooth group data), meaning that the vanilla normals are coming out different, and the vanilla BT vectors ... makes it tougher to track this down. This is what I am kind of side-tracked with at the moment. Also, all of my testing has been in K2, the one test I attempted in K1 crashed the game on load. The Ugly The bump-mapping doesn't render (none of it, no vanilla, none of people's experiments etc.) when the game is running in wine on a mac, so I can't see whether it looks right at all. The only ways I can tell that "it's working" are: the game doesn't crash (anymore) when my model loads the game doesn't give me the error message about invalid bumpmap (anymore) since I know from redrob's g0t0 bump research on LF that low alpha on the main texture is necessary, I have done that on my test textures, and the meshes that have working tangent space numbers turn 'solid' or 'alpha 1.0' while the non tangent space meshes remain (mostly) transparent. if the models don't have their tangent space numbers on a node, the node also loses its bumpyshinytexture, which I *can* see in k2 (but not k1). So yeah, I don't have the software to actually see normal maps working, I can just sort of tell. sort of. Crap. After trying every every other option ... I just realized I might have to try the steam version. ALSO - Color Normal Maps as TGAs in Override I didn't see it here, which could be a 'me' problem, but I just read this last night on OldTimeRadio's NWN thread (on forums.bioware, not here) and "tested" (see The Ugly above) it today. It seems like we can use custom (8-bit) color normal maps in KotOR! I don't know if people are largely aware of this or not, but the impression I was left with from this thread was that we were stuck with grayscale height maps rather than actual color normal maps. In case you're wondering why that's a big deal and don't want to look it up, color normal maps encode a full 3-dimensional vector at each pixel, whereas grayscale height/bump maps basically just alter the apparent height of a surface. The visual differences can be kind of subtle, definitely, but when done well and in the right gfx engine, a normal map is a much more powerful tool. For anyone that wants to try this extra easily and has (kind of old but hopefully basically the same) photoshop, open a full color normal map of whatever format. Go to Image > Mode > Indexed Color. I like Local (Adaptive) for Palette, 256 color, Forced None, Dither None (when possible ... if it is creating weird banding you will have to dither) for settings. Save it as a TGA, pop it in your override (rename it to an existing bump map texture ... such as twilek_m01b like the one used in this thread), go look at a twilek (or whatever you chose to replace). The thing I have no idea about is whether you need to reverse the blue & red channels (swizzle it) in these for them to work correctly (as they appear when exported by Kotor Tool). I found this technique to do the color switch in photoshop before I realized that none of it was working for me for a lot of reasons: http://i.imgur.com/nNHu7yf.jpg Testing? I am thinking I could post a vanilla-recompiled model or two for people that can see the bumps to test with. Suggestions? Something that's going to show the normal mapping in a potentially good way and is known to compile easily would be ideal. I have used DarthParametric's Test Pyramid a little bit to calculate on, but I'm too noob (and busy) to attempt to get it in-game. FYI, the values he posted above are definitely for the non accumulated face vectors. Here are the numbers I get from my calculations for it (for anyone else trying to implement the calculations): Anyway ... unless the normal mapping on the new models turn out to look all messed up ... newly normal-mapped models (and compiler support) might be coming sooner rather than later.

Not quite. 128 is a tangent, bitangent (or binormal), and normal vector in a single 'field' (the vertex normals here vary slightly from the normals defined by bit 32, but are almost exactly the same values). The vectors are I think definitely averaged with surrounding faces but I haven't yet figured out if they are weighted by area and or angle, and what the exact orientation of the tangent should be (all I can say right now is that it might be different from what 'the standard' (of today) says it should be). I have been using your test pyramid I just started making major progress on it a couple days ago, so not sure yet on some aspects. Edit: Yeah, I meant to define that term 'Tangent Space' explicitly but forgot because it was kinda late. (I was hanging out w/ a mathematician on Tuesday nite. This stuff is all way below him, but he did school me a little bit). Mathematically speaking, 3 vectors define a space. A tangent space in particular is the space defined by a tangent, bitangent, and normal vector. So yeah, the '128 bit' data item is a tangent 'space', meaning it is these three vectors.

Still haven't had time to write tables, so, another teaser, MDX data! I have some knowledge/theories about the MDX data layout that I would like to relay. First off, let's talk about the MDXDataBitmap (this is what MagnusII calls it). It is the UInt32 at offset 256 in the common mesh header, directly following the Int32 known as MDXDataSize. The MDXDataBitmap tells you what common mesh elements are contained in an MDX row. What I mean by saying common mesh there, is that the Bitmap does not indicate subtype MDX row content, such as the bone map for skin nodes. Why is that interesting? Because the MDXDataSize (length of a single 'row' of MDX data) includes all the vertex-related data in its size number, including sub-type stuff such as bone map. The MDL contains all the information you need to know what is in the MDX rows for a specific node, and the exact offsets at which you can find said data. For those with limited understanding of programming etc, the MDXDataBitmap uses each bit across a 4 byte UInt32 (aka, 32 bits) to indicate that a particular thing is present (1) or not present (0). Each of the bits represents a power of 2, so, the first is 1, then 2, 4, 8, 16, 32, ... you can add or boolean OR each bit's value together to get a full value, so, for example, 39 = bits 1,2,4, and 32. Without further ado, here is what I currently know(ish) about the MDXDataBitmap: Value/Bit Meaning 1 Vertex coordinates 2 Texture0 coordinates ('tverts' in ascii models) 4 Texture1 coordinates ('tverts1') 8 Texture2 coordinates? (no vanilla models use either of these) 16 Texture3 coordinates? (no vanilla models use either of these) 32 Vertex Normals 64 ??? 128 Tangent Space 256 ??? 512 ??? 1024 ??? Why 11 values? This is the number of offsets that are stored immediately following the MDXDataBitmap in the common mesh header structure. In semi-typical Bioware fashion, the offsets are almost in the order the fields appear in the bitmap. So, now I am going to reveal a theory that just occurred to me while writing this ... I have learned a great deal about that coveted '128 Tangent Space' (I say coveted because this is the structure required to support normal/bump mapping) ... and ... I think there is a pretty good chance that 256, 512, and 1024 could all be Tangent Spaces, one per texture (calculating Tangent Spaces uses texture UV coordinates for orientation of the tangent vector). That would mean we might actually be able to normal/bump map 4 separate layered textures individually! (stress on the might at this point, 100% untested theory) The vanilla models only use 2 textures max and as far as I know the second one is only used for lightmaps, so there's no data anywhere in vanilla-land to support my claim. Although the lack of those extra 3 texture slots ever being used for bump mapped textures would explain why their corresponding MDX row offsets are never used... Anyway, back to the known universe. In the MDL common mesh header, after MDXDataBitmap are the 11 offsets I mentioned earlier, these are a number of bytes into an MDX row where you find each particular thing. Offset Meaning 260 Vertex XYZ coordinates (12 bytes, 3 floats) 264 Vertex Normal (vector in 3-space) (12 bytes, 3 floats) 268 ??? Unknown bit 64 ??? (Unused, Unknown) 272 Texture0 UV coordinates (8 bytes, 2 floats) 276 Texture1 UV coordinates (8 bytes, 2 floats) 280 Texture2 UV coordinates (8 bytes, 2 floats) 284 Texture3 UV coordinates (8 bytes, 2 floats) 288 Tangent Space vectors for Texture 0 (3 vectors in 3-space (defining a 'space')) (36 bytes, 9 floats) 292 ???Tangent Space vectors for Texture 1 (3 vectors in 3-space (defining a 'space')) (36 bytes, 9 floats) 296 ???Tangent Space vectors for Texture 2 (3 vectors in 3-space (defining a 'space')) (36 bytes, 9 floats) 300 ???Tangent Space vectors for Texture 3 (3 vectors in 3-space (defining a 'space')) (36 bytes, 9 floats) If my offsets are off by 4 here or anything like that, I apologize. The tables I have drawn up for myself use mdlops unpacked array indices, not byte offsets, so I am roughly translating on the fly here. The order of things is all accurate (to the best of my knowledge). Some of you might be asking ... but where do I find the bone map in my MDX row?! Glad you asked. Offset 12 in the skin mesh header leads to the bone weights and offset 16 leads to the bone indices. MDLOps was programmed to just assume it was the last 8 floats if you had a skin mesh. That 'works', but this is about information, not functionality. The additional tangent spaces hypothesis could actually be tested by an intrepid model hex editor (MDL file changes only). The idea would be, start with a bump-mapped model like goto or c_malbeast, find a mesh node w/ the bump-mapped texture on it, move texture0 name to texture1 slot (move it by +32 bytes), then change the MDXDataBitmap (add 128 to it (changing 128 to 256 basically), also add 2 to it (changing '2' to '4', moving Texture0 coordinates to Texture1 coordinates), then you have to move the -1 at offset 276 to offset 272 and put the value at 272 (often the number 24) at offset 276 (swapping Texture0 and Texture1 MDX offsets), then you would move the -1 at 292 to 288 and the offset at 288 to 292 (swap TangentSpace0 into TangentSpace1). Something like that. Success would basically be 'it doesn't look different'. I know that is a really quick and maybe incomplete description of the experiment, so, you know, hex-heroes only As usual if anyone has contradictory information, or is in a position to confirm or deny my findings, please correct, augment, etc. anything I might have said, thanks! I won't be around again until mid next week, so don't expect any quick responses Also, for anyone that is a fan of the cruel and twisted nature of our universe, read this:

Congrats and good luck with the big adventure! Not sure what we're going to do w/o your weekly avatar updates Your droid request came in just as I was ramping up on a protocol droid reskin. I am hoping to do all the droids eventually so maybe I'll switch gears and have a housewarming present for you by the time you're set up again.

Yeah that was my bad ... it basically came down to me misreading a forum that had less-obvious 'quote' styling, so when everyone was congratulating and thanking FairStrides it looked like they were all claiming to have taken over the project ... and I just picked wrong (and tried to use my memory instead of looking it back up, classic error!). Sorry again for suggesting that you were a skilled toolmaker I have lately been elbow-deep in the MDLOps code, and I feel like I can address the discussion of vertex normals on some level now. I have definitely noticed all the visual issues that redrob41 pointed out (especially the neck issue, which he is definitely correct in his assumption of the reason). I just want to mention one important limitation of vertex normals as part of the MDL/MDX format. (Please forgive misuse of 3d modeling terminology ... it's not my primary focus). When you have a sharp edge between two faces, you have two very different vertex normals for the vertex locations defining the edge. The MDL/MDX format stores the vertex normals per-vertex in the MDX file (similar to UV vert info), so it will never be possible to have perfect sharp edges across an edge defined by welded vertices/connected geometry. The vertices along sharp edges must be 'copied' or duplicated or unwelded or whatever the term is (I call it 'adjacent unconnected geometry' in my head because ) when you have the vertices of different faces lined up in the same/overlapping position. So yeah, wherever you are going to want sharp edges, don't weld your vertices. In terms of the more sophisticated approaches to defining sharp edges that VarsityPuppet mentioned, I think the only thing that makes sense at the mdlops level is to use the smooth-group information. My reasoning is that modeling software generally handles the 'sharp angle to smooth group' calculations (with varying levels of success ... but that's software for you) so the smooth-group info in the ASCII model should already have that built in (if that was the artist's intent). Also, regarding the shadows, other than misclassified models, I have seen a lot of shadow errors creep in from modeling software munging the bone element trimeshes in various ways. I can only speak from experience with 'soft shadows' turned off, but in that situation, it is definitely the 'bone' (*_g) elements that cast the shadows (at least for bodies. I just did quick research into this because one of my models was getting oddly stretched shadows). The two things I notice modeling software messing up most often for my bone trimeshes are: dropping the tvert indices in the faces list (because there is probably no texture assigned and definitely no actual tverts, so ... what do they mean exactly?) and messing up the orientation. Also, for me, I have seen munged hooks somehow affect shadows ... so yeah, it's complicated. I have not yet purposefully undertaken bone geometry modification ... I'm afraid of what it will do to animations. On an unrelated but on-topic note, I will probably take my first crack at some of the format tables and/or controller lists soon.

@FairStrides, When I sat down to work on "scale" my understanding was exactly what you wrote above. Which is part of why I thought it was going to be so easy. However, the more I looked for where to put the scale value in the headers ... the more I started to realize it's not there. The only "scale" value I was able to find in headers is the "animationscale" field in the Model header. So yeah, as far as I know, this controller is the only implementation of "scale" or "scaling" of any kind. It can, however, be used just like a lot of other controllers in any of 3 different ways: 'single value', 'keyed', or 'bezier keyed'. The single value usage is the same as how alpha and selfillumcolor work. It's sort of the same as how position and orientation work, but those actually are copied to the mesh header for whatever reason (maybe because they are required, whereas scale 1 can be default). Basically when you connect "scale" in the ascii model to a single-value controller entry, you get working per-mesh scale (per-node actually, because it is available on all node types). Incidentally, fx_part_04 seems to be the only non-lightsaber TSL model that actually *uses* this feature (single-value scale controller for 'initial' scale). It has scale 2.5. The sabers also use it to start their scale at 0.0 (and yeah, then they have animations using the scale controller in keyed mode to scale up and down like you describe). fx_part_04 also animates the scale. The following other TSL models animate scale but start at scale 1.0: fx_koltobub, plc_starmap, v_grnadhs_imp. Yeah ... sigh ... the numbers almost-but-not-really-at-all make sense I am going through the same thing with those numbers for emitters right now... @DarthParametric ... that actually does sound like a really good use for it. The characters just get weird ... even though I have had fun laughing at a tiny-hands atton. Also, speaking of controllers, I "figured out" the thing with how bezier keys are represented in binary, and there are actually some uses of them in K1 (haven't checked TSL yet). I say "figured out" because what I actually figured out was to RTFTorlack, and it is in there, and it is actually the same in kotor (it seems so far).

@DrMcCoy thanks for your comments and your work on xoreos-tools. I would be lost without unkeybif! Also your xoreos dev blog and wiki are great resources that I would recommend to people. I arrived at IDA through the xoreos wiki linking to ScummVM's reverse engineering howto (prior to that I had used borg and/or straight vim/xxd. IDA is better.). Thank you for this clarification. Yes, I too have noticed the same thing regarding the presence of an ASCII model parsing routine. There definitely is an 'official' Kotor ascii model dialect of which I was wholly unaware. A problem now is how much of the 'official' kotor ASCII naming can be adopted while maintaining compatibility with the NWN-centric tools like NWMax etc. that people rely on. A good example is the 'lightsaber' mesh type ... among many others. I have been using the the code of NWMax, Neverblender, NWN-Tools etc to do string and formatting checks as well as fill in the picture of what things actually do in-game. In terms of progress, I've got a lot of bits mapped out, especially things completely missing from the cchargin mdl info table. Lights, emitters, and mesh (w/ a large number (probably all?) of the controllers). Enough that I'm starting to get to the hard parts. Like the random pointed-to data segments ... and how bezierkeys are differentiated from linear in the binary (even ascii, i know that they are 'controllernamebezierkey' instead of 'controllername key', but do they have any extra data? knowing about bezier easing and whatnot I would expect so ... just not sure) model ... among other things. Basically I am double checking things, writing things up, and trying to verify as much as I can ... when I'm not working on other projects. And, a major question I have is this: from that parsing routine, it is easy to tell that the game engine is stashing the data into memory structures, but, do you have a sense of whether it actually uses everything that it stashes? For a random example, it knows about the 'beaming' setting, but does the engine actually use that information at some point? Especially because a few of the bits (not many) don't seem to be used in any models in either game. If you have an impression on that, I would love to hear, because I don't exactly want to attempt to verify a bunch of stuff that the engine is likely to not even support anyway Incidentally, figuring out the lightsaber mesh implementation is a pretty substantial challenge it seems like ... and the final 3 chars of controller headers are driving me a little mad. @DarthParametric, thanks for your research and screenshots. The only one of those bits/properties that I don't think has any kotor equivalent is tilefade. I can tell you with certainty that the currently released mdlops does not use transparencyhint or beaming in compiled models (it seems that the game can know about them on some level though... even when I figured out where beaming should be and hexedited it into models I couldn't get a test where any change was apparent. unfortunately my in-game testing skills are nowhere near good enough yet to be able to make conclusions based on their results). Also scale is more than 99% implemented in the current mdlops compiler but not really 'enabled' sort of. It is easy to do silly things w/ scale ... quite a bit harder to do anything that looks really good and works 100%.

Thanks for the advice Blue, but line 3 of the download page does mention "Please do not disassemble, reverse engineer, copy, distribute etc. the program." So I won't really be going that route. It would also be a bit difficult for me to understand since I can't even run KAurora in the first place Also it would be reverse engineering a reverse engineer job ... kinda like cloning a clone. I have looked at xoreos (the code mostly, but also some helpful stuff in their dev blog, and of course the docs folder in their github repo) but haven't actually talked to anyone working on it at this point in time. In general I'm making pretty good progress in learning and discerning things. (Not even really intentionally, just ... finding things while looking for and attempting other things). I am in the midst of writing up something more complete, but here is a first update related to some of the unknowns I spelled out in my first post. Animation Controller 240: this is a RandomBirthRate, a float value I suspect. I don't know exactly how it functions, but it has similar values to the birthRate (which is particles emitted per unknown time unit). I suppose the two options that occur to me for how it might work are: when it is set, it defines a range between the normal birthRate and the randomBirthRate. there are a number of places where it is 2 - 5 apart (above AND below) from birthrate, which in this scenario would mean that the effective birthrate was somewhere between the two at any given time. the problem with this scenario is that randomBirthRate would be meaningless w/o birthRate, and the few places where they are set to the same value would be not doing anything. consider birthing new particles at the given frequency. in this scenario, randomBirthRate is basically additive over the basic birthRate. So, if birthRate == randomBirthRate, the effective birthrate would be somewhere between birthRate and 2*birthRate, depending on the random effect. Unknowns in Common Trimesh Header: I've actually learned a lot of things here, but for now I'm going to keep it simple and just talk about the 'short' (aka uint16) values starting at offset 308 and going to offset 316. Rather than 4 shorts, this is actually 8 (unsigned) bytes. The reason the original interpretation was 'good enough' has to do w/ the little endian byte order. My first clue was the 'value of 256 = cast shadow' ... in a big endian short, in binary, 256 looks like 0000 0001 0000 0000. Translate that to little endian (which is how everything in kotor binary files is), and you get 0000 0000 0000 0001. This is the same as a 0 byte at 310 and a 1 byte at 311. Which, incidentally, I believe to be the correct interpretation. Here's how it breaks down AFAICT: 308 - lightmapped 0|1, 309 - rotatetexture 0|1 (i assume this enables the "Rotation" numbers after offset 316 but haven't tried it), 310 - needs study, 311 - shadow 0|1, 312 - beaming 0|1 (made tree light beams in nwn i think? not sure if it makes an appearance in k1/2), 313 - render 0|1, 314-316 is still unknown maybe padding or something. I haven't yet had time to figure out how many models each byte is set in (and whether any are more than just 0|1 values). Anyway, just a couple notes from the front lines. I am kind of hoping that some intrepid modder will take some of these bits of knowledge into their hex editor and maybe help confirm or deny some of my claims, if anyone tries it, good hunting (and thank you)! Also, just, a little methodology note. The converse of what I mentioned above about the '256 value in a short that is actually bytes' thing is maybe worth spelling out because it is kind of weird. Suppose you are putting a value of 1 as a short (or uint16 ... 2 bytes) at offset 308. In terms of individual bytes, that will put a 1 at 308 and a 0 at 309. In fact, even if you were putting a value of 1 as a long (or uint32) at offset 308, it would still be a 1 in byte 308, with 0's at 309, 310, and 311. This is not news to people who've been hexediting on this stuff for a long time ... buuuut, on a side note, I now hate little endian byte order more than anything in this world

@DP Thanks for clarifying the chain of custody on KAurora for me, it is actually a little difficult to piece together. I found redrob41 taking over stewardship in 2008 (it looked like), the current upload is by Sithspecter, and the description page mentions "The source code will be released with a later version along with the necessary license." which raises questions about whether the closed source status is because of a ) authorial intent or b ) not wanting to figure out licensing restrictions. I personally have not open sourced things just to not have to deal with it, so ... yeah. Thanks again. If it were Magnus' intent to have someone else do the format research in the open, I absolutely would/will respect that and do it myself. I did not mean to make it seem assumed that I would be granted such access, which, admittedly in the quote you picked out, it kind of did . My basic position is just that the original MDL/MDX format tables from 2003?4? are what some people are still working from, they have issues (that some people have solved), and I would like a better source of information to be put into public view if possible. If it were to require me to do clean-roomed research, I would go about it and contribute what I could. It would just be less, and slower. @Fair Strides Thanks for jumping in, I will PM you. Edit: Eugh ... Just found and reread the change of stewardship of KAurora post that I had found earlier. My memory of it was poor, sorry. It was 2014 and much clearer than I remembered. Never try and type something w/o looking directly at what you're talking about...

@Purifier thanks for the neverblender release announcement! Now I just have to determine whether it's worth upgrading. The reason it is a question is that I have substantially modified my NVB, and if I want to upgrade I'll probably want to produce proper patches ... or do a git merge ... and as a software engineer I am kinda lazy ... I have also been approaching the modeling issues from both sides, NVB/python and MDLOps/perl. My goal has been getting them to produce identical results (so I can see the things that have *actually* changed by comparing MDLOps ascii files against neverblender exported files). It would probably be wise to take the neverblender discussion to a new thread. @DarthParametric - that is interesting that you encountered the combat camera weirdness on a KAurora compiled model. I haven't used KAurora ... I think maybe I tried, but I'm in wine, so it's a bit of a crapshoot as to what windows software will or won't function. It seems really unlikely that KAurora would misclassify a model ... what was the workflow for that? Starting from zero, or starting from some existing model? I am really interested in that because I am strongly considering implementing a new droid model (probably based on HK?, but heavily modified) for Elbee (T1-LB) from the comics series. Elbee the sullen hulk. I just wanted to alert anyone that currently maintains MDLOps that I am working on a suite of improvements, and I am interested in discussing it much more than I'm going to have time to right now . Anyway, here's what I've done so far: Controlled precision: we lose repeatability in the process because MDLOps doesn't really 'handle' precision. This is bad for anything that's a floating point value. Google says that for 4 byte floating point numbers you need to maintain 6 significant figures to repeatably go from number string => floating point value => number string, and 9 sigfigs for fp value => num string => fp value. MDLOps approach is just 'more is better' combined with 'whatever you want to do, perl', routinely outputting 16 sigfigs. I don't think those are real, they are garbage. So now anywhere floats are used, somewhere between 6 and 9 significant figures of precision are used explicitly. That will probably be refined to 'the right' numbers at some point, but so far it is working well. Reworking the templates used for reading from binary models to fit KAurora's better understanding. So far I've only reworked the common mesh header stuff, but it's already helping. Implemented and fixed some of the unhandled attributes already known: shininess, lightmapped, bitmap2-4, 'sparkle'. I have been trying to take as many names from nwn-tools as possible to maintain maximum compatibility with NWMax ... it seems possible that bitmap2-4 should maybe be 'texture2'-'texture4' instead, but i'm not sure how much it matters. I use neverblender, which I am going to have to extend to retain all the kotor-specific attributes (it already retains some custom data (aka data that blender doesnt understand) at the mesh level, so it should actually be easy!). These are all implemented for decompile and recompile. Fixed a couple infinite loop and infinite recursion conditions that affected a few of the models that have 'bad things' happening in them. One of the k1 dor_... models animates meshes by name that don't appear in the model itself, mdlops hated that. Placeholder for controller240 - gathers data on values only, decompile only. Performance & reliability - there are still problems I'm working on here, but as a software engineer who's been using perl for 10+ years, there were a lot of little things to fix to make it function better, faster, and more deterministically (overreliance on $_ and nuances of buffered IO are (among) the evils of perl). Improved ability to determine nodetypes when classifying controllers, leading to more complete decompilation of controllers (I have 0 'didn't find controller X in node type Y' messages now) And here's what I hope to do soon: Compilation support for more controllers Debug mode that will export all the unknown flippable parameters to ascii models and then compile them back in also Improve the nice work you guys did not too long ago on the model seams (implementing the cross-mesh smoothgroup test (also figuring out whether you guys got angle weighting & face weighting in there ... when i was reading quickly it seemed like maybe only face weight?) If I can see what KAurora knows I'll fix all the unpacking templates to current best understanding Figure out wtf is up w/ scale & specular And here's what I hope to do longer term: Full(er) animation controller compilation (decomp support is surprisingly good already AFAICT, but right now only position & orientation can get back into game models) Remove supermodel requirements (I currently understand this to be a limitation of bone understanding in the MDX ... but these goals are all lofty and not well-understood at this point) I am pretty solely focused on the technical aspects of it, just modifying MDLOps.pm really, not very concerned w/ any kind of GUI or CLI 'features'. Once I solve any of the 'harder' problems it will probably be worth thinking about doing a release of some kind ... so far it's been mostly somewhat 'frilly' stuff to make way for real improvements. MDLOps is an amazing tool already, and I really want to help it get further along in making people's modding experiences easier, better, and more reliable.

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).

Yeah, I totally noticed that about PC models also, my pfbam never had any combat camera issue, just the missing shadow. I think there's probably something in the engine making the PC models be handled slightly differently in that regard (but not completely differently, because they still lose their shadows ... weird). perl is an interesting language. it is kind of difficult until you understand its data types really well. on the plus side, it only has three data types (unless you consider refs (which are scalars) a fourth type, which i kind of do). a lot of things that are really painful in other languages are a total breeze to write in perl. the issue is that they are not usually very easy to read after that . but yeah, i generally keep people nowadays from having to learn perl, pushing them more towards using javascript in node.js instead, which is why i'm not too aware of good learning resources. still though, a lot of systems administrators still use perl for scripting systems and build tasks. i am loving how much perl source code exists for kotor tools. it is really up my alley. now if only 3d geometry stuff wasn't always so mathy i'd be set! It is definitely interesting how a little thing like the difference between CHARACTER and Character can make such a difference. If you feel like subjecting yourself to a bit of excruciating detail on why this is, read on! I figure if you think you might be interested in perl ... hey why not ... The classification in the ascii model only controls 1 byte in the compiled model. MDLOpsM.pm contains a map connecting names with their byte values, it is a hash, %classification around line 196. The names, or keys, in that hash are all ucfirst (upper case first letter). The important values there are 'Character => 0x04' and 'Other => 0x00'. So, the classification is read from the ascii model (that's actually the part I fixed), and then it gets used while writing out the binary file. In this stage, it is used directly as a key/name into the %classifcation hash. perl does not find $classification{CHARACTER}, so it returns 'undef' aka undefined. My guess though, is that, because that undef value is being used in a 'pack' call (the pack call is basically letting you be very specific about how perl interprets different values) that is claiming it should expect an unsigned char (byte), it interprets undef as being 0 (which was Other, rather than Character, which was 4). So basically the bug just makes the game think your model is classification Other instead of classification Character. Honestly, I'm surprised such an issue wouldn't cause more problems in-game.

That is interesting that the mdlops.pl and MDLOps.pm files seem to be necessary in the same directory as mdlops.exe. I am not sure how to explain that ... I have not really experimented with that exe file. The only mdlops.exe I have used is the mdlops.exe that ships in the KotorTool package. It's an older version, maybe a 0.6 or 0.5. It definitely runs without any perl code available. I just re-read all the docs that come w/ MDLOps and yeah, the document you are looking for is 'installing perl.txt'. It tells you how to install a windows-compatible version of perl (in this case, ActiveState's ActivePerl, which I used to use a long time ago also ...), and the dependencies that mdlops will need to run. Basically it covers what you need to do to get to the point where 'double-clicking mdlops.pl' will be a thing that actually works (runs the program, not just opens the code in a text editor). I know that the mdlops.pl code uses Tk (also known as Tcl/Tk) for its interface, but this is not covered by the perl install documentation. There is a thing called ActiveTcl, also by ActiveState, which you might also need to install to get it working. It's been even longer since I have used Tcl/Tk and ActiveTcl, but I will provide any assistance I can... As far as the blender and neverblender version stuff goes ... I can't really speak to that as I am basically a brand new blender user who's never used any other version. OH. I just thought of something you might want to do before you go down this road of installing perl and whatnot. It is actually really easy to determine whether the fix will solve your problem or not. Here's what you can do to test a single model: open in a text editor your ascii model file that you are about to compile; find the line that says "classification CHARACTER" (usually like 5 lines in or so) and change it to "classification Character". You can then compile it using mdlops.exe and it should be fixed when you try it in game. If you still have the shadow/camera issue, then there's no point in installing perl and all that other stuff anyway.

This change is definitely against MDLOps 07A2 ... Sorry to hear that it hasn't resolved your issue. I haven't seen this issue again since I made the change. Some debug questions: After you changed MDLOps.pm, are you running MDLOps by running the command "perl mdlops.pl" (or by double clicking mdlops.pl I guess) or by running mdlops.exe? If you are running mdlops.exe, it is extremely unlikely that your change to MDLOps.pm had any effect. My understanding, and people will correct me if this is inaccurate, is that mdlops.exe is a compiled executable that includes perl, Tk, MDLOps.pm, etc. -- all the dependencies. It is completely standalone from the mdlops.pl and MDLOps.pm files. This is, for example, why you can use mdlops.exe without installing perl (I think! I don't actually have a windows box to test with!). That is my first/best guess as to the problem. If you're definitely already using mdlops.pl and the modified MDLOps.pm... can you post the 'classification' line from the ascii version of your p_juhanibb.mdl file? Also: speaking to the earlier version questions you had ... I use blender 2.77 and neverblender 1.23a which was released earlier this year i believe. i found it on nwnvault.

I ran into this issue, and I have tracked this back to Rece's Lightsaber Crystals addon 2.0 (aka Rece's K1 Lightsaber Mod (UPDATED+ADDON) 2.0). I was using the mod's June 15, 2015 version that is 'current' as of now, with K1R 1.2, and the gog edition of K1. If anyone encounters this issue, and you have the directory you used to install Rece's Lightsaber mod, do this: save a game just before talking to Bolook for the first time, quit K1 create a backup copy of the danm14ac.mod currently in the modules/ directory of your K1 directory copy the danm14ac.mod from the backup/ directory in your 'K1 Lightsaber Crystals addon by Rece' directory into your game's modules/ directory. This is the backup that was created automatically by TSLPatcher when you installed the mod. fire up K1, load your game, play through the quest, save your game, quit K1. restore the backup copy of danm14ac.mod you made in step 2 back to your modules/ directory. If you don't have the original directory you used to install Rece's lightsaber mod, I recommend just copying your save game into a clean K1R modded game to play through the quest, then copy back. You might also want to go that route if you have other mods which change danm14ac.mod significantly. I did not; in a game w/ 50+ mods installed. If anyone has any reason to think I might be wrong about which mod is causing this ... please let me know. I'm down to get a bit more scientific in terms of the set of mods I have installed and the testing and whatnot if actually required. I'll wait about a week for comments and then leave a comment on the Rece's Lightsaber Mod download page so that people will have a heads-up.

File Name: Console M4-2K File Submitter: ndix UR File Submitted: 03 Jun 2016 File Category: Skins TSLRCM Compatible: Yes It's the console from M4-78. A high-res, animated take on the vanilla version. Includes an updated model for illuminated surfaces, non-mirrored screens, and restoration of two surfaces that were maybe originally intended to be screens but ended up as flat metallic surfaces. Also includes non-animated options. Knights of the Old Republic 2: TSL only. Click here to download this file