JCarter426

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.

Normally no, but getting them to run around a maze and pick up weapons is going to require custom AI anyway. Might be tricky, but I think it could be done. Something like a variant of GN_WalkWayPoints() with different paths for each maze configuration. Either the OnBlocked script or triggers could have them change between waypoint paths when they run into an obstacle.

Looks good. I'm looking at the original model too, and while I like the idea of weapons hidden in the maze, it doesn't seem like it would be all that difficult to find them. Maybe the maze could be supplemented with force fields between each wall section that can be triggered on or off. Like once you take an item, it changes the whole route of the maze that leads to that item.

They do, although if it's only misbehaving for them it could be a model scale or rigging issue.

The Kreia thing isn't a supermodel issue, so probably not. She would need an entirely new animation set to fix her hand issue, which probably could be done, but it's not something I'm interested in doing in the near future. I'm not sure what the problem with Hanharr is, but it could be a supermodel issue, so I'll take a look at some point.

Most models don't have animations on them, and inherit their animations from another, usually from one of the stock supermodels S_Female03 (for female characters) and S_Female02 (for male characters, despite the name). Even many models that have animations only have a few of them (just whatever animations that model needs that's super special) and still inherit most of their animations from a supermodel. When you convert a character model with MDLOps, you have to include a copy of the supermodel it uses (if any) in the same location so MDLOps can read it and compile the model correctly. So in Mira's case, the contents of your folder would look something like: P_MiraBB_edited.mdl.ascii S_Female03.mdl S_Female03.mdx With P_MiraBB_edited.mdl.ascii being the ASCII file you exported from Blender and S_Female03.mdl/.mdx being the original binary supermodel files extracted from models.bif. Note that generally you must compile with the supermodel for the game you are compiling for - so you would want KOTOR 2's S_Female03 for Mira, not KOTOR 1's. Also, older versions of MDLOps want a copy of the original binary model rather than the supermodel. But I hope you are not using an older version of MDLOps so you don't have to deal with its dark rituals. MDLOps v1.0 and all versions of MDLEdit are fine with just the supermodel.

The way each faction feels about the others can be adjusted dynamically via the AdjustReputation() function too. That's how the Sand People are triggered friendly or hostile depending on whether you're wearing the disguise. So I wouldn't worry about the specifics of that; any combination is possible, probably. It could probably be done by giving each team their own faction, one of the lesser-used ones like Sand People, Czerka, and Gizka, and changing the reputation levels as needed. Should be fine so long as everything returns to normal at the end of the match. Also I totally overlooked before that you redid the arena from scratch rather than just rescaling it, so well done there.

For the totally open one, perhaps a series of duels. You get to choose which player on your team participates in each round, and the last team standing is the winner. I think this would be a good opportunity to make use of the SwitchPlayerCharacter() function, which is only otherwise used for the Leviathan prison break. There can also be a variations on this, such as how many and which teams participate in a round, and how many members of each team participate (1-3) and could even be determined by a random number. There could also rules regarding who is allowed to compete in a round (like you can't send the same team member twice in a row, for variety) or what sort of weapons are allowed (so you have to be strategic with who you send). Hmm, would there be any conventional combat in this? I suppose some grenades and Force powers have a knockback effect, but the usual shooting/slicing does no such thing. Maybe rather than just being knocked back, they have to hold down a switch and can't be involved in combat. And if they're attacked, they can't use the switch - or to make it simpler, you can't use the switch as long as an enemy also occupies the hill. The goal could be to hold down the switch for a certain amount of accumulated time. All the knockback stuff could still apply, of course - if they're not on the hill, they can't hold the switch. An alternative would be to have being on the hill offer some advantage rather than being the goal. Like maybe as long as a team member occupies the hill, it gives the rest of your team shields or heals them or makes their attacks do extra damage... but the person on the hill has to stay there, giving you a numbers disadvantage as before. A few LucasArts games had a different sort of king of the hill style too, with the hill having some object to collect that you have to hold on to for as long as possible. If I remember correctly - we're talking older than KOTOR here - this was called "Kill the Fool with the Ysalamiri" in the Jedi Knight games. You had to hold on to the ysalamiri to win, but as long as you held it, it would disable your Force powers, and of course everybody would try to kill you to take it from you. I think one of them changed the premise a bit and made the item to collect a lightsaber, so you had an advantage while you held it instead of a disadvantage. The goal could again be the duration the item is held, or maybe the amount of kills you make while holding the item. This might be more suitable for the maze arena, as you would have to hunt down the item or whoever holds it through the maze. I think you could justify it either way. The audience might want to see bloodshed but they also want to cheer for the teams they like and see them win and death matches put a damper on that. And obviously the competitors don't want to die. Maybe it's just better business. You could always have both options too. Maybe one of the Hutts you can choose does death matches and one doesn't. Death matches do limit the gameplay options, though. Logically the game should be over as soon as any of your party members are killed - because they can't die for story reasons - and that's not how combat in the game usually works. And this limitation wouldn't apply to the other teams, because who cares if NPCs die. So I'd suggest limiting death matches to solo encounters, if they are to be used at all.

Shem had one such mod back in the day: Super Enhanced Mod, Ultimate Sound Mod (required for SEM, must be installed first) and optional Add-On. I don't think I ever tried it for KOTOR 1, though, so I can't comment on the experience. Also compatibility with newer mods may be an issue.

Do you have a barkbubble_p.gui file installed?

Sounds like a TSLPatcher issue - either not using it at all for spells.2da, or the UTI not being patched to reference the new spell. Both mine and InSidious' do use it, however, so that shouldn't be an issue.

There isn't really a screen that's "assigned" to them. baseitems.2da determines which items may be equipped by droids or humans in the aptly-named droidorhuman column. 2 for droids, 1 for humans, and 0 for either. The entry in the equipableslots column then determines what slot it goes in. The two races have mostly the same equipment slots, but they have access to different items for them. And this should be determined by the Race field in the UTC. I figure the easiest way to test this would be to start a new game after editing Trask's file and use him to check this.