DarthParametric

Modders
  • Content Count

    4,567
  • Joined

  • Last visited

  • Days Won

    514

Everything posted by DarthParametric

  1. Edit the ini and add EnableCheats=1 under the [Game Options] section.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. You might want to attach that here so we can see what was changed. What mod was it from?
  8. 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.
  9. It's more entertaining to drag it out for a few more years anyway. Keep 'em thirsty.
  10. Yeah that means it's a GPU issue. Probably AMD I'm guessing? Or maybe an integrated Intel GPU?
  11. Try downloading the optional NM FIX archive and see if that fixes the problem.
  12. 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.
  13. 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).
  14. 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.
  15. 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.
  16. 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.
  17. 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).
  18. Only if you install all other mods in TSLRCM's Workshop folder, not the main game folder.
  19. Sounds like a broken install. Are you using Workshop mods?
  20. You shouldn't ever use Workshop mods really (and the Aspyr version is garbage anyway), but if you must then only install TSLRCM. But once you do that, all mods must be installed in that mod's Workshop folder, not the game install folder. That's why it broke last time. Aspyr's Workshop implementation creates a cascading hierarchy based on Workshop mod install order, so if a recent mod has a heads.2da then any other heads.2da in an earlier mod folder or the base game folder will be ignored.
  21. It's not a texture issue. The head missing is either a model issue or a modified/missing heads.2da. Are you using the Steam version of the game and Workshop mods?
  22. You have to use a cracked exe. It won't work with a protected exe, such as from Steam or one of the CD/DVD versions. Grab this one - https://deadlystream.com/files/file/1320-kotor-editable-executable/
  23. Assuming your DLG and UTP are in the MOD or Override folder and the ResRef matches, then that would suggest some issue with the DLG itself. Did you edit/create it with KOTOR Tool? Because that doesn't work for TSL (should still work for K1 though). You might need to attach the DLG so it can be looked at.
  24. You broke your install by the sounds of it. Probably a hard overwrite of heads.2da by another mod.