Jump to content

ndix UR

Member Since 12 May 2016
Offline Last Active Dec 16 2017 04:39 AM

#61093 Download:Traditional Mandalorian Blades

Posted by ndix UR on 04 December 2017 - 02:26 PM



File Name: Traditional Mandalorian Blades

File Submitter: ndix UR

File Submitted: 03 Dec 2017

File Category: Mods

K1R Compatible: Yes


Traditional Mandalorian Blades
for Knights of the Old Republic


This modification adds traditional Mandalorian beskar iron melee weapons, the Beskad and the Kal. The weapons can be found and purchased in-game.


If you prefer different bonuses for the weapons, you can use your favorite GFF editor to modify the UTI files that the installer places in your Override folder.


I made the models and textures. The textures are 1K and relatively simplistic. The original uncompressed textures, along with UV and AO map overlays, can be found in the Modder's Resource package (it is the same as K2:TSL version's Modder's Resource package).


Thanks to JDub96 for requesting this, and also to Kexikus for his folder priorities tutorial that helped me realize that .mod takes precedence over .rim ... which was making me go a little insane :).


Re-distribute or re-use this mod as you like, in full or in part.


The modification is designed for use with K1R. Whether it works without it is unknown.


The modification uses model variation 41 of vibroblade and vibrosword. It will
not work with other mods that provide w_vbroshort_041 or w_vbroswrd_041.


The modification MAY be incompatible with other mods that affect Igear in
Taris undercity (module tar_m04aa), the Mandalorian encounter on Dantooine
(module danm14ac), or the Mandalorian commander on Kashyyyk.


You can find the objects in-game at...






Click here to download this file

  • jc2 likes this

#60223 Download:KotOR High Resolution Menus

Posted by ndix UR on 31 October 2017 - 01:29 AM

@Lucy, it is likely that the patch did not apply properly, or that you're not running the EXE you think you are. The way you describe your issue is consistent with what happens without the patch. Screenshots would help me tell for sure.


And yeah, the package screenshots are horrible by design. I downsized them by 50% and JPEG'ed the heck out of them. This way when you run it on your own machine you're extra happy.

#59854 PMHC06 Fixed for TSL

Posted by ndix UR on 21 October 2017 - 12:23 AM



File Name: PMHC06 Fixed for TSL

File Submitter: ndix UR

File Submitted: 19 Oct 2017

File Category: Mods

TSLRCM Compatible: Yes


Just a fix for the PMHC06 head model (Blond Guy with Bangs?). The model contained some bad node names/linkage which are corrected to match its supermodel, allowing this poor fool to now blink and move his eyes!

Kind of a quick job, anyone that wants to do a better job is encouraged to do so, using my model as a starting point or not, as they prefer. Feel free to reuse, repackage, redistribute the contents of this package with or without attribution or notification.

Knights of the Old Republic II: TSL


FILENAME: pmhc06-fixed-tsl.7z

A modification for Knights of the Old Republic II: The Sith Lords.


1. Place ALL the files in the 'Override' folder of this package into your game's Override folder.


This mod includes a new model for the Blond Guy with Bangs (PMHC06) model from TSL.
It fixes the issues outlined in the following forum post:

The fixed model has eyes that move and can blink.

Changes to the model:
- Nodes renamed:
eyelidL => eyeLlid
eyelidL01 => eyeRlid
eyeL => eyeLA
eyeR => eyeRA
teethUP => teethupper
teethDWN => teethlower

- Flipped normals on the right eyelid
- Nudged the vertices under hair_front backwards a tiny bit

Thanks to 1Leonard and DarthParametric for fleshing out the issues.
Kudos to DP for the rerig attempt, but that is not the approach I followed.


Remove the added files from your Override folder.


This mod replaces the PMHC06.mdl and PMHC06.mdx files.
It will not be compatible with other mods that do the same.


Smoothing might not be perfect.



