JCarter426

If it's Steam, it's entirely possible you're putting the 2DA in the wrong location. But I don't use Steam so I can't tell you what the right location is.

You'll have to remove all your edited UTC files and start a new game. If he's already spawned human with a different appearance line, he's going to stay human.

Yeah, the model is a mess. In addition to the overlapping UV islands, the hair is essentially lots of triangular meshes that clip through each other. Maybe you could flatten the hair and render to texture to add alpha masks, but I don't think that would help much. Also, any attempt to remodel the head would have to deal with all the smoothing errors generated by the modeling tools, unfortunately.

Ah, if it adds a new item type and that line is not in baseitems.2da, then it will indeed crash the game. Carry on.

If you're only editing a few items, you shouldn't edit baseitems.2da. That will change every other item in the game of that item type. What exactly were the edits that you say crashed the game?

It's been an eventful week. I have more discoveries to report, on another case of me breaking something and then everybody putting it back together again. Only this time, it broke because I was doing things the right way! It was only when I screwed up that I got the results I wanted.... So, I've been porting areas for a while. During the MDLEdit beta testing, once editing areas became a thing, I got some of Dantooine ported to K2 quite nicely: But for every attempt after that, something went wrong, like the latest one on Taris here: Some of the rooms don't render. When I got to Taris, this was after a handful of failed modules like this, and I finally realized the rooms that aren't rendering are only those without any real walkmesh data (no aabb node on the model and an empty WOK file). Even though the layout and visibility files were set up correctly (they're the original ones from K1) and all the textures were there, and so on, these rooms would not render. On Taris, all the walkable parts of the area would show, but the skybox and background buildings would not. I'd noticed before that K2 rooms have a tendency to include walkmeshes even when they shouldn't need them. Skyboxes were immediately obvious and suspect. You're not supposed to walk in the sky. Yet they were there, and though I didn't understand why, I tried adding a walkmesh to one of my problematic rooms on Taris and got it to render: After deleting the unneeded WOK file but leaving the MDL & MDX intact, I was able to confirm that K2 does not actually require a WOK file. Also, copying the original (empty) WOK files from K1 did not help with the rendering. It seemed only the presence of the aabb node was needed to get it to show. But the Dantooine skybox has no such node. The game was rendering it even without one. It couldn't be that K2 requires an aabb node for rooms. I had a working Dantooine to point to. I kept saying "This works! Why does this work?!" Well, lots of thanks to @bead-v for troubleshooting, and also @ndix UR for providing some suggestions. It took days of thinking and testing to figure out, but now the answer is clear: room models without an aabb node might not be visible in K2. Because obviously it was that. Of course K2 has different requirements from K1 that nobody predicted. The reason Dantooine was working for me was because when I set up the module, a year ago, I forgot to include the VIS file. Apparently, the lack of any visibility list forces the game to render every room all the time... even when it would have trouble rendering them otherwise. The counter-intuitive consequence of this was that when my module was set up incorrectly, everything that was supposed to be there would be there; when the module was set up correctly, stuff would fail to render. Naturally, I only forgot the VIS file the one time, and included it in every subsequent porting attempt, and therefore got unsatisfactory results. Every time I set things up correctly, the game would not behave, because apparently K2 has a higher standard for what qualifies as an area model than K1 does. So the upshot is that areas ported from K1 to K2 will have problems because of rooms lacking aabb nodes (probably every skybox, and more). Also, all rooms created for K2 must meet the same requirements, or else they won't render; everything needs an aabb node even if it doesn't require a walkmesh. bead is working on an update to MDLEdit to address this issue - an option to add a dummy aabb node when needed. The specifics are still being debated because of a complication in detecting whether a model is an area model. Apparently, the only way to do that is to check for an aabb node or the presence of a WOK file, since those are things that only areas have. I suspect the complication in solving this problem may in fact be the cause of it - that at some point in development for whatever reason, Obsidian introduced an aabb node requirement because it was the only viable way to check if the model was an area model and should be rendered... and then that meant every model required them. Given that K1 rooms can lack aabb nodes (that's the whole problem) the only other option is to check for a WOK file. Therefore, areas should be compiled with their original WOK files present, when applicable - in the same way that character models require supermodels. The part of this that I can't get over is I happened to misplace one file one time, and that mistake is what made KOTOR behave. If I hadn't screwed up, there wouldn't have been a working example for us to look at. We wouldn't have identified the problem without that, or at least we would've had a harder time of it. So the moral of the story is you can't look at how things work and use logic and reason to plan your modding course of action, because the game won't accept that. You have to approach KOTOR like a blunt instrument. Make mistakes that work.

Probably the same deal. I've noticed it before, but it never bothered me as much. I'm not sure if I'll include this in the fixes, but it's attached here if you want it for personal use. n_sithsoldier.mdl n_sithsoldier.mdx

You would be better off changing Atton's line in appearance.2da. If you copy the entire Selkath line and paste it on Atton's, changing the row number and label back to what they were, you should have no problem (beyond any problems inherent with the Selkath model). However, because the Selkath appearance is a full body model, Atton's appearance will no longer reflect his equipment, like Kreia, unless someone were to make new models for it.

You can take whatever model you want and rename it to match the naming scheme of a different weapon type to make it a variation of that weapon. e.g. Take w_blstrpstl_001.mdl/mdx, rename the files as well as editing the MDL base's name in a hex editor or MDLEdit to w_vbroshort_101.mdl/mdx (or whatever) and then edit the UTI of the vibroblade to use model variation 101.

Ah, that's interesting. I was wondering why even have a WOK format when some of the collision is on the AABB node on the model anyway... but I guess legacy NWN fussiness is always the explanation... when it isn't the Xbox's fault, anyway. So far the only thing that does work is if the model has an AABB node... but it's not that K2 requires it. I checked the skybox of m14aa and neither the original K1 model nor my working ported version have an AABB node. Still doesn't explain why K2 skyboxes tend to have them, but eh. Yeah, I'm used to that because I've caused the doubling-down on the layout coordinates and other problems before, like cutscene animations being stuck at origin. Breaking things is how you learn.

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.