JCarter426

Not where there isn't a walkmesh, no. They'd be spawned to the nearest walkmesh, which would make them visible to the player in many modules - especially given how K1 likes its single-room modules.

Yeah, that would be an eventual possibility if the thing were finished. But just getting a gender change was buggy enough on its own.... I've tested the head thing in K2 separately but I don't have a handy video showing it because I never implemented it into the K1 code. That's more complicated because to accurately copy the player's head, including any modded heads, you have to use the DuplicateHeadAppearance() function and that specifically requires two spawned characters. That's what's used in the revelation flashback to copy the player's head onto the stunt model. This clone has to be spawned somewhere and I never figured out a good solution for the where. I still think the best solution would be a hidden utility room, if it didn't require editing every bloody area in the game to work. I've made a mental note that if I ever get into video game development, to include such rooms just in case. I've seen them in other games, and even KOTOR uses them sometimes, but there's no standardization here. The next best option would be to spawn them wherever (such as the player's location) but have the game fade to black during the whole process, which would probably only amount to a second or two anyway.

I remembered I had an old save from my testing, so I recorded what my work in progress was a couple years ago: As you can see in the video, though, I never finished debugging. The script started adding duplicate items to my inventory. Actually, I remember that started happening after I fixed another bug.... Anyway, it's not in any releasable shape, but you can see proof of concept at least. It's just a ridiculous and buggy proof of concept, which is why I never finished it. An easier option, I think, would be to eliminate some of the armor models to free up the slots. Keep different models for light, medium, and heavy armors but eliminate the other half and you free up three body slots. Then you could use those for such things as Republic armor or Darth Bandon's armor or whatever you want. Somebody could do a poll to see what armor models people want kept or eliminated maybe.

As the Dark Lord says, for K1 we're limited to the 9 body types in the game, all of which are already used for the player character. To be specific: A - Underwear B - Clothing C - Light Armor (Class 4) D - Light Armor (Class 5) E - Medium Armor (Class 6) F - Medium Armor (Class 7) G - Heavy Armor (Class 😎 H - Heavy Armor (Class 9) I - Jedi Robe J - Revan Armor Additionally, K2 has: J unused (there's no Revan armor item in the game) K unused L - Dancer Outfit (unused for male characters) M - Zeison Sha N - Jedi Master Robe You can change what models those slots use, and you can change which items use which slots, and you can create new item types and configure them to use whichever slot (including underwear) but you're locked with using one of the existing slots and any changes will affect all models in that slot. In K2, you can use the J and K slots for whatever you want, and in fact I released a mod that uses them for Republic armor and uniforms a long time ago. In K1, you're not so lucky. You could replace one of the models with the Republic soldier armor if you did new textures for every other item that uses the same model, or configure them to use a different model. I thought about doing that once, and I think I even made textures, though it was so long ago that I assume they were awful. There is a method of circumventing this, for either game. A really convoluted method that requires editing some core files that would be a nightmare for mod compatibility. But it would work. I wrote and tested some code for it a couple years ago and got a proof of concept going, but ultimately decided it was too convoluted to be worth doing. It would work something like this: You equip a dummy item. This doesn't have the appearance you actually want, just whatever placeholder you choose (perhaps clothing or underwear). It will only be visible for a few seconds. The player and party heartbeat script (k_hen_heartbt01) constantly checks what item the character is wearing. When it detects that the character is wearing the dummy item, it fires some new code that will ultimately give us the look we want. First, the script removes the dummy item from the character's inventory. Second, the script spawns a clone of the character elsewhere in the game. The main problem here is that due to the way the script functions work, the character must be spawned in the game world, even though we don't want to see this character. To get around this, one option would be to spawn them in an unseen utility room... but you would have to add such a utility room to every area in the game. Or maybe you could live with fading to black for a few seconds. Third, the script detects the character's size and gender in order to equip them with an item that matches their body type. The new item will be a disguise item, pointing to a new line in appearance.2da. Each body type would require a different line and item pointing to that line. This appearance is a placeholder - it won't have the correct head. Fourth, the script copies the head from the clone NPC to the player, thus restoring the player's original head. Finally, the script destroys the clone NPC. The heartbeat script also checks if the player has unequipped the disguise item in order to destroy it and replace it with the original dummy item. I've tested most of this - I had scripts to swap out the items working in K1, though it was a bit of a buggy experience. For example, part of the GUI would have to be disabled in game options or else you'd get a feedback note every time the item was changed. I only tested changing the gender in K1 and not the body size or head. I had it replace the Sith trooper disguise with a female version for female PCs. I did test the head thing in K2, and I believe I wrote code for the body size that could be enabled if needed. But I gave up working on it because it's just too ridiculous. I could be convinced to reconsider if there was enough of a demand for it, and maybe we could work out a compatibility solution for the heartbeat script, but at the time the stuff I specifically wanted to do with it - female versions of the Sith trooper, Sand Person, and Mandalorian disguises - was so minor compared to the amount of effort required to make it function, and it would never function perfectly, so I gave up. I think you'd be better off porting all of K1 to K2. That way you get the extra K, L, M, and N body slots and you can do whatever you want with them. Or just replace one of the nine in K1. I'd rather have different outfits like the Republic armor, Sith armor, dancer outfit, and so on rather than several slightly different looking armors that I'm only putting on for the stats, anyway.