I place no additional restrictions on the use, distribution, etc. of this package and the files herein.




Click here to download this file

#59852 MDLedit bug reporting thread

Posted by ndix UR on 20 October 2017 - 08:53 PM

bead-v, can you share with the source code of this excelent application? I am very interested in animation parsing



#59684 KOTORmax

Posted by ndix UR on 10 October 2017 - 01:32 AM

They are more alike than different at this point (in terms of compile/decompile capabilities, in terms of GUI, MDLEdit is way better :)), and they aim to be fully cross-compatible with each other. However, they often use different algorithms on the backend to achieve the "same" results, which sometimes lead to slight differences, sometimes ones we don't even fully understand :) A good example is our AABB tree computations, both of us are 'wrong', but both seem to work, despite slight variations in the output trees.


This is a topic bead-v & I will likely address at length in a different thread once a new MDLOps is generally available.

#59647 tga2tpc

Posted by ndix UR on 08 October 2017 - 11:32 PM



File Name: tga2tpc

File Submitter: ndix UR

File Submitted: 08 Oct 2017

File Category: Modding Tools




Author: ndix UR
Release: October 2017
Version: 1.2.0


Convert TGA images to TPC format for use in KotOR and TSL.

TPC files contain the information from a TXI file (so the TXI file is no longer needed when a TPC file is used), and can be uncompressed or compressed with either DXT1 or DXT5.

Advanced features like animation and cubemap layering are initiated by the presence of specific TXI directives like cube 1 and proceduretype cycle.

For some reason, the game really wants normal maps to be in TPC format. This will let you create and use full color normal maps without having to make them into simple height maps.

The tool is free, open source, and cross-platform. Code is available at https://github.com/ndixUR/tga2tpc

The app is written in javascript, built on Electron using three.js, jquery, bootstrap.


How do I set it up?
Windows: unzip the package, run tga2tpc.exe

Mac: unzip the package, move tga2tpc.app to /Applications, run it
* This is not a signed application, so you have to do whatever is required to run non-MAS applications on your MacOS version.

How do I use it?
Drag files in and hit start. There shouldn't be much more to it than that. Using square and/or power of 2 sized textures is a good idea (sometimes required), TXI information is optional, and the settings are pretty much self-explanatory.



  • Create cubemaps
  • Create animated textures
  • DXT1/5 Compression available (requires 2^n texture size)
  • Horizontal/Vertical flip, for those pesky wrongly oriented TGA files
  • Bicubic downsampling for mipmaps (precomputed small versions of the texture, part of the TPC format)

Known Issues
  • Cannot create uncompressed animated textures.
  • Only for converting from TGA to TPC. For TPC to TGA, use Kotor Tool or xoreos-tools.
  • Progress bar doesn't update as often as you might want.
  • Bicubic downsample is slow. I recommend only using it for final conversions, not testing.
  • The package size is large. This is the cost of easy cross-platform GUI support. All electron applications are large like this.


DarthParametric for inciting the creation of this tool, and doing the testing.
DrMcCoy and all the contributors to xoreos, whose TPC decoding implementation provided the basis for the TPC library herein.
bead-v for moral support.


Click here to download this file

#59139 How many new rows can the appearance file have?

Posted by ndix UR on 06 September 2017 - 11:09 AM

The number of rows is a full 32-bit unsigned int, so ~4 billion. However, AFAICT, that's not the limitation you would reach.


2DA files store offsets to each piece of data using 2-byte uint16's, the offsets are from the end of the offsets block to the start of the particular datum (think, one actual cell in the table). This means that you will run out of space when your table data reaches 64KB (and you want to add another thing beyond 64K). Everything is a string, so it completely depends on the content of your table. You could run out with a single row of 4 32K strings, for example. Alternatively, you could store a single row, single cell with 256K or more probably, because it's just one really long string from offset 0.


For perspective, my appearance.2da is 693 lines, and its minimum available offset is 19935, which means the file is 30.4% "full". My alienvo.2da is only 44 rows, but 16% full.

