JCarter426

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.

The numbers I mentioned before are for before the final romance conversation. So if they're set to that in your save, they're wrong. I don't have any recent Bastila romance saves to check, but I believe K_SWG_BASTILA should be at 12 at that point in the romance.

I'd suggest extracting the entire archive and using xoreostex2tga from xoreos tools to convert the TPC files to TGA files.

During the lesson of sight, T3-M4 speaks one of Kreia's lines: In addition to the erroneous message log, if T3 isn't present on the Ebon Hawk, the scene will break. This can happen with modded versions of visasmarr.dlg that fail to respawn T3 immediately after the encounter. I suspect it would also happen with TSLRCM alone if one sold T3 to Kodin before initiating this conversation, but I have not tested that. This happens after the player speaks to Kreia about the duel with Visas. ("When Visas attacked, she did something to my eyesight.") This issue was reported to me by @Snigaroo and I'm not sure of his specifications, but I confirmed it on my system with Windows 7, the original 4 CD version, updated with the 1.0b patch. This issue is present in the current version of TSLRCM, v1.8.5. I tested from a clean installation with no other relevant mods. The issue happens with different saves and installations. The problem is that the speaker for this line in kreia.dlg is set as T3M4: However, if my suspicions about selling T3 are correct, then a proper fix would require something more extensive.

There's some sort of script that changes her appearance, on account of her clothing being a full body model. She has different appearance lines for her light side clothing, dark side clothing, and one for all other body slots. My guess is that her appearance is changed by her heartbeat script, although the functionality could be hidden several layers down in the header files included in that. It would be easier to change her appearance.2da lines to your desired specifications.

The row label does nothing and is only there for viewing convenience. The game only cares about what the actual line number is. K2's placeables.2da is a good example of this; numbers 281 through 290 repeat, so everything from 291 on is off by 10.

VO files need to be in mono. That's the most common mistake I've seen, so I'd check that first. I've also heard of the Steam version taking some issue with custom files, and I believe the fix for this is to add the fake header that other files use.

Cleave and most of those other obscure mechanics are leftovers from Neverwinter Nights. I'd be quite surprised if any of them worked, although that testing sounds thorough enough. I might test some more on my own when I have a chance. Here's the write-up for it from the D&D SRD: Cleave, Great Cleave, Great Cleavage

If I remember correctly, there is a push function that ignores the walkmesh to some extent. It's been a while since I messed with it, though.

I don't recall if new classes can learn new powers, but it certainly won't give them new Force points for their class. And even if you have points, having them hidden makes it unplayable anyway.

The game doesn't give them any Force points. This seems to be hard-coded rather than based on the forcedie column in classes.2da like you might think. It doesn't even display the bar for it. So if you multiclassed from Jedi to non-Jedi, for example, your character would still have Force powers, but no longer be able to see how many Force points they have. It's possible to make other classes, but there are some limitations. They can only use existing tables for power gain, feat gain, saving throws, and base attack bonus. These all have to be identical to some other class', though you can mix up which are used for which. Depending on what you want to do, you may be able to get away with editing the original table without affecting NPCs that use the original class.

Ah, I thought you meant a more traditional free-for-all type of gameplay. Which I do still think could be done, the execution would tricky indeed. I wouldn't mind playing around with some mechanics a bit to see what could be done, once/if I ever finish some of my own ongoing projects, that is. Huh, it certainly seems a lot taller up close. Also looks like there are three different layers to it. I wonder if it would be possible to implement some sort of scoring system with it. Like you get one point for knocking someone down to to the next layer, but more if they go all the way down.

Well, I didn't say that. I'll take a look at why it's happening, but if it's not an issue with the supermodel and an issue with the Wookiee models themselves, then it's out of my hands. I mean, I could do it, but a) I don't particularly want to re-rig four Wookiee models, and b) it wouldn't be appropriate to release with the supermodel fixes given the potential compatibility issues and would be best left as a dedicated Wookiee mod (which I'm not particularly interested in doing because see a). But I'll have to see what the problem is first.