JCarter426

That might be the nicest way to put it. Regardless of what one thinks of their work and whether it's a "mod" that had any chance of release, it's clear to me they wouldn't have put that much effort into it if they didn't care about it. I can certainly sympathize with the idea of not being allowed to work on something you care about. A few years ago I lost the motivation to ever embark on that sort of undertaking, when I heard about a fan project like this getting shut down - I think it was what they're calling Galaxy in Turmoil now - and I can only hope that nobody here will ever have to use the "but it's a mod" defense.

Yeah, if it doesn't work then plan B: void main() { object oOutfit = GetItemInSlot(1, OBJECT_SELF); if( GetTag(oOutfit) != "g_a_mstrrobe06" && GetTag(oOutfit) != "g_a_mstrrobe07" ) { object oRobes = CreateItemOnObject("g_a_jedirobe01", GetFirstPC(), 1); ActionUnequipItem(oOutfit, 0); ActionEquipItem(oRobes, 1, 1); } } Excluded the dark armor variant too for good measure.

The Revan armor isn't defined in nwscript.nss but assuming the game checks baseitems.2da for the item type, this should work: void main() { object oOutfit = GetItemInSlot(1, OBJECT_SELF); if( GetBaseItemType(oOutfit) != 89 ) { object oRobes = CreateItemOnObject("g_a_jedirobe01", GetFirstPC(), 1); ActionUnequipItem(oOutfit, 0); ActionEquipItem(oRobes, 1, 1); } }

Yeah, it is that, not sure why, though. I loaded up my edited model and the lean animations were there. Maybe some sort of compiling error. I'll fix it, though. Eventually. Edit: When has become now.

At least in the original game, the check is solely based on Visas' alignment.

Eh, but that's my mod, and I included TSLRCM's animations. 🤔 I'll take a look when I'm more awake.

Are you missing the supermodel S_Male02 that comes with TSLRCM or using a mod that alters it?

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.