#58605 Black Line in middle of face.

Posted by ndix UR on 19 August 2017 - 09:48 PM

I also regularly experience this issue. It seems to be an issue with the algorithm in the game for getting data to make mipmaps from. Mipmaps are smaller versions of your texture which the game uses for rendering at different distances. This is why close up you (almost) never see this issue, and it is generally very affected by camera angle/distance.


You can reduce the issue by making sure that all your UV islands have nice big like-colored dead zones/borders around them. I didn't know this early on and have paid the price.


The game's mipmaps are 1/2 size at each 'level'. So, at the first level, your UV island border pixels are blended with 1 pixel (from the original sized image) from across the border. At the 2nd level, 2 pixels, 3rd level 4 pixels, 4th level 8 pixels, 5th level 16 pixels. It's a bit more complicated than that, but that is kind of the general idea. You have to balance the size of your border areas with the level at which the mipmap has so little detail it doesn't really matter. Like, a 2K texture will have 11 mipmap levels, which would need UV island borders of 1024px to be "perfect" at the last level ... but that last level is only 1 pixel, so what detail would you really be trying to preserve with that?


For me, personally, I find 16px for 2K textures to be a good balance.


A reason why you see this less in default textures is that they use the TPC format, which includes precomputed mipmap images (for which, presumably, they took care to make sure the mipmaps came out with good visual characteristics). TGA images don't have mipmaps, so they are generated by your video card (there is an OpenGL function that does this), which is also why there is some variance w/ different cards/drivers/etc. Seems like driver-level AA settings would help too, but in-game AA settings don't seem to affect the issue.


In an ideal world, the mipmap generation would use UV mapping to refrain from using pixels from outside the UV islands, but that is not 2003 tech :)


My understanding for why this issue never really goes away is that the game seems to maybe use black pixels when a mipmap is blending with pixels outside the border of the image. That is just a theory though.

#58119 Download:Ebon Hawk K1 Fixes

Posted by ndix UR on 02 August 2017 - 02:01 PM



File Name: Ebon Hawk K1 Fixes

File Submitter: ndix UR

File Submitted: 01 Aug 2017

File Category: Mods

K1R Compatible: Yes


This mod provides geometry corrected versions of the following EbonHawk model files:




Screenshots show some of the problems that are fixed.


** Ebon Hawk Geometry Fixes **

** A Modification for Star Wars: Knights of the Old Republic **


Author: ndix UR

Filename: EbonHawk-K1-Fixes-V1.7z

This mod fixes a number of geometry issues with the Ebon Hawk models used in KotOR. It attempts to plug all the holes in the ship and make it space-worthy.


Likely incompatible with other mods that replace Ebon Hawk model files, but is compatible with other mods that modify the cockpit external views for Ebon Hawk, as this mod does not touch m12aa_01q, the model for those.

Known Bugs:

None. It will not work for K2:TSL, which uses different models.


Place the files in the 'For Override' folder into the Override folder in your game program folder.


Remove the files from your Override folder.

Legal Disclaimer:

All materials and copyrights belong to LucasArts, Obsidian Entertainment, and Bioware Corp.

The author places no warranty or restrictions on use of this mod.


Click here to download this file

#54790 Taris Dueling Ring

Posted by ndix UR on 09 March 2017 - 10:57 PM

B4-D4 vs Verbal

#54729 [K1 & TSL] Fix Ebon Hawk shader and UVW issues

Posted by ndix UR on 07 March 2017 - 04:50 AM

Thanks! The cockpit seems to be the hardest part by far...


For K1, I finished my detailed walkthrough and found the following geometry issues in the rest of the ship.


In the cargo hold (with the supplies dispenser):




In "Kreia's room" there is an open seam on the floor to the right of the doorway (when exiting the room)



There is a small open seam to the left of the doorway that leads from the swoop/workbench room in the direction of the engine room & cargo hold.



