ndix UR

View File HD UI Menu Pack HD UI Menu Pack for Knights of the Old Republic v1.1 - 20180318 by ndix UR (DeadlyStream user) This modification adds high resolution UI menu textures. 2K is the base resolution. The content is redrawn vector art, no modified scale-ups here. It is focused on menu backgrounds, and includes some of the overlay components for the menus. Pure Vanilla (PV) Edition aims to provide the closest match to the original menu texture assets. This mod doesn't touch a lot of the 'extra' menu-like GUI elements yet, such as the galaxy screen, computer interfaces, pazaak, etc. It also doesn't mess with the main menu at all yet. Requirements You must be running menus at a high resolution for this to really work. At the default menu size, this mod will probably look bad. You must have KotOR High Resolution Menus or an equivalent mod installed for good results. Known Issues The original textures were for 640x480 menus. The 4x sized textures in this package would look best at 2560x1920, which nobody really uses. If your display is less than 2560px width, you may experience seams where different textures are intended to meet seamlessly. The game just isn't that good at scaling UI textures with alpha channels used for transparency. There's nothing I can really do about it. There are some sprites in the menu processes that haven't made it into the package yet. They may sometime. I've added x/y clamping to some textures that should have transparent edges over 3D backgrounds. It makes the transparent edges work well, but the diffuse edges work less well. It seems you can't have it both ways, and this is the trade off. Install / Uninstall To install, copy the files from the package Override/ folder to the Override/ folder for your KOTOR game installation. To uninstall, remove the TPC files for this package from your KOTOR game Override/ folder. Legal THIS MODIFICATION IS NOT MADE, DISTRIBUTED, OR SUPPORTED BY OBSIDIAN, OR LUCASARTS ENTERTAINMENT COMPANY LLC. ELEMENTS TM LUCASARTS ENTERTAINMENT COMPANY LLC AND/OR ITS LICENSORS. The content of this mod is free for use and reuse, with no implied warranty, you can redistribute it, in original or modified form. If you do, a credit of some kind is nice but not required. Submitter ndix UR Submitted 03/15/2018 Category Skins K1R Compatible No  

It looks like that mod is intended to be distributed in a .mod file called nih.mod ... so I would assume that the files in that package need to be packed into a .mod (easy enough to do with KTool, by the way) and then maybe it would work? Actually there are also two .nss files without compiled equivalents ... so you might need to compile those scripts also? I haven't done much with scripts so I'm not sure on that part.

So, you might want to check out this thread: http://deadlystream.com/forum/topic/1726-bump-mapping-research/?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.

View File HD NPC Portraits HD NPC Portraits for Knights of the Old Republic v2.0 - 20200119 by ndix UR (DeadlyStream user) This modification adds high resolution rendered portrait images for NPCs. The 1K portraits have 256x the resolution of the 64x64 originals. The portraits are rendered to match the poses, expressions, colors, and lighting of the vanilla portraits as closely as possible given the following constraints: Only vanilla textures (and my own additional maps based on same) are used While the textures are quite low-res, most of the work was in material setup using a modern rendering engine, so even the vanilla textures still wind up looking much better than they have any right to. This is because of real lights, shading, and material properties, of which the original diffuse textures are only a part. I didn't really redo geometry, beyond appropriate use of edge split and subdivision surface modifiers. It also includes 1K versions of the darkened placeholder portraits before you meet characters in-game. BONUS There's a portrait for Trask Ulgo, because why not. Also I've included additional alternative non-vanilla expressions for Mission & Jolee because I don't care for their vanilla expressions. INSTALL / UNINSTALL To install, copy the TPC files from the package Override/ folder to the Override/ folder for your KOTOR game installation. To uninstall, remove the TPC files for this package from your KOTOR game Override/ folder. LEGAL THIS MODIFICATION IS NOT MADE, DISTRIBUTED, OR SUPPORTED BY OBSIDIAN, OR LUCASARTS ENTERTAINMENT COMPANY LLC. ELEMENTS TM LUCASARTS ENTERTAINMENT COMPANY LLC AND/OR ITS LICENSORS. The content of this mod is free for use and reuse, with no expressed or implied warranty; you can redistribute it, in original or modified form. If you do, a credit of some kind is nice but not required. Submitter ndix UR Submitted 03/03/2018 Category Skins K1R Compatible  

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.

