JCarter426

That's one I probably wouldn't mind releasing eventually, though it still requires some touching up. I should note though that I didn't make the mask. It's from a very old mod by Silveredge9 & Quanon , though I don't know where it's hosted anymore. Nexus probably stole it, if you want to look there.

Either the vertices aren't aligned, in which case you should toggle snap to vertices and move them into position, or they are aligned but don't have the same skin weight data so they're moving differently, in which case you should edit them in the weight table to make sure that all vertices that intersect have the same values.It looks like the neckline of the torso mesh is set to 100% torsoUpr_g: So I'd expect the issue is that the neck is a separate mesh and the lower vertices on it would have to be set to the same.

Hmm, I'll have to take a look sometime. I thought I had tried factions but as I said I don't remember, and who knows whether I knew what I was doing back then. I can see why feat gain might work, but I've never tried it. It would certainly be essential to creating new classes and worth looking into. The problem remains, though - at best new columns work on a case by case basis, so long as the 2DAs happen to be set up to allow it already, which appearance is not, apparently.

I got more oddities to report, another one that I don't think necessarily needs fixing but I figure this is the best place to bring it to everybody's attention, and one I suspect might be a similar case. Both these problems show up on the model 204telc for anyone who wants to investigate. The first issue - the one I know how to fix - is that the windows become invisible. I believe this is related to either KOTORMax's lightmap export script or how MDLEdit deals with them. The gist is that the window meshes are not lightmapped, and any part of an area model compiled without a lightmap or self illumination becomes completely black. Because the TXI uses the additive blending mode, black = transparent, so you get invisible windows. So any area that has transparent meshes might need double-checking. The second issue is that all objects using the Animate UV setting - the fountains, the sign to the Ithorian compound - are not actually animating. I didn't touch them at all, apart from linking them to my new Odyssey base. And I thought the workings of animated UVs had been known for a long time, so I'm a little perplexed. But as I said, I suspect it might be a similar eccentricity that the tools don't account for out of the box, but could still be fixed. Has anybody worked with them before? Edit: Never mind on #2. I recalled a vague memory of somebody saying something about some situation with meshes that can't be linked directly to the base. Linking meshes with animated UVs to a dummy that's linked to the base works, and that's probably how it was on the original and I just didn't notice. So I can reconfirm that condition applies here, though I don't understand why.

Yes, please, do tell. I tried it with something a lot simpler than appearance.2da once and had no luck, though I forget exactly what I was doing. I think I tried adding a new faction maybe. It's an issue with a lot of key areas - body models, lightsaber types, Jedi classes... I'd be interested to hear of any new columns at all that would work anywhere. It might reveal some hidden insight.

Merchant markup is set by the script that opens the store, not in the store file. This is how, for example, Suvam is able to give you a discount after you beat him at pazaak, but the items in his store remain the same. // 378: Open oStore for oPC. void OpenStore(object oStore, object oPC, int nBonusMarkUp=0, int nBonusMarkDown=0); I believe the last two are percentage increases/decreases, the first for the merchant's inventory and the second for anything they buy from the player. One would have to locate the scripts for each merchant, decompile them, adjust the values, and recompile. It's not difficult - assuming the scripts will decompile properly - but tracking them all down would be a bit of work.

That's because Hanharr is a Wookiee. Alien dialogue in K2 doesn't work like the other dialogue, or like the alien dialogue in K1. The VO_ResRef entry is meaningless, much like how player lines in K1 have them. Aliens in K2 have a set of VO defined in alienvo.2da. The audio played is determined by three parts: the alien race (Wookiee, Duros, Sensor Ball, etc), the emotion (comment, question, seductive, etc), and the take number (1, 2, or 3). The Record No VO Override flag will tell the game to use alien VO when it's set to 1, or at least that's what I think judging by the look of it. It's been a while since I messed with this. The AlienRaceNode flag points to a line number in alienvo.2da to establish the race and which files to use. The Emotion list is what lets you add variety and in part determine how long the node is since many are split up into short/medium/long. Note though that DLGEditor lists all emotions that exist, not just ones available to that race. No VO set actually has files for every emotion. Finally, the game picks one of three takes for that emotion to use, I believe randomly. The lip files are named the same as the the VO files, though they may not work in certain modules due to the lips being missing, so you might have to extract them. This also means it's possible that some VO lines don't have any lip files on account of never actually being used in the game, though I'm not certain of that. Also, in your screenshot, there's something wrong with the dialogue. It looks like all the alien VO data has been stripped from it. On Hanharr's line, No Record VO Override should be 1, AlienRaceNode should be 12, and Emotion should be Question_Medium. Did you by any chance edit the file in KOTOR Tool? It doesn't support K2 dialogues, and might break them.

