JCarter426

Right, yeah, they do have WOK files, but as far as I can tell they are totally empty. When imported in KOTORMax, they have no mesh with an OdysseyWalkmesh modifier, and when compiled with MDLEdit they do not produce a WOK file for that reason. There is, essentially, no walkmesh data at all for these rooms. I hadn't considered this before, but I was not including the original WOK files in the folder I had the ASCII files in when exporting. I had them all there when I converted to ASCII, but then I moved the ASCII files to their own folder. This may or may not make a difference. Mm, I've checked for that. I zoomed out with GLIntercept when the rooms should have been visible, and they're definitely not rendering at all. Even if the skybox had been offset by that much, I would think at least some of it would be visible given its size and the coordinates. I already sent the files to bead-v via Discord, but if you or anyone else wants to take a look, they're attached. Remember the binary models were compiled for K2, not K1, because of sinful porting. Edit: bead-v had me check for the presence of aabb nodes. There isn't one on either the original K1 room or my ported v1. Obviously there is one on v2 since I manually added a walkmesh to the room. m02ab_02r.zip

To my knowledge, the Sith don't have a custom saluting animation, so no. What I've gotten rid of is this beauty: And the idle animations on the other Sith models. I guess BioWare put them in to give them some variety, but they only made the idle anmations, so there's no transition between them and the stock set, making it jerky. I didn't like it, and didn't think the new animations added anything particularly valuable to the game in the first place.

But it's not supposed to be night. bead-v is working on it, though....

I got another problem that I can fix, but a tool fix would be preferred. Some backstory first. I've been porting areas since the MDLEdit beta testing, and it worked for the Dantooine courtyard (m14aa) right away. But then, for every attempt after that, there would inevitably be something wrong. I've now nailed down the reason for this. Here's my latest attempt, with m02ab on Taris: Several rooms are not visible at all. The visibility and layout files all check out, since they're direct copies of the ones from the game. I even tried rebuilding them with new room names and still had the same problem. And of course I compiled all the models, copied over all the textures and lightmaps. Everything should be working, just like Dantooine did. And yet, several rooms are invisible. I noticed that it seemed to be limited to rooms that don't have a walkmesh, like the skybox and some of the background buildings. All the walkable areas are rendering, and the others aren't. This was consistent with my earlier broken attempts in other areas, though I didn't make the connection before. So I tried adding a walkmesh to one of the rooms (m02ab_02r) to see what would happen: And there it is. Now that room renders. I've noticed before that many rooms have walkmeshes when they shouldn't need to, like the skyboxes on Citadel Station. Yet I went back and checked m14aa and its skybox does not have a walkmesh, and my ported version of it did render. So I wanted to confirm whether the issue was K2 requiring walkmeshes when K1 didn't, or something MDLEdit was doing. I kept the compiled WOK file and reverted the MDL & MDX files for that room, and that turned it invisible again. I also tried removing the WOK while retaining the newer MDL & MDX files and the room was visible with that. So the fault seems to lie in MDLEdit. When it compiles a room that doesn't have a walkmesh, there's a chance that it won't render in the game.

Having too many saves on the Xbox is definitely a problem, but I've never heard of it being a problem on the PC version. I can tell you I've had more than 700 saves before with no problem other than the game taking a while to load the save menu. I also agree it isn't worth doing for K1 because it will probably mess up the order. K2, however, separates your saves by the player name in the GUI at least, so you might be ok with that.

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.