DarthParametric

43 minutes ago, Sith Holocron said:

Has anyone tried this in TSL?

The model would need to be recompiled for TSL, but otherwise should be fine, assuming it's actually used.

HoloPatcher runs on Linux and Mac (plus Windows) and is what you want to use as a replacement for TSLPatcher.

https://github.com/NickHugi/PyKotor/releases/download/v1.60-patcher-beta4/HoloPatcher_macOS_x64.zip

That is very odd. Some sort of Windows 11 derpiness perhaps? You can try editing the batch file. Open it in a text editor (Notepad, etc.) and change the line

hires_patcher %WIDTH% %HEIGHT% %LTRBOX% %EXE%

to

hires_patcher.exe %WIDTH% %HEIGHT% %LTRBOX% %EXE%

Save it and try running the batch file again.

Did you just move the batch file by itself? It needs hires_patcher.exe in order to actually do anything.

Repeatable? That seems odd. I can't think of any reason why it would crash on exiting if it was perfectly fine coming in and nothing changed. Did you delete the CurrentGame / FutureGame folders in the root game folder after the first time?

Unfortunately, KOTOR doesn't provide any crash logs that might help diagnose it. But if you post a save just before exiting I can try it on my end.

The Aurora family of engines (Aurora/Electron, Odyssey, Eclipse/Lycium) share the same limitation of only supporting a maximum of 3 dynamic lights per mesh. Any additional lights beyond that won't be rendered. The issue you are describing sounds like that. There's nothing the mod can do about it, it's an engine limitation.

Nobody can tell you the row numbers because they will vary depending on how many mods you have that add appearance rows and what order you installed them in. But the vanilla K1 rows go up to 500-ish, so it will be after that. They are clearly labelled. Look for P_MAL_Pureblood_Sith A05_MED and use that row.

As to editing NPC appearances in general, changing a UTC won't have any effect in a module you have already saved in (assuming they were already spawned). At that point their appearance is stored in your save and edits to the module creature list are ignored.

Yeah I had a look and it seems that I missed that. I thought I had accounted for it but apparently not. Kind of funny that it took someone 5 years to tell me though.

There are a couple of possible ways to fix it, each with varying downsides. Probably depends on how many other instances there are of that placeable.

Have a cutscene like that one in TSL where H8 electrocutes T3 and blows him up, then spray paints himself white and blue and assumes his identity.

44 minutes ago, Cr00ker said:

1.10.0

https://deadlystream.com/files/file/1258-kotor-1-community-patch/

Check your Override folder. You should have a bunch of scripts (NCS files) with names in the format of cp_xxx.ncs in there.

7 minutes ago, Flori009 said:

added difficulites

K1CP doesn't add any difficulties.

Yes, there seems to be an issue with certain models compiled by MDLEdit on Linux for some reason. Fortunately this can be resolved by importing the model into KBlender and re-exporting. It will be addressed in the next full release, but I'll see about pushing a hotfix for Linux users in the meantime.

The only change made to Yuthura's DLG in the academy is to remove the infinite XP exploit. There are no structural changes to the rest of it, just that one Sith Code entry.

https://github.com/KOTORCommunityPatches/K1_Community_Patch/blob/master/tslpatchdata/changes.ini#L20311

1 hour ago, N-DReW25 said:

The way the holograms are broken in the vanilla game does like this

The specific issue is mesh render order. Whether or not a particular mesh is animated is irrelevant. All that matters is what order a collection of meshes is being rendered in, which determines how alpha blending is calculated. Render order is determined by the model hierarchy. So a mesh inside another mesh (like an eyeball inside a head) needs to be lower in the hierarchy so that the containing mesh renders on top of it. The reason this is a problem for heads in particular is because by default skinned meshes (like the main head mesh) are always at the bottom of the hierarchy, so meshes doing double duty as bones and visible meshes like eyes/eyelids/teeth will be above them, thereby causing the weird rendering issue. The way to fix this is to reorder the hierarchy, with the skinned meshes at the top, above the rig/skeleton.

As to creating full bodies, this is done because separate heads end up in the middle of the hierarchy, as a child of the head hook. Since you need the head mesh to be above the torso to render in front of it, the only option is to have it all in one model.

8 hours ago, DroneSniper said:

I experienced a constant crash after leaving the Dantooine ruins where the star map is

Yes, this is a known issue on Linux. There's a fix for it in the next version, but in the meantime you can download working MDL and MDX replacements from the Github repo. 

2 hours ago, Omanakole said:

Would it be possible

Possible? Yes. But I have no interest in doing so.

55 minutes ago, Dark Hope said:

Let me publish them.

Sure, go ahead.

46 minutes ago, bdKotor2 said:

workshop

Do not use the Workshop for TSL.

11 hours ago, jbd2025 said:

do you know how to uninstall this mod?

As a general rule you do not "uninstall" complex mods. At least when you have installed other mods afterwards. You nuke the entire game installation and reinstall everything from scratch.

Without knowing what other mods you might have installed, the only non-nuclear suggestion I have is to create a dummy install of the game somewhere, install K1R onto that, check its Modules folder for lev_m40aa.mod and ebo_m40aa.mod, and copy those to your actual game's Modules folder. Although I don't know if K1R actually edits ebo_m40aa, so that mod may not exist, in which case you can delete the one in your game's Module's folder. Of course if you have installed any other mods that edit either or both of those modules then you'll likely end up breaking something else.

9 hours ago, Vanguard2023 said:

When should I install this mod in the KOTOR Mod Builds? https://kotor.neocities.org/modding/mod_builds/k1/full

No idea, never used it. Install it last if you're unsure.

6 hours ago, RogueHippie said:

that file wasn't in the folder for the mod

It doesn't exist in the mod because there is no need of a physical file. All the required patch info is contained in the ini.

This is a problem on your end, not the mod itself (it works fine for everyone else). Attach the log file that TSLPatcher spat out.

6 hours ago, LoneWanderer said:

What kind of scary, game-affecting, unpleasant or at least noticeable glitches and bugs are we even talking about?

Off the top of my head, the most egregious bug that K1CP fixes is probably with Xor. There have been many attempts before, but none of the previous mods actually fixed him. Hell, I'm still not 100% sure even K1CP's multiple revisions of fixes have finally solved the problem permanently. Beyond that, there are a couple of minor soft-locks that people somehow manage to get themselves into, the Sand People disguise glitches, and things like that. But you're correct that there's no one big earth-shattering fix that makes K1CP indispensable. Rather, it simply tries to smooth out some of the rough edges. If people don't really notice, then that's actually a compliment. After all, the idea is to keep the game in line with the original developer-intended experience as much as possible.

6 hours ago, LoneWanderer said:

But is such self-sacrifice even necessary when most people won't see a difference?

It keeps me amused and off the streets.

15 minutes ago, N-DReW25 said:

it is for this reason why the K1CP mod, a bug fix mod, didn't bother making their mod compatible with K1R

Not really. When AFP first started it and it was just a collection of pre-existing fixes, there was no issue because the scope was pretty limited. It wasn't until JC and I got involved and the project changed from a collection of other people's mods to custom fixes that encompassed every facet of the game that incompatibilities started to creep in. It was just an inevitability when faced with two mods both trying to make fundamental changes to the same crucial components like OnEnters, plot-critical DLGs, and so forth. Add to that, once JC and AFP went AWOL and control of the project was ceded to me, there was never going to be any effort to try and address the incompatibilities simply because I have zero interest in K1R and what it does.

41 minutes ago, EbonHawkStowaway999 said:

changelog

Readme rather than changelog, but thanks. Corrected.