JCarter426

Ah, so it actually doesn't make a difference if I save the height map on the alpha channel. Or are you saying it generates a solid white channel only if there isn't an alpha channel already? Yeah, 1.0.0. That's the most recent version on the site? I flipped them all down and now it's fine: So I assume it's a relative issue. Although, it's possible that up and down matter for other things in relation to tangent space. I haven't noticed any other issues yet, though. For example, the legs are rotate 90 degrees, but I assume there's no issue because they don't smooth with any other UV islands on my model.

Dumb problem is dumb. So, so dumb. After "fixing" my model - I decided to start over with the arms, imported the original meshes, did a new skin wrap without chopping the arms up this time - I still encountered the highlight issues on the wrists. I barely touched the wrists that time, so it turns out it wasn't anything I broke. A surprise, to be sure, but a welcome one. It took me a while to connect the dots, and I couldn't have done it without you guys, but it finally makes sense. It seems that for the tangent space calculations, direction matters. Up always has to be up. And there's probably a very good mathematical reason for that, but without knowing that, and without having reason to check for that, it took me days to see the problem on the original game UVW map. The arm UV islands point down, with the wrists at the bottom of the map. The hand UV islands, however, point up, with the wrists and the base of each finger at the bottom. Just as the polarity of the UV islands was causing a problem on the shoulder seams, the differing orientation was causing the problem on the wrist seams. Probably most of what you listed were, yeah. The only part I did an extensive mapping on was the torso. I un-mirrored and realigned the skin part and completely remapped the underwear part. For most everything else, I only moved the UV islands around to make room on the texture. The boots and necklace were from her clothing model. MDLOps had other problems with it:

Cool, glad you enjoyed it!

Mm, ok, I'll give it a try later (probably after some sleep). The thing is that on the original model, the shoulders weren't on the same mesh as the arms. And the underwear was painted on rather than being actual geometry. I split the shoulders from the underwear, then decided to attach them to the arms thinking that would improve the seams. Then as a consequence, I had to remove the hands to get around the 16 bone limit. I didn't remap them because I didn't think I had to. But maybe I have to. Edit: After successfully transferring the problem from the right shoulder to the left shoulder, and then getting rid of that part, I think I can confirm that mirrored UV islands were indeed the cause there. I just never expected that to be a problem. So, to summarize for @bead-v: I un-mirrored part of a model (the torso) but left other parts (arms, hands) alone because it wasn't necessary for my purposes. However, this caused issues along the UV seams. Where the different UV islands met, there would be weird highlights from what I assume was KOTORMax/MDLEdit having trouble applying smoothing across those seams. The cause of the problem seemed to be the handedness of the UV islands. Since I mirrored one part of the map but not the other, they were facing different directions. Flipping the others so they're all flipped the same way seemed to solve the problem. No fancy UVW mapping was necessary - simply mirroring the problematic islands and adjusting the texture was enough. For some reason, most of the smoothing oddities seemed to go away when I removed my bump map. This might be another entry for the "don't do that" category, but I'm hoping any new information will help you somehow. I'm still figuring out the hands, but I expect I just broke something and there's no helping that. I meant to detach them along the UV seams and I noticed that I had not, in fact. i don't know what I did to cause the initial problem, but it was probably at that point, and any attempts to fix it have only made it worse. I'm now debating whether to start over with new arm meshes and a new skin wrap, or chop the model up differently, or try a new UVW map, or... what, I don't know. Not a lot of appealing options.

I don't expect it to anything for KOTOR, no. However, with the original height map saved on the alpha channel, it should be possible to retrieve it from the normal map, which as far as I understand is not usually possible. Converting an RGB bump map to greyscale height map even with Nvidia's tool will result in some quality loss because the normal map doesn't save all the information. Of course, it shouldn't be an issue for me because I have my original height map saved, but I think it's nice to have the option. It's in that area, yeah, but I don't see anything wrong with it. At least, nothing fundamentally different from the original model, or different even from the left shoulder which lacks the problem. I did some cleaning up with the UV seams (and attached new files) but I still see no difference. I also noticed some skin weight issues that I suspect were KOTORMax's doing (it had to remove excess data due to more than 4 bones per vertex) but I can fix those later. That said, I'd be very surprised if this wasn't my fault. I did edit the shoulders and hands specifically, so it must be. I had to edit them to get around the 16 bone limit and now I'm wondering if I should've chopped them up differently. Still, it is strange they go away when the bump map goes away.... Handmaiden Shoulder Issue_v13.zip

