DarthParametric

Against my better judgement, working on another head port:

Just make sure that if it is just planes that (after UV mapping) you duplicate it and flip the normals, since Odyssey does not render backfaces.

K1CP edits several AREs, but none that overlap with your changes (currently). Still, module injection would be the proper way to do this.

Nobody was telling you to install it. You were instructed to take its version of TSLPatcher.exe, that's all.

https://deadlystream.com/files/file/1258-kotor-1-community-patch

TSLPatcher works fine for all versions of the game. It will prompt you to browse for the game's folder if it can't find it, but most modern mods don't even set automatic game folder lookup anyway. What you can't do is use the Workshop for the Steam version of TSL. As long as you don't do that, you'll be fine. TSLRCM doesn't use TSLPatcher at all anyway, so that's moot. Neither does M4-78 as I recall.

You always need permission to reuse/distribute any author's work, unless they have explicitly stated in the readme/description that they allow reuse/redistribution without permission. So if you want to redistribute one author's model and another author's texture then you need permission, again, unless one or both has stated otherwise. The problem you are going to have in this case is the likely impossibility of contacting ToastyFresh. You'll have to talk to the DS admins regarding their position on that. Recompiling models to suit a particular game isn't difficult for weapons. You'll want the latest beta version of MDLEdit. Since you'll presumably have a bunch of models to work on, start by batch decompiling them. In MDLEdit, go to File -> Batch -> Convert to ASCII. In the window that pops up, select all the MDLs and hit the Open button. Wait for it to finish. Now you can delete all the original MDLs and MDXs. Make sure you toggle the game setting to KOTOR2 (button on the top left) before compiling. You can batch compile all the models at once via File -> Batch -> Convert to Binary, but be aware that you'll need to manually edit all the filenames, since they'll all be called something like "w_vbrdblswd_001-mdledit-mdledit.mdl" etc. Your other option is to manually compile them one at a time, which will allow you to edit the filename before saving (File -> Load to load the ASCII, then File -> Save -> Binary). If you have a lot of files to deal with, you may want to look into some sort of batch renaming tool to get rid of the cruft in the filenames.

The more practical route would be for someone to develop a batch model converter. It would have to be black box and newb friendly.

Ah, that one. Yeah you're out of luck for a texture for that one, but here's the UV template:

If this is an existing untextured TSL head then it is just leftovers from K1 and you don't need to re-unwrap it. You can easily dump a UV layout image from Max or other 3D apps, but since it presumably already has a texture in K1 you just need to identify which it is. What's the model?

Yeah I would just start with a copy of the original star map, delete everything except the base and the meshes you are going to replace. Add your new meshes and give them the same pivot position/orientation as the originals. Export that as an ASCII when done. You don't even necessarily need to delete the originals - you could just disable their render flag. They might be useful as shadowcasters. That would also make your life easier for the merge, since if you make your new meshes each children of the originals, then all you need to do is paste the data for your new meshes at the end of the geometry list , since their data block lists their parent object (although you would need to edit the render flag settings of the originals). Order in an ASCII is more or less irrelevant, outside of listing parent objects before children. I'm not sure if that is strictly required, but MDLEdit is kind of finicky so better to be safe than sorry.

I don't use Blender, so I couldn't tell you how to handle that side of things. Here's what the top of the hierarchy looks like in Max: So you'd have to deal with the legs being below parts you'd (presumably) retain from the vanilla ASCII. It's actually not too difficult if you use Notepad++ and the Aurora MDL language definition for it. That will let you collapse each mesh/object so you can easily select and excise bits you don't need:

Pretty sure I already told you how to do this. Just copy and paste from one ASCII to another. Export your geometry in the same hierarchy as the original and all the pivots and rotations are the same, etc., then copy and paste all the emitter nodes, etc. and anims from the vanilla file. Possibly you may have to fiddle with the hierarchy to makes things easier.

Perhaps @AmanoJyaku could be persuaded to look at k_plev_throwdown in lev_m40ac, since that looks to be where it is set, but DeNCS cannot decompile it.

The only way that would work would be to be have separate racial texture assignments for that model in appearance.2da. That would mean you'd need to duplicate the vanilla textures for the other variants of that armour to match the new naming convention. But if you change the UVs you'd have to remap all those textures anyway, so it's really not that big a deal.

All of that is pretty trivial these days with the available tools. The only real limitation is adding additional planets/locations to the galaxy map, since there is a hard cap to the total number possible (but you can get around that in other ways).

Pretty sure that's just Davik's armour. Loot it off his corpse before getting on the Hawk the first time.

As alluded to in this post, it's because there isn't a single "ready" animation like there is for dance, etc. Each weapon type has its own separate ready anim. Since you can't script arbitrary anims in K1, unlike in TSL, specifying it in a DLG is the only way. I assume that the ANIMATION_LOOPING_READY scripting constant is supposed to work the same way as the DLG version does, but it seems not to be the case. Perhaps some intrepid soul that has delved deep inside the internal workings of the engine, like @ndix UR, could shed some light on what is going on under the hood.

I'd just remake the map geometry and then you can transplant all the emitters and so forth back into it afterwards (literally just copy and paste it into the ASCII).