DarthParametric

The nulls are just model variation numbers with no vanilla models. It would be almost a certainty that some mod uses one of those variation numbers.

I couldn't see it on my tests, and as I recall both the turret inventories have null weapons equipped (which is the fix).

It's not done yet. Provided above is one way to circumvent this particular occurrence, but further experimentation by @JCarter426 only lead to more head scratching about the exact nature of the underlying cause And there's also the question of where else it might occur in either game.

OK, here's an overview of how you go about a fix like this. The first step is to locate the specific room model that needs fixing. This is pretty much down to loading the entire module's layout into Max/GMax and trying to match up what you saw in-game vs the location in the layout, Then you can select a piece of the offending geometry and find out which model it is part of. Typically at this point I then reset the scene and load that specific model only. Some people prefer to work inside the full layout. That's a matter of personal preference and doesn't really affect the way you go about the fix. Just make sure you enable the Export Layout Co-Ords option. On to the fix. Here we see the length of corridor in M01aa_03a: I will assume you know how to manage hiding extraneous elements like walkmeshes and so forth. The light sockets we are interested in are comprised of two separate meshes. The white outer/surrounds: And the red inner: If you zoom out, you'll see that each mesh is comprised of much more than just the light sockets. Level models are typically divided based on materials. Primarily shared diffuse texture, but in larger levels there can also be further division based on shared lightmaps. In this case the problem is that three light sockets lack the red inner mesh. The solution is to duplicate some of the existing red mesh and slot it into the empty light sockets. We start by selecting the red textured mesh and creating a copy of it by going to Edit -> Clone. It is very important that in the options window that pops up that Copy is chosen. The default is Instance, which we don't want. That option transfers any changes made between the duplicate and the original, which would be bad. With the new copy selected, hide everything else. The next step is get rid of all the geometry we don't need. In this case there are two light socket inners at this end of the hallway, but we only want the left-most one. The reason is that the righthand one has different lighting info, making the texture very dark (as you can see in-game - it's in the dark, collapsed section). Expand the Editable Mesh modifier in the stack, select the Polygon sub-level, then select all the polys of the light socket inner that we want. Now go to Edit -> Select Invert (shortcut CTRL I) and press DEL. That should leave just the socket inner mesh. Now to make out life easier, switch to the Hierarchy tab, enable the Affect Pivot Only button, then choose Center to Object: After that disable the Affect Pivot Only button. This can be a little flaky, so you may want to deselect the object and reselect it to be certain. With the rest of the scene unhidden, the socket inner piece can easily be dragged to approximately where it needs to be: Don't worry about precise positioning at this stage, as we'll handle that at the vertex level. To make it easier to see what you are doing, enable the Edged Faces option in the viewport. With this done, we are going to utilise the Snap feature to line up our mesh with the existing light socket surrounds. You may first want to go to Tools -> Grids and Snaps -> Grid and Snaps Settings and make sure Vertex is ticked in the Snap tab. With that done, select the Vertex sub-level of the Editable Mesh modifier (I circled the wrong thing in the image below, whoops). Select the verts in one corner of the object, and enable the Snaps Toggle button in the toolbar Hover the Move tool over the front-most vertex until you see a little blue cross. Then select and drag to the position you want to snap it to. You may need to alter your view position to make sure you are snapping to the correct vertex. Remember to only snap using the front-most verts. The back verts will retain their proper relative position as long as they are selected together. If you make a mistake, use Undo (shortcut CTRL Z) rather than trying to drag it elsewhere, as that often makes things worse. It can take some practice to get the hang of it, as the system is a little finicky. You should get something like this: Once you have done one, you can duplicate that mesh and repeat the process two more times for the remaining sockets: For the sake of reducing the object count, you should merge your three socket inners into a single mesh. Select one of them, then select the Editable Mesh modifier and hit the Attach List button (you can also use Attach to select objects directly in the scene, but I find the List approach less subject to mistakes). Select both of your other meshes in the list that pops up and hit the Attach button. Now your three socket inners are a single object. The final step to make sure there are no problems is to run a Reset XForm command from the Utilities tab. Then switch back to the Modify tab, grab the XForm modifier and drag it underneath the OdysseyTrimesh modifier. Right click on it and select Collapse To. This bakes all your transforms with destroying the OdysseyTrimesh data. Not a big deal in this case as it would be trivial to recreate, but something you want to get into practice for when dealing with skinned meshes. And that is pretty much it. All you need to do now is make your new mesh a child of the OdysseyBase, export it, and compile it. As we didn't make any walkmesh changes you can discard the binary walkmesh that MDLEdit produces.

I have a fix for it. Will add it to the Endar Spire Hull Fixes mod shortly. But I can run you through how to replicate it if you want. The solution is in fact a copy and paste, of sorts.

It is a model problem. You can see the furthermost light socket in your picture has a redish pink interior. The problem light sockets lack a copy of that mesh for some reason.

Looks like there are three light sockets along that length of hallway that are missing the inside meshes.