Yeah, I did notice the colors were inverted right away after you first mentioned, I just wasn't paying attention to the map before because when I'm not doing it wrong it's usually an automated process. Greyscale height > Nvidia filter > Tupac. I've got an adjusted workflow now... and actually converting to indexed color was a pain anyway, so I prefer this. I've also configured the Nvidia filter to actually save the height on the alpha channel now that it's an option, so that's also good. It's still difficult to see whether it makes any difference in the game, though.

OK, I had another go at it. It seems RGB > DXT5 works, while Indexed Color > anything is also fine, but RGB > Uncompressed and RGB > DXT1 crash the game. The Nvidia thing makes sense, though it would've been nice for them to say that somewhere. There's no need to muck about with the channels, by the way - it's a simple flag in the plug-in. It's hard to tell with KOTOR quality models which way is correct, but I'll trust your judgement. Sadly, the weird highlights are still there, though.

Huh, I was under the impression KOTOR maps had to be saved that way. To clarify, I first make a height map (attached) and use Nvidia's Normal Map Filter for Photoshop to convert it to an RGB normal map. I then save that in indexed color mode as I thought that was the requirement, though this is based on my vague recollections from the initial testing back in the LucasForums days... I think it was Darth_Sapiens' thread. Then I run the TGA and TXI with obsolete data through TGA2TPC and it makes the TPC and I thought it was working. It's strange that the Y axis would be inverted. There is an option for that in the Nvidia filter, but I hadn't selected it. I suppose I could invert the inversion, though I don't see what was causing it to be inverted in the first place. Edit: I ran TGA2TPC without converting the TGA to indexed color mode first and the game did in fact crash. JC_HandBA_H.tga

Hmm, no change. What did I do wrong? I saved as a power of 2 in indexed color mode and had Tupac compile it as usual, or at least I thought I did. Plus it seemed to be working - the highlight issue aside, it was at least bumping the parts that were meant to be bumped. You know, I'd been wondering if they were doing anything for a while. But I've been copying and pasting from the first bump map I did, so I always left them in. Thanks for clarifying.

Well, I'm back. The Handmaiden has some weird issue on her shoulder here, and similar problems on her wrists. It looks like a smoothing issue, but... well, the problem goes away if I don't use a bump map. Just removing it from the TXI data is enough - leaving the model as bumpmappable is fine. The weird highlights go away whenever the bump map goes away. But I don't understand that because that part of the bump map is solid blue. And if I do get rid of the bump map, different weird highlights pop up on her back. And obviously I'd want to not get rid of the bump map in any case. Files attached. I've included the binary model and all textures for once, in case it's something there I did wrong. Handmaiden Shoulder Issue.zip