My mistake, it must be a consequence of running KOTORTool through wine. I've never tried it on 'dows. I was unaware you first class citizens get blue normal maps from KOTORTool. For me, specific examples would be 'any'. I guess I'm not surprised though, you guys probably get real data in the TXI field too (I get truncated text or garbage. I pull my TXI text from the end of the TPC files w/ a text editor). I always thought it was odd too, because I had found a thread on LF where the author talked about figuring out how to process the channels properly... and yet it didn't match what my results. Thanks for clearing that up for me.

I used this technique awhile ago and actually encountered some drawbacks. xoreostex2tga isn't equipped to read or output animated textures. All told, for TSL, I wound up 129 textures short when I used this mass conversion technique. The other difference is a positive one, which is that they export normal maps in the standard 'mostly blue' form, instead of the KOTORTool 'mostly red' form. If you want the normal maps for use in other 3D packages, it is a very nice feature.

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

I've done a TSL Toasty Fresh weapon set for personal use that I used for a long time (and still use parts of). The problem with your crashing is likely from the shadow casting. The only way to make models not exhibit what I call 'the infinite shadow issue' is to make the meshes not have any overlapping parts within themselves. You can think of it as no hidden/internal/trapped faces ... here's an example: Sometimes, this issue just shows up as "weird" elongated shadows that seem to distort towards a point in the distance (when viewed from certain angles), at other times it causes crashing. I assume which behavior you get depends on lots of different factors. So I don't know if you'll want to fix TF's meshes, but you can always just turn off the shadow flag if you're looking for something quick and dirty. I think I just left them alone because there are only a couple that are bad and for me they don't crash, just have messed up shadows (also I only recently figured out what the problem is and how to fix it).

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

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

The TGA format includes an ability to say which corner is the 'origin'. GIMP gives you access to set this when you first save a TGA, for instance. The game expects a specific value (which I can never remember). If you make the wrong choice, your image is seen by the game as 'upside down' or mirrored horizontally. Probably Pixelmator made the wrong choice, maybe without letting you, the user, choose. If it's not that, you can get weird behavior from not having an alpha channel, so that's also an option.

I tried a lot of stuff to try and get this to work, but I am accepting defeat for now. Do you know of other lists in-game that are resizable with PROTOITEM extent? None of the ones I tried did, but I did not try many. This is far from perfect, but you can get it to a useable/readable state: For that, I used: PADDING = 32 on LB_GAMES, INNEROFFSETY = 48 on PROTOITEM > HIGHLIGHT and PROTOITEM > BORDER, ALIGNMENT = 10 on PROTOITEM > TEXT > ALIGNMENT

Just in case you aren't aware, your NaN issue stems from the fact that (most of the) rotations are compressed quaternions which aren't valid floating point formatted numbers (they are 3 floats occupying 4 bytes via a certain math/bitmasking algorithm, which is why treating them as doubles doesn't really help, both float/double have actual internal data structure (separation of value & mantissa, etc)). I decode and use them internally as unsigned ints (just 4 bytes, no funny business) but of course an array/buffer of bytes exported as hex will work fine too. If you were trying to decompress them for any reason, like if you wanted to be able to alter them in a meaningful way, you'd want them as uints so you could do the necessary bitwise logic on them (the required shifts don't line up at byte boundaries). The IEEE754 float32 type specifies a particular value for NaN, so when you read the NaN back in to recompile your model you wind up with a very different, defined, constant value for those rotations.

Yeah, it seems to me like only mods that add more than 16 placeables would be incompatible with K1R, if we are thinking of that as part of compatibility. Otherwise, my personal plan would be just to add verbiage like 'This mod uses 4/24 available placeable slots.' to my readme. When you get into the technical weeds of the issue, it relates to the client/server architecture from NWN, and the fact that walkmeshes were a server-side phenomenon designed to prevent clients from cheating. It is in the message from 'server' to 'client' where the 'low byte' cast from full int happens. Because of that, the only place I'd expect to see something similar (for a similar reason) might be in area models or doors, but thankfully neither of those are governed by 2DA lists in the same way. Actually doors sort of are, from genericdoors.2da, but I just checked and they seem to use a proper int and not a byte. So feel free to add many hundreds of door types (vanilla only has 65). I always assumed the 3 light issue was for shadow-casting dynamic lights only. Actually, I've always wondered what limits you could go to by adjusting videoquality.2da ... or whether those values are even really used? It has separate rows for dynamic and shadow-casting, now that I check. I did some testing in NWN not too long ago and it seemed like it could handle more than 3 concurrent shadow-casters. The idea of using visual effects on an invisible placeable is an interesting one.

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%. Figure 1. TPC with alphaBlending set to 1.0 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 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 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 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 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.

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.