JCarter426

FYI, you only uploaded one model. The only thing that jumps out as odd to me is that the talk animation is parented to talkdummy, which I believe is normal for lip movement but maybe it was particularly sensitive to your edits. Could try baking talkdummy and relinking everything. Although, as far as I remember, that model doesn't even have functioning lips. I also noticed it has no talk animations (e.g. tlknorm). So there could be something else fishy on the model.

Ah, that's interesting. I figured dummies might be necessary for animations, as I noticed the shuttles are linked to them. Also figured it would want the -a specifically because if linking to any random dummy would change how the objects behave, then you'd have an issue if you wanted to link use dummies just for organizing and placing objects. So by the sound of it, the -a dummy is a sort of room within the room that behaves more like a placeable than a room. Though they still have some area characteristics, as objects linked to them can be lightmapped. And if it's used for dynamic objects, it would make sense that it's rendered at a different point than the static rooms, which would explain why it fixes the window issue.

That's the sort of thing we'd need, yeah. Any sort of speech recognition that actually works will work. The PHN format that the CSLU toolkit outputs is not that complicated. It looks like this: Those are just start and end timecodes (in milliseconds) followed by the phoneme. The only tricky part of the format is the phonemes, as KOTOR only accepts a few specific phonemes and LipSynchEditor is set up to filter them based on CSLU's naming conventions. So long as whatever replacement tool is able to output its phonemes as a text file, it wouldn't be difficult to write a program to convert its text format to match CSLU's, or edit LipSynchEditor to filter based on the new format.

Hmm, that's just for mesh alpha though, right? I'm pretty sure for textures with alpha channels, it's the lower one that's rendered on top. That's how my Darksaber works, for example. Although, now that you mention it, I do remember it being backwards when I was working with alpha on the trimesh modifier instead. I didn't know about the alpha blending, though. That's cool. So, it seems like there may be more options for the window/skybox issue, though the weird linking to a dummy thing does work. I'm still curious which factor exactly is in play there, but perhaps we'll never know.

Nowadays, one doesn't. If you don't already have the necessary tools, there's no way to get them because of bad practices on the toolmakers' part. Unless the folks in Oregon get their servers running again, nobody can install CSLU, which is the only thing that will generate phoneme data that LipSynchEditor can read to generate .lip files for KOTOR. We could, in theory, find another tool to generate the phonemes. I've looked through LipSynchEditor's source scripts and I'm pretty sure if I had phonemes from another source as a text file, I could write a program to convert it from that format to CSLU's so LipSynchEditor would read it. Or, I'm sure, one of the many better programmers on this site could come up with a similar solution. If we had another tool. I've looked, and other people have looked, and it seems CSLU's might be the only one around that works and doesn't cost money. Although right now it doesn't matter how much you money you have if you don't already CSLU installed. You can't install the program unless their servers are running, and you can't copy an installation from one computer to another because the program checks hardware IDs and will refuse to run. Even though it's a free program. Currently, the only way to generate lips is to convince someone who already has CSLU to make them. Though, it would be possible to do most of the work even if you don't have CSLU - most of the work is writing text files - and just have someone who has CSLU batch convert them and send over the files.

