DarthParametric

With the rules regarding porting changed, it probably makes more sense to port the TOR Selkath over. Come back in another 12 months.

Speaking of the TSL textures, there's one there that I don't even remember seeing in the game, but it would probably make a good basis for some colour variants (probably more so for females): Edit: Here are a few quick palette swaps for the female version that you could add as new variants or replace existing ones with - https://www.darthparametric.com/files/kotor/tsl/[TSL]_Commoner_Female_Texture_Variants.7z

You could do something like VP's Onderon Traveler Clothing mod and swap the commoner clothing models out for that. And now with the porting rules being relaxed, you could back-port it to K1. There are also some higher res commoner clothes texture variants in TSL, which again could be back-ported to K1.

Ah, my bad, for some reason I interpreted SH as suggesting the lines be re-recorded. As far as "true" meaning goes, I don't think there is any. You (or someone else) will just have to headcanon something.

Wouldn't adding subtitles be better if you want to know what they are saying?

You can see all the pertinent model/texture details here - https://swtor.jedipedia.net/en/npc/jedi-entity She uses the same head as Jedi Knight companion Kira Carsen.

I think the Reven head would require some fairly extensive texture work, as it has those scars/wounds. There is no unique appearance for Meetra that I can see. They just used a generic NPC and slapped a ghost VFX on it.

There are Max import scripts that import the TOR skeleton, so that's not a drama - https://forum.xentax.com/viewtopic.php?f=16&t=11317 (don't forget to grab the update on page 2). The problem is you can't get the KOTOR rig and animations out of Max, at least not in a form that Motionbuilder would work with. I think the only practical option currently would be to create a new KOTOR rig from scratch using actual bones. Unless someone created a Max script that automates the geometry to bones process. Edit: Well, well, here is something quite interesting: This is the K1 male rig in Cinema 4D. I discovered that you can use the Max Bone Tools to mark any object as a bone ("Bone On"), so when you export the KOTOR rig as an FBX you get proper bones in other apps. And you can also export the animations, as our fine dancing friend here demonstrates. Somewhat ironically it doesn't look like this when importing back into Max, as for some reason the FBX importer screws up the bone sizes so they end up as tiny cubes. The only real problem I can see now is that the TOR import script imports the meshes/rig rotated 90 degrees. I wonder if we might be able to get someone like @bead-v to have a look at it and add in a snippet that would correctly orient it? It would still need to be scaled, but that can probably be done manually. Edit 2: So setting the FBX import dialogue bone option to "Convert as Dummy" solves the problem of the bones being the correct size/shape in Max, albeit as dummy objects rather than true bones (it also causes some weird visibility issues unless in wireframe mode). Looking at a TOR import, it seems the root bone of the rig ends up with a Y rotation of 180°. Meshes have their rotation values at 0°, despite being in the same position. Based on that, the scripts ideally need adjusting to do a -180° Y rotation and a 90° X rotation to import TOR assets in the same orientation as KOTOR assets. Scaling still needs to be examined in depth, but from a cursory glance it looks like a BMN rig is going to need to be around 87% of the original TOR scale to match a medium K1 male rig. I haven't looked at a female yet. Edit 3: After some Googling I came across some Maxscript that will allow for a quick and dirty rotation of the current object selection: ( group selection name:"MyGroup" select:true $MyGroup.pivot = [0,0,0] rotate $MyGroup (angleaxis -180 [0,1,0]) rotate $MyGroup (angleaxis 90 [1,0,0]) ungroup $MyGroup ) You can also insert the line select $* at the top to automatically select everything in the scene. But this will add those rotations to every object, which is probably undesirable when dealing with bones/animation. I'd prefer to "offset" the world axis during the import so that the original rotations are retained. Edit 4: So I am guessing that the TOR team must use Maya. That would explain the models - they are in a Y up, Z forward facing (right-handed?). KOTOR needs a Z up, Y forwards facing (left-handed?). My meagre understanding of these sorts of things is that this can be solved with a matrix transform.

I remember there was a thread about it on the sub-Reddit where people were slowing down and playing with the audio. IIRC some of it was reversed. I can't remember if it was actually anything or just gibberish though.

Hah, I wondered how long it would take this to resurface. You could directly port one of the TOR heads now.

