JCarter426

Good job on the porting, but you got fooled by Obsidian's poor naming conventions. That model is called Sith Assassin but it's actually the one used for the Ubese bounty hunters. I believe the assassin body models are n_darkjedilowf and n_darkjedilowm and the head is named similarly although I don't know which one it is offhand.

@A Future Pilot recently made her put clothes on when she's talking to her brother. I think that will balance out the karma.

It's possible, yes. Things are in motion to make it happen.

Hmm, when MDLOps runs it should say it's loading the parent supermodel. If it's not doing that, then that would suggest something is wrong with the ASCII file. First, I'd say you should make sure the ASCII file was decompiled with the most recent version of MDLOps and not an earlier version or KOTOR Tool's. The other thing you could try is MDLEdit, which has more or less the same procedure but uses different compiling methods.

A supermodel is a model with animations on it. The model (in this case Sith assassin) is parented to a supermodel (in this case S_Female02) and gets all its animations from that. Most models don't have animations on them and instead get them from the stock set of 5 supermodels so they all have all the animations available on those models. Because efficiency and such. Misunderstanding. You don't need to put the supermodels in Override as they're already in the game. And copying binary models from one game to another is bad, as you've experienced. However, MDLOps needs a binary MDL/MDX supermodel in order to properly compile any body model. So when you compile, you need to have: a) The ASCII model file you're compiling b) The binary MDL file for the supermodel your model uses c) The corresponding MDX file for the supermodel source - all in the same location. MDLOps will then generate the new MDL and MDX model files for your model that you want to put in Override. The issue here, though, is that you get different results depending on what you decide to use as your supermodel. This is where the approach turns into a sledgehammer, but what I would suggest in this case is extracting S_Female02.mdl/mdx from both games and try compiling the assassin models twice, using each one as your source supermodel.

But do you want to do it properly or do you want to do it for KOTOR?

That is what I'm talking about. That's not always true. I'm not exactly sure what causes it in every case, but I've experienced problems with compiling a model with the supermodel for the game it's being put into rather than the game it came from. For K2 body models ported to K1, this often results in the animations on the left arm breaking. Some things do, however, have to be compiled with the source matching the game it's compiled for - face bones won't animate if they're compiled with the wrong one, for example. In the case of the robe bones, a K1 supermodel can't be used as the source because it lacks those bones and therefore it'll never compile properly for them. I had to jump through some hoops to get the bones to animate on a K1-compatible rig. But despite all these complications, for every model I've ported so far, something has worked. Just a matter of figuring out the right combination of things.

You might have to try using the other game's supermodel as the source then. It's tricky to navigate because different things will break depending on which you use, but there is a process that works for everything.

First, put some clothes on. Trask can tell you how. Second, in order to compile a body model, you need to have the supermodel in the same folder for MDLEdit or MDLOps to read and get the proper animation data. For that model, the supermodel should be S_Female02.mdl/mdx. Just extract it and put it in the same location as the other model. Although, you may have problems depending on which game's supermodel you use, due to differences in the models. You might have to try both. I'm not sure what the issue with the head is, as there are no secret modeling rituals here. Most likely you've set something in the 2DAs incorrectly.

There's a new episode of KOTORadio out and I'm mentioning it in particular because this was a special occasion. It features two Deadly Streamers, with a special guest appearance by Jennifer Hale. Last summer, @Jenko came to visit me and we hijacked the show to record a commentary of KOTOR Episode I: A Familiar Path, the special edition of the original movie by @KOTOR_Trilogy. We talk about how we ended up remaking a fan film from 10 years ago of a video game from 15 years ago and get into some technical details about how we did that. Mr Director calls it our ".kor commentary". I've edited our commentary together with footage of both the Special Edition and the original Episode I, so you can listen to it and watch both versions of the film side by side. We made the Episode I Special Edition after the rest of the trilogy was complete, so be warned that we do mention some spoilers for Epiodes II and III, and a couple for the @DarthYcey films. And of course for the games a well. If you haven't seen any of our films, the best place to start is here. And now here's the commentary: And yes, that really is Jennifer Hale.

K2 will recognize one layer of folders in Override. At least on the one true version installed with 4CDs; I can't attest to anything else. If you have multiple copies of a file in different folders, it loads only the one in the first folder, alphabetically. I don't remember whether files in root take priority over files in folders or not. K1 as far as I know doesn't support them at all.

