DarthParametric

You only want to be using the supermodel for the game you are compiling for. If you are compiling for K1, use K1's supermodel. It should also go without saying that the model must share the same rig as the supermodel. You can't use TSL robes with K1's supermodel, as they have different rigs (all the extra bones Obsidian added for the flappy bits).

B is what it should be, body-only. F is full body (i.e. integrated head).

And what is the value of the modeltype column? The supermodel is S_Female02. You need a copy of the binary supermodel in the same folder as the ASCII model to compile against. You should get a warning if you don't. What are you using? MDLEdit or MDLOps?

The supermodels contain all the animations. You've obviously grabbed one of the walking/running animation mods. Delete them all from the Override if you want to return to the vanilla animations.

If it is being used to replace the Dark Jedi, that's a full body model, so doesn't use a head. The appearance.2da line would need to be amended.

I'm not sure what it is exactly that you are having issues with, but check your Override for supermodels: s_female01.mdl/mdx s_female02.mdl/mdx s_female03.mdl/mdx s_male01.mdl/mdx s_male02.mdl/mdx

That's really something you should be directing to @ndix UR. It would be better to update the existing mod rather than make another one. Also, please don't needlessly quote the entirety of large posts like that. It just clutters the thread and makes it harder to read (and it's also a pain in the ass if I want to go back and edit things). If you want to bring something to the attention of a post author then quote a specific line or just use the @ symbol with their username to tag them.

Here you go: https://www.darthparametric.com/files/kotor/k1/[K1]_Player_Head_TSL_PMHC06_For_K1.7z I completely forgot until making this post that @ndix UR had already fixed this model previously for TSL, so I ended up reinventing the wheel a bit there (I didn't look at the hair mesh verts though, so I might need to go back and check those). I also hex edited the TPCs, adding the blending punchthrough TXI semantic, which seems to be necessary in K1 to get a clean hair alpha. The vanilla version of the textures was inducing a lot of haloing.

Just export the skin weights and load them back in, manually assigning the unlinked bones? Should take 30 seconds.

How do internal engine calls to case variants work on *nix systems? I know it fails on external calls like textures and GFF files.

You can either use a location armband like WhereAmI and run around in-game, or you can load up the level in GMax/Max and derive them that way.

NPCs are defined by a creature template, a UTC. Their position/orientation is defined in the module's GIT file. Basic idle animations are controlled via the scripts defined in the UTC. For background NPCs that are just static/standing around, you should be able to duplicate an existing NPC in the module and edit their specific details like tag/resref, name, appearance, etc., then add the positional detail for the new creature in the GIT. If you want more advanced behaviour, like patrolling/wandering around, this is done via scripts and waypoints. Again, looking at how existing NPCs work will get you most of the way there. Once you have everything in place, you will need to package up a copy of the entire module with your additions as a MOD.

Looks like a good improvement over the original, but my suggestion would be to get GLIntercept and use the freecam to zoom in for better screenshots. You can also try Googling "boab" for some reference material, seeing as that appears to be the kind of style they were going for. And if you really wanted to change things up, you could consider editing the level models and adding more/bigger leaf planes.

How's the length compared to a KOTOR character model? The proportions seem like it's a little short to me (or conversely a little too wide).

It would be good to get some formal updates for both KMax and MDLEdit on their respective release pages. I can't keep track of all these informal updates.

I've encountered some odd behaviour with the area tools. When loading K1's STUNT_57 layout it is duplicating most of the room models. It moves the empty duplicates to the correct layout positions and leaves the actual room models at world zero. Here are the relevant files: STUNT_57 - Rakatan Temple (LS End Scene).7z

Weird. How did it manage to do that? Due to something Max does? And how did MDLOps manage to deal with it? There were no noticeable issues in-game with the compiled models it produced.

So with the performance gains I decided to try getting rid of all the sprites and seeing what happened. This is what I came up with, 180K polys worth of static meshes: Somewhat surprisingly, the performance hit was fairly minimal. Something like 5-7fps. I'm interested to see if that improves with a condensed, monolithic mesh version, assuming I can get MDLOps to compile it. I'm not a fan of the apprentices/Sith, but they are placeholders. I'm wondering whether I should use some of the TSL models, maybe in conjunction with a separate mod that replaces all the K1 Dark Jedi with those as well. Edit: OK, god damn, it took MDLOps well over an hour (!) to compile, but I finally managed to test the monolithic mesh version of the crowd. As with the level model, it was a noticeable improvement, once again returning to a solid 60fps. So it seems that the real issue at play here is entity count? Too bad there's no practical way to animate the crowd as a single mesh (I think it would only be possible with PLA - point level animation). @ndix UR: What is your analysis of this performance issue?

Probably shorter, if anything. The source female model was scaled and skinwrapped to the K1 Dodonna model, so the body is more or less the same, but the point of attachment for the head is a bit higher in the K1 model. Aside from special ceremonial exceptions. I'm pretty sure every single military force has had consistent officer uniforms, with the only real distinction being various badges of rank. Not necessarily true. I believe you could cobble together something along those lines from TOR body parts. It would probably require custom textures though.

The source model is m44ad_01a. MDLEdit can successfully load and compile the vanilla ASCII. It crashes on loading the condensed ASCII. Initially I thought this may have been because one monolithic mesh contained more than half the level's polys (~26K out of 44K), so I split that out in to what I figured was more manageable chunks, topping out at around 4K for the largest. But it still crashed MDLEdit when loading the ASCII. https://www.darthparametric.com/files/kotor/misc/K1_m44ad_01a.7z Edit: @bead-v - When trying out variations of my crowd model, I managed to crash MDLEdit again on load by virtue of the condensed version where I combined all meshes sharing a texture into single meshes. I think this must be some upper face or vert limit per mesh that MDLEdit can't deal with.

Ahah! After what seemed like an eternity (must have taken like 15+ mins), MDLOps finally compiled the model. Much to my surprise, not only did the game not crash, but the framerate (for an empty scene) was now locked at 60fps except for one very brief drop of a frame or two in the pan to Revan's face. Very interesting indeed.... It seems like @ndix UR and @bead-v will have to compare notes on their level model compiling.

The water appears to be having a negligible effect. I deleted the water plane and at absolute best I maybe gained 1fps, but that could easily be explained away by the margin of error in my pretty sloppy testing. I also tried changing the CPU affinity to a single core. It didn't really make any noticeable difference when farmed out to an unused core, but I did notice that it maxed out utilisation the entire time it was running. Although that was for an empty scene. I'll need to try it again with a model-heavy scene.

I can drop the mesh count from ~330 to ~60 before it starts getting too tedious to bother. But given the way the light maps are split, there's actually not much to be gained by welding. A lot of the rejoined meshes are physically separate chunks. And presumably most of the welded geometry would be split again on export based on UVs anyway. I'll export this version and see what effect, if any, it has on framerate. Edit: This may require the assistance of @bead-v and @ndix UR, as MDLEdit chokes on my condensed version.