JCarter426

It's certainly possible, but the difficulty is that the K1 supermodel does not have the bones needed to animate the cape, like the K2 one has. And while new bones can be added to the supermodel, they would require thousands of frames of animation keys to match the game's animations. Maybe capes could be added as dangly meshes instead (like Bastila's skirt flaps) but I don't know how good that would look.

I just might. I'll have to take another look at the designs first, though. The last time I worked on them, they ended up being a totally different design, so I'd want to make some changes to bring it closer to the game appearance again.

...then you go to Dantooine? Or did you mean what happens if you're on your way to Dantooine when you're captured? In that case, you're automatically sent to the last remaining Star Map planet after escaping the Leviathan.

Cool! I'll be interested to see how much of it you can change. I've done some pazaak card designs over the years but I never thought about putting them in the game - I made them to have them printed out. It might be nifty to see them in the actual game.

Yeah, that works, no catch to it.

Both the card images and the font are textures. The cards are named lbl_card for K1 and pcards for K2, in the GUI pack of each. There are a lot of files for the fonts and I don't know which one affects pazaak or if it would affect anything else. As for changing the position of the text on the card... that's an interesting idea, and I have no idea if it's possible. There are .gui files for pazaak but it's anyone's guess how much of that can be changed. The GUI is a bit hit or miss in that regard.

It's actually not. In K1, you must add new item properties in the UTI and then specify which upgrade grants them. In K2, all you have to do is change the upgrade level to 1 (for only some underlays available) or 2 (for all upgrades). I think KOTOR Tool has a problem with that, so you might need to use K-GFF. It already won't restrict Force powers.

File Name: JC's Battle Undergarments for K2 File Submitter: JCarter426 File Submitted: 25 Apr 2018 File Category: Mods TSLRCM Compatible: Yes By popular* demand! This mod will add a new item that has the appearance of underwear but grants a defense bonus when equipped (+4). The mod does not integrate the item in the game at all; you will have to cheat it into the game in some manner. The item is "jc_under01". *For populaces totaling one or more individuals on Deadly Stream. Click here to download this file

File Name: JC's Battle Undergarments for K1 File Submitter: JCarter426 File Submitted: 25 Apr 2018 File Category: Mods K1R Compatible: No By popular* demand! This mod will add a new item that has the appearance of underwear but grants a defense bonus when equipped (+4). The mod does not integrate the item in the game at all; you will have to cheat it into the game in some manner. The item is "jc_under01". *For populaces totaling one or more individuals on Deadly Stream. Click here to download this file

Sure, why not. I'm sending it into the upload queue now. I've added nothing fancy, just a +4 defense bonus, but you (or someone else) will be able to edit the UTI further however you wish.

No, that's not possible. The UTI doesn't contain that information. The model is determined by baseitems.2da and appearance.2da. You could make a new item type that has the stats of armor but the appearance of underwear (model A) but it would require a new line in baseitems.2da. And to make yourself look like a Twi'lek would necessitate editing appearance.2da regardless of what else you want to do.

Ah, that makes sense. Also, I made a typo before. bumpshinytexture replaces envmap, not bumpmaptexture.

No problem. It's good to have a resource like this. Use an alpha channel as normal. Black will be translucent, white will be opaque. However, all the dark parts of the texture will still be translucent due to the blending mode, since it is additive and black is adding 0. There's no way to get around that unless you use punchthrough or two different textures. By the way, here's what happens when the game is missing the TXI:

Additive is equivalent to "add" or "linear dodge" mode - the color is added to whatever is underneath it. Punchthrough is equivalent to "normal" mode, I think. In the game, punchthrough is generally used when only transparency is needed, when there really is supposed to be nothing there (grass, leaves, grates, hair, etc) while additive is used for any translucent texture (such as windows) because it brightens the background and makes it easier to see. You might be wondering why punchthrough is even there when we have alpha channels that can handle transparency. That's because the game is crazy and won't render anything behind another object even if its texture is transparent from the alpha channel, unless a blending mode is applied. This increases the intensity of the bump map. If you have part of the bump map that is higher than the base texture, bumpmapscaling 2 will double the height, bumpmapscaling 3 will triple it, and so on. At least, that's my guess. I noticed a subtle but possibly not imaginary difference when I tried it. This is for use with a bump map on a texture that uses an environment map. If you're using cm_baremetal on a metal texture, for example, you'll want to use bumpshinytexture instead of bumpmaptexture. I believe there's more to it than that. This is an assumption based on how I've seen it work in other games, but I believe decal will make the texture render on top of anything that it's flush with. A burn decal on a wall, for example, will always render on top of the wall texture, rather than the Z-fighting nonsense you'd usually get. This just tells the game the texture is a bump map. This is an optimization thing. A mipmap has multiple copies of the texture in different sizes and the game renders the smaller ones from far away, only rendering the real size when you're close up. I'm not entirely sure how it works with KOTOR since KOTOR also has different texture packs, and I've only seen the mipmap parameter on certain textures. But it's not really a concern to us, thanks to modern hardware.

Doors, placeables, creatures, waypoints, and anything else that's spawned. Static cameras are the only game objects that do use them. That would be a no. That's all that matters, right? You don't have to mess with that stuff in 3ds Max or even AniCam. You do have to if you want to place any camera in a GIT file. Sounds like it's doubling everything you enter? That doesn't make sense... at all...

Oh, that does make sense. That's a strange way to go about it, but I can see why they would do that. You could still do it all in the same dialogue without requiring a new trigger, but it might end up being more work so it might not be worth it. Static cameras: a ) are required to be placed in a module's GIT file, which means they can't be placed after you've entered the module and make for a compatibility nightmare b ) use the obscure quaternion rotation system c ) are restricted to a single module d ) can't be animated Animated cameras: a ) can be animated but don't have to be animated b ) use intuitive XYZ values for rotation c ) are contained in a model file that can be named whatever and used wherever (though difference in module layout is obviously still an issue) There is one and only one thing static cameras can do that animated cameras can't: You can change cameras in the middle of a dialogue node with SetDialogPlaceableCamera. Unless I had to do that, I wouldn't ever use them. I hadn't ever considered a circumstance like the Xor encounter, though. That's a unique case because it can pop up in different areas, as you said.

