JCarter426

Funny, we just dealt with this problem on Discord yesterday. That's due to the model having mismatched MDL and MDX files. I'd suggest you remove both and search for the most up to date version of that mod and reinstall just those files.

DAN_MTm2

Additionally, his medal was stolen and left at the crime scene by the Sith in an effort to frame him (for a crime he incidentally did commit) so he wouldn't be wearing it. But if you (or anyone) want to make an NPC appearance change mod thing, SpaceAlex released all those assets as a mod resource for anyone to use and finish and there are other available resources as well. The art really isn't the hard part. Partly on account of it's already been done by talented individuals, but mostly because actually putting it into the game is harder and more time consuming and that's the reason SpaceAlex never finished.

FYI, I've already ported every module from K1 to K2 and plan to release them as a mod resource. I'm just waiting on an update to MDLEdit to make that possible, due to issues that I've outlined here. I don't mean to discourage anyone else from having a go at it, but if you do you're likely to run into the same problems and you'll be repeating a lot of boring work I've already done. Your ZIP is missing all the textures, including all the lightmaps. I've outlined how to port textures here, though I didn't cover lightmaps there because they don't have the file name conflicts that post was concerned about. If you want to get all those, you'll have to extract everything from the various lightmap BIF archives in the same manner. That should be enough for your personal use, but for release you'd have to hunt down every texture used in the area and include them. You'll have to be more specific about what's not working. The models are probably in K2 already. Most K1 doors still are, from what I've seen. However, ones that aren't use may have had their lines in genericdoors.2da overwritten. To restore them you'll need to add new entries with the correct information and edit the UTD files to have their appearances point to the new entries.

Oh, that's interesting. I would guess it's due to changes in the follower AI. There are obvious other changes so this could be another, more subtle change. After a cursory look I don't see anything obvious, though, in either k_hen_heartbt01 or k_ai_master. These scripts are a bit of a maze to navigate, and there's always the possibility of it being a hard coded change to ActionFollowLeader().

That should be enough in most situations, but it depends on which dialogue and it's even slightly different in each game. In general, though, the speaker will face the listener if that is set, and if not, will face the speaker of the previous node instead. In K1 at least, as far as I recall, a party member will attempt to turn to face the previous speaker in interjections, so you technically don''t need to set anything other than the speakers for each node. I recall one working instance of this on Korriban; if you have HK-47 and Jolee in the party, HK suggests doing something murdery and Jolee turns to him and retorts. But I find speaker/listener to be unreliable overall. It results in some dumb stuff like Vrook teleporting in one of the Council scenes, facing one person and then immediately facing another rather than turning like a person would. So I would suggest scripting it as well. I would add, though, that you should also use SetLockOrientationInDialog to turn off the usual speaker/listener behavior before you start issuing SetFacingPoint commands. Something like void main() { object oPM1 = GetObjectByTag("whatever1", 0); SetLockOrientationInDialog(oPM1, TRUE); } at the start of the scene, then void main() { object oPM2 = GetObjectByTag("whatever2", 0); AssignCommand(OBJECT_SELF, SetFacingPoint(GetPosition(oPM2)); } for the node you want them to turn on. And you'll want to SetLockOrientationInDialog back to false at the end of the scene. You might also need to add a delay, but I forget if you do. I remember adding a delay of 0.1 seconds when scripting animations in K1, but I don't remember if it applies here too.

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.

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.