JCarter426

Nah, I have it, but only on my old computer. Not on the new setup, or on my laptop. Fortunately I have easy access to it now and I've been doing most of my KOTOR work from it. I didn't make this known before because I didn't particularly want to be inundated with requests, especially before I brought my old computer back home... I mean I still don't, and that's why I outlined the steps for everybody else in my blog entry here, but in this case it was only a few lines so it wasn't a bother. No problem.

Update: CSLU Toolkit The CSLU Toolkit is now available for download without any license. As such, I do not believe it is necessary for me to fulfill requests. However, I hope the steps I describe below will prove helpful, and I am available to help troubleshoot problems. I have attached additional scripts for working with the CSLU Toolkit. Download CSLU Toolkit Update: SithCodec I have developed a program which can remove and append the headers for KOTOR audio files. Download SithCodec Apparently, I'm one of only a few individuals who still has access to the CSLU Toolkit, software that can output phonemes based on an audio and text sample. Historically, this has been pretty much the only way to generate LIP files for KOTOR so characters' lips will flap when they talk. LipSynchEditor converts from CLSU's PHN format to the LIP format, but to do that you need the PHNs first... unless you want to make lips manually, but that isn't practical. Unfortunately, the Center for Spoken Language Understanding's servers have been offline for a long time. As such, it's currently impossible for new users to install the software required to generate these PHN files. Only a few veterans like myself still have it installed. And I can't even guarantee I'll have access to it forever. It's currently installed on my old computer, but not on my newer system that I built after the servers were offline. I doubt the computer that does have it will last forever, so it's probably only a matter of time before I lose access to CSLU too. Until then, though, I'm able and willing to generate lips on request. And I've gotten a few requests already. Now, I don't want to make a habit of this and get stuck as the guy who does everybody's lips for them because making lips with the CSLU Toolkit is a long, boring process. What I can do for you, though, is tell you can do for me so I don't have to do all of it for you. If you follow the instructions below and send me all the necessary files, all I have to do is hit a button and send stuff back to you. And I have no problem doing that. CSLU requires three things: 1) audio of everything you want to create a lip saved as an individual mono WAV files; 2) a text file accompanying each audio file that contains the words spoken in that line of dialogue; 3) a master list matching each audio file to each text file so it knows what to process. First, you need your VO files in the mono WAV format that the CSLU Toolkit wants. If your VO is new, you merely have to make sure to save it in this format. If you're working with VO from the game, you'll need to convert it first. The game VO files are generally MP3 files with extra bytes added at the start of the file to confuse us. Stripping this header will restore them to regular MP3 files. This can be done with a batch script and you can read up on that here. That will make them MP3, but they still need to be converted to WAV. Any old audio converter can do this. Freemake Audio Converter is one I use for Windows. Alternatively, you can use the Miles Sound Tools to play and convert the VO directly from the original game format to mono WAV. Next, you need to write out all the words spoken in every line and save them as text files. I typically name the text files the same as the audio files. You then need a list of all your audio and text files. This is the most tedious part of the process, but fortunately I've attached batch scripts below to make this easier. text.bat will create blank text files for each audio file. You still have to type the dialogue into them, but at least you won't have to worry about the file names. list.bat will create the master list. It will search for every WAV file and create a line in the list for each one, saving all this as lips.txt. My script assumes each text file is named the same as each audio file, so if you want to use this script, that's required. Send me: 1) all your mono WAV files; 2) all your transcribed text files; 3) your master list of everything to process. Once I have all of those, I can run CSLU's script to generate PHNs and send them along. I can also batch convert to LIP if you want, because that isn't nearly as big a deal as all the above. If you want me to make lips files for you, post a comment below with the necessary files attached or linked, and I'll get to work. Lip Batch Scripts.zip MakePHN.zip

Here you go. Murder Mystery Lips.zip

This should take care of it. NM14ACRICK08047_.lip

What is the VO file for that line though?