The 'main section' w/ the holo-emitter has a few open holes in the floor, most of which don't get noticed because they have black behind them. Here is one of them:



There's also z-fighting at the threshold of the engine room, but I didn't get a picture of it. Partly because it doesn't come through at all in a still pic.


TSL Ebon Hawk 003EBO


I did a walkthrough and first bit of investigation into the TSL 003EBO module's models. Obsidian made it harder to detect most of the seam issues by surrounding the back 7/8 of the ship in a star box (almost all black). However, they also made the lightmapping a bit brighter in a lot of places, making some of the other seams easier to see (esp. in the cockpit).


Stuff that was the same as K1:

  - instrument panel seams in the cockpit (not the big gap from Example 1 though)

  - z-fighting on engine room threshold

  - small open seam on doorway from workbench room


What's new?

  - way more lightmapping issues, the most common 'issue' is that things have just been blacked out in the lightmap texture image.

  - the black floor panels on the way to kreia's room are the only ones i found where the lightmap error is "these are completely unmapped".

  - more loose polys, similar to the black plane popping through the cockpit instrument panel, but less bad in other places.


Medbay lightmapping:



Front hallway just outside cockpit:



This is a seam issue that you could not actually see in-game in K1, but which I fixed up all the same in the K1 model I posted before...



These are new, loose planar polys in the doorways, haven't backtracked them to see what they are connected to. I took a hidden one of these out of the front window of the K1 cockpit...



I think that is pretty much it as far as I've been able to tell so far ... I don't have fixed models ready for upload, though I do have a bit done (K1 hawk might be completely done unless other people find more that I have missed)


This was the hardest part, so I started with it. It came out ok but maybe not perfect I think:



I'm at the limit for pics in a post, if you want to see the last one or two, here's a link: https://imgur.com/a/dSkf1

#54689 [K1 & TSL] Fix Ebon Hawk shader and UVW issues

Posted by ndix UR on 04 March 2017 - 11:30 AM

Wow, when you crack open the Ebon Hawk cockpit model in a 3d editor it is a wonder the ship doesn't fly apart! I found several more issues (these are all for K1, model m12aa_01p):


There's a hole in the wall...



No shortage of open seams around the instrument panels...



And, not sure how I never noticed this, but now I can't unsee it...



Everything I saw in this model for errors was geometry based. The holes in the Example 4 panel were maybe supposed to be part of one of the animated meshes, but yeah, no geometry is present in those spaces. Same for the hole in the wall.


To get the ball rolling, here is a fixed version of the K1 m12aa_01p model:


Attached File  EH-cockpit-fixed-K1.7z   263KB   43 downloads


I filled the Example 4 holes using a new mesh w/ different keyframes from any of the other blinking lights ... so that part is neat. It seemed to come out pretty well...


No lightmapping changes ... the only thing that seems maybe questionable to me w/ the lightmapping in that model is below the Example 4 instrument panel there is a very black area w/ just a few blinking lights. It looks a bit odd, but maybe intentional.


I had to cheat a bit, copying and translating the AABB tree from the original model. I have a thing that generates AABB trees, but apparently not well enough yet...


The model worked fine for me, but it is pretty experimental so hopefully it will work for you also!

#48573 Kotor TSL Where am I armband

Posted by ndix UR on 01 September 2016 - 06:26 AM

I could only find it using archive.org and knowledge of the specific filename. I hope it works. Good luck.



#47825 Are there any KOTOR 1 mods which have the UI for things like inventory, Pazaa...

Posted by ndix UR on 01 August 2016 - 05:59 AM

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.

#47777 Bump Mapping Research

Posted by ndix UR on 31 July 2016 - 12:14 AM

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  :P 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-tu...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:

  1. the game doesn't crash (anymore) when my model loads
  2. the game doesn't give me the error message about invalid bumpmap (anymore)
  3. 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.
  4. 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


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.