Jump to content

ndix UR

Member Since 12 May 2016
Offline Last Active Today, 07:24 AM

#63748 Salk's "SW:KotOR Upgrade 2.0"

Posted by ndix UR on Yesterday, 11:25 PM

Feel free to use my K1 Ebon Hawk geometry fixes.


That particular mod is free for anyone to use in any way they see fit, credited or not, because I really never want to see those geometry errors in any sort of new work anyone ever does.


Best of luck in your endeavor.

#63404 How I managed to create rgb bump maps

Posted by ndix UR on 06 March 2018 - 09:10 PM

So, you might want to check out this thread: http://deadlystream....rch/?hl=bumpmap


Also, through some extensive research, DarthParametric and I have found that the indexed color bumpmaps are really the same as grayscale/black & white TGA bumpmaps (the way they will be parsed/handled by the game). Which is still nice, it's nice to have bumpmaps on systems that support them. You're just not getting what you might be thinking of if you have access to actual normal maps.


If you want a true full-color tangent-space normal map like the ones the game uses, you just need to convert your 24 or 32-bit TGA to a TPC file containing the appropriate 'isbumpmap 1' TXI value. The vanilla ones used by the game are uncompressed TPC files, but that is not a requirement.

#63189 How does the game handle transparency?

Posted by ndix UR on 26 February 2018 - 12:14 AM

The game handles transparency in a lot of ways, as JCarter426 touched on.


Most often the alpha channel in a texture isn't used for transparency, it is used as a sort of 'strength map', either for an environment cubemap or a normal map. More transparent = stronger effect.


There's an alpha controller for any mesh subtype node for specific models. This is used, but somewhat rarely.


Textures can have 'blending punchthrough' in their TXI info, which causes the alpha channel in the texture to be interpreted as transparency and properly take other geometry behind the transparent area into account when compositing.