XeNTaX is the place to go for the tools. Sorry I don't have direct links as I got most of the tools a few years ago. But I can tell you what you're looking for. EasyMYP is the equivalent of KOTOR Tool. It'll extract files from the MMO's archives. The majority of the game file names, however, are encrypted. You need to add a hash list that's able to it what to name everything, although even the most recent one won't succeed with everything. It is disappointingly incomplete, particularly for the later expansions. But it does cover a lot. There are two ways to get models into a modeling program. The first is Noesis, a free model format converter that will be able to convert from GR2 to OBJ or whatever you want. It's not perfect - sometimes it'll flip normals and it doesn't import skin weights at all. But it's pretty good for static meshes. You need a plug-in for it to work with the MMO models. The other method is to use the GR2 import scripts for 3ds Max. One imports the skeleton and the other can import meshes to be placed on the skeleton. If you want to port body models, this is a necessity. It doesn't do animations, though; supposedly, nobody has released anything for that yet. Jedipedia is a good source for hunting down models. It catalogues item model and material ID numbers. You can search for these IDs in an index to find the specific model and texture files. Generally there is an index for each body part. Since I'm not that familiar with the game as some of you out there, I also find TOR Fashion useful in hunting for items. It sorts items by type and similarity and is generally good at matching an official item name to the visual, which one can then look up on Jedipedia to get the ID numbers. That should be enough to get you started. If you're trying to port a body model, once you have all the parts in your modeling program you'll have to weight it to a set of KOTOR bones. And for that, it's a matter of time, effort, and whether you're fortunate enough to find something that will make the assets both games cooperate. We're currently working on some resources to make the porting process easier. Right now I'm working on a BFN rig (female player, normal size) that fits the S_Female03 standard. Theoretically, you can import any MMO model that uses that skeleton and my project puts it into the proper pose and corrects the proportions so it can then be given a skin wrap to match a KOTOR model. My intent is to eventually do one for each skeleton (or each one I want to use) and either get them in a releasable for so anyone with the tools and the inclination can port stuff with them, or allow for some sort of batch porting process by which we import every mesh (surprisingly, there aren't a whole lot of them) and form some sort of archive for them. But it's still early days.

Just one line? Which line?

You need the version for the game you're porting to, so in this case K1. Everything else seems fine, so if that's still not working, it's possible MDLEdit requires you to convert to ASCII, then load the ASCII before compiling. I usually do manual adjustments with KOTORMax rather than a straight port so I don't remember the specifics on that. And if that is the case, then you would likely have to do manual adjustments as well, because MDLEdit & MDLOps don't always get the smoothing groups right when converting.

You aren't supposed to install S_Female02. You just need it in the same folder as N_SithSoldier when you convert that from K2 format to K1 format. Both MDLEdit and MDLOps need to read data from the supermodel to compile a model's animations properly.

KOTOR 1 > BIFs > models.bif > Aurora Model & Aurora Model Extension That texture is N_SithSoldier02. All the soldiers use the same model but different texture variants. You'll have to replace 1, 2, and 3 to cover all of them.

Renaming the textures isn't enough either. You'll need to either leave a copy of the K2 texture files with their original names or edit the model to change the texture name. Probably easiest to do that with a hex editor to find and replace all instances of the texture, if they have the same number of characters. If not, you can edit them in MDLEdit by right-clicking each mesh. Also, it's usually a good idea to edit the model name to match the file name. You can do this in MDLEdit by right-clicking the header to edit the values.

The model and texture will only work together. The original male and female variants didn't use the same texture mapping, hence the vastly different quality textures. They could have mapped them the same (like they did with the officer uniform) or done textures of equal quality (like most player models)... but they didn't. My model is an edit of the male variant, retaining its original texture mapping so it can use the higher quality texture.

It shouldn't matter, yeah. That's just a preview in 3ds Max and shouldn't affect the animation actually being there.

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. 🤔