DarthParametric

LAA patching is unlikely to achieve anything. The game was originally designed to run on cut-down Pentium III Celeron with 64MB of pooled RAM after all. On a PC, most of the added overhead is probably handled directly by the GPU and its dedicated VRAM. You won't be able to patch the EXEs of the Steam versions given their DRM, so it is kind of moot in those instances. I'm not sure whether the GOG versions already included it, but there would be no harm in patching those.

In that instance you could presumably at least cap a new video and sync the audio to it manually so that at least it is in 1080 (or higher).

Just a referrer spoof I imagine? Should also be able to achieve the same thing with a custom referrer addon/script.

What SFX? Can't pull them from the video?

https://github.com/crosire/reshade They think the same as any other commercial entity. They don't do squat unless they are getting paid to do so. There's no financial incentive for them to bother with additional patches.

No, it won't work with Reshade, or any other OpenGL override. The source for both is available though, so merging is always a possibility for those of the code monkey persuasion. It doesn't address the saber issue, no, but possibly it could if you knew which shader/s to edit (and how to edit them).

If you are using the Aspyr version of the game, that's the problem. Amongst many other bugs they introduced, they screwed up the fog. This is what you want: https://github.com/HappyFunTimes01/ShaderOverride See here for more info - http://deadlystream.com/forum/topic/5345-fog-and-speed-blur-fix-for-the-2016-tsl-patch

http://deadlystream.com/forum/files/file/1152-tga2tpc/

Cool, glad to hear it worked. I wonder how many other KOTOR graphical issues could be fixed in a similar manner.

Any large mod going forward will need to incorporate custom placeables into room models where possible to bypass the issue. If they rely on scripted interactions that can't be done any other way then they'll need to make that clear so end-users are aware and can plan accordingly.

Things like pony tails and bangs can be turned into "damgly meshes" (AuroraFlex/OdysseyFlex) to provide a bit of dynamic movement. Have a look at the vanilla models to get an idea of how it works.

I'd say adding a new head via new 2DA rows would be the "better" approach. Replacing an existing model is just easier. You'll want to start with an existing head to get the rig, and use as a guide for scale and position of your custom mesh. There are a few eccentricities with with the way KOTOR works, which may necessitate changing your mesh to suit. Poly count-wise, I probably wouldn't go above 5K per mesh chunk if you can help it. You also do not want to enable shadows on any single mesh over 1K or so polys, or you'll get a crash. If you are considering long hair, you are probably going to wind up disappointed.

The base install adds eight entries, the optional content an additional one. I can mitigate the optional one (sparring circle) with a level model replacement, although that merely makes for a different type of potential incompatibility. Diversified Wounded Republic Soldiers On Taris currently adds twelve of its own, but a number of those are "spares" that I was toying with swapping around with scripting before this issue cropped up. I'll have to revise that and remove the unnecessary ones. In fact I was already replacing the room model in that instance anyway, so maybe I could just dispense with placeables for this one altogether and make them part of the room model. That will probably mess up my staggered animations though. It looks like vanilla entries 8, 9, 47, 62, 78, 90, 94, 97, 115 could all be repurposed by K1R or some other major mod. I dare say there are a few more that are populated but unused in the game.

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.