DarthParametric

I use KGFF for actual GIT (or other GFF) editing aside from DLGs for which I use DLGEditor (mostly), but Holocron Toolset's layout editor (if you open a module and double click on a GIT) is a very useful visualisation aid. It can be handy for quickly repositioning things and grabbing their co-ords, or editing trigger boundaries and getting the offsets, but I don't use it to actually save files because historically it had problems with adding spurious data. For cutscenes, I do framing/camera positioning and NPC/location placement in Max, and in the past I did all my GIT co-ord determination there as well, alongside a few helper scripts I have made over the years. I should probably talk to someone about adding equivalents of those to KBlender. Scripting I do in Notepad++ in conjunction with the NWScript language definitions. Vriff has created a new "Neo" line of tools though, so possibly I will work some of them into my workflow when I eventually get back into modding KOTOR.

No. Like I said, all keyframed objects are required to be under the A node in a room model. Never used it, and would never use it. I do any model adjustments in KMax or KBlender as appropriate.

Your arguments are wrong. The function is void PlayRoomAnimation(string sRoom, int nAnimation); So, for example, in my K1 Taris Upper City Cantina mod where I have monitors change their screen display based on your progression through the fight ladder, I have commands like PlayRoomAnimation("m02ae_03a", nDPAnim); Where m02ae_03a is the specific room model (the one with the Hutt) and nDPAnim is an int that is determined by GetGlobalNumber / GetGlobalBoolean lookups. The model has scriptloop01 through to 10. Additionally, all keyframed objects must be children of the "A" node. That is, the dummy with the room name with "a" appended to the end. You can see an example in your MDLEdit pic on the right:

Not as finished mods, no. I can make the assets available for anyone else that wants to do it though. Although I can't recall what state the Trando progressed to. http://www.darthparametric.com/files/kotor/misc/DP_TOR_Ports_Aliens_Trandoshans_WIP.7z http://www.darthparametric.com/files/kotor/misc/DP_TOR_Ports_Aliens_Wookiees_WIP.7z I have a set of KOTOR hand meshes with remapped UVs that fit the TOR hand textures if those are of use to anyone. I was far too lazy to deal with fixing TOR fingers. http://www.darthparametric.com/files/kotor/misc/K1_Hands_TOR_UVs.7z

You may not need to worry for armour. Like I said, it's really only for anything with exposed skin, or possibly any of the "skintight" torsos. It will look like this:

Oh, that's something I forgot to mention. For any model where you need a seamless neck join (like underwear or anything exposing the base of the neck/shoulders), you'll need to adjust the TOR mesh to fit KOTOR's low poly neck stump. It's literally a case of hexagonal stump in a round hole.

I haven't watched it, but judging from the thumbnail, probably. In specific regards to TOR models, expanding on what I said above you'll need to scale them by around 8 to 9x, depending on the target you're trying to match and rotate 180°. But the two big things are reposing the legs and arms, and adjusting the limb (specifically forearm) lengths. I usually found it was easier to just lop off the TOR hands/gloves and utilise vanilla KOTOR hands rather than try and reposition them. But that will probably vary a bit depending on the specifics of the source model and what rig you're targeting it to. As far as remapping skin weights goes, TOR heads use a lot more face bones, so those need to be condensed down to the nearest KOTOR equivalents.

Scale and position it to match vanilla KOTOR models, swap it to the KOTOR rig, remap UVs to fit it all on a single texture (at least if you want variants). TOR models use an A-pose, so you'll need to reposition the rig first before baking the changes. There are also a multitude of scale differences (like the torso and the arms), which typically makes fitting it to the KOTOR rig a pain in the ass.

The script's OnEnter appears to be: void main() { object trigger = GetObjectByTag("utt_belloq"); DestroyObject(trigger); ActionStartConversation(GetFirstPC(),"unk_belloq"); } So the issue is simple. You're destroying the script owning object (the trigger) while the script it is trying to execute is running. That instantly kills all commands in the script. I would suggest you look at some vanilla trigger OnEnters to get a better idea of how to do this. The two primary approaches are checking and setting a local boolean on the trigger (k_inc_utility has functions for this), or if you want to destroy the trigger either start the convo first and set the destroy on a delay, or signal an external object (invisible placeable typically) and have it fire the convo and destroy the trigger via its UserDefine. The other simple solution is to simply remove the destroy command from the OnEnter and move it to a script on the first node of the conversation.

You'd need to edit the mod's texture, presumably a TGA given the age of the mod, in an image editor like Photoshop, Gimp, etc. There will presumably be two separate textures, one for females and one for males.

Here you go. I'm not sure if your game being non-English will be a problem after being saved in my English version. Dantooine_Ruins_Door_Fix_xispect.zip Crash? There shouldn't be any crash. What you encountered is a "soft lock". You managed to break the script that triggers the cutscene, leaving you with no way to continue the main quest. I still don't know how people manage to break it, hence why it's not fixed. I can't replicate the problem on my end.