ndix UR

I think I might have identified a bug in TSLPatcher. The problem seems related to files within .mod files (probably any ERF archive) that end with minus '-' or plus '+' before the extension (maybe anywhere in the filename?). Basically, the trailing minus and plus are getting removed. It doesn't depend on modifying the +/- files directly, just unpackaging and repackaging of the .mod file in order to add files or alter GFF files does it. The place this seems to come up is with danm14ac.mod in K1. It has two scripts called k_pdan_state1-.ncs and k_pdan_state1+.ncs which are part of the 'Murdered Settler' quest you get from Bolook on Dantooine. After you run a TSLPatcher based installation that modifies danm14ac.mod ... the resulting .mod file only contains k_pdan_state1.ncs. The file sizes of state1- and state1+ are the same so I'm not sure which one is winning out, but either way, the script name no longer matches the DLG file, and the quest becomes impassable. Not sure if this is fixable in existing code (with available time), but it's something to check in a newly written codebase. In the short term maybe it makes sense for mod-makers to manually include any affected files in their mods so that they are installed directly to Override/.

Interesting. I will look into it. I am assuming that these are all 4K textures? DXT1 or 5 (and does this change the behavior)? EDIT: Reproduced the issue, I think I've got it sorted. Next release will be fixed. Turns out that it is good to free malloc'ed heap memory copied into (and out of) emscripten compiled libraries (if only someone had told the dxt-js author ).

Happy Birthday (PST)! Mine was yesterday, so consider this the birthday hand-off high-five. http://deadlystream.com/forum/files/file/1004-alternate-revan-romances-updated/

I could probably do that, it was seeming a *bit* small to me, but I made it "exactly" 45cm as specified in the article. I found a screenshot of the SWTOR object you're talking about (I think), although I didn't find a shot of it with a human for scale. I was thinking I'd eventually add some clan-specific fancy versions, so maybe I'll do models closer to the SWTOR thing for those. I can see some other things I might adjust in the image also, so thanks for pointing it out. Not sure when I'll get around to an updated version, but when I do I'll make sure some of this stuff makes it in.

Here's my attempt (in case anyone reaches here by searching). Enjoy. K1: http://deadlystream.com/forum/files/file/1172-traditional-mandalorian-blades/ TSL: http://deadlystream.com/forum/files/file/1171-traditional-mandalorian-blades/

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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SPOILERS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You can find the objects in-game at... 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. Click here to download this file

