JCarter426

There isn't any indication about a lot of things. My guess would be that you were meant to play as one of them as in the Atton vs Sion encounter, and then whichever one survives goes on to appear in the party confrontation scene, with perhaps Atton/Handmaiden being on Kreia's side. But there's no material left for such a thing. There's only one version of the party confrontation, and it implies a light side ending and that all the party members have been trained as Jedi. Also, frustratingly, some of the remaining content is only voiced by Atris, not Kreia.

It's not really a bug. The envmap is supposed to be set to default in appearance.2da so the game loads the shader info from the model. It's default in K1 too. The issue is that the game always loads shader data from the texture on the model, and there is no texture on the model. They removed them from the K2 versions for some models, maybe intentionally. It seems to me that they willfully stripped the shaders off of a lot of NPCs, probably to improve performance in areas with lots of them. That's not an issue for modern PCs so it would be nice for us to have the option, but now changing the TXI data isn't enough. They need a model edit or the appearance.2da hack too. Hutts are also missing the bump map they had in K1. It's not in the files at all and would have to be ported to get their proper look back.

You know TSLRCM restores these encounters, right?

Oh, so that guy was supposed to be blue. That's one item off my list of testing notes then. Some people use it. Problem is none of us do, and haven't tested at all. There are some minor reported issues, but nothing game-breaking, I think, at least with v1.7.

Most of those make gameplay changes that we generally shy away from unless it's obvious there's a mistake or some other problem. I don't particularly disagree with the changes, but I think it's a subjective issue. This one does seem up the Community Patch's alley, though.

These are all the animations that exist on the player supermodels: Plus the combat animations b9a3 and f2p1a don't exist but are supposed to (and are fixed by my Supermodel Fix) and TSLRCM adds a couple animations to S_Male02 for Atton's leaning.

The game is frustratingly inconsistent with those checks. There are instances with a guaranteed [Success] and others with a guaranteed [Failure] in addition to the ones based on a skill roll. I believe [Lie] should never lead to a [Success] or [Failure] because there is no "lie" skill. In such cases, it's meant to be [Persuade/Lie] - for example, "[Persuade/Lie] I found Malak's diary." - but of course there may be mistakes or, frustratingly, more guaranteed success or failures.

If you can figure out which Override folder is the right one, install the attached file to it. k_pkor_las36!plt.ncs

I meant to post this back in June, but I forgot. It was supposed to be a quarterly thing, but it remains a semi-regular thing. Updates Supermodel Fix for K2 - Fixed a facial issue and updated K1 style running to match what I did with it in my supermodel port. Yay for consistency. Minor Fixes for K1 - Minor updates for minor fixes. Fixed some leaf textures and converted them and others to superior TPC format. Darksaber for K1 and for K2 - Made new blade textures using the Saber plug-in for After Effects. Fixed the hilt alignment because apparently I had people holding it sideways before. Flipped Y-axis on the normal map so it doesn't look like it came from the mirror universe, and maybe made other improvements, hard to say. Converted other textures to superior TPC format. Security Spikes for K1 - Fixed an issue with the code that let it open doors the player normally couldn't interact with, like ones meant to seal holes in the fabric of the universe. Lightsaber Visual Effects for K2 - Added optional textures for the new colors added by the Ultimate Saber Mod, in case you want to use that and have consistent blade quality. Mandalorian Armor for K1 - Fixed a minor issue with Option A & the upgrade screen. New Mods Robe Adjustment for K1 - Two options to give you additional robes on Dantooine. The first option gives you robes to actually wear during the montage; they have the stats of clothing, so the change is merely aesthetic. The second option makes Zhar give you the robes he normally gives a bit earlier, right when you can start wearing them. They can be installed separately or together. Jedi Tailor for K1 - Adds a Trandoshan who will tailor your robes for you. He'll change the color between brown, black, red, and blue without affecting the robe stats. He also sells stuff and gossips. Something Completely Different My pick for this entry is Sith Armor - Freelook Filter Mod by @ebmar. It's such a simple and in retrospect obvious thing to add, but at the same time it's one I doubt I ever would've thought of or bothered with doing myself, so it's especially nice that somebody else did.

There is no quarterstaff model variation 6. When the model doesn't exist, the game defaults to the 1st variation (or if that doesn't exist, it crashes). You need to extract w_qtrstaff_001.mdl/mdx, rename to w_qtrstaff_006.mdl/mdx, and hex edit the MDL to replace all instances of w_qtrstaff_001 with w_qtrstaff_006.

