JCarter426

Oh, ack... roundabout solution to roundabout problem, should've figured. If that's the case, I believe you can still edit the initial alpha value on their individual mesh nodes.

This is another thing where a wiki would've come in handy. Yeah, all the cutscene animations - those on stunt models, as well as animated cameras - are numbered starting at 1200, while the names begin with CUT001W because at some point in development somebody forgot that in programming you always start with 0. As for the transparency issue... I only have two flimsy guesses. The first is that since you said you're using the original model as a supermodel, maybe it's interfering... if that's the case, perhaps removing the offending animations from that might stop it interfering. The second I think you already know but it wouldn't hurt to double check - make sure that on the frame before and after each animation, there's a key to reset it to the values at frame 0. Also, messing with what the frame 0 value is might help in this case - if it's at 1.0 at the start and end, perhaps changing it to 0.0 or 0.5 might get it to behave.

Mm, and I'm glad you're enjoying it too.

Yes, whether you use TSLRCM or not, the mod adds new VO files for T3. I just wanted to make it clear that my mod undoes TSLRCM's changes for the same issue. In the original game, alienvo.2da points to T3 VO files that don't exist. TSLRCM edits this entry to point to other droid files that do exist. My mod adds files under the original, missing names, and then simply reverts TSLRCM's changes so they point to T3 files once again.

View File JC's VO Fix for K2 Summary This mod fixes two problems with the VO in the game. T3-M4 was missing some VO files. This would cause his lines to be skipped when these files were referenced in the original game. The files missing were his short "question" variants. I was able to edit together new ones using his medium and long lines as a source. Some of the Gand entries were misplaced; they were typed on the unused Gotal line rather than the Gand line. In this case, the VO did exist, but it wasn't being referenced properly in the 2DA file. I've adjusted the file to correct that. I don't recall if this presented any problems in the released game, but the affected VO files were the "question" and "sad" variants. I didn't remove them from the Gotal line in case that was actually used for Gand VO in the game. Installation Extract files from the downloaded archive. Run VO_Fix_K1.exe. Click "Install Mod" and select your game directory (default name SWKOTOR2). Uninstallation Remove the installed files. Replace alienvo.2da with backup if necessary. Compatibility TSLRCM does address the T3 issue, but it does this by replacing T3's VO with generic utility droid VO, which I really, really didn't like. So if you're using TSLRCM, this mod will revert that change. Credits KOTOR Tool – Fred Tetra TSL Patcher – stoffe Permissions Mod JC's VO Fix for K2 Mod Author JCarter426 Game Star Wars: Knights of the Old Republic II - The Sith Lords Attribution Preference "VO Fix by JCarter426" or "uses JC's VO Fix" or some other reasonable phrasing. This mod is released under the following licenses: Attribution Only License Attribution Only License (AOL) * You've got mods! * The creator of this mod has authorized the contents of this mod for public use. Other modders are free to use and edit materials from this mod and include them in other mods. This license applies to everyone equally and no further explicit permission from the original mod creator is required, provided the terms of this license are followed. The user must provide clear attribution for the source and creator(s) of these materials, following the specified attribution preference. The file that contains this attribution must be included along with all the other mod contents. (For example, crediting the original mod creator in your mod's description on a website, but not in any file someone would actually download, would be a violation.) The user must include any additional credits as indicated. This license applies only for the use of these materials in other mods (i.e. a form of software accessed within a video game). This license does not grant the user unlimited power to distribute these contents, edited or unedited, even if attribution is granted. These materials are being offered to encourage the creation of new mods that alter the game experience. (For example, distributing these materials as a mod resource on another website, or uploading the entirety of the mod as a "new" mod without really changing anything, would not be in the spirit of this license.) Where appropriate, it would be nice to provide a link to the original mod and/ or tag the original mod creator. However, this is not mandated. This is just a polite suggestion. Disclaimers DEE-DEET? Donations If you enjoy my mods and would like to show your support in a monetary manner, you may do so via PayPal with this donation link. For various legal and ethical reasons, this is entirely optional and is not a requirement to downloading or using any of my mods. I also do not create specific mods for hire. I make mods as a hobby and will most likely do so regardless of any donations or lack thereof, but modding does take up a lot of my time and every bit helps. Submitter JCarter426 Submitted 08/16/2018 Category Mods TSLRCM Compatible Yes  

That's just what you're adding though, right? Though judging by what you say, I guess maybe there would've been stuff going on with the transparency on the original anyway. It's just such a roundabout way of doing it... why would they do that?

This is exactly what I had to do for G0-T0 to get around the mysterious crashes caused by editing his texture of all things. This was years and years before MDLEdit, though I recently looked at it again and noticed MDLEdit crashes on loading his model as well unless animations are stripped - again, exactly as you described. As I remember it, I had to resort to a supermodel because back in those days MDLOps couldn't properly decompile models with animated meshes (droids, doors, some placeables) and while the new tools definitely can for lots of models, I'm guessing they might still have some hangups on a few. I'm surprised you need animations on the hologram models at all, though. I had thought they used stunt models for their animations.

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.

Even if it didn't mess with it, I don't think it could be applied quick enough to hide the character. I haven't tested it but I'm assuming there would be a brief lag between the character being spawned and the invisibility effect being applied through their OnSpawn or whatever. I also don't remember if there's a true invisibility effect or if we're limited to the distortiony cloak effect that doesn't even work on all video cards or if frame buffer effects are turned off. Mind you, the visibility is going to be brief regardless. 1 or 2 seconds, max. I'm just being fussy about that.

TXI files alone won't work for K2. Changes to the model are required, like I did with my Shader Fixes. I included the same N_Mandalorian.mdl/mdx files in my Minor Fixes so if you want to just include the files in your mod you're free to do so (see that mod for details). Though, by the look of it, you've already made changes to the model so you may be better off correcting it yourself. In that case, all you have to do is make sure your texture file is applied on the model before exporting it. The game reads the TXI data from the texture on the model, not necessarily the texture it's using. Or you could edit the envmap entry in appearance.2da to use the shader you want, which is kind of a hack method but also works.