DarthParametric

There is also the fact that John Cygan (Canderous) and Robin Sachs (Admiral Karath) are also both dead.

For models like weapons, the texture needs to be specified in the model itself. I don't use Blender, so I don't know how KBlender handles this, but you can always edit the ASCII it exports manually in a text editor. You'll see a bitmap line amongst the various data for the mesh. For example: node trimesh BlstrPst02 parent w_BlstrPstl_003 position 0.0102975 0.131421 0.0833597 orientation 1.0 0.0 0.0 0.0 alpha 1.0 scale 1.0 selfillumcolor 0.0 0.0 0.0 diffuse 1.0 1.0 1.0 ambient 1.0 1.0 1.0 transparencyhint 0 animateuv 0 uvdirectionx 0.0 uvdirectiony 0.0 uvjitter 0.0 uvjitterspeed 0.0 lightmapped 0 rotatetexture 0 m_bIsBackgroundGeometry 0 shadow 0 beaming 0 render 1 dirt_enabled 0 dirt_texture 1 dirt_worldspace 1 hologram_donotdraw 0 tangentspace 0 inv_count 94 bitmap w_BlstrPstl_003 If your mesh doesn't have a texture assigned, it will say NULL.

Sounds like oldflash's movie saber mod: https://www.gamefront.com/games/knights-of-the-old-republic/file/movie-style-replacement-lightsaber-hilts

You're using a model with PBR textures, metal-rough in this particular case (the other major type is spec-gloss). Odyssey pre-dates PBR usage by a decade or more. PBR attempts to approximate real world lighting and thus has no lighting data baked into the textures. Ye olde engines like Odyssey use Blinn-Phong, which is all faked and thus relies heavily on baking highlights and shadows into the diffuse map. It's not really practical to convert existing textures from one to the other. It's something that needs to be done at the authoring stage. Those texture outputs are from Substance Painter. I doubt they supplied the source files, but if they did it would be possible to edit it and export it with baked lighting. It does, but not like a modern engine. It's implementation is extremely anaemic and you're not going to see any real benefit from it, especially on something like a sword. That said, enabling it is done via TXI semantics, and it is tied heavily to envmap use (the envmap mask acting as a mask for the normal map as well).

Edit the ini and add EnableCheats=1 under the [Game Options] section.

The spawning of the party is the same for both LS and DS routes. The updated OnEnter should work correctly. Make sure you are loading a save before entering the beach for the final time. Even reverting to the vanilla OnEnter won't work just loading a save already on the beach, since there is a specific check for that.

It's not particularly difficult if you know what you're doing, but it's not something you can expect someone with no experience to manage since you'd have to edit the full body model to do the head swap, then create a custom texture for the head.

Except that you are forgetting that Dodonna has a separate unique full body hologram appearance, because K1 doesn't do holograms the same way as TSL.

You've got the permanent slow debuff bug. I have a couple of mods that fix it. For non-droids use the Cup of Caf mod and for droids use the Droid Oil Bath mod. I'm pretty sure Sniggles mentions this in the build instructions somewhere.

Looks to me that what @LDR intended to do was hijack the original OnEnter to run his required spawns, then load the vanilla OnEnter afterwards. Except he forgot to add that ExecuteScript part to the end. So the vanilla OnEnter never fires at all, which is why the party doesn't spawn. This should also cause the initial Rakatan encounter to break as well, since the OnEnter also spawns those.

You might want to attach that here so we can see what was changed. What mod was it from?

Looks like the module OnEnter (k_punk_41aa_en) spawns the party and a separate trigger OnEnter (k_punk_fincs_en) starts the cutscene. If the party is not present but the cutscene triggers then the problem is that the G_FinalChoice global is correct (i.e. > 0) but the UNK_PARTYSHOWDOWN global is already at 1 (i.e. the party should already have been spawned). Seems like the only way that should be possible is if the scene has already been completed and everyone warped back aboard the Hawk for take-off. Load up a save at the top of the beach before you hit the cutscene trigger in KSE and check Globals -> Numerics for G_FinalChoice and UNK_PARTYSHOWDOWN and report what the values are.

It's more entertaining to drag it out for a few more years anyway. Keep 'em thirsty.

Depends on how much of that is due to the spec map and how much is simply baked into the diffuse. I'd guess that latter based on the 2nd pic and the game's age.

