DarthParametric

Made some adjustments to the lighting and the horizontal bars/surrounds. Also switched the exported texture from DXT5 compression to uncompressed, as there were some nasty compression artefacts (probably not really noticeable in a compressed video). I think it needs to be shifted a squidge to the right. And it could possibly stand to be narrowed up a touch as well to tighten in around the buttons, although it probably needs to be tested on other aspect ratios/resolutions first to see how it mates with ndix UR's GUI files for non-1080/16:9 resolutions.

I tried out the pre-rendered approach. After looking at the vanilla model (I replaced the original background plane with my own), I realised they used self-illum to brighten it up. I did that as well but I still need to fiddle with the balance of it, as I had compensated for the previous darkness by changing the lighting of the render, so now everything is probably a bit too uniformly bright. I can play with that later though. For the moment I am still messing around with different materials. I'm not really keen on the look of the horizontal blue stripes/surrounds, might need to fiddle with those a bit.

I did do an Anakin AOTC high poly hilt, but that is around 32K polys, not a practical game model. Here are a few KOTOR bits and pieces I could find. An untextured Vader ANH hilt. It could probably also be converted to an Anakin AOTC hilt without too much drama. The TOR concept/Ven Zallow hilt (very low quality): The Starkiller/Force Unleashed hilt that I could never get to work properly with MDLOps (should be fine now with MDLEdit though, a mere 9 years later): The Ki-Adi-Mundi hilt: An untextured Revan's hilt (apparently?):

Played around with a physical mesh replacement background. I tried adding it to the menu model with some dynamic lighting, but that was kind of crap: I was thinking about trying baked lighting, but it's probably just better to do it completely pre-rendered and keep it as an image. Needs various adjustments, but more in the vein of this kind of thing:

I was poking through my scrap heap earlier and noticed I have an ESB version that never made it past the WIP render stage, circa 2008. I can throw that one together as well if you want.

There appears to be a case sensitive issue where MDLEdit will not recognise the name of a node with differing case from the first instance, as per this example.

I dug out my ye olde Luke ANH saber and slapped together an installer for it. Also provided a straight override for the vanilla turquoise hilt. Not Kol's perhaps, but why settle for anything less than a genuine Graflex™? https://www.darthparametric.com/files/kotor/tsl/%5BTSL%5D_Luke_ANH_Lightsaber.7z

You chose a good time to return. The first step is to remove NWMax and grab KOTORMax. Then ditch MDLOps in favour of MDLEdit.

MDLEdit will handle sabers just fine. All it takes is a simple decompile and recompile to the other game version. There's no need for any of the complexities with the old MDLOps replacer routine any more.

The MDX is generated when compiled. You don't have to do anything to it. Loading the ASCII model, it looks fine. It's the same as the vanilla I_Mask_012 model - http://starwars.wikia.com/wiki/Stabilizer_mask Make sure your MDL/MDX is named correctly (I_Mask_050) and your UTI is pointing to the right model variation.

Your source model was I_Mask_012 and you didn't change all the references. However the cause of your error appears to be a case-sensitive problem - you have "parent i_mask_050" and it was expecting "parent I_Mask_050". That is a bug and should be reported to bead-v in MDLEdit's bug thread. i_mask_050_FIXED.mdl.7z

Seems like user error to me. There are no nodes like that in the vanilla I_Mask_011 model (for either K1 or TSL).

With the release of ndix UR's KotOR High Resolution Menus, I figured a K1 main menu model edit was in order. Nothing fancy so far, just a replication of the widescreen adjustment I released for TSL, stretching the background and adding in an extra VFX node (although I did replace the logo image with a less washed out one). The image quality of the background is terrible, even at its native res. It's full of artefacts and colour banding. I'm wondering whether a better approach might be to replace it with an actual physical model.

I wonder if vcard/driver is a factor. There is also things like that black line on faces, where someone with the same card as me gets it, but I don't, so it seems like variability is fairly high.

Inyri Forge did a Bryar Pistol for K1 - http://deadlystream.com/forum/files/file/601-bryar-pistol-and-bryar-rifle-by-inyri-forge/ I made a DL-44 aeons ago which was included as part of the KOTOR Weaponry Improvement Project - https://www.nexusmods.com/kotor/mods/134 (although it looks pretty terrible, blech) The various Clonetrooper mods include a DC-15. For example http://deadlystream.com/forum/files/file/392-k1-clone-wars-armors/ and http://deadlystream.com/forum/files/file/416-tsl-clone-wars-armors/ Kol Skywalker's saber is just a poor man's Graflex knockoff. You can get by with an ANH/ESB Luke or ROTS Anakin hilt. I made a Luke ANH hilt at one point, but it doesn't seem I ever released it. Oldflash did an Anakin ROTS hilt - https://www.nexusmods.com/kotor/mods/220/

