JCarter426

In this case, that's a problem for two reasons. KOTOR Tool has a bug that causes all items in a creature's inventory to be droppable even if they were set to not drop before. K-GFF is the preferred method for this sort of editing. If you don't loot Brejik's corpse, the game will script in a yellow lightsaber for Bastila no matter what changes you've made to Brejik's inventory. So you'll have to edit that script as well.

I got another bug to report. You can probably file this under "problems only JC will ever have" but I've confirmed it's KOTORMax's doing and not mine. I've attached two sets of ASCIIs and binaries; v19 is broken, while v28 works. If you warp to stunt_51a or stunt_07 (among others) in K1 you'll see it. I've compiled both with MDLEdit, so the issue was specifically with the data KOTORMax exported. The fix was to copy data from the original ASCII file (also decompiled with MDLEdit) to overwrite the data that KOTORMax exported. The problem here was with my cloaked robe/dancer outfit rig, putting the K2 robe bones on the K1 skeleton. It works as intended, but it had unintended consequences with the cutscene dummy on certain animations. It would cause the model to get stuck in the wrong position, either at its last known location or the origin. I solved most of the problems by baking the cutscene dummy and adding some missing keyframes in certain places. However, this process seems to have broken the talk animation - the one literally called "talk" that handles the lip movement, not the character talk animations such as tlknorm or tlksad. The problem was specifically with cutscene animations for female characters when they talked. Male characters (talking or not) and silent characters (like the player) would not have this problem. It took me a while to figure this out, though. When I did, I was able to manually edit the ASCII file to fix the problem with the data KOTORMax gave me. Here is KOTORMax's output: node dummy cutscenedummy parent S_Female03 positionkey 0.0 -0.00019955 0.0 0.0 0.5 -0.00019955 0.0 0.0 endlist orientationkey 0.0 0.0 0.0 0.0 0.0 0.5 0.0 0.0 0.0 0.0 endlist endnode And here's the corresponding part on the original ASCII model / what I had to do to fix it: node dummy cutscenedummy parent S_Female03 extra_data 18 endnode Changing that and that alone was enough to fix it. Talk Woes.zip

That's a beefy Wookiee.

