DarthParametric

Or - perhaps - they couldn't match the movement to the audio.

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?

if actually available

https://github.com/crosire/reshade

How Aspyr thinks

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

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.

DarthParametric, in light of this report from ndix UR I suppose you'll have to pull compatibility between "Diversified Jedi Captives on the Star Forge 1.0" and a bunch of other mods appending to placeables.2da, including K1R?

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 = 0

FixClamp = 1

Atton's dialogue with Mira only lacks VA

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

of the 8 jedi, only 3 appear in the game

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.