JCarter426

sounds.bif is only 185 MB and doesn't even include most of the game's audio. If this is all your installer does, your situation is more like saying "there is no way for us to stop someone from pirating 5% of the game after we give them the other 95%". I understand you're in a delicate position. As you say you can't add DRM unless know what to tell it to check for, and you'd have to crack the game to do that. On top of that, the GOG.com version doesn't have any DRM regardless. But 5% of the game, which is very easy to extract, does not amount to the whole game. This may be pedantic, but I hope you can understand why a lot of people are skeptical at your team's insistence that this is a mod when it runs on a different EXE and doesn't require the game to run.

It will warn you about that and select the offending object so you know where it is. It's actually pretty handy.

This can't be done for body models like that. The game will apply one texture (the one in the texa entry on your appearance.2da line) to the entire model. Unless you null that out (changing it from PMBAMC to ****) you can't have multiple textures. And in this case, you don't particularly want multiple textures, given that you would have to edit every appearance line and then your mod wouldn't even work for custom appearances. Instead, what you want to do is put everything on one texture. Generally, the game likes powers of 2, and prefers square textures, though you can get away with whatever except for a few cases where it's required. Once you have your new texture with everything copy/pasted in and applied to the whole model, you can adjust the UVW maps with UVXform (scaling it to .5 width and height, or whatever you end up going with) and UnwrapUVW to move everything into place (adjusting all vertices by .5 in the necessary direction). If you prefer, you can do this in Blender, then copy the new UVW maps onto your skinned model in 3ds Max. You can do that so long as the geometry is identical. All UVW modifiers should be below the skin modifier for KOTORMax to export. Yes, that's right. And the OdysseyTrimesh modifier has an option to override everything to white for export. That way if you prefer to have it black in the material editor (this will prevent it from showing the alpha channels) or if you just forget about it (the default is grey, after all) you don't have to worry about that.

Ah, nice, you got it working. I'm a tea person, but I still like your solution.

Interesting idea with the water. I always thought it was meant to be a reflecting pool, but never thought to do anything with it out of laziness/lack of ideas. I also suspect the water might be blocking it. Bump maps are reactive to light sources - if you put a bump mapped model in a really dark room, for example, you won't see much of a difference due to how even all the lighting is. So the water mesh may be blocking all light, even though it's meant to be translucent, just because of how the game calculates things. However, there may be some fix for it. I believe there's a water alpha setting that isn't entirely understood, and you may also want to look into alpha blending to see if it would have an effect here.

That is the correct way to do it, but it should be done before skinning. There may still be a way to fix it now, though if there is I don't know it. Or actually I probably do, but I'm struggling to recall the specific steps. This may help:

Hmm, I'm guessing something may have gone wrong with Reset XForm but this sounds like a @bead-v question. What I thought had gone wrong hadn't, though. Looks like all vertices are in place, but perhaps the scale on the mesh being off is throwing off how it's animated.

Ah, it was an issue with your mesh scale rather than the whole project. That would explain the spaghettification you were having once it was properly compiled. Yeah, if you scale any geometry, you must use Reset XForm or else the scale 3ds Max displays will not match what KOTORMax thinks the scale is. And if you run into any other problems like that, with what you see in your modeling program not matching what's in the game, you can usually take your exported ASCII and import it back into your modeling program. That will at least refresh the display so you can see what the problems are. As for the arms, they look like either the game is still confused about some things (probably the pivot points). So I'd say try the importing the exported model trick, and then if you see the arms crazy out of place, move them into place by going into the editable mesh modifier and moving the vertices so they snap to the shoulders.

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.