I've started experimenting with editing and creating new areas, so I thought I'd take advantage of our new forum here to document my tinkerings. Areas have been the most problematic matters for KOTOR modding since the early days, mainly because the modeling tools couldn't handle vital things like lights and animations. Also, different tools were necessary for different procedures, and they each had things they couldn't do, and would break different things. Fortunately, recent developments courtesy of @bead-v have sorted that; KOTORMax and MDLEdit can handle any type of model and can successfully import and export everything necessary for area models. But that was only recently, and as such I haven't dabbled much in areas because I thought it was too much of a hassle before. I've always been interested in it, though - I first got into modding making maps for Jedi Academy, and I was thoroughly disappointed when I learned things weren't so simple with KOTOR. I wasn't the only one who felt that way either. Even after making new areas was technically possible, few did. And with the new tools, the limits have yet to be tested. I've decided to do some of that testing. I'm not going into this completely blind - so far I've been able to half-remember several discoveries made by my predecessors, and I've made a few of my own already. The idea of this thread is to document things a little better as I go through them so nobody in the future will have to half-remember anything. And anyone else experimenting with areas is welcome to join in, of course. I think we'll get started with a little show and tell: I've set up a new area as a proof of concept, and I've attached the files below. There's not much of a point to it now, beyond letting you take a look at some empty areas, though I expect I might end up breaking things and require troubleshooting in the future, so here's a working version of it as a baseline I guess. For now you can look at it, and I've included everything so you should be able to fiddle with it for personal experimentation if you want, though obviously don't put it in a mod because go get your own. Anyway, I've created a new area for Citadel Station by rearranging various rooms from three different areas and making some other adjustments. I took the hallway from 204TEL, doubled the length, added doorways at either end, and changed what each door leads to. Most of the side rooms are copies of the apartment complexes from 203TEL, with a few rooms from the Ithorian compound at the end of the hall. I also changed the exit, as I decided to use the existing one as a sort of lobby area, and instead added a doorway to the wall. I pulled the new exit hallway from 208TEL. I made some other edits like putting in new signs and made some changes to the lightmaps so everything blended together better. But for the most part I just pieced together existing models in a new layout. I'd done this before, mostly by editing layout files in Notepad, but I figured more extensive changes would be possible with the new tools, so I wanted to try it out. I was impressed by how easy it was. I did the basic layout with all the rearranging and had a working area in just one evening. It took a bit longer to make the other edits, especially dealing with the lightmaps, and to debug a few things. Though, even a lot of what I didn't know was intuitive enough, like making the new walkmesh. This isn't a brand new area from scratch, but I think it is distinct enough compared to the other Citadel areas - all the residential ones at least have the same architecture, with copies of the same basic rooms but different variations on them. Similar, but not the same. And it was the work of a few days by someone who didn't know what they were doing yet. Pretty easy. Now for some technical details. There were a few things that gave me trouble and between half-remembering things and experimenting, I've come up with solutions for them and perhaps more importantly a guess for why the game is the way it is. Animate UV This is one of the properties on the OdysseyTrimesh modifier in KOTORMax. It's a form of animated texture, but rather than have an animation on the texture file, the game animates the texture mapping. 204TEL has two instances of this: the water fountain and the sign to the Ithorian compound. During my early edits, they wouldn't animate. I was able to conjure up a memory of reading something elsewhere on Deadly Stream and realize the reason for this is that objects with animated UVs cannot be linked directly to the model base. They have to be linked to a dummy that's linked to the base. The dummies in the game seem to be named with the room name + "a" (e.g. trimesh linked to dummy 212tel03a linked to room 212tel03) though I don't know if the name matters. Alpha Shenanigans The parts I've circled are rendering on top of the window rather than behind it. It stands out more if you see it in 3D space, but in the picture you can tell by how they're dark brown when they should be tinted green due to the glass of the window. It's happening because both the window and the offending objects - the skyline, the antennae - make use of alpha channels to have part of the texture transparent. The game doesn't render overlapping alpha channels correctly. The game will always pick one object to render on top of the other object(s) regardless of how it's actually supposed to be. This is actually a known bug in OpenGL, which makes it like the hard-codedest of hard-coded problems. Let's say you have a room with two windows, Window A on the west side of the room and Window B on the east. If you're outside the room on the west side, Window A should appear in front of Window B; if you're outside of the room on the east side, Window B should appear in front of Window A. But the game will always render A on top of B regardless of where you are. You can trick it to render B on top of A if you prefer, because the game determines the rendering order in a very specific way. The object that is rendered most recently is always rendered on top. Normally, the way to do this is to edit the hierarchy of a model's objects - put the one you want rendered on top at the bottom, so it's most recent. The easiest way to do this is to unlink all the transparent objects, then link them in the desired order. But that wasn't applicable here because the rooms are on different models. Yet it wasn't a problem on the original game models, so it had to be something I was doing differently. I tried fiddling with the layout file, the visibility file, even the module's .are, and none worked. It took me a while to figure it out, but the answer again was that transparent objects should not be linked directly to the model base. Like the animated UV issue, they should be linked to a dummy that's linked to the base. I'm not exactly sure how this fixes it, but I'm guessing the game renders all objects linked to all the room bases first before rendering things linked to things rendered to the base. There is some sort of delay, in any case, that makes the window rendered after the skybox room, which is what we want. Lightmaps and Lack Thereof I had another problems with windows when I first started working on my area - they were totally invisible. It didn't take me long to guess this was because they weren't lightmapped; any part of an area model that lacks a lightmap or self illumination is rendered totally black. Since windows use an additive blending mode, and black adds a value of 0, my windows were appearing completely transparent rather than the intended partially transparent. It didn't take me long to guess that, though I had to deal with the other two problems before I figured out the real reason this was happening. Objects that don't have a lightmap or self illumination should not be linked directly to the model base. It was the same damn thing a third time. Once again, they should be linked to a dummy that's linked to the base. To be fair, all the areas I was editing were set up that way. However, I didn't notice because I had to create new rooms to get my new walkmesh to behave, so I had unlinked everything from the start and then linked everything to the new bases. I'm actually glad I overlooked this, though, as I don't think I would've figured out as much as I did if I hadn't broken three things. My guess is that objects linked directly to a room base behave in a certain way, and can only do certain things. Linking them to another dummy is a way of telling the game "don't treat these objects like area model objects" and you if you do that, you can do different things with them. It's already affected three things, so this might have applications in other areas. Smoothing This is kind of a no-brainer - I'm used to having to do my own smoothing for character models, but after all the other troubles I had, when I ran into what turned out to be a smoothing issue, I expected it to be a bigger problem. Generally, area models aren't as complex as character models, and MDLEdit is pretty good figuring them out, but it did mess up one part of my area. So you should double-check your smoothing groups because the tools don't always calculate them correctly. That's all for now. I'll be back as I poke at more things. 212TEL v1.zip

