JCarter426

So you're saying I've installed literally hundreds of MDX files for no reason. Lovely.

Would that be why the visual effect models included in one of the official patches have MDLs but no MDXes? I've always found that strange.

Toasty Fresh was working on a K2 version, actually. The beta was released on LucasForums, which is now gone, but the upload still appears to be active here. Although, it seems most of the swords are not in there. I was the one doing the porting back in the day, and you can find the original files I sent to Toasty Fresh here as well, but I believe this is just the same stuff. I know there are more swords than that, but I can't explain what happened to the rest. As for the other matters, porting Jolee's clothes should be simple enough. It's the same process as weapons except you also need to extract a supermodel (in this case S_Female02 I believe) and put it along side the model you're porting so its animations will compile properly. Note that you don't actually compile or include the supermodel at all, you just need it there to compile your other model. As LiliArch said, you don't need any fancy modeling tools, just MDLEdit. Heads are trickier, though. You do need to make changes in a modeling program and maybe somebody ought to do a tutorial for this.

In the past, if you wanted to add something to an area model, you would have to add it as a new room to the layout and visibility files because directly editing area models wasn't a thing. So a lot of older mods used placeables for that reason. Currently, placeables still have some advantages - like they can be scripted in, which is better for compatibility because there are many ways to script something in but usually only one model in a room to edit. Plus, if you want to give it an inventory or make it at all interactive, you're going to need to put in some sort of placeable, so it's easier to make a new one rather than add an invisible one on top of editing the area geometry. If you want your placeable to be animated, you may also run into some issues depending on which room you're in, because rooms can only play one animation at a time. Also, the lighting isn't that big a deal for reuse. The game's lighting is not super complicated and realistic - how else would they be able to get away with tons and tons of placeables with no lighting at all? It's all situational, of course, but there are advantages to lightmapping that still apply. You can achieve the same result by baking the lighting onto your diffuse textures, but that depends on the texture mapping.

Not every appearance is set to have those. You'll have to check your line in appearance.2da to make sure the modelj and texj entries are filled in correctly.

OK, um... I was going to try something but I wanted to see the crash first as a baseline... and neither the MDLOps nor MDLEdit version crashed. I went through the whole history of the Rakata dialogue tree. Also, the hologram looked like this: I don't know if that's normal or not.

Nah, I was still on the Ajunta Pall statue thing, sorry.

Hmm, it's a waste to use two placeable models for that statue, considering the placeable limit. It could be done with one animated model, and then you'd have an extra slot. That would be my guess. It might be crashing on specific phonemes used in emotions on those lines but not in the generic comment ones. I'd suggest removing the talk animation from your model to confirm if it's that, and then you could set up a supermodel copy of the original model with all but its talk animation stripped, perhaps... or figure out how to fix the talk animation. I imagine talkdummy might have to be baked and the objects you split linked to it again, but working with that sort of thing is hit or miss. If it's any consolation, S_Male02 also has the talk animation and both TSLRCM and my supermodel fix edit it without causing such crashes, so this should be possible, in K2 at least. I've edited it in K1 for my Jedi robe/dancer outfit bone rig but that's had so many problems I'm not confident using that as an example of something that works.

I wasn't. Good thing I wasn't, too, by the sound of it. That's a good question. Normally, I would assume an animation, but if that were the case, I would really wonder why the problem would be happening. And in fact, it isn't. It's two different models: PLC_Statue2 doesn't have the sword and PLC_Statue3 has the sword. Also, last time I played K1, the placement of the sword was bugged for me. It didn't appear on the dialogue node that said I placed the sword, but rather after the conversation was over. Which would be after I took the sword back, since it was in my inventory, and shouldn't appear on the statue. This is probably a scripting error rather than a modeling error, but maybe somebody will want to take a look at that.

Funny - I've used bones for placeable models. But MDLEdit did compile them in those cases, as far as I remember. This was a few versions ago, though.

I got some reports on the area tools. As I said when we talked on Discord, these are more ease of use issues than critical bugs. But I think I've nailed down which problems were in KOTORMax and which were in the user, so here we go: If I've imported rooms from different modules or duplicated rooms, then some rooms will have the same assignment number in the room order. This breaks the Order Rooms function - it won't allow reordering of rooms until the conflicts are dealt with. The issue will happen if there are Odyssey base objects with the same room number (obviously) but it can still occur after the duplicate rooms have been deleted. I suspect this happens if there are still walkmeshes pointing to the deleted ghost rooms. At first I was deleting all Odyssey bases and OddysseyWalkmesh modifiers and redoing everything, but fortunately that is not necessary. I've found that setting every Oddyssey base layout type from "room" to "none" will clear the room order and then they can be set back to "room" without having to relink everything. Though these must be done one by one, so it's a little inconvenient. Edit: Scratch that, I was just dealing with this again and this didn't work. It gave everything the same assignments they had before. And the walkmeshes assignments seemed to be cleared already. I did have to delete one of the "duplicates" and create and link everything to it. Maybe when that error occurs, have an option to clear the room order and all assignments? After changing the room order, the new order is not reflected in the visibility GUI or the walkmesh room link GUI. KOTORMax's visibility preview is super handy in theory, but the problem is you can't control the viewport while editing the visibility because it's in a prompt window. If it could be changed to an undocked window, like the animation editor, that would make it a lot more convenient. Visibility is always output in the order that it's selected rather than being based on the room order or alphabetically or something. This doesn't make a difference, but it kind of irks me that there's no way to change it once it's done apart from setting everything to no and starting over. A way to reorder the visibility in the same manner as the rooms would be nice. With the above two matters in mind, I've found it quicker in some cases to edit the visibility in Notepad, but there is no way to then import that back into the KOTORMax project. Same goes for the layout file. I tried importing them without models but KOTORMax treated it as adding new copies rather than updating them. I can update the info if I import everything from scratch with the new files, but this means losing stuff outside KOTORMax's scope like selection groups or anything not linked to an Odyssey base (like objects kept for reference, or templates for things like doorways). So I can get around the issue, but it would be more convenient if KOTORMax had an update function for layout and visibility files. For your consideration.

Huh, it seems to be a moot point because the Internet Archive saved it: download Miles.

Doesn't crash on loading models with animations! Looks good so far....

That's not the installer. I mean, it is, but all it does is ping the CSLU server to download the actual installer. And their server has been down for over a year. Their server did go down once before, and came back after a few months, but never for this long. Their website is still online, though, so who knows what's going on in Oregon. We've also tried manually copying the installation and making registry edits, but the checksum blocks the program from running because it checks hardware IDs and knows the other computer is not the one it was installed on. So you have to legitimately install the program by pinging their server which hasn't been online in over a year and without their server, the EXE is useless. Direct all complaint emails to these people. I do have the installer for an older version of Miles (the real installer) that used to be hosted on their website for free, but I don't know if I'm allowed to share it.

It is the CSLU thing.

I thought it worked too, though @DarthParametric once said he couldn't get it to.

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.