There are approximately zero reasons to use those, but ok. Well, you're right - it does look like you want 180°. I've attached an animated camera that confirms this, though it's not going to tell you anything you don't already know. I don't know what to say other than that BioWare wasn't at all consistent with orientation. 90° being south is typical of some other modules, such as m01aa. It's probably just a quirk of that area. Though it is weird that only the static cameras would be incorrect, that wouldn't be the most shocking oddity with this game. Camera Rotation Test (m17ab).zip

First, what sort of cameras? Static ones in the GIT file? Second, the orientation in the game isn't consistent. Some modules have 0° as north, some don't. So you might just be in one of those modules.

I'm guessing the game renders it and attaches it to the camera if the flags in the ARE are set... otherwise it doesn't. I don't recall any script functions that would turn it on or off, and I also don't recall needing any specific OnEnter script for it to work. I've known weather to work in 231, 301, 506, 601, and 605. So it would be hard coded if anything. I know The Witcher has randomly-generated weather, and I believe this already supported by the engine and not anything they specifically cooked up for The Witcher. So whatever it is, it does seem to be something that can be triggered on and off... although I don't know if it works in KOTOR. Each room in the ARE has a flag to allow weather, though I don't know how this works. I remember assisting someone in editing this before without any luck - rain would show up everywhere or nowhere. The game definitely doesn't have this problem for modules that are already set up for rain, however.

The rain does use particles, but I'm not sure if you can edit them. As far as I can tell, the weather system is generated from an emitter that follows the camera, a 10 meter cube or something like that. Presumably the game uses some sort of model for this, but you'd have to figure out what it is. It's easy enough to create rain with the fountain emitter, though, and it's even possible to have rain (or snow or whatever) in the first game.

Well, no, there's no such file. That's just an instance of the waypoint template sw_waypoint001.utw with a custom tag. As for the script that spawns the party members, that's k_pebn_pophawk.ncs.

This should work (attached). Ministry.zip

Oh, my mistake. I assumed it was using an event fired from heartbeat but it's actually his perception event (1002) which... should not be failing. Unless you went into stealth or something. It might be something wrong with the general AI. The other one being used here is the damage event (1006) which makes him surrender. But you said that's working. Still, you could bypass the problem with heartbeat like I was saying before. If you copy the whole 1002 tree to 1001 and put in a condition that the henchmen are dead, then it should fire that when his heartbeat event fires in the event that the other one doesn't.