With the change in porting rules now firmly in effect and the interest in porting up to and including an entire game's worth of content obvious, I've started poking around to see how things can be done in the long term. As it is now, we have a smattering of individual mods that include ported content, which is all well and good, but this depends on individual modders with the required knowledge producing and releasing mods at their own leisure. As with a lot of things in the modding world, a lot of people are interested, but far fewer know how to do it. So I'm interested in automating the process in order to port content on a much larger scale - for example, making every module in K1 available in K2 - and release this content as mod resources that will be as easy to access as anything you can extract from KOTOR Tool currently, or perhaps even allow for the creation of an automated porting tool that the average end user can run. The latter case would apply even to stuff that was allowed under the old rules, like a lightsaber mod that was done for one game but not another. In general, I'm looking to make things easier and require less manual tinkering. Even before the rules change, I experimented for my own personal use. To make things easier for me, I started extracting files en masse rather than bothering to figure out what I needed for each specific job, given that this was for personal use and not release. Once the rules changed and I was free to distribute these, though, it became clear that this was not ideal. My modified texture packs that included all of K1 and K2's textures amounted to about 800 MB of data. It didn't seem reasonable to include all that in an official upload and put a strain on the servers. Plus, this is the sort of thing I've criticized the Apeiron team over, so I figured I should tread carefully and look for a better method. A more ideal situation would involve a tool that could extract assets from one game and send them to another. I started writing some scripts for this, though I've had mixed results and what I really want involves charting into some unexplored territory. Ideally, this new tool would generate a new BIF or ERF archive - portedmodels.bif or what have you - rather than requiring thousands of files to be placed in Override and all the potential file conflicts that come along with that. Ideally, these will be made as universal resources like the existing models and textures - that way people can still edit them and put their edited files in Override without having to overwrite any files. I've spoken with @VarsityPuppet about developing something like this in the long term, and I'm also interested in seeing whether certain porting processes can be automated with MDLOps or MDLEdit, so I imagine we'll be talking about those eventually. In the meantime, I'll also be posting my own, more hacky results. I've included two such attachments in this post. K1toK2 Texture Conflict Guides K2 has hundreds and hundreds of files that were reused from K1. It's not necessary, and generally not a good idea, to try to copy these over. Not just because they're unneeded, but because files with the same names might not actually be the same textures. There's a very good chance Obsidian altered them and kept the original names. So I've created these guides that list the names of textures that are included in both games. There are three lists: for textures.bif, swpc_tex_gui.erf, and swpc_tex_tpa.erf. (The last list also applies to to _tpb.erf and _tpc.erf.) There are two sets of lists: one that lists conflicts, and one that lists files that are only in K1. K1toK2 Texture Filters These are simple batch scripts that will delete all textures in a folder that are known to be in both games. That way you can extract a game's textures, run the batch files, and filter out the textures that are already in the other game. Extract the contents of textures.bif, swpc_tex_gui.erf, and swpc_tex_tpa.erf from K1 with your preferred method and place them in the same location as the included batch scripts, or you can put them each in their own folders if you prefer. You should have thousands of TPC files and a handful of TGA and TXI files. Run the three batch scripts. These will delete all the conflicting texture files, leaving only the ones that are unique to K1. The batch scripts will delete themselves when finished. Copy the remaining textures to K2. You can put them in Override (or a subfolder in Override) or you can repackage the ERF texture packs to include both the original K2 textures and the extracted K1 assets. Note that if you do want to put them in ERFs, you will have to do _gui and _tpa separately, and you will also have to repeat the process for _tpb and _tpc using the _tpa script if you want to include support for the lower quality texture options. For the first version, I've specifically filtered out every file that has a matching file in K2. Eventually, I want to confirm which (if any) textures Obsidian modified, so we can include both game versions by renaming one copy. If you use my filters and start porting K1 content to K2, you won't run into any missing textures, but they might not necessarily look as they did in K1, at least for now. K1toK2 Texture Conflict Guides v1.zip K1toK2 Texture Filters v1.zip

I don't know if this is worth reporting, but I was messing with KOTOR Stuff to extract a set of specific files from ERFs and it skipped a bunch of them. I've attached the batch file I was using to extract files from K1's swpc_tex_gui.erf. It said in the console that it failed to find them in the ERF, though I know they're there since I generated the list by extracting all the files and filtering what I wanted. Maybe the massive number of files just overloaded it. Also, I noticed if the folder KOTOR Stuff is extracting from has a space in its name, it'll treat that as the end of the name and ignore the rest. (e.g. "New folder" is read as just "New".) K1_gui.bat

If you're doing one at a time, you could wait until you finish one, if you rename all the save folders to start where the other ends. Kind of a pain to rename them due to how the numbers don't match though.

JavaScript? You working with Tyvokka to run KOTOR in Netscape? This is all very interesting. A new module editor is the next big thing a lot of us want to see... we've even been talking about how it could be done with KOTORMax. But your screenshots look a lot like the Dragon Age Toolset and a live preview like what it has would be very handy.

You can, yes. It's tedious, but it can be done. Probably easiest to do it in Notepad. First, extract the Selkath MDL and MDX and convert it to ASCII format with MDLOps or MDLEdit. This will create an editable text file. Do a search for the string "newanim" until you find the animation you want to duplicate. The naming scheme for these is tricky to decipher, but I have a tutorial here and animations.2da may also help. Though you may find it easier to import with KOTORMax or KOTORBlender so you can see the animations. Anyway, once you've figured out what you want to duplicate, copy the entire tree of text, from the newanim like to the doneanim line and paste it anywhere at the bottom of the animation list, after the last doneanim but before donemodel. Change the name of the animation, newanim xxx to newanim yyy and doneanim xxx to doneanim yyy. You'll have to figure out what you have to change it to, of course. Repeat this process for all the animations you want to duplicate, then convert the file back to binary MDL/MDX with MDLOps/MDLEdit.

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.