Models have a 'transparencyhint' in the mesh subtype node header, this acts as a 'blending punchthrough' for specific nodes, and keeps you from having to specify 'blending punchthrough' in TXI information. (It doesn't let you use the alpha channel for other purposes on the same texture though).


Textures can have 'blending additive' in their TXI info, which makes them behave like a 'screen' or 'overlay' blending mode in photoshop, wherein black essentially becomes 100% transparent and white becomes 100% opaque. This might not use information from an alpha channel at all (mostly it is used in textures that don't have alpha channels in the vanilla assets), but I don't know what happens when you do have alpha channel info and are using 'blend additive'.


TPC files have an alpha blending (possibly alpha mean) value in their header, which relates to compositing behavior (you probably wouldn't need to worry about that in unity).


In your original quesion about stars/black backgrounds, just guessing, you are probably looking at a 'blending additive' situation.

#62964 Download:KotOR High Resolution Menus

Posted by ndix UR on 16 February 2018 - 03:17 AM

I have a 21:9 also, and there's no fix currently available. However, lucky for you (and me), I just figured out how to fix it like two days ago, but it does require a modification to the EXE file. Particularly, it involves changing a certain value that is some kind of screen proportion number. I am still trying to determine the correct value for different screen proportions, it's not something very simple like 3/4 or 9/16 or like that.


It should be in the next update though...

#62664 [WIP] (b1.1.0) KOTORPatcher - TSLPatcher-like app for Android

Posted by ndix UR on 04 February 2018 - 10:47 PM

You'd think so, but no. They are field types 16-18. In my Aurora docs the field types end at #15 with the 'List' type. There are 19 total field types for Odyssey GFF (0-18).

#62660 [WIP] (b1.1.0) KOTORPatcher - TSLPatcher-like app for Android

Posted by ndix UR on 04 February 2018 - 08:39 PM

Odyssey GFF files have 3 additional field types that weren't present in my Aurora documentation. Orientation/Quaternion (16, complex, pointer to 4 floats); Position/Vector (17, complex, pointer to 3 floats); StrRef (18, complex, pointer to int32LE). If you guys have documentation that specifies these then maybe I need to find a newer edition...

#62397 KOTOR1 Placeable Limit

Posted by ndix UR on 20 January 2018 - 09:45 PM

While trying to install a mod that added entries to placeables.2da, I came across a relatively severe limitation in KotOR that I feel should probably be known to anyone attempting to make or use large-scale or placeable mods. Maybe this is known or was documented on lucasforums, but I didn't find it anywhere.


Unique placeables defined in placeables.2da are limited to 256 (0-255). If you use a value higher than 255 for 'Appearance' in a UTP file, it rolls over. So 256 = 0, 257 = 1, etc.


That might not sound like a big deal, but the vanilla game already has 232 placeables, which means that there are only 24 placeable slots available for use by modders. K1R adds 8 placeables, so if you're using that, you have 16 slots available. BOS:SR 1.5 adds 21 placeables, so if you're using that, you have 3 slots available. And if you're using both of those mods you're already over by 5. So people using K1R and BOS:SR can't use any additional placeable mods (and should experience some visual errors in-game from getting the wrong placeables).


This seems like key info for users to be able to evaluate what mods they want to try and use based on how many placeable slots they use. It is also among the first things to check if you have any problems with placeables not showing up or showing up as the wrong thing.


I am wondering if any experienced modders know or will be able to think of viable workarounds for this? I've tried putting placeables.2da into module files (and removing it from Override/), but that doesn't seem to work. My only other thoughts have been:

  • Making certain placeables characters instead of placeables? You lose any walkmesh related functionality like blocking line of sight...
  • Combining certain placeable models and using animation states to swap out the mesh that is showing. For example, BOS:SR includes 6 rock placeables, could it be 3 if one rock was the 'on' state and another was the 'off' state?
  • Baking placeables into area geometry? This is more work, harder to make fine adjustments, and you can't interact with the objects at all. It would have the advantage that you could 'easily' lightmap 'each instance' of the placeable though. Now that we have advanced model compilers this is at least a more viable option than in the past...

I can say that this definitely applies to the GOG and Mac Aspyr versions of K1, I don't know about others.


FWIW, this limitation doesn't seem to be present in TSL as its vanilla placeables.2da file has more than 300 rows (thanks DarthParametric for checking that).

#62183 TPC compressed texture transparency: alpha blending

Posted by ndix UR on 14 January 2018 - 01:33 AM

The TPC texture format contains a floating point number in its header that we refer to as 'alpha blending'. It appears to be critical when used with DXT5 compression. This tutorial will try to help you use this feature properly.


What is alpha blending?


Alpha blending is not a direct 'opacity' or 'transparency' factor. It is only relevant for non-environment mapped textures that contain alpha-channel image-based transparency. For example, semi-transparent signage, mostly transparent windows, ghosts, etc.


The best description I can give you for what alpha blending is:


TLDR: alpha blending is not object opacity. It hides any mesh behind the textured object that has opacity less than tpc alpha blending number. Set it to 0.0 when using texture alpha channel as transparency.


The meshes that will be hidden include any mesh that may be using alpha channel solely for environment mapping. Let's see how this plays out in practice with some visual aids. Each figure uses a TPC encoded version of the K1 Manaan Overhaul semi-transparent texture for the Sith Embassy signage. Transparency of the sign is right around 50%.


Figure 1. TPC with alphaBlending set to 1.0


Attached File  trans-1-0.jpg   124.39KB   0 downloads


With alphaBlending set to 1.0 the only thing that shows through the sign is the skybox itself. This may be some kind of depth buffer test to make sure that something always blends through, which, in the 1.0 case, leaves just the most distant mesh, the skybox.


Figure 2. TPC with alphaBlending set to 0.9


Attached File  trans-0-9.jpg   125.27KB   0 downloads


This seems to be the critical shot. With alphaBlending set to 0.9, lma_wall11 is showing, while lma_wall09 is hidden. lma_wall11 is 100% opaque, 0% transparent. lma_wall09 is 85% opaque, 15% transparent.  So because lma_wall11 opacity > alphaBlending, it is shown, while, for lma_wall09, opacity < alphaBlending, so it is hidden.


Figure 3. TPC with alphaBlending set to 0.5


Attached File  trans-0-5.jpg   122.93KB   0 downloads


In figure 3 we can see that both lma_wall09 and lma_wall11 are showing because their opacities are both greater than 50%.


Figure 4. TPC with alphaBlending set to 0.0


Attached File  trans-0-0.jpg   116.53KB   0 downloads


This looks exactly the same as figure 3. Wait, isn't that weird though? Why can't we see the other sign through the first sign? It's opacity is 50%, which is greater than 0.0...


Figure 5. TPC with alphaBlending set to 0.5, reverse viewing angle


Attached File  trans-0-5rev.jpg   107.41KB   0 downloads


Just by looking through the sign in the opposite direction, the signs in the background now are blended through. This is showing a couple things. First, it seems that alphaBlending doesn't actually control instances where the same texture is behind itself. Instead, it appears that there is some kind of directionality at play. I haven't figured out what determines the direction of blending. I investigated whether it was the faces that appear earlier or later, but that didn't necessarily seem true.


Using alpha blending


The game's vanilla textures use all kinds of different values from 0.0 - 1.0 here. I do not fully understand why or how they have come up with a lot of their alpha blending values. In my testing, it seems like if you have a semi-transparent object, you set this to a low value, 0.0 or 0.1, and if you have a non-transparent object, you set this to 1.0.


The important thing is that you do not think of alpha blending as the transparency or opacity of the object itself.


If anyone comes up with better guidelines for setting this value through scientific testing, I will be happy to update this post to reflect the improved guidance.

#62083 Mod of the Year Results!

Posted by ndix UR on 09 January 2018 - 11:03 PM

Personally I liked having K1 and TSL separated, more winners and more to vote on. Also, when combined with the 'no vote' option, it meets the needs of people who only/mostly play one or the other.


I am conflicted about the Upcoming / WIP category. On the one hand, I've never tried a pre-release mod, but on the other, I do have a lot of respect for the people who are able to document their progress and keep the community involved.


Just my two cents.


Thanks to all the organizers for keeping this tradition going, and to the people who submitted nominations.

#62079 Editing offsets in binary 2DAs

Posted by ndix UR on 09 January 2018 - 09:49 PM

OK, thanks. Is the NUL separate from the cell terminator ([other cell] NUL NUL
NUL [other cell]), or do I just leave the data blank ([other cell] NUL NUL [other cell]? And is the data section null terminated or delimited (is there a NUL ending the file)?
Thanks for the code, I'll try to get that to regular Java and test it.
My editor has separate encodings for ASCII and UTF-8, so the binary data is probably just messing things up.


It is just the single NUL as terminator for representing empty string AFAIK, so [other cell] NUL NUL [other cell] NUL. The bold NUL is a separate 'cell value'. I just think of the data section as a concatenation of null-terminated strings (this is how strings work in C), not that the NULL is a delimiter. So, what I see in that is [other cell][''][other cell].


There is a trailing NUL on the last element of the data section, but not an *extra* one. In my terminology, the last data item is a standard null-terminated string. In what you have above it would be [last cell] NUL EOF. Where EOF is not an actual byte, just a human-readable thing signifying end of the file for purpose of discussion.


Yeah, I would definitely recommend using a hex editor to view your binary 2DA results and not a text editor.

#62072 Editing offsets in binary 2DAs

Posted by ndix UR on 09 January 2018 - 08:50 PM

Don't use '****' in binary 2DA. They become an empty string (single null character). When I read 2DA values I convert empty string to '****' and when I write 2DA I convert '****' to empty string, but whether you want to do that depends on your use case (mine is a general purpose editor).


Here is some javascript that I use to compute all the offsets. I do it early so that I can create a single Buffer w/ the exact file size before any writes are done. This is the part that makes it so that you only have one offset per unique value.




I can check later, but I'm 99+% sure that they are not UTF8 and probably are straight ASCII. Windows of that era was pretty exclusively UTF16LE, which 2DA's definitely are not. UTF8 is a superset of ASCII, so most text editors refer to ASCII as UTF8 nowadays.

#62056 Editing offsets in binary 2DAs

Posted by ndix UR on 09 January 2018 - 11:24 AM

Looking at my code ... I think they are offsets into the data section. 16 bit unsigned little-endian integers. No delimiter. Double null bytes (or a 0 short if you prefer) end the offsets section.


Not sure how you would represent them or deal with binary data in Java. But they are 'short' in most architectures.


In my application I just treat them as integers/numbers because they are only used to read the values, once I read the values I don't retain the offsets in the object because it's a lot easier to recalculate them all when you write it back out. And when writing them out, it generally takes a proper binary writer that will know how to encode a general "integer" into a uint16LE for output.


The weirdest part, I thought, was encoding integers and floating point numbers as null-terminated strings to put into the data section.

#61093 Download:Traditional Mandalorian Blades

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

Posted Image


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 :D.


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