JCarter426

They animate for me. The only difference I see is that when loading the area instead of the individual model, it does not zoom out on the timeline to fit the animation length.

Heeeeeeeeeeey, that sounds... ...familiar. My guess is it's thanks to the good old -a node. It seems like that's a catch-all method to have objects on an area model but behave not like an area model. Obsidian definitely did something under the hood that changes how things are rendered. I think we discussed this away from the ears of the common soldiers already, but might as well put it on record. In K1, dynamic objects (creatures, placeables, doors) only render depending on the visibility file, just like areas. If the room they're in isn't visible from the room you're in, you won't be able to see them. You can confirm this by messing about with the camera using GLIntercept. In K2, it's different, however. All dynamic objects render all the time. This includes any area objects linked to the -a node. Here's a good visual example of it: I took the screenshot when my party was in their apartment. You can see an example of a room that's visible from our apartment - the exit to the shuttle bay. You can also see that the apartment complex across from us is not visible from our apartment and therefore most of the area geometry doesn't render. However, all the dynamic objects in those rooms do render - the doors, the placeables, Harra - as well as the windows and window blockers on the room models, because they are linked to the dynamic -a node. Why they did this, we can only guess. But as I said in my previous bug reports, I suspect the presence or absence of a walkmesh is interfering with things because Obsidian used the aabb node to differentiate between static area models and dynamic objects as some sort of prerequisite for what should be rendered. Perhaps if they hadn't done that, then all rooms would render all the time, making the visibility file pointless. The trick, it seems, is sorting out what exactly the other prerequisites are....

The music side of things sounds easy enough. I've attached sound objects and the scripts to play them. These are the game sound objects - UTS files - and not the actual music. You can put in whatever music you want to play, so long as the file name matches what's on the sound object. I've included support for up to ten tracks, named sh_juke00 through sh_juke09. Or you can change them to whatever you want if you edit the files. The scripts will stop all ten sound objects, then play the specified new track. That's assuming they're all spawned, however. I don't know if you can spawn a sound object through a script - the notes in NWScript don't say - so they might have to be added to the module. Anyone who wants to continue this will need to figure out how to spawn the sound objects, create a jukebox placeable, and make that placeable able to fire the scripts for each track through a dialogue or whatever. SH Jukebox.zip

They do appear to be null. Could have been a mod that was changing their inventories, or the null weapon itself. I was able to find another instance in the Sith base on Manaan, outside the visible game world this time:

That's because Sithspecter was trying to fix the bug. High Quality Blasters makes that model variation invisible. I don't see anything under the Ebon Hawk but that is indeed where the origin is, so I wouldn't rule it out. If it is there, it would probably be from one of the turrets - tat17_turret_01.utc and tat17_turret_02.utc.

Can confirm. It's perplexing. And I don't know if discovering the underlying cause is even worth it, when fixing it is so much easier. For those interested, though, we were able to confirm the following things: It only occurs with certain appearances. All the affected models lack hand hooks. (e.g. HK-47 is unaffected) Not all models that lack hand hooks are affected. (e.g. Gizka are unaffected) It only happened with one UTC file that we tested. The weapon is spawned at world origin, making the problem unlikely to occur in other areas because the origin is usually outside the visible game world.

They were likely added by KOTORMax as part of the baking process. The keys are there in 3ds Max and I can confirm that removing them does get rid of the problem, even without the "extra_data". I can take a guess at the problem now. I suspect it's some order of priority issue which may be limited to the talk animation specifically. I had thought the game the game loads animations in the following order: stunt model > body model > supermodel and that it shouldn't matter what animations are on the supermodel because it's loading from the stunt model first. Plus, in most cases it's only playing animations directly from the stunt model (CUT001W etc). But of course the game is playing the talk animation from the supermodel for the lip flap. It seems at the very least the order of priority loads the talk animation first, so keyframes for cutscenedummy on the talk animation will override the keys on on the stunt model, causing the problem. The question now is whether this problem is limited to the talk animation. I haven't encountered any other examples of it so far, but if the order of priority really is: body model > supermodel > stunt model and it just usually isn't an issue because the game usually only plays animations from the stunt model, then there very well could be other problems. But we can't fix what we don't know. I guess we'll have to wait and see.

I see a difference, but because of the aliasing on those lines from the low resolution texture I'm not sure if it's for the better or the worse.

Funnily enough, @DarthParametric noticed that too just last week. If you want to see how it looks in the game, you can load the model in MDLEdit and go to edit > textures to enable the bump map flag for that. Then, change N_SithSolder01.txi to: bumpshinytexture cm_baremetal bumpmaptexture N_SithSoldier_b

Fixed and updated.

There's something wrong with the cuffs there. They're modeled with actual geometry, rather than being painted on. 🤔

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.