I wasn't either, but as long as they're technically different things being animated - bones vs meshes, or whatever - I wouldn't be very surprised. I'm guessing when the engine plays the animation, each individual object gets a different set of instructions. So it's conceivable those instructions can come from different sources, though it's in most cases it's all or nothing. Essentially, every model - the stunt model, the character model, the supermodel, is told to play CUT001W (or whatever animation it is) and through various black magicks it decides which keyframes from which model in which order for all that to happen. Or something.

I suspect cutscene animations only override animations on objects that are animated on the cutscene model, while anything else uses the animation on the character model (or the whole supermodel chain) - much as an overlay animation works. Like how the blaster deflection animations only affect the arms but everything else keeps doing whatever else it was doing at the time. So the if the stunt model only affects the cutscene dummy and bones, then it's still getting animations for the mesh transparency directly from the meshes on your model. It could be the game actually can't get that sort of thing from a cutscene model or supermodel... that would be my guess for why they went to the trouble of setting it up that way, anyway.

I was about to report but you beat me to it. 1.0.5 will load c_holododonna, so the crashes must be related to the recent update that broke animations. That's why I was scratching my head before about how roundabout it is. It seems the stunt model is used for the character animations as well putting it into position onto the holoprojector as is usual with cutscene animations... but animations are also used on the character models, for things like Vandar fading in. That must be a mess to navigate.

Huh, the original release VP gave me a few months ago included a DLL file, but I don't see it in the alpha release on the site. You forget that, guy?

Been using it for a while now. It's great!

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.