DarthParametric

That's also the fix for the grass issue - https://steamcommunity.com/app/32370/discussions/0/41973821366855313/

The three lights per mesh issue persisted into Eclipse. It was always something DAO modders had to watch out for. It caused merry hell trying to carve up a level into sub-meshes in such a way that you wouldn't get super-noticeable seams.

It's still compatible with K1R, as long as you don't install a bunch of other mods with placeables. A mod author can't account for every possible combination. As I said above, we'll just have to provide warnings about the issue. Ultimately managing the problem comes down to the end-user.

One of the things I find curious is that KOTOR uses placesables for everything. In Dragon Age Origins they split out static objects into their own category, "props". Those would get placed into the level during the assembly in the level editor and receive baked lighting. They would be exported as part of the level geometry chunks. Placeables were strictly interactive objects, mostly ones with animations, like chests, etc., and those would get placed in the area editor along with creatures, triggers, etc. I can't remember how Neverwinter Nights handled it, but based on the fact that the KOTOR levels seem to have been directly assembled in 3DS Max, I am guessing they didn't directly use the Aurora Toolset or some KOTOR/Odyssey-specific derivative thereof. In terms of optimum scenarios, I would think removing all static placeables and baking them into the levels would be the best idea. But in terms of practicality that seems like its never going to happen. You'd need to rebuild half the game. Perhaps the process could be streamlined if someone could extract the placeable position data from the GIT in a manner similar to a LYT file that would allow KOTORMax to batch import them. But even then that's the simplest bit. You'd need to create all new lightmap UVs for every static placeable, and bake all the lighting for those new props in every affected level. I just can't see that being a realistic proposition. The other problem is that I believe placeables receive tinting via the GIT. Certainly in TSL at least. If you were to make them static, you'd also then need to retexture them. I think the idea of cleaning out null or unused entries and assigning those rows to major mods like K1R is a good, practical starting point. Beyond that it would be the end-user's responsibility to manage what mods they install that use placeables. Although obviously all mods from now on should carry a warning about it to inform end-users. Fair Strides is rebuilding TSLPatcher, perhaps some sort of row ID check could be implemented into that? It could pop up a warning during installation if the max row ID is exceeded.

But it's only in that specific module, right? Cutscenes work fine in every other module when overridden with MODs. Does that module do something unique that no other module does?

All vanilla modules are only RIMs. The MOD format (player-made module) is a legacy of Neverwinter Nights.

No effort on my part. Thank the author, Humus. I'm glad it works though. I have contacted Humus about the possibility of access to the source code, which would allow merging with Reshade, and (more importantly) potential extension to fix other KOTOR problems.

It should be self-explanatory from the description and title. This provides the same function as the original Admiralty mod, as far as Cede and Carth are concerned. You do not need that (and indeed, using them together would cause all sorts of problems).

I hate to necro an old thread, but I found something that may be of use to this issue. I mentioned in earlier posts about the possibility of overriding the GL_CLAMP call. I discovered that something people were recommending to fix K1's grass issues also has the ability to do this. GLOverride - http://www.humus.name/index.php?page=Cool&ID=5 If anyone with the black line issue would line to test this, grab the file from the above link, extract to your K1/TSL folder, open opengl32.ini in a text editor and change FixClamp = 0to FixClamp = 1I'm unable to test it myself. The one instance where I noticed a similar problem was on an XP machine, but the GOG version crashes on XP using that DLL.

I would assume that is an engine limitation. Atton is the player character in that scene.

