DarthParametric

Nothing of direct importance to modders. I gather it has something to do with data structures in the model format, but @bead-v would be the one to elaborate on its mysteries. You can't. It's an engine issue, due to the way it handles the render order of objects. It was likely a deliberate choice as the lesser of evils vs other render problems.

TOR doesn't use blur for saber trails. It's all VFX textures.

Looking at that, the UVs are uneven, but they are roughly in the right place for the texture. Looks to me like your eye texture is rotated 90 degrees. K1_PFHB04_Eyes_UV_Fix.7z PFHC04 on the other hand is something I can't really fix. If someone else wants to take a crack at fixing the smoothing, be my guest: pfhc04-kotormax.mdl.ascii Otherwise, you'll have to live with the vanilla model for now. Come back in 6 months after bead-v has done his MDLEdit update THAT HE HAS NOW TOTALLY PUBLICLY COMMITTED TO DO WITH NO CHANCE TO BACK OUT OF IT. *cough*

Yeah, but it's still crap. Just a different kind of crap. Make me a 2020 replacement for Taina's Replacer so I can just sidestep dealing with smoothing/normals altogether and simply inject my UV/vert position changes into the vanilla model.

What head is that?

The PFHB03 one is an easy fix. For some reason the head link flag wasn't enabled. K1_PFHB03_UV_Fix_v1.1.7z The problems with PFHC04 are shading errors. Since the original vertex normals get destroyed when decompiled into an ASCII, you have to do a lot of screwing around trying to recreate them. Damn your eyes @bead-v. I'll have to play around with that tomorrow when I get a chance.

It's a UV problem. If you want to change it you'll have to adjust them so they are properly symmetrical. As to PFHC04, I was only looking at the teeth meshes earlier, but I see now that the tongue mesh does protrude through the lower teeth mesh. That would need a mesh adjustment to pull it back a bit. Edit: Here, try these out.

The teeth use mirrored UVs. The are fine in the vanilla model, so the problem is your texture presumably. As to the eyes, eh, looks fine to me.

The first step is stop using sabers on Peragus you goddamn cheater.

Looking at some of the anims, there is maybe a bit more lip repositioning in the SS/Single Saber animations compared to the 2HS/Two Handed Saber anims. You could delete all the relevant keys on those SS anims, or maybe copy the positions/rotations from the equivalent 2HS anims. That would kind of be a pain to do manually though. Maybe you can hassle @JCarter426 about writing a program to automate it.

Looks like she has some duck lips going on in the single wield pose though. Are you using a supermodel mod? Not that I'd expect one to affect those particular anims in TSL anyway. Still, if you are it couldn't hurt to try removing them and see what happens.

Doesn't seem like there is anything particularly out of order with the skin weights for the lips/mouth/chin. Have you tried swapping to a different head to see if the issue occurs with them? If it does, then presumably the problem lies in some mod, since I don't recall seeing this issue reported before.

What's the problem? I can't see anything wrong with the mesh or UVs in the vanilla model.

It shouldn't be. The model formats are slightly different between the games. A TSL model will crash K1. Perhaps it could be in K1 format, but I thought that also caused a crash (although you'd expect that they'd have the engine load both). Maybe newly compiled K1 models just work properly now in TSL? Not sure, never tried it. That's a question for @bead-v.

Masks, blasters, vibroswords, etc. have never needed supermodels, even in the ye olde MDLOps days. Lightsabers used to require hijacking an existing binary saber model using the Replacer function, since MDLOps at that point couldn't write the proper saber model format. It had nothing to do with supermodels. But since the format is now mostly figured out and both MDLEdit and new MDLOps can read/write it properly, yes, all you need is just the ASCII files. Just be aware that the vanilla sabers (and some old saber mods) have an incorrect scale flag for the blade planes of the cyan saber (or in mods, sometimes other colours), which causes the "blade stuck on" bug. You'll need to manually edit the ASCII and switch the scale value to 0, just like in all the other saber models.

None. Lightsabers only have a couple of inherent animations (blade extend/retract, throw) which are on each saber model. Masks and other weapons have no anims. All other combat animations are handled by the character models. Each model will tell you if it uses a supermodel. If the supermodel field in the OdysseyBase says NULL then it doesn't use one.

This scenario wasn't about WIP threads, it was about request threads. It is entirely possible that someone could come along a couple of years down the track to suddenly fulfil a request out of the blue as new people looking to mod join (or if I get bored), especially with the abilities of tools increasing in recent years, opening doors that were previously closed.

"Think of how stupid the average person is, and realize half of them are stupider than that." - George Carlin

There doesn't appear to be any equivalent in the PC EXE.

Yeah I had a look in TSL's Xbox TLK and didn't see it. You'd have to look through the XBE. There's no trace in K1's PC EXE. Although regardless I tried what I assume are the equivalent keystrokes on the feedback screen, to no avail.

It shouldn't do either. It should look exactly like one of your earlier screenshots, i.e. you'll see straight through the torso to the other side because the back won't be rendered, since those faces are pointing away from the camera. You can see this occasionally with vanilla models, where there is some gap in the geometry, sometimes caused by incorrect weighting on adjoining verts, so it only happens during certain animations. You'll need to unwrap (UV map) it first. Then at the very least I'd suggest assigning a basic texture of the UV map to it to check everything is working in-game. To export it, the mesh will need to be a child of the OdysseyBase. It will need an OdysseyTrimesh modifier and a Skin modifier, although if all the verts of the original were weighted 100% to the upper torso bone you could alternatively make it a child of said bone and leave it as a static trimesh.

It doesn't hate them, it just doesn't render them by default. You should be able to "force 2-sided" in the object properties window (right click on the object, choose Properties). But as I said, the game will cull backfaces, so it's useful to see that in Max so that you don't miss a gap and have to come back and fix it later. That's probably viewport near plane clipping. See here for more info. Depending on how close you are trying to get, that might be an indication that you are working at the wrong unit scale. Shouldn't be, no, unless you have grid snapping enabled.

Well in a request thread, if the OP isn't looking for a response, then either someone fulfilled the request, or nobody ever did. If someone fulfilled the request, but the link is dead (highly likely in old DS threads, since it nukes old attachments), then I think it is appropriate for someone to necro the thread and ask if anyone still has a copy rather than make a new thread. If nobody ever fulfilled the request, then it depends on the nature of the new posts. A bunch of "me too!" posts adds nothing and should be considered bumping. Anyone actively trying to fulfil the request by creating a new mod should be encouraged to do so, since fostering the creation of new content should be the primary goal of DS, but perhaps they could be gently mod/admin-assisted in migrating to a WIP thread instead. I guess the point is that there need to be some rules around "low effort" necroing, but I don't think that it should be banned outright. Blanket rules are tools of the lazy and can needlessly stifle discussion/creativity. It's really a kind of case-by-case situation.

What matters is not the necroing of a thread as much as the reason/purpose behind it. If there's a thread about an unsolved bug or issue, and suddenly 3 years after the last post someone posts a solution, that's good content. However, if some numbnuts just starts randomly posting inane conversational posts in ancient threads that add nothing then that should be an infraction, akin to people bumping threads with multiple posts. Since this is often a habit of new members, I have long been in favour of manual moderation for any new member's first five or so posts, as is common policy on some other forums. No, I think public floggings are appropriate. There needs to be a demonstrable result of people's actions that others can observe. And hopefully learn from (but I wouldn't hold my breath).

Not that I can recall (or nobody would bother with GLIntercept). What's the button combo on Xbox?