JCarter426

Yeah, it's my fault. Not sure why yet, but I'll look into it.

I think I like #2 the best. It sounds a bit muffled, but that might be due to the filter on the original line and might not affect totally clean VO. #3 sounds like it has far too much echo to me, more like something played over a loudspeaker.

Yes. The interface isn't as user-friendly, but it shows you exactly what is in the GFF file so you can't go wrong if you know what you're doing. You may find it easier, though, to edit the inventory in KOTOR Tool and then use K-GFF just to remove the drop bugs. This is as simple as searching for each item and setting the drop flag from 1 to 0. You can write them with Notepad, and in this case you don't have to write the whole script but just change the item resref from g_w_dblsbr004 to whatever you want. The trouble is, though, the source scripts are not included in the game files, so you would likely need DeNCS to decompile it. Source scripts are regular text files saved with an NSS extension. These need to be compiled to NCS before being put into the game. Likewise, you need to decompile NCS to NSS to edit them. Both NWNSSCOMP for compiling and DeNCS for decompilng can be found here.

View File JC's Supermodel Fix for K1 This is a fix for a number of issues present on the supermodels, the stock animations used for most characters in the game. When wielding dual melee weapons, male hands would clip through the weapons for some animations, notably the looping ready pose. The issue seemed to be that the fingers were gripping the weapon too tightly, so I loosened them up for the male models. If you think you've spotted any other issues, send me a picture so I can confirm what the problem is and whether it's an issue with the supermodels. If so, I'll add it to my to-do list. Submitter JCarter426 Submitted 09/08/2018 Category Mods K1R Compatible No  

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.