View File Fixed Hologram Models and Admiralty Redux for TSLRCM This mod attempts to address some of the issues with holograms in TSL. In the vanilla game, the majority of holograms have things like eyeballs and teeth being visible through the head. This is caused by the way the game handles transparency, in conjunction with the order in which it renders the individual meshes that a model is comprised of. By changing the hierarchy of the meshes within these models, certain elements can be occluded, resulting in less cases of “bug-eyed” holograms. This is not a perfect solution however. Because meshes do not self-occlude, visual glitches still remain during certain animations and camera angles, but this is likely the best that can be done without being able to make alterations the game engine itself. Additionally, because their interactions are primarily via hologram, this mod includes a revised version of Jinger/Kreia’s Admiralty Mod, which changes the appearance of Admirals Cede and Onasi to give them outfits more fitting of their rank. And while I was at it, I also revised certain appearances with head swaps and custom model merges (hair, etc.) to try and reduce overuse of the same heads and make NPCs a little more distinct. N.B.: TSLRCM is a requirement for this mod. It is not compatible with the vanilla version of the game. Specific Changes: Ebon Hawk: Bastila hologram (Light Side male Revan) Ebon Hawk: Bastila hologram (Dark Side male Revan) Ebon Hawk: Carth hologram (Dark Side female Revan) Ebon Hawk: Carth (Admiral Onasi) hologram (Light Side female Revan) Ebon Hawk: Canderous hologram Ebon Hawk: Jedi Master Atris hologram Ebon Hawk: Jedi Master Kavar hologram Ebon Hawk: Jedi Master Vash hologram Ebon Hawk: Jedi Master Vrook hologram Ebon Hawk: Jedi Master Zez-Kai Ell hologram Peragus: Administration Officer hologram Peragus: Dock Officer hologram Peragus: Maintenance Officer hologram Peragus: Medical Officer hologram Peragus: Security Officer hologram Peragus: Coorta hologram Peragus: Coorta thug #1 hologram Peragus: Coorta thug #2 hologram Harbinger: Republic Captain hologram Harbinger: Republic Navigation Officer hologram Harbinger: Republic Doctor/Med Officer hologram Harbinger: Republic Soldier hologram (partial) Harbinger: Admiral Cede hologram Harbinger: Admiral Onasi hologram Telos: Admiral Cede hologram Telos: Admiral Onasi hologram Telos: Admiral Onasi physical appearance Dantooine: Jedi Master Vandar hologram Dantooine: Jedi Master Vrook hologram Dantooine: Admiral Cede hologram Dantooine: Admiral Onasi hologram Nar Shaddaa (Goto's Yacht): Goto hologram/projector VFX Korriban: Bastila hologram (Dark Side male Revan) Korriban: Jedi Master Vash hologram (M4-78) Korriban: Jedi Kaah hologram (M4-78) Malachor V: Bao-Dur hologram Known Issues: There are still visual artefacts from overlapping sections of individual meshes, particularly noticeable in the case of the neck being visible through the jaw which occurs with certain animations and/or camera angles. This is not addressable by model edits. The problem is the way in which the engine renders overlapping transparency within a single mesh. The Republic soldier on the Harbinger has been replaced as of v1.3, however the helmet is still somewhat problematic. I'm not sure that is addressable without completely remodelling it, and perhaps not even then given its shape. Hair planes with alpha transparency don't function as intended as holograms, so typically look pretty terrible (e.g. Peragus Maintenance Officer). There's not much that can be done about those, other than completely remodelling the hair to rely on geometry rather than texture transparency. Dangly meshes used for hair bangs tend to look conspicuous due the requirement of placing them under the head mesh in the hierarchy. Particularly egregious examples may warrant having these elements being turned into skinned meshes in a future update. No doubt there are still a few holograms that need attention that I have missed. If anyone can provide a list of such cases, I may address it in a future update. Note that some holograms look fine in their vanilla state. I am only interested in hearing about ones with issues like those already addressed in this mod ("bug eyes", etc.). Compatibility: I've edited UTCs to point to custom appearance.2da entries, so the mod should be compatible with any other mod that only edits the vanilla 2DA entries. However, it will not be compatible with any mod that forcibly overwrites the module files this mod edits, that outright replaces the UTCs in question, or that also edits the UTC appearance values. Install any such mods first, then this mod afterwards. To make it clear, do not use this in conjunction with Jinger/Kreia’s Admiralty Mod or Darth Hayze's TSLRCM Compatibility Patch for said mod. They are superseded by this mod. A separate patch is provided for M4-78 to handle its version of the Korriban academy module. After installing the main content of the mod, run the installer a second time and select the "Additional Patch" option from the drop down menu. An optional patch has been added to give the robe-wearing holograms unique named textures for use with robe mods that use the same filenames as vanilla robe textures. This will prevent texture issues (but note that they will still be wearing the vanilla-style robes). Acknowledgements: Thanks to Fair Strides for creating a customised version of TSLPatcher to handle filename clashes, which made this mod practical. Thanks to Jinger/Kreia for permission to release a revised version of the Admiralty mod's content, the textures from which (with modification) are used in this mod. Thanks to zbyl2 for permission to redistribute TSLRCM's module files to ensure compatibility for Steam Workshop users Thanks to JCarter426 for permission to use the female Republic soldier body model from "JC's Republic Soldier Fix for K2" and his adjusted N_CommM04 texture from "JC's Minor Fixes for K2". Thanks to bead-v for KOTORMax and MDLEdit, and ndix UR for MDLOps 2K18 Edition, all of which were required at various points to get this to work. Thanks to ndix UR for TGA2TPC Thanks to Malkior for providing the impetus for the mod via this thread. Thanks to L0ki194 for offering input on the case of the Harbinger's "Doctor" vs "Medical Officer". Submitter DarthParametric Submitted 01/19/2018 Category Mods TSLRCM Compatible Yes  

The probable cause of this has been identified by ndix UR. It seems that the game will only recognise placeable IDs up to 255. With the pre-existing game data, that only allows around 20 custom entries. If you are using multiple mods with custom placeable.2da entries, then this is the likely cause. At this time the only solution is to limit which mods you use to not exceed this limit.

I always wondered why both TSLRCM and M4-78 use RIM files for 702/703KOR rather than using MODs like for every other module. Having just tried testing something in 702KOR using a MOD, it seems like this doesn't work properly for the academy module, for some reason? The module loads, but things like cutscenes are broken. It's not an insurmountable problem, as TSLPatcher can patch RIMs I gather, but I am curious as to the cause.

The Aspyr version doesn't alter appearance.2da, so it's not that at least.

Probably more likely due to you playing on a laptop. Integrated graphics?

It won't work unless you load from a save before entering the final room on the Star Forge. Installing the mod multiple times should make no difference, besides bloating the size of placeables.2da, assuming you don't revert the edited files with the backups TSLPatcher makes. But why would install it multiple times?

Check here for various tools - http://www.starwarsknights.com/tools.php The specific link for K-GFF - http://www.starwarsknights.com/mtools/kgff_131.zip

That's just the message that pops up when you click on them while they are still alive, hinting that you need to use a Force power. There's nothing to suggest they were ever intended to survive. Either they die peacefully (LS character using LS power) or they die painfully (DS character and/or using DS power).