I am old and probably need glasses, but I'd still dispute that assertion. To me the differences are so subtle as to be more or less imperceptible without multiple back and forth comparisons. And from the range that you would generally see a Trooper you'd never tell the difference.

You must be looking at something different, as there is no discernible difference with or without it as far as I can tell. We were discussing this a week or so ago on the Discord channel, looking at it in TSL. My conclusion was that neither game bothered using it because it added nothing of value.

For TSL there is Darth333's WhereAmI armband - http://www.starwarsknights.com/mtools/whereami206.zip For K1 I believe Star Admiral's Utility Armband provides the current module name - https://www.nexusmods.com/kotor/mods/1076 Edit: Oh, sorry, you want the specific room model name. I don't think that is possible to derive directly in-game, only the current module. You'll likely need to load up the entire layout in Max/GMax.

Progress on Hanharr:

Did you try the updated version of the mod?

It's not a texture problem, it's a model problem. You can see the loin cloth on the ground at one point.

Poking through the module, the dialogue used for that scene is part of dan13_zhar.dlg. That first line, "Ah, so you are the one who rescued Bastila." fires script k_pdan_zhar08: void main() { ActionPauseConversation(); ExecuteScript("k_pdan_player03", GetFirstPC(), 0xFFFFFFFF); ActionWait(12.0); ActionResumeConversation(); DelayCommand(2.0, SetDialogPlaceableCamera(37)); DelayCommand(6.0, SetDialogPlaceableCamera(2)); } And k_pdan_player03 is: void main() { ClearAllActions(); ActionJumpToObject(GetObjectByTag("wp_pc_start", 0), 1); ActionMoveToObject(GetObjectByTag("dan13_WP_council", 0), 1, 1.0); } Perhaps that is the problem - there is no command to face the player. But scripting is not really my thing.

It can happen in conversations where the character is scripted to face towards a the party but the script chooses a party member that is off in another room. In this instance you'd expect the script to be looking for the player specifically, but you'd have to check the DLG for that scene to work out the specific script that is firing. I'd guess it is probably some generic global script, not a module-specific one, which could be the problem.

Much the same way. It's just two bandoliers, so shouldn't be too difficult. Chuundar is probably more troublesome. I'll probably have to model that necklace from scratch.

The belts were derived from one of Bowdaar's customisations: It was chopped up, scaled and conformed to Jakarro's body, then new geometry was added to hide any backfaces.

View File Get a Grip! Zeison Sha Armour Male Model Fix This mod addresses an issue with the vanilla Zeison Sha armour model for males (PMBMM). It appears something happened during its creation by Obsidian that results in the left hand being unable to reach far enough across the body to properly perform a two-handed grip during weapon animations. The model was also undersized compared to the other male models. Fixes: Scaled the model 102% to bring it in line with the height/size of other medium male models Adjusted some hand and wrist skin weights to minimise bad deformation Swapped to the PMBNM rig to alleviate left arm position/rotation issues Known Issues: It seems like swapping to the PMBNM rig may have traded one set of issues for another. There appear to be some deformation problems with the right hand that aren't present when using the original rig. I may swap to a third rig at some point to see if I can find a better solution. The dual melee wielding animations still suffer from the vanilla bug of the off-hand clipping through the hilt. Download @JCarter426's Supermodel Fix for K2. Installation: Simply copy the model files across to your Override folder Acknowledgements: Thanks to @JCarter426 for pointing out the issue and testing the various fixes Thanks to @bead-v for KOTORMax and MDLEdit Submitter DarthParametric Submitted 09/05/2018 Category Mods TSLRCM Compatible Yes  

Got a Zaalbar variant, although I'm still fiddling with the textures: I also need to figure out what to do about the eyelids. The face structure around the eyes doesn't line up well enough with the original to get a decent blink. I might have to edit the animations, ugh.

Testing out the feasibility of some alien model replacements:

So going back to the bone limit issue, it definitely seems like in K1 at least that 18 or more bones on a mesh is not possible. I am testing a full body model and I had split apart the head/torso/arm meshes to sidestep the bone limit but I didn't pay close attention and had some stray weights on the head and split the arms off one ring of verts too low. That meant the torso ended up with weights for the two lower biceps for a total count of 17 bones. Interestingly I noticed no problems with this mesh. However, the head had stray weights from both collar bones, resulting in 18 bones. This caused the previously described verts stretching to the model base's 0,0,0 (appeared to be verts weighted to the right brow). I went back and had a look at the vanilla Holo Vandar (C_HoloVandar) and Revan (N_DarthRevan) models, as I had previously reported that those both had meshes with more than 16 bones and yet worked fine. Vandar's head mesh has 17 bones and Revan's torso mesh has 17 bones. So it seems to me the bone limit is 17, not 16, but that is definitely the upper limit. On a different note, I noticed when loading a binary model into MDLEdit that the bones listed for a given mesh were wrong. It looked like that old index issue where it was being wrongly assigned things like dummies (camerahook, etc.) and other skinned meshes. This appears to only be a cosmetic issue inside MDLEdit however, as decompiling the model resulted in the same mesh in the ASCII having the correct bones.