File Name: Traditional Mandalorian Blades File Submitter: ndix UR File Submitted: 03 Dec 2017 File Category: Mods TSLRCM Compatible: Yes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Traditional Mandalorian Blades ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ for KotOR 2: The Sith Lords This modification adds traditional Mandalorian beskar iron melee weapons, the Beskad and the Kal. The weapons can be found and purchased in-game. The weapons have upgradeable Grip and Edge (because I couldn't figure out how to get just Grip upgradeable, which is what would have made sense to me), but they don't mention upgradeability in the description. 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 in size and relatively simplistic in version 1. 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 K1 Modder's Resource package). Thanks to JDub96 for requesting this. Re-distribute or re-use this mod as you like, in full or in part. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ COMPATIBILITY ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The modification is designed for use with TSLRCM. 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 Kex on Dxun (module 403DXN) or the Mandalorian mercenaries on Dantooine (module 605DAN). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SPOILERS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You can find the objects in-game at... 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. Click here to download this file

@Lucy, thanks for posting the screenshots. That second shot shows exactly what you get with an unpatched EXE. This is useful info for anyone else experiencing any problems. Either the patch is not happening when you run the hires_patcher.bat and put in your information (this would be indicated in the patcher's output text), or you're not running the patched EXE that it is producing. Another way to tell if the patcher worked is if it produces a swkotor.bak.exe backup of your executable. If there's no backup, it didn't make any changes and was not successful. That is interesting. All I did when I was testing is extract the TPCs, convert to TGA, scale up by 4x, and place in Override/. I just did some math and my resolution does happen to be 4x the default (in the horizontal direction). Not sure if that's a factor--it wasn't intentional. It is interesting though because my lbl_c_topm texture is 1024 in width, so maybe it gets cranky about down-scaling? That would be unfortunate. That particular GUI element for lbl_c_topm is 259 width base (texture is 256 width base), your res of 1920 is 3x, so the element itself is 777px at your res (1036px at mine). I would expect your 768 version to work flawlessly though... Here's what I'm looking at: The other textures in play there are lbl_cg_mcgtopl, lbl_cg_mcgtopm, and lbl_cg_mcgtopr.

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

View File KotOR High Resolution Menus Bubbling up from the font of dark knowledge, ndix UR presents KotOR High Resolution Menus, a UI mod package providing full high resolution menu and UI support for Knights of the Old Republic. The tyrrany of 640x480 menus and 6-item lists is over. Normally, when you increase the game's resolution using a widescreen patcher like UniWS, the menus stay very small in the middle of the screen and the borders get larger. This package is designed to be used *after* the widescreen patcher has done its work. It scales the menu screens up so that they fill the screen. This package requires modification of the swkotor.exe file using a supplied patcher, and is only known to work with GoG, 4-CD, and macOS (x86) versions of the game. It should be compatible with any Steam version that uses UniWS. The main content of the package are sets of GUI files (.gui), scaled for specific resolutions. The package contains GUI files for over 30 common resolutions with the following aspect ratios: 4:3, 16:10, 16:9, 21:9, and 32:9. Here is a list of the currently supported resolutions: Installation Find the gui.WxH folder matching your resolution, modify your executable using the supplied patcher, copy the GUI files to your Override/ folder. The details for this process can be found in the package README.pdf file. Read it. Follow the instructions therein. The documentation includes everything you need to know to manually patch your EXE if the patcher does not work for your version. Uninstallation Remove the GUI files, restore the original backed up version of your swkotor.exe file. IMPORTANT NOTES: This is not a resolution hack or widescreen patch, such as you get from using UniWS. You should already be successfully running the game at the resolution you are trying to get menus and UI for. Nothing in this package will give you any additional resolutions available. That is not what this does. If you are trying to get high-res menus for one of the resolutions supported by default (800x600, 1024x768, etc.) there is probably no point to using the GUI files named 'mipc*' provided by this package (mostly the in-game "HUD"), however, this scenario is untested. There are a few of the GUI files in this package you can use without modifying your executable. Here is that 'safe' list, in case you are unable to modify your executable: It gets you the main menu, some dialogs, and the in-game HUD elements. Thanks DarthParametric for testing, contributing a double-clickable thing for Windows users, and prompting me to finally figure out the needed EXE modifications. tk102 for GFF2XML and XML2GFF source code, which made it a lot easier to get this up and running. Known Issues The patcher is currently incredibly limited, making no effort to search for values, only looking at specific locations where they are in the executables I have access to. This package does not contain any higher resolution artwork. At high resolutions, menu backgrounds will be blocky, and the striped list backgrounds are unlikely to line up with list items. For numerous reasons, you will want to get a high resolution menu art package. The game's initial character selection screen does not lay out the selectable characters properly according to GUI file field values. It is useable, but not perfect. The blue hilight borders had to be removed from around the characters to maintain a clean look. The map screen is scaled up, but the map itself is not. Furthermore, the position of the map within the frame is somewhat random/poorly understood. The map, however, is completely useable, and the points of interest and player indicator are all positioned accurately relative to the map. Some of the 3D models in menus, such as on the character stats or character generation screens, display line artifacts over them. This is caused by the very low quality graphics being scaled up to provide the border overlays. Extracting the graphics as TGAs, scaling them up, and placing them into Override/ sometimes solves these problems. This package omits statussummary.gui and dialog.gui. Scaling them up cause problems. The files don't behave as expected, and it seems to not require a customized version in order for them to work as one would want. You might notice 1280x1080 in 21:9 even though it is not 21:9. It is for split-screen on 21:9 monitors. Rescaling the dialog/cut-scene letterbox (which is optional) seems to introduce occasional issues with letterbox placement, particularly when the letterbox animation happens. This may be fixed at some point in the future. There is no scaling on font size, and as far as I know no one has figured out how to do it, so users on TV/couch setups may not find the help they are looking for with this. Upgrading 1.4 to 1.5: If your resolution was not previously supported, copy new .gui files to your Override/ Upgrading 1.3 to 1.4: If you have Polish version, you can run EXE patching process If you have 32:9 display, copy new .gui files to your Override/ Upgrading 1.2 to 1.3: Copy all the .gui files to your Override/ Upgrading 1.1 to 1.2: Repeat the EXE patching process on a backup EXE if you want letterbox scaling Upgrading 1.0 to 1.1: Remove dialog.gui from your Override/ Copy 1.1 pazaakgame.gui to your Override/ Submitter ndix UR Submitted 10/29/2017 Category Mods K1R Compatible Yes

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 ************************************** TITLE: PMHC06 Fixed AUTHOR: ndix UR VERSION: 1.0 RELEASE DATE: 10/2017 FILENAME: pmhc06-fixed-tsl.7z A modification for Knights of the Old Republic II: The Sith Lords. -------------------------------------- INSTALLATION -------------------------------------- 1. Place ALL the files in the 'Override' folder of this package into your game's Override folder. -------------------------------------- DESCRIPTION -------------------------------------- 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: http://deadlystream.com/forum/topic/4610-renaming-bones-in-models 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. -------------------------------------- UNINSTALLATION -------------------------------------- Remove the added files from your Override folder. -------------------------------------- COMPATIBILITY -------------------------------------- This mod replaces the PMHC06.mdl and PMHC06.mdx files. It will not be compatible with other mods that do the same. -------------------------------------- BUGS -------------------------------------- Smoothing might not be perfect. -------------------------------------- LEGAL -------------------------------------- I place no additional restrictions on the use, distribution, etc. of this package and the files herein. 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. Click here to download this file

https://bitbucket.org/bead-v/mdledit

TLDR: the problem is understood and a fix is in the works. Thanks for the report, this was a fun problem. Skin mesh has a few structures that are equal in size to the number of nodes. Q & TBones for example. Past implementations have assumed that those nodes would be in 'name array order', the order you get by following the 'node number' read straight out of the node header. It turns out though, that those structures are in 'actual node order', which is the order you get via depth-first traversal. Most of the time, those two orderings are the same, but not always apparently. For whatever reason (my guess is something reordered the nodes in the presence of transparencyhint nodes), the models like N_DockOf have name orders that are very different from node order. The mismatch causes all the weights to to be decoded into the ASCII file with very wrong node names. The recompile operation actually works fine if you have a valid weights list (it just reorders the names list to match node order in the compiled output model).

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.

This is why good things happen when Tools 'leave the nest' and go into the world. Actually, in this version, the app expects a big multi-frame TGA image like the kind we normally make for animated textures. I could (somewhat) easily make it handle an input set of images (one per frame) though, and that sounds like it could be an improvement for some workflows, so cheers!

View File tga2tpc tga2tpc Author: ndix UR Release: Sep 2020 Version: 4.0.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 32-bit color normal maps without having to make them into simple height maps by using indexed color. 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. It includes a ported version of the AMD/GPUOpen Compressonator image compression library. ============================================================ 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 power-of-2 sized textures is always required for optimal quality, TXI information is optional, and the settings are pretty much self-explanatory. The nature of TPC alpha blending is not necessarily intuitive so you may need to seek information to use it properly. Compressor settings: Super Fast - the lowest quality setting, uses the pre-4.0.0 image compressor that includes the 'compression failure' error for long conversion queues Fast - Bare bones setting Normal - Runs two profiles and selects the best result, adaptive color weighting Slow - Deeper refinement of the color palette for each 4x4 pixel block Ultra - 3D refinement of the color palette for each 4x4 pixel block How Automatic encoding mode selects encoding for each texture in the queue: 24bpp TGA = DXT1 32bpp TGA = DXT5 8bpp TGA = 8bpp uncompressed isbumpmap1 or compresstexture 0 in TXI data = 24 or 32bpp uncompressed ============================================================ Features Create cubemaps Create animated textures Automatic compression selection based on trends from the vanilla game High quality DXT1/5 compression engine using custom ported version of AMD/GPUOpen Compressonator Multi-core image compression on systems with 4 or more cores Horizontal/Vertical flip, for those pesky wrongly oriented TGA files Bicubic downsampling for mipmaps (precomputed lower detail versions of the texture, part of the TPC format) Control texture alpha blending setting (part of TPC format), can be loaded from TXI file comments of the form: "# alphablending 0.67" Known Issues Cannot create uncompressed animated textures. Super Fast compressor has a memory leak issue, leading to errors for long conversion queues Using 4:1 and wider size ratios for individual frames of animated textures seem to crash the game. 2:1 is fine, 1:4 is fine, etc. Only for converting from TGA to TPC. For TPC to TGA, use Kotor Tool, xoreos-tools, tpcview, etc. Progress bar doesn't update as often as you might want. The package size is large. This is the cost of easy cross-platform GUI support. All electron applications are large like this. You are likely to have problems trying to read TGAs from folders containing markup entities/encoded characters (like ') ============================================================ Thanks 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. Submitter ndix UR Submitted 10/08/2017 Category Modding Tools  

Another thing I noticed today about the format is that they 'de-dupe' the data values, so one piece of data referred to in many columns only appears once in the data section. So you actually have 64K worth of 'unique' data space, and then you can combine those data into ~4 billion rows max. So that makes a bit more sense. It also explains why they would use uint16's for the offsets, because in all the 2DA's I've looked at, the offsets actually make up the largest portion of data in the file (in bytes). That would be the theoretical limit of the format. As DarthParametric recounted for Dragon Age Origins, I would be relatively shocked if any game's shipped 2DA handler was so correctly implemented as to let you take full advantage of the format.

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.