I have made some quick and dirty placeholder replacements for the save/load, inventory, and equipment screens to remove the painted in lines that no longer match the dynamic GUI elements. Nothing fancy, just solid blocks of colour. They were for my own use, but I figured others my find them useful as well. They should remove the most distracting elements until someone creates a proper high res background repaint. K1_WS_Save-Load_Equip_Inv_Screens_PLACEHOLDERS.7z I found scaling up beyond a certain point (I think maybe it was a width of 1024?) caused the game to crash. But even going to the maximum stable size (768x96 seems fine), repainting the alpha channel, and trying various TXI semantics like clamp and downsamplemax I still get the line. And for those wanting to play along at home, lbl_c_topm is the texture in question for the party screen. I'm not sure what the character creation screen texture/s is/are.

Yes, the texture and model variation are tied together. For example, say I want to make a different coloured version of the Verpine Headband for K1. I dig out its UTI, g_i_mask11.uti, and change it to a custom variation number, let's say 75. So I change the ResRef and Tag values to g_i_mask75 and the model variation to 75, then save that as g_i_mask75.uti. Extract its icon texture ii_mask_011.tga. Edit the icon as appropriate and save it as ii_mask_075.tga. Then extract the model, i_mask_011.mdl/mdx. You can look at the binary MDL in a hex editor, or the easier route is to decompile it and open the ASCII model in a text editor. You'll want to change all instances of I_Mask_011 to I_Mask_075. You'll also see that the texture is I_VerpHBnd, so change all instances of that to whatever you want to call your texture. If you are hex editing you'll want to keep the same number of characters, but if editing an ASCII you can change it. For example, I would use something like I_DPHBndA. Then save if you are hex editing, or recompile if editing an ASCII. The model's new filename would be i_mask_075.mdl/mdx. Extract the model's texture, I_VerpHBnd in this case, including the TXI if appropriate (KOTORTool has an option to also extract a TXI). Edit the texture as you see fit and then save it as whatever name you specified in the model, I_DPHBndA in this example, and likewise rename the TXI if appropriate. Put all the files in your Override, add to your inventory with KSE, and load up the game to test: It's the same for TSL, except some of the filename formats are different.

Match your texture variant number to whatever you put in the UTI.

OK so upon further testing, it appears that I am suffering from a random crash on loading character creation that is unrelated to this issue, as I can induce it independently. So scratch that off the list. Additionally, I have also established that the problem is unrelated to UV changes/vert count. Basically the changes you introduced to fix the skin weight/node assignment issues in certain vanilla models now appears to cause that very same problem to occur in other models. To expound, take a vanilla model and simply decompile it, then recompile it. It should work fine, like so: 01_PMHC04_Edit_Initial_Compile.7z But if you take that 2nd generation binary model, decompile it and recompile it, you get something like this: 02_PMHC04_Edit_Decompile-Recompile.7z If you look at the ASCII of the 2nd one, you'll see the skin weights assigned to wrong nodes issue, as I showed in my previous post. If, however, you decompile and recompile the 2nd generation binary model with one of the older builds of MDLEdit like v0.5.0, you do not get this issue. Skin weights remain intact on subsequent decompiles/recompiles. 03_PMHC04_Edit_0.5.0_Decompile-Recompile.7z

I wasn't talking about creating a new cube map. I was explaining how you use an existing cube map to make your new texture shiny.

PMHC04 from TSL, but the vanilla model is fine. The problem is with a modified version of it, as described.

It seems like edited models with differing numbers of verts and texture verts may be causing the game to randomly crash (not 100% certain as yet). On trying the old decompile/recompile trick, skin weights are being assigned random non-bone objects much like the issue with vanilla models above, like so:

Cube maps are the envmaps, CM_Baremetal and so forth (that's what "CM" stands for). If you want something shiny, you paint those areas dark in the alpha channel, effectively making the texture transparent in those areas and letting the envmap show through (as long as you specify an envmap in the TXI).

Subscribe to TSLRCM on the Workshop first, then subscribe to M4-78. After that, manually install all your other mods to the M4-78 Workshop folder.

There is zero difference in how you texture a KOTOR non-level* model regardless of whether it is a prop, a weapon, a body, a head, etc. RGB diffuse and alpha for either transparency or cubemap blending. The only change is now with the new tools you can additionally make use of a tangent space normal map, but again that applies to everything. *And even in the case of level models, the texturing itself is no different, you just need a second non-overlapping UV set to bake your light maps.