To clarify, it's TSLRCM that removes T3 from the party after the Visas encounter. Not any of the Kodin business - it's part of the actual Visas encounter. The current version of TSLRCM also adds him back, but we were using an edited visasmarr.dlg based on an older version of TSLRCM that did not (perhaps before he was removed from the encounter at all) that caused the bug. I was speculating that if T3 was missing from the party entirely due to Kodin or other shenanigans, the same thing would happen without any other mods. But if you can't trigger the encounter at all in that situation, then that's not the case. Still, the erroneous message log is there, as well as the potential for worse problems. Yeah, that would probably work. It's just more complicated than changing the speaker is all I meant. It's TSLRCM's "problem" because it's TSLRCM that makes the mistake. I get that you did it that way because you found it more convenient for the dynamic cameras, but that's really not what the speaker field is meant for, as evident by the erroneous message log. I don't think it would be reasonable for a mod that does something to T3 or Visas to have to edit Kreia's global dialogue as well. That's not good for mod compatibility.

Probably not, that sort of thing is usually handled through an NPC's local booleans & numbers. If you could figure out which one the dialogue is checking you could edit your save to fix it - but not with KSE, so it'd be kind of messy.

Hey, I was able to decompile this script.

k_inc_force is an include file. Include files don't get compiled on their own because they have no main() or StartingConditional() function, but they get included in other files that do (in this case k_sp1_generic). So you do need to edit k_inc_force, but it's k_sp1_generic that you need to compile, with the edited include script present. It sounds like something is wrong with your compiler. I would recommend using NWNSSComp instead, which may be found here.

Generally speaking, any mod uploaded to Deadly Stream within the last few years will be compatible with TSLRCM. (Though a mod may say it's not because that's the default setting and an update to the site a while back nuked the settings back to their defaults.) Everybody around here assumes the vast majority of the audience is going to want to play with TSLRCM installed, so there is no point in uploading a mod that's not compatible with it. Any mods that pre-date TSLRCM should be assumed incompatible. That accounts for the majority of GameFront's archives, and whatever of that is still on the Nexus. Purely aesthetic mods like minor texture changes and maybe some head mods may be safe, so long as they're not editing any UT* or DLG files. Unfortunately, a lot of older mods, such as the Ultimate Saber Mod, are not safe at all and the authors are long gone. We're in the process of troubleshooting and patching some of them via Deadly Stream's abandonware policy, but progress is slow. When in doubt, pick whatever you like from Singgles' builds and what's explicitly marked as compatible with TSLRCM here. At least within TSLRCM's sphere of influence, most of the compatibility issues have been worked out. So long as the mods don't obviously do the same thing and use TSLPatcher where appropriate, they're probably be compatible.

I'm not sure if I did the room you wanted, and I hacked it together pretty quickly so it might not be pretty, but sure. M10ab_16a-kotormax.mdl.ascii

I think it makes sense, since they have their fingers in everything. I'd be worried about repetition of course, but I think there's plenty of room to do new things with Czera, and it would already be different from the other planets because they're not in charge of this one. Maybe they've only just recently tried to get a foothold in. It might even be a chance to give them more nuance, seeing as they'll likely be less evil than the establishment for once.

Gmax might not have it, unfortunately. You can right-click and convert to an editable poly, so long as you right-click and convert it back to an editable mesh when you're done editing, and reapply the walkmesh modifiers. Should be functionally the same - doing it with a modifier is just more convenient since it does it non-destructively, but that's why 3ds Max costs hundreds of dollars.

I find it easiest to import the entire area with KOTORMax's area tools. That way you can see the whole thing and not have to hunt down each room, and you can still export a room individually by selecting its base when you're done. It's not super complicated, but the engine is very particular about what it wants. Only one walkmesh per room. The walkmesh must be a trimesh (not an editable poly or any other type of object). Safest thing is to apply an Edit Mesh modifier or convert to editable mesh when you're done editing. The walkmesh can't be self-intersecting or have any gaps. Both of these lead to unpredictable issues. So it's best to work from one mesh, extruding, cutting, or creating polys where necessary, and not build it with different objects and try to merge them later. The walkmesh uses a special material to configure what areas are walkable, with a sub-material for the different surface types. In this case, there's already walkmesh where the beds are. That part of the floor is set to non-walkable: You want to chop up that pink rectangle up so it has a walkable surface covering the bed. Working with trimeshes can be a pain, so I prefer to add an Edit Poly modifier first and remove unwanted edges like so: Once the part we want to edit is actually a real rectangle, editing the geometry is a lot easier. Just make sure to make it a mesh again when you're done.