JCarter426

Any mod that includes a file with that name is likely to cause problems. I think I remember having that issue when testing K1 Enchantment / Enhancement, which has a few other such issues. The problem is due to reused file names. You intend to replace one NPC in one area, but BioWare used the same file name NPC for another NPC somewhere else, so it overrides both. This can lead to game-breaking bugs when there's a discrepancy in their information, like the UTCs having different tags or scripts.

Yeah, the floor between the doors is a bit of a raised platform. The trim is there on both sides, but it's much brighter on one side than the other.

I see it in 003EBO.mod, which would mean any changes TSLRCM makes to it are only effected in that module.

It doesn't look like there's anything missing to me, just a darker lightmap. It's the same with the door frame. There are some bad triangles in that room, though.

Cool! I guess all the prices are set once the store is open for both buy and sell. I wasn't sure they would be because the upgrade system in K2 gets refreshed when you switch between things. But all the better for us.

Yeah, it might not even be worth trying to calculate the orientation given that almost all of the time they're spawned facing a cardinal direction, which is really easy to figure out. So, you can get the XYZ position from the GIT. Based on your original data... XOrientation: 0 XPosition: 339.387878417969 YOrientation: 1 YPosition: 145.786026000977 ZPosition: 56.140998840332 That would be... Vector(339.387878417969, 145.786026000977, 56.140998840332) For the orientation, you can just start at 0 and and if that doesn't work, rotate to fix it. Location(Vector(339.387878417969, 145.786026000977, 56.140998840332), 0.0) Then if 0.0 doesn't work, I'd suggest trying 90.0, 180.0, and 270.0 (or -90.0) until you got the right one. Scripting is in standard 360 degrees, no quaternions or radians, so that's not so bad to figure out manually. Good luck.

Hmm, I wouldn't have expected that to work. I can see why it might, but I guess I'm not so optimistic when it comes to predicting the game's behavior. Are the prices still correct if you switch back and forth between the buy and sell options? If all the prices are locked down when the store first opens, that would be a welcome surprise. The XYZ coordinates are the same. The only difference is the orientation, which I believe is a quaternion in the GIT file, just with some of the data missing. A quaternion with the values (0, 1, 0, 1) is equivalent to (0, 90, 0) in standard Euler XYZ degrees. It looks like the GIT file only bothers with the first two quaternion values (stored as XOrientation and YOrientation) because creatures aren't rotated along the Z axis and the real part is assumed to be 1. So the proper quaternion would be (XOrientation, YOrientation, 0, 1). This online calculator seems to convert correctly. I believe whatever output value isn't 0 is your float angle for the script, but I'm not entirely sure. Yes.

If I'm reading the script right, though, ChangeItemCost is going to permanently change the cost of items in the player's inventory and the price change isn't going to be limited to Crattis. I'm guessing this function is related to the kolto price hikes and wasn't intended to be used in this manner. But I'm thinking it could be made to work if there were another script that restores the item cost. Crattis' heartbeat or the OnExit script if there is one for that area already would be good options. I'd also attach something to the other merchants in that module to be safe, so opening their stores resets the price, in the event that you manage to talk to them before the price is otherwise corrected.

Also, rather than checking each crystal's tag, you could just check the base item type: if( GetBaseItemType(oItem) == BASE_ITEM_LIGHTSABER_CRYSTALS ) That way it'll apply to modded crystal items as well. Assuming the price change method actually checks out, I can think of at least one other merchant that would benefit from such adjustment. Everybody in the game says to go to Fazza to sell wraid plates, but of course he buys them at the same default price as anybody, which means it's more profitable to trek all the way to Yavin and sell them there with Suvam's discount.

You shouldn't need to do that. A less complicated way (no messy 2DA editing) would be to use one of Crattis' local booleans. This is done more often in K2, with several numbers being reserved for such things, but in K1, local booleans 49 through 58 are unused as far as I can tell. Local booleans are set and checked the same way as global booleans, except they are set and checked for a specific object, in this case Crattis.

P_JuhaniBB has a case of 17 too. Not really helpful information now, but I happened to notice that the other day. And continuing with the tangent space calculation issue, I've encountered it with another model and I've attached more files in case they'll help. This is an MMO model, but it's the same problem as before - smoothing errors across UV islands, only with normal map enabled. (Please ignore any other problems with the model. Oh, and the binary is for K2.) Tangent Space Troubles with Ported Underwear.zip

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.

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

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.