DarthParametric

Hrm. I'm not sure that I have the specific mesh I encountered the problem with any more. I know it was a Nautolan head that I ran through Turbosmooth. But the version I dug out of my crap pile is only around 8K tris/4K verts (if it were a single mesh - it's actually split out to about half a dozen). It does seem that was only a single iteration though. I think the mush version must have been 2 iterations as kind of a "let's see what happens" experiment. But running the source low poly through that still only comes out to ~32K tris/16K verts. Maybe it was actually ye olde MDLOps choking on it.

You keep the meshes separate. That was the entire point of splitting them. The original mesh (sans neck? I gather this is your collar thing?) can be left as-is. The new mesh you can just collapse the stack and do whatever you need to do to it to get the results you desire. You can add a new skin modifier later once any modelling is done.

Single skinned meshes up around 10K polys tend to turn to mush, presumably due to some upper limit for weights in the model format or something (@bead-v would know more). Shadow casting meshes above around 2Kish polys cause crashes. It's mostly the hair that's the problem, and that should be able to be completely separate static mesh, so you shouldn't have too many hard limits.

Pretty good likeness, but it seems like some extra subdivision wouldn't go astray.

Not for KOTOR work, no. Instances are duplicates that inherit the properties of the parent (and also vice-versa in Max's implementation). It's an extremely useful tool for rendering, since it uses far less memory than unique copies. In this case you need to select Copy. That will make a unique object that you can edit freely without affecting the original.

You can also use doors as well. Either via script, if you want it to remain permanently closed, or the door itself can act as a transition trigger simply by passing through it. The K1 Dantooine Enclave module (danm13) is a good reference, since it has one of each. The transition to the Ebon Hawk uses a trigger, the transition to the Courtyard uses a door. Edit: Ah, I see you have updated your post. Your proposed transition would need to use a trigger.

The Autodesk solution (or recommended action anyway) is, from an elevated command prompt in the GMax directory run: regsvr32 /u MAXComponents.dll Then: regsvr32 MAXComponents.dll

Looking at the model, looks like the smoothing group assignment is pretty ropey. Try this and see whether it is better or worse. Edit: The N_TatComW_F head also has a Joker smile baked into the texture, which is a bit disconcerting. I tried an AI upscale of the textures and painted out the extended mouth corners on that one. Edit 2: Based on some further feedback from @ebmar, I made additional adjustments to the UVs and texture for N_TatComW_F. K1_Commoner_Female_Head_Fixes_Revised.7z

That's why you hit that handy "never show me this message again" checkbox. Max is very sensitive about out of order stack changes, even though they rarely have any actual consequence.

Probably not an unsafe assumption, even if it is not the case in this specific example. Perhaps @DrMcCoy could shed some further light.

As when any such debates arise in game development - add a toggle for it!

What has been seen cannot be unseen.

I'm assuming these are all the debug functions? PrintString, AurPostString and the like? I was playing with those only yesterday and noticed that despite removing if (!ShipBuild()) checks, they still didn't appear to function. I assume they gutted them from the retail release altogether? While they are unnecessary for the code to run, I would argue they should remain in any decompiled scripts since, in the absence of commented source for the module scripts, the debug functions are the only thing remaining that can indicate developer intent. Additionally, the user can manually change them to SendMessageToPC for their own debugging purposes if needed.

Anticipation building for the announcement of the winners in 2021.

Deleting geometry is actually ok. It's only adding new geometry that destroys the weights. This was something I was going to come back and add after re-reading what Malkior said. Namely that you could select the appropriate block of polys around the neck region all weighted 1 to torsoUpr_g, then duplicate the mesh, on the original delete the selected polys, on the duplicate invert and delete everything else. Now on the split out neck piece you can add new geometry with impunity, as long as you don't reposition/alter the bottom ring of verts that mate to the rest of the body. Reskinning it manually once modelling is complete is trivial, since all the verts will be weighted 100% to one bone.

Since only walkmeshes support multi-materials, you'll either have to split the leaves out to separate meshes to assign a different texture, or create a new double width texture with both branch and leaf textures side-by-side. The latter approach may be the easier route if you have to completely remap them anyway. Max's UV tools are pretty clunky. I assume GMax's are even more limited, but the basics should be mostly the same. I'd suggest a search on Youtube. Some basic Max tutorials should be broadly applicable if you can't find anything GMax-specific. Just keep in mind that the lightmap UVs are stored in channel 2, so be careful you don't destroy those. Your problem with collars is going to be that you'll need more geometry to make anything half-decent, which will destroy the skin weights. There are ways around that, but GMax is not particularly ideal for it since it lacks some of the tools Max has.

The problem with the trees (or any other level geometry) is that new additions will need to be lightmapped. Given that we don't have the light positions used for the original bakes, you have to completely guess and do a lot of fiddling with settings/rebaking. Probably not what I would suggest for someone just starting out. Armour/clothes/robes are all skinned meshes, the same as heads, etc. Adding geometry or welding verts will destroy the skin weights, since weights are assigned per vertex and thus rely on unique vert ID numbers, so this is not something to be done haphazardly. You can shuffle vert positions around without affecting the weights, but there's only so much you can do with that. Especially since moving a vert too far from its starting point will likely introduce undesirable deformation during animation. You might want to describe in more detail what it is you want to achieve. Also, regarding Max, if you have an EDU email address you can get free educational versions of Autodesk products. Licenses should be valid for 2 years.

Here you go: K1_Temple_Summit_Bastila_Showdown.zip

Yeah, I'm sure we've discussed it before, but I don't recall ever testing it. I guess I should bust out a baseitems edit and see what happens.

There are only two races in KOTOR, Human and Droid. Wookiees and Zabrak are a Human sub-race. So the User limitation property only tells the game whether it is for Droids or Humans. In K1, Wookiees are restricted from using robes and such via baseitems.2da. I thought that the Sub-race property added in TSL could be used to do the same directly in the UTI, but it seems selecting Human as the sub-race just acts the same as the User Limitation. You can limit and item only to Bao-Dur or Wookiees, but not restrict them. That would still have to be done in baseitems.2da. @JCarter426 might have to weigh in on that. I have vague memories of discussing the denysubrace column in the past, whether or not it can be tallied to cover more than one sub-race. Armour and robes are divided into body types for different armour classes. What model is assigned for each is defined in appearance.2da. Revan's robes uses its own unique body type, body J. Hence the model name is PxBJ. You'll want to read up on how that all works before going further.

By default, companions don't have a body model assigned for the J slot (Revan's robes). It will required editing appearance.2da to add it in. Adding a Sub-race: Human restriction should prevent Bao-Dur from using it, since he is the Zabrak sub-race.

I think @bead-v just reused NWMax's snooper, and it's pretty barebones. There are alternatives around. The Dragon Age I/O script used one called YAGG, which IIRC did pop up a save dialogue. It's possible that the existing one can too, but maybe it's just not being fed the command to do so (the script outputs instructions to the Listener that tells it what to do). Since you input the export location in the base's modifier panel right above the export button, I imagine it was determined there was little need for it.

I'm not even sure what you mean by that. You shouldn't need to manually run it if the script is set up to launch automatically with GMax. Click the little up arrow in the taskbar to reveal hidden icons.