Oh, a lady droid. Interesting. Doesn't the one on Nar Shaddaa that's bad at pazaak have a female voice already?

Yes, that's right, and the order in which the models are loaded would matter as well. As far as I can tell, the game saves rendered models to memory so it can read any new instances of the model from memory rather than starting over every time as an efficiency thing. And it saves them based on the model name rather than the file name, which normally shouldn't make a difference because all the original game models have them named the same. And with the functionality of the current tools, there's no reason to have them different, so in general you should rename the model base to match the file name.

You're missing the TXI files. The mods should've come with them, but for future reference what you need is a text file that reads: envmaptexture CM_Baremetal saved as whateverthetextureis.txi. Or envmaptexture whatever other shader you want to use instead of CM_Baremetal (CM_SpecMap, CM_Bright, mycube, etc).

Here were my results: And I've attached the most up to date files for anyone who wants to take a look. I believe all the problems (apart from the weird inverted alpha option) have been sorted on this one. Hand_Normal_Testing_v31.zip

I think somebody fixed the turret already, I just didn't have it installed. I can't unsee those pipes now, though....

I like to keep you all guessing. Or actually, it's a misshapen collection of fixes I've compiled over the span of years and as soon as they're done I forget what they are. From the pictures: The annoying transition messages, yes. That's the plot crystal, the one used to build your first lightsaber... I guess it's hard to tell from the regular crystal items, but it used to be they all had the opila icon. Now they look like the normal blue/yellow/green crystals. The protocol officer's hair seam. Wrists on the clothes were misaligned before. The placeable model was pretty bad before. There were metal parts hovering in the air; the UV mapping was terrible - somebody painted a mural of a droid onto the bottom of the kiosk, apparently; and I never liked the droid head because it looks like an R2 unit rather than a KOTOR droid, the head is too small to be from an R2 unii or a KOTOR droid, and the model is used for non-droid kiosks all over the game, so I thought it made more sense to remove it outright. Ack, you are correct... but what's fixed there is the Sith fighter laser color. The lasers were green in the original game, even though they're red in the Bink videos Full list of changes for v1.0 :

View File JC's Minor Fixes for K1 Summary This is a collection of various things that I found annoying enough to alter. I collect things that I don't think warrant their own mods into a single mod, to be released to the general public when it becomes more substantial. Contents I've divided this mod into five categories: Straight Fixes, Bug Fixes, Resolution Fixes, Aesthetic Improvements, and Things What Bother Me Fixes. Straight Fixes are fixes for issues I think are genuine errors or mistakes or oversights or what have you. There's a problem, here's a fix for it. No artistic license is involved. Bug Fixes really fall under straight fixes but I've separated them into their own category because they're more severe and there's absolutely no reason not to have them. They fix bugs that could potentially break your game. What I've included are either well known and easy for me to do a quick fix or came to my attention directly. There are lots of other bugs this mod doesn't fix, so I strongly suggest that you seek out a more extensive bug-fixing mod. Resolution Fixes are all textures from the game for which there were identical, higher resolution textures somewhere else in the game files. So I've swapped the lower resolution ones for the higher resolution ones. I've separated these from the straight fixes because a) I didn't make any of the content here - it's all extracted from the game, and b) they don't actually fix "problems" per se - it's just an increase in resolution. It looks the same, with slightly more pixels. Aesthetic Improvements are my attempts to improve the visual quality in certain areas. I've tried to maintain the original aesthetic of the game while improving the quality. But the nature of the improvements necessitates new content created by me. You might not like my work, or you might use a different mod that touches on these areas, or whatever, so I've isolated these from the other fixes. Things What Bother Me Fixes fix things what bother me. They might not bother you but they bother me, so I've isolated those as well. For a full release history, see the accompanied file. Submitter JCarter426 Submitted 08/07/2018 Category Mods K1R Compatible No  

Ah, ok. I did some testing and it didn't seem to make a difference whether the height map was there or whether it was all white. It really didn't like having an inverted height map on the alpha channel, however. Did some weird things to it. It should be, yes. And only when using a normal map. It's not an issue with the regular smoothing.

Well, like I said, I file the problem under "don't do that". It would be nice if you could have the tools fix it, but if it the problem can be avoided on my end, I don't mind sorting it. Maybe I'm still scarred by the dark times of NWMax & old MDLOps, but I'm used to adjusting my methods to make the game happy. It is good to understand why these things break, I think, even if the problems can be solved.

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.