You need to have the supermodel extracted in the same folder as the model when you compile for animations to work, and specifically the supermodel for the game you are porting to. For most female heads, this is S_Female03; for most male heads, this is S_Female02 (don't ask). However, you should know that you can't port a head by compiling it willy-nilly and expecting it to work perfectly. The lips will be messed up if you don't adjust them in a modeling program. I'm working on way to automate this process for heads ported from K2 to K1, but I expect heads ported from K1 to K2 will always need these adjustments, due to the numerous new animations in K2.

Yes, that's right. However, it was not Improved AI that was causing the problem, but rather the way the scene in TSLRCM was set up. That sort of thing is universal to the game - party member spots an enemy, scene breaks. stoffe's mod improves the reaction time for spotting hostile creatures, so it would guarantee the scene would break. I'm not sure why it wouldn't happen with TSLRCM alone, or if that is indeed the case, as I only know what has been reported. But in any case, the problem is resolved now.

View File JC's Zhug Attack Fix for TSLRCM Summary I noticed two issues regarding the Zhug attack in TSLRCM: Some of the appearances were wrong, so they were all clones of Azanti Zhug. More importantly, all the Zhugs were spawned as hostile. This would cause the cutscene to break if the AI for one of the party members spotted a Zhug and attacked. This had the unfortunate consequence of removing the choice to add a third party member to team up with Atton and Bao-Dur. This mod fixes both of those things. This mod requires TSLRCM version 1.8.5. It may not be compatible with earlier or later versions. Only 1.8.5 has been tested. Installation Run Zhug_Attack_Fix.exe. Click "Install Mod" and select your game directory (default name SWKOTOR2). Uninstallation Remove the installed files. Replace with backups if necessary. Compatibility This mod requires TSLRCM version 1.8.5. It may not be compatible with earlier or later versions. Only 1.8.5 has been tested. This mod is included in the KOTOR 2 Community Patch. If you use that, you don't need this. It may also not be compatible with other mods that alter the Zhug encounter. Credits KOTOR Tool – Fred Tetra TSLPatcher – stoffe K-GFF – tk102 NWNSSCOMP – Torlack, stoffe, & tk102 Permissions To the maintainers of TSLRCM: Maybe include this in the next update? If there is one? Maybe? To everyone else: I hereby grant nobody except myself permission to upload some or all of this mod anywhere for any reason. For any reason. If you would like to include any part of this mod in anything, then please contact me for permission. Disclaimers I'LL TAKE THE STUPID ONE, WHO DECIDED TO THREATEN US RATHER THAN SHOOT US WHEN HE HAD THE CHANCE. Donations If you enjoy my mods and would like to show your support in a monetary manner, you may do so via PayPal with this donation link. For various legal and ethical reasons, this is entirely optional and is not a requirement to downloading or using any of my mods. I also do not create specific mods for hire. I make mods as a hobby and will most likely do so regardless of any donations or lack thereof, but modding does take up a lot of my time and every bit helps. Submitter JCarter426 Submitted 07/28/2018 Category Mods TSLRCM Compatible Yes  

It should be possible with EffectForcePushTargeted(). That applies the same effect but you can specify a location, and I believe you could calculate the target location based on the player and enemy vectors.

This isn't possible because the game only changes animation based on what items are equipped- usually the weapon, but there is also the case of Mira's wrist launcher - and not the lightsaber forms. There is evidence that Obsidian intended to implement this, but they probably didn't have the time or budget to make animations for all the forms, and unfortunately they didn't program the stuff we'd need even if someone were to make all those animations. We're limited to specific animation sets: unarmed, complex unarmed, stun baton, single melee, dual melee, double-bladed melee, single blaster pistol, dual blaster pistols, blaster rifle, and repeating blaster rifle. If you wanted you could change any of those to do different things, but they would always depend on the type of item equipped and not on the saber forms. Plus you'd have to get rid of some of the existing ones first. Even if you had animations already, it couldn't be helped. It's an unfortunate situation, for example, that extra animations for Mira's wrist launcher exist, but there's no conceivable way to use them without replacing something else because on the programming side they only implemented the grenade thing. Force powers are a simpler matter. You need to write a script to handle the game mechanics, then apply it to a line in spells.2da. All the data that determines how and when the Force power is available to the player is configured there as well. You'll also need to add a line to dialog.tlk so the power will have a description in the GUI. That makes it somewhat of a pain as you have to use a token with TSLPatcher so the right line number is referenced, which is why I've never bothered to ever try making a Force power. TSLPatcher doesn't behave for me. I have thought about adding some, though, and in fact specifically Force pull. Maybe I'll get around to it one of these days. Also, as long as we're on the subject of Force powers and animations, I don't believe it's possible to add new animations for Force powers either. Again, we're limited to what are already used - even though, again, there actually are extra animations that are never used.

I... have no words for this. Don't do that. If you want to remove an item from your inventory, the easiest way would be to use the KOTOR Savegame Editor.