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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~COMPATIBILITY~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~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 willnot work with other mods that provide w_vbroshort_041 or w_vbroswrd_041.

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

You can find a set of Beskad & Kal in a footlocker near a group of Mandalorians on Dantooine.

The Mandalorian commander in the Hidden Hunters quest uses a Beskad, and drops Kal & Beskad.

To cheat the objects to yourself in-game, with cheats enabled, use the following codes:giveitem w_beskad_001giveitem w_kaldgr_001

THIS MODIFICATION IS PROVIDED AS-IS AND IS NOT SUPPORTED BY BIOWARE/OBSIDIAN ENTERTAINMENT OR LUCASARTS OR ANY LICENSERS/SPONSORS OF THE MENTIONED COMPANIES. USE OF THIS FILE IS AT YOUR OWN RISK AND THE ABOVE MENTIONED COMPANIES OR THE AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGE CAUSED TO YOUR COMPUTER FOR THE USAGE OF THESE FILES.

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

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**************************************