JCarter426

What threw the units off would be the initial import in Blender or how you got your project from Blender to 3ds Max, so I can't say for sure. But when I'm opening a MAX project with bad units, I've found that opening it with the "Use Game Units" setting in KOTORMax off in the project's original units, then turning game units back on after everything is open tends to fix it. If you're having problems with MDLEdit, there's a bug reporting thread for it here. I'd also suggest you get the latest hotfix version here. Though MDLOps should work too. They both do essentially the same things, though how they do it is different. The basic compiling procedure for both of them is: Export your ASCII model from your modeling program. Put it in a folder somewhere. If you're compiling a body model, check the model's Odyssey base to see what its supermodel is and extract the supermodel files to the same location.. In your case, this is S_Female02, so you need to extract S_Female02.mdl and S_Female02.mdx and place them in the same folder as your exported ASCII file. Launch MDLOps/MDLEdit. Configure the target game. Load in MDLEdit or select file and read model in MDLOps. Save as binary in MDLEdit or write model in MDLOps. (You can also use the batch option in MDLEdit or the read and write model option in MDLOps for the last two steps.) Rename the compiled files to their proper names (e.g. PMBAM.mdl/mdx and not PMBAM-mdledit.mdl/mdx or PMBAM-ascii-k2-bin.mdl/mdx and such).

Must be the units, then. Fortunately that can be fixed, though I use 3ds Max and not Blender so I can't tell you how. Ah, good. Also, if you export as geometry, it shouldn't make a difference even if you didn't delete them. Back to compiling theory then.

First, PMBAM isn't supposed to have animations on the model. Looks like a compiling problem, not an export problem. You'll have to compile the model with the binary S_Female02.mdl and .mdx files in the same location for animations to work. Both MDLEdit and MDLOps need to read information from a supermodel to compile body models. Or, actually, you said you "deleted" the animations, but did you just delete the keyframes or did you remove the animations from the Odyssey base as well? Second, it looks like you imported with the wrong units. Or maybe the other model needs to be scaled to KOTOR size. Third, the textures are configured through appearance.2da rather than on the model, unless they're given a null value (****) in appearance.2da. So you either have to edit the texa values in appearance.2da or rename your textures to match the existing PMBAM* textures.

I'm not the best source of intelligence on this because I've usually avoided dabbling with GFF files in TSLPatcher precisely because of its problems, but a few common changes I have made are: Changing a character's appearance. (Changing fields.) Adding items to a character or placeable's inventory. (Adding structs - and the source off one of my major gripes with TSLPatcher, because if you keep running it, you get more and more items.) Making an item droppable or not droppable. (Changing fields. It's somewhat of a minor miracle that this works both as adding/removing a struct or just changing the field.) Changing what items a character has equipped. (Changing fields.) Changing an object's scripts. (Changing fields.) Making an item upgradeable. (Changing fields.) Changing an item's model and/or texture variation. (Changing fields.) Some less common ones: Giving a character the necessary feats to equip an item. (Adding structs.) Changing a character's soundset. (Changing fields.) Changing a character's conversation. (Changing fields.) Some things TSLPatcher cannot do, but that have come up before: Removing an item from a character or placeable's inventory, or one that's equipped. Changing an item name or description. A whole mess of things with dialogue files that I'd be surprised if they were ever resolved.

Yeah, I get that, but as you said - it's easier to write a program that handles a text file. I guess this is a thing for VP to figure out though. And even if that doesn't pan out, the features of just the text format alone sound good. Like editing models in a text editor? I'm used to that. Mm, I see... I was thinking that with your compiler, or this might be another matter for the merger/installer/whatever new tool, it would be easier to see that structs were identical. As in, not similar, but 100% the same data, because it was added multiple times, or they came from the same source in such a case like merging different copies of the same file. But maybe checking the entire struct would take a lot of processing time, and then any shortcuts for that would be situational....

I believe the struct IDs are by type rather than... by ID. Like every inventory item will have the same ID. So that's a problem, yeah. TSL Patcher can only count structs - so you can change the field # in struct # to whatever or delete a specific struct # or of course add a struct. I believe it can delete, anyway, but it doesn't support it because of the problems that would cause - if something were deleted, all the numbers would be changed, so your mod wouldn't work with any other mod that alters the same part of that GFF, thus defeating the point of the Patcher. And when it's told to add, it just keeps making more structs. If you're VP is making a new format, though, I would imagine that it would allow for more functionality than that. Theoretically, in the future. As for what would be considered identical, hmm... I guess that's situational, and it depends on the specifics of the mod being installed, but it could be as simple as a resref. "Add g_w_lghtsbr02 if there isn't a struct with one already", that sort of thing.

Yeah, I guess I should've said compiler + merger that I guess you'll be forcing @VarsityPuppet to make. What I mean though is if you toolmasters are designing the new GFF text format and tools to read it, it may enable more read/write functionality in the future. So we could say "only add this item if this exact GFF tree doesn't already exist" or "delete this exact GFF tree" where TSLPatcher is currently limited to "add this GFF tree" or "delete GFF tree # whatever without knowing what that actually is".

Yeah, that's on my wish list for this. It's something VP and I talked about before, though I figured it would just be a simple export of coordinates and then maybe we could import that into an existing GIT file somehow. bead-v is the one who thought of going to the trouble of inventing an entire new format for GFFs instead. Though I'd be happy to see either. I was thinking that, too. I don't know the specifics of TSLPatcher's current issues, beyond what it can and can't do with sort of an inking of why because I bugged Fair Strides about it for an explanation, but if we have a new, modder-designed format to work with that can actually go back and forth between GFF and text, then some other things on our modder wish lists might be doable. For example, perhaps the new compiler (whether it's included in MDLEdit or whatever) could detect what different GFF trees actually are, so it would know not to add tons and tons of duplicate items to a creature's inventory if run multiple times, as TSLPatcher does, or perhaps it could allow for deleting trees.

I've only ever seen this make a difference on the NWMax or KOTORMax side of things. You can take a character model and make it an effect or a placeable or whatever and the game doesn't care as long as it's a properly-compiled model (though it may not function properly due to lacking animations and such) so I'd be surprised but interested to hear if that made a difference anywhere. For example, one of the stranger things on the list of things I've done is replacing one of the Gamorrean models with a plasteel cylinder. And then running around the Refugee Quad with angry containers trying to bludgeon me. All for the sake of testing.

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.