StarWarsKnights.com hosts it.

It doesn't matter. The game won't read it because it won't know what it does. I've tried it before, though I don't remember if it crashes or just doesn't read the new information. If you want try it, go ahead.

It's not a row, it's a column. It's not possible to add new columns to KOTOR 2DA files and have the game recognize them. I understand that it is possible for NWN, and that makes me sad.

Yes, but those wouldn't be universal scripts used by the whole party (or worse, every NPC). They would be random scripts just to add the item in the game, like editing Bandon's OnDeath to give a specific UTI rather than dropping the one he does. That's your typical mod compatibility issue, and most mods don't edit the same things.

Yeah, the heartbeat script is the only compatibility issue. If you don't use it, you're fine. But in that case, though, you are still limited to the one item: one character issue. So you couldn't, for example, give Bandon's armor a custom model and have it wearable by the whole party. You'd have to pick a character and restrict it to them, or have multiple Bandon armor items, one for each character. Unfortunately the only way to add support with everything for everybody is the heartbeat script (or a similar script) and it's a mess to deal with. Though it's ironic, because editing it is so bad for mod compatibility, nobody edits it anymore. Kreia's Assorted Robes is the only mod I recall that does it and that I still see people using today. Agreed.

I could, and for the most part I have, though I never finished debugging it to stop creating duplicate items. But it all does work, no maybes about it. The K1 version already accounts for gender and player class, and I have separate code I tested in K2 that duplicates the head, though I never united the two because I never decided how to deal with the clone NPC spawning as I mentioned before. Like I said, what I actually wanted to do with it wasn't what I judged to be worth the effort at the time. If there really were a use for it I'd be willing to take a look at the code again, but I don't exactly see people lining up with new player models that are just waiting to be put into the game. Actually, the way I set it up is somewhat simplified. I intended to release it for general use at the time, so I accounted for people who don't know much scripting. If you wanted to add an item with that functionality to my system, all you would have to do is name your UTI files in a specific way and put the needed disguise effects on them. Though just that part alone requires knowledge of disguise items, new appearance lines, and how to use tokens in TSL Patcher, so it still isn't that simple.

Yeah, that's true. People would still have to make models for such mods and set up all the items and follow my notes so it all works properly. If I finished my scripts and released them, that wouldn't change the amount of people with all the required knowledge and skills to do anything with them. Perhaps I haven't been clear enough on what my code would actually do, however. The situation now is that when you equip a clothing item, it does one of two things: a) assign a body slot and point to the model in that column of the character's appearance.2da line, or b) apply a disguise effect that points to a specific line of appearance.2da and use the cell from that line instead. For option a we are limited to the available body slots in appearance.2da (9 for K1, 14 for K2). We can't add more. For option b we're limited in that any character who equips the item gets the same disguise. So female characters still look like male Sith when they equip the uniform. Heads are tied to it the same way, so if you want to add a new appearance row for Bastila, anybody who equips the item will have to look like Bastila. The only provision to get around this, currently, is to restrict who can equip the item. In K2, there are provisions to restrict the item to specific characters (e.g. Atton's jacket, Mira's jacket, Handmaiden's robes, player's armband) while in K1 you can get the same effect if you restrict it to a feat only one character has (e.g. Battle Meditation for Bastila). That's doable right now, and several mods have done this. This does mean, however, that only that character can equip it. You need a different disguise item for each character. It's that final issue that my code would eliminate, if completed. In my above video, Carth and the female player are equipping the same Sith armor item. The script applies either the male or female disguise variant depending on what it detects as their gender. If this were extended to account for body size and heads, then it would effectively function as if you added new body variation. Every character could equip the item and their body would change based on their gender and phenotype but their head would remain the same. But even if I smoothed out all the bugs, it wouldn't be a flawless experience. There would be a delay, a fade to black or some more ridiculous solution, and there's the feedback issue (in K1 only) that I mentioned. It could be done, but it would never be perfect, and it would be a lot of work for a simple armor mod.