I've done that too, still kind of bleh. In some cases it's just been quicker to do it manually by deleting the hand bones from the model and importing it from a project I'd prepared earlier with the hands already there. Usually it's only one row of vertices and they all have the same skin values, so it doesn't make much of a difference. Still bleh no matter which path you choose, though. Would be nice to be able to make bead-v--I mean KOTORMax do it for me instead.

Cool. As it is, I'm super happy just knowing what the problem is now. When it failed before I would merge the objects and redo the hand weights manually. Bleh....

I don't have a bug to report this time but more of a feature request. I just figured out the solution to a problem that has perplexed me for a while. I know how to fix it, but it's a little time consuming so it would be handy if the fix were built in. One of the hack ways I edit models is by copying text from one ASCII file to another in Notepad, so I can import meshes from different models weighted to the same set of bones. The most common situation, and what I was doing in this case, is to take hands from a player underwear model to replace the hands of an armor model either to get rid of the gloves or, in this case, to put female hands on a male armor. Editing 3D models in Notepad sounds dumb but I find it easier to edit when it's imported all together and weighted correctly. It works for the most part, though KOTORMax's import script will fail if there's a reference on a mesh node to an object that doesn't exist. A common occurrence is I copy arms from a K2 model onto a model that originally came from K1 and forget about the sleeve bones. KOTORMax understandably freaks out if it's told a skin has a bone that doesn't exist. But in the past, it would give the same error even when I knew everything should check out. And I just realized it's because the import script is case sensitive. So it doesn't know that lhand_g is the same thing as Lhand_g, and so on. The game doesn't seem to care; the cases are inconsistent from model and that doesn't matter. But apparently it does matter on import.

Huh, I realized (only after ten years) that you could do that with doors, but I didn't realize you could do that with placebles as well. Is that ever used? I also remember the animations being limited by the object type. There's a chance I just did it wrong, but when I tested it before I was unable to script placeables to use anything except the placeable animations. I forget what I was using, but say I was trying to script a dance animaton - I added the animation to the model and then scripted the dance animation, but nada. Creatures have tons of animations so it shouldn't be an issue, but I imagine doors would be limited to however many there are, I think 9 or so.

Yeah, the same thing happened to me. I just did a quick select by material to attach everything, but MDLEdit wouldn't load the model. I remember something similar cropping up with a few specific areas during the MDLEdit beta testing so maybe bead-v can explain it. Manaan seems to run fine though? That certainly could be an contributing factor, and it may be worth removing it for the other reasons you mentioned, but I doubt it's just the water. Some things I could maybe write off due things like water or grass or the size of the area or lots of NPCs spawned, but that wouldn't account for everything. I've never been able to nail down a pattern on the areas that have had particularly bad lag, though, and my hardware has changed over the past 15 years too.

Oh I know it can be done, but I'm not sure how to go about it in a way that's quick or easy. I don't think you can do a quick welding of vertices without potentially messing up other things, so some of it would have to be done manually... a lot of effort just to fix one area, and any other areas would be need to be fixed on a case by case basis.

Ah. I'm surprised there'd be noticeable lag with only that many of them, but I guess not too surprised. It might not be just the number of objects on the model - it could also be the number of elements on each object. It looks like a lot of faces, particularly on the pyramid, have been needlessly detached as separate elements. If that is the source of the problem, though, I don't know of a quick and reliable way to fix that.

Sounds like you're having better performance than we got before, maybe thanks to the lite models or the static poses. With full quality (well, KOTOR quality) animated models for everything it was dipping down to the single digits on that pan. But it's dropping even with nobody there? There must be something weird going on in that area. It's always been a mystery to me why some areas perform worse than others. As you said, this is a tiny area and I remember the stunt module lagging more than the regular game one, so that's doubly mysterious. @VarsityPuppet recently suggested it might have to do with how many elements the models are broken up into, but I don't know if anyone has ever properly investigated what's really going on.

@Jenko did this before and found that once everything was replaced with actual models the frame rate drops into the totally unacceptable range. We tested various scenarios with different things changed and it seemed to be specifically the poly increase. My guess is it's when they're animated. The area geometry can have tons more polys, and those droids might be ok because they're just standing there. But when the humanoids were upgraded from rectangles to actual models, even an idle pose was too much for the game to handle. Maybe you could make higher quality cardboard cutouts, though.

I meant replacing them but keeping the existing shots vs replacing them and adding new shots. In the former case it would be possible to still keep the original audio. But if you would prefer that to be replaced as well, well....