I haven't really looked into how the post-race stuff triggers. Although what you describe is basically what I was referring to above regarding Manaan. It would seem weird to me to be switching on the fly like that, but to each their own.

The idea doesn't sound overly practical. The suit part is straightforward enough if you use the existing full body model as a disguise. If you wanted to see the player's head, that's a whole extra bunch of pain to deal with unless you hijack a body model slot. Then there's the actual appearance swapping. On Taris and Tatooine you could probably just script a switch when you enter and exit the swoop levels. But isn't the swoop place on Manaan just part of one the main modules? I'm not sure how you'd deal with that. Maybe a trigger in the doorway or something, but that would be super jarring (even more so than magically changing clothes either side of a level load). Edit: An additional point regarding the suit. The "SpaceMan" model is a lite model, so it's not very detailed. I think it would need some reworking, for example adding gloves with fingers from a different armour model. I'd also get rid of the backpack - fortunately the model appears to have a full back underneath it rather than a hole as you'd typically expect.

I was looking at Juhani and wondering whether it might be worth porting a TOR Cathar head to replace her (and maybe add additional NPC and/or player heads). I noticed they actually have something like her hairstyle as a player Cathar option, which I would guess was an intentional nod. There's also a set of facial markings that are kind of in the same ballpark. I was also thinking how this is really a situation where being able to do something like what Motionbuilder does and map the animations to a different rig would be awesome. If you could transplant the K1/TSL animations to a TOR rig, you could just create some new supermodels and import the TOR models as-is, without needing to go through a whole bunch of editing and reskinning.

I see they have added a combined version. However that was only added a couple of weeks ago, so anyone that started a mod install before then presumably still has the separate versions, in which case the fog fix will not work unless it is moved to the TSLRCM folder.

If you are using the Workshop version of M4-78, copy across the shader fix content to TSLRCM's Workshop folder (opengl32.dll, shader_ident.txt, plus shaders_original & shaders_override folders).

The specific arena room model is M02ae_07a, which is part of the Taris Upper City Cantina module (M02AE).

You didn't add any custom textures then. What were the models you added?

Did you add textures as well? It could be they need to be downsampled for Xbox.

Are the normalhead values you are referencing in appearance.2da new rows in heads.2da, or existing ones? If you are editing or replacing heads.2da, I am guessing the former. What happens if you add a new row to appearance.2da and point it to a pre-existing head?

Hrm, I wonder if this is the source of some visible geometry gaps I was getting from snapped verts. I might have to run some MDLEdit vs MDLOps comparisons. It seems like 5+ sig figure vert co-ords are present in KOTORMax-generated ASCIIs as well. Although to be fair to bead-v, I gather this is just straight from Max. I wonder how accurate the snap tool is? Maybe I should try using a vert co-ord copy/paste script. I doubt that will make any difference, but if you want to try it then use Affect Pivot Only in the Hierarchy tab. For matching the pivot of another object, my preferred approach is to make the target mesh a temporary child of the mesh with the desired pivot, set the reference co-ord system of the Move tool to Parent, hit Affect Pivot Only, zero out the XYZ of the position, then select Reset XForm in the Utilities tab and hit the Reset Selected button. In the Modify tab, drag the XForm modifier underneath the Skin and OdysseyTrimesh modifiers so it is just above the Editable Mesh modifier. Then right click on it and select Collapse To. That will bake your transforms without destroying your skin.

I believe you'd need to set the Minimum 1 HP flag in the NPC's UTC, then in its OnUserDefined script when its health hits some specific value have it end combat and change the NPC's faction to neutral and probably use ActionStartConversation to launch a dialogue if you want it to happen in a cutscene (you could just have it walk/run to a waypoint and then be destroyed, but that would be kind of awkward if the player still has active control). You may want to check out existing examples of that sort of thing, like say the Malak fight on the Leviathan.

I think bead-v was thinking of using an Edit Normals modifier in Max and taking the normal data from that, which presumably would drop the use of smoothing groups (outside of legacy support I guess). I'm not sure what the Blender equivalent would be, but I guess it would take some work to keep both MDLEdit and MDLOps cross-compatible with whatever additional data from either Max or Blender that might be added to an ASCII.

There is supposed to be provision to smooth across meshes when using shared smoothing group IDs, but I have never seen it work, and I had @bead-v confirm that is not working as intended. I guess it is possible there may be some edges cases where it does work, but I have never encountered them personally.