In regards to both type and number, I'll point out that Odyssey has a single material assignment per-mesh. It doesn't support multi-materials, except for walkmeshes. In practice what this means is that a model made up of many individual meshes could have multiple different diffuse textures, as long as they are each assigned to a different mesh. This is extremely common practice for body models in Jedi Outcast/Academy, for example. Although when it comes to bodies in KOTOR, typically you want a single texture because of how texture variants work (but that's a whole other thing). One major difference between Odyssey and other engines of similar vintage is that is does not use specular maps. Spec maps are used to fake surface highlights from lights, to provide a suggestion of reflectivity. Instead, Odyssey relies solely on cube maps, which it refers to as environment maps, blended over the top of the diffuse. It controls this via the alpha channel of the diffuse, which acts as a mask. The darker the alpha, the more of the envmap that shows through. The classic example of this in action is the silver/metal Sith Trooper. If you want a metal look for a weapon, which is likely, then you're going to have to get to grips with creating an envmap mask. If the model comes with a spec map it's possible you may be able to use that as a basis (probably by inverting it).

Static objects like weapons should be pretty straightforward even if you have little/no experience. Animated objects (like bodies - armour/robes/clothes) are possible but require a fairly reasonable degree of experience to convert. You have two main options for software. The first is 3DS Max (which you can get via an educational license if you are a school/university student) or the cut down crippleware (and thus free) version of it, GMax. Alternatively there is Blender. Both have import/export scripts for KOTOR models, KOTORMax in the case of the former and KOTORBlender in the case of the latter. How you get the source model into your program of choice depends on what format it is in. As mentioned, GMax is crippleware, so it's the most limited. You can get an OBJ import script for it, so that route is feasible. For Max and Blender, there are various native and 3rd party import scripts around for different game model formats. In regards to some of those you mentioned, STL is a 3D printing format and should never be used for game meshes. TGA is a texture format, not a model. I have no idea what an ODF is (unless it's the open source Word DOC equivalent - maybe it's a readme). MSH is pretty generic and could literally be any of a number of different game-specific formats. OBJ is a static model format that is widely used and typically natively supported by almost any 3D program. Although not mentioned, FBX is another format you'll see commonly which both Max and Blender will accept (but not GMax). If you are sourcing models intended for direct use in another game then you'll almost certainly need to deal with whatever native format they are in. Possibly conversion via a separate tool may be necessary (as with some Source engine games, for example) or you may need to find a specific 3rd party import script that will handle that format. Blender typically has more support for that sort of thing. You can try searching the Xentax and ZenHax (a Xentax splinter group) forums for those. There is also Noesis, a free program that supports a lot of different game formats natively, and which has additional format support via scripts from Xentax/ZenHax. Noesis will allow you to export models in a wide variety of common formats like OBJ or FBX, so it can be handy for conversions. Regarding mesh density/poly count, if it is already a game mesh then it's unlikely to be a problem. Even models intended for current AAA first person shooters wouldn't really be an issue in pure poly count terms, although it would be a complete waste in KOTOR. The main issue with poly count is shadow casting. The engine will crash if a shadow casting mesh is over about 3-3.5K triangles. But that has an easy solution, you just make a dummy shadowcasting mesh that is low poly and don't enable its render flag. As far as other limitations go, a big one is that Odyssey (KOTOR's engine) doesn't support emissive textures. It does, however, support emissive meshes, which it calls self-illumination. This means if you have any glowy bits on your model, they'll need to be split out to their own separate mesh so that the self-illum flag can be enabled on them. Alternatively, it may be easier to create new overlay meshes to sit on top of the original, especially if they are simple shapes like buttons and so forth. Beyond that I can't think of anything too significant.

This is literally impossible. The lights in the module are not the lights that were used to generate the baked lighting. I'd suggest not getting too caught up in even trying considering that the vanilla lightmaps are terrible anyway. Just focus on placing light sources that make logical sense based on the the scene (like those light panels on the pillars in the background). You can adjust shadows per light or globally in the individual light properties rollout.

No. Do not do this with models. A model should always be recompiled (or hex edited) to change the OdysseyBase name to match the filename.

You can do it yourself. Just edit appearance.2da in your Override and change Mira's row (456) to use the "normalhead" ID from Kira's added row (past 677 for TSLRCM).