JCarter426

Hmm, that's interesting. I think I'm starting to connect some dots... Logic would tell me that if a texture can have shader info (either on a TXI or in a TPC) then the game should read that when it reads the texture but we've always known that's not the case. You can't use whatever cube map you want on a texture for PMBFM, for example - it always ends up as CM_Bright. And that's down to the shader info on PMBF01 being "envmaptexture CM_Bright". Even if you were editing PMBF02 or 03 or whatever, it wouldn't care. So we've known for a while now that the rule was you can't have different things on different texture variations. It would always default to whatever the first texture said. For HK-47, I can guess the reason his model is lacking textures in K2 - they left them out because they knew they'd be using multiple textures on different HKs for the same model. It's the same case with the Mandalorian variants and other models that rely on race textures. They're missing shaders in K2 and editing the TXIs doesn't do anything. While I was working in K2 I was just used to that being the way things are, and then when I got back into modding K1 I was surprised when I didn't run into that problem. I figured that was down to the games being different, since there are numerous things that are broken in one and not the other. But if your theory is correct then it's nothing to do with the game, and it's not the first texture's shader info either - it's the shader info of the texture that's on the model (by coincidence, this is usually the first texture variation). Even if that texture is never being drawn. Now, I've looked at the Mandalorian models. There's a texture in K1 and there's no texture in K2. I don't know why. But this is starting to make a lot of sense. I feel like it can't be that simple but I don't think my memory is reliable. For so long I've been defaulting to editing appearance.2da because I knew that worked. So I can't say I had to do it every time I did it. Further testing is still needed. Yeah, that's been my policy as well.

I've gone back and edited the descriptions of some of my mods - Sound Effects for K1, Blaster Visual Effects for K1, and Blaster Visual Effects for K2 - because I've started a new thing. It's a video series I'm calling my Mod Showcase. I felt that the previous setup wasn't doing a very good job of showing what the mods were all about. With the sound effects, the screenshot was... obviously not helpful in the slightest because that's not how sound works. The Blaster Visual Effects mods do have a more visual thing going on, but I have firsthand experience of being unable to judge these mods by still images alone. When the games' paused it's kind of just a big blur. It really isn't the same thing as seeing it in motion. I needed to watch the blasters fired from multiple angles when I was working on the mod to decide how I felt about my changes, and I kept going back and forth on the issue. For a while I wasn't sure if I was making things better or worse. I can't tell you how many kath hounds I killed during testing. So, in both cases, I thought having video would help to give people more of an idea of what the heck the mod does does and maybe more of an incentive to download it. The videos serve as a more in depth preview, for those of you who only take a cursory glance and judge the mod by its screenshots (I'm certainly guilty of this myself). I do a bit of before and after also go into a little technical detail about how I've done things from time to time. I've only done two so far, but I might continue this format with my other mods. These were the only ones that stood out to me as needing a more involved explanation, but I already know what my mods do, so a second opinion would help. Let me know if you have any specific requests. Also, to my surprise, with the site upgrades Deadly Stream automatically embedded my YouTube videos when I pasted the links. I didn't have to fuss around with it at all and was able to put them in the descriptions with no difficulty. I'd actually had this idea for a while and made the first video without considering how to get it onto the site. We could embed YouTube before, but I wasn't sure if it would work in a mod description, and then I wasn't sure how to do it in the upgrade. And then it went and did it on its own, so it definitely gets a pass on ease of implementation. It's too early to say whether my showcase is a good idea, but I do think some other mods could benefit from a video preview (particularly other sound effect mods) and if you were worried about having to fuss around then you don't have to worry about that. Many kath hounds died to bring you this information.

Here's a quick and dirty list in the meantime: On your model, for each bit of geometry that you want to use a normal map, make sure the object has the OdysseyTrimesh modifier and select it to be "bumpmappable" and export. On the ASCII, this flag is "tangentspace 1". Export and convert to binary as usual. Your model's diffuse texture will have to point to the bump map in its TXI data. "bumpmaptexture" and then the name of the bump map texture. Make the bump map texture. You can do this in your modeling program if you have skills like DP, or you can do it the lazy way and make a greyscale height map, with white being the raised bits and black being the lowered bits. You can convert a height map into an RGB normal map with a tool such as Nvidia's plug-in for Photoshop. Save the normal map as a TGA in indexed color mode. For the TXI data, at minimum you need the bump map's to say "isbumpmap 1". Convert your bump map TGA and TXI to TPC if you don't want to crash the game. The diffuse texture is fine as is. I've attached example TXIs. Mine have a bit of extra properties too. Hmm, is this problem specific to K2? I've only just started fiddling around with maps on character models but I haven't had any issues applying them yet. But if remember correctly, the TXI issue is only a problem in K2. K1 does load it properly from the TXI when the 2DA is set to default. So if it's the same deal as that, maybe the bump maps are ok in K1 too. Bump Map Example TXIs.zip

Oh, that makes more sense. It's probably that the game is can only read what it wants to read (i.e. if it's looking for one channel it doesn't know what to do with two, and the reverse) and there's nothing we can do about that. And really what it wants to read makes sense. You want SFX and VO and such to be mono and music to be stereo. The cutscene sound mixes are in the music folder and maybe they're there for a reason.

Huh, that would be interesting. It wouldn't have a lot of practical benefit, since in general with video games you want the sounds to be mono because the engine is taking care of putting everything in real 3D space. However, it would be better to have the option than not, of course, and I definitely could imagine some uses, such as with music. Now that I think about it, of course the files must be stereo. The sound mixes for some of the game cutscenes are there, and they definitely aren't mono. If anything, it's strange that WAVs we add have had to be mono up to this point.

You really shouldn't have to do anything fussy with the audio files to get them to work. I've been putting them in the game for many, many years and I can tell you that back in 2009 I did not know anything about a fake WAV header and couldn't have been adding one. I've always used standard, raw, uncompressed WAV files. They do have to be mono and that's what I've seen trip people up a lot. Sampling rates of both 48.0 KHz and 44.1 seem to work. I only know that because I've forgotten to pay attention to that before and surprisingly didn't have problems with either. I don't know if putting them in Override will actually override what's in streamwaves but there are a couple options if it doesn't. You could include the original in your install under a different file name (like whatever_bak.wav). Then add both to the installer and let it overwrite the original ones. Alternatively, you could set up another patch as an uninstaller. Have both versions overwrite, one with your mod's files and one with copies of the originals. That's probably what I'd do. I've actually thought about making uninstallers with TSLPatcher before, but I always thought it was too much a pain, and I don't think it can delete certain things anyway. But this is one case where it seems doable.

I do for the male ones, actually. I'm not sure if the female lines are different or not. These are from K1: In K2 the player doesn't have a soundset, however. It's possible to add one, but only by editing a save file after you've started the game.

I have a request. I just uploaded a new mod for the first time since the overhaul (much nicer, by the way) and I noticed there's an option to follow the file. Selecting this, however, does not make me follow the corresponding support topic for the mod. So it would be nice if it did both. I'd also prefer this to be on by default, but that's a lesser issue.

View File JC's Blaster Visual Effects for K2 This mod changes the visual effects for all the laser blasts in the game. Energy blasters, ion blasters, disruptors, bowcasters - I've replaced them all. Except sonic, because really, sonic? In general, I've added more detail and made them match what's depicted on film as best as I could, when there was a visual reference. I took screenshots of the movies and got out my eyedropper tool and everything. The cores of the lasers are brighter so they look more like lasers, instead of having the whole thing as one flat color. I also messed around with light objects so each laser will illuminate surrounding objects in the appropriate color. For disruptors, I've included three color options: white, green, and yellow. The default install is white, like the original, and the other two are included as optional things. Submitter JCarter426 Submitted 06/04/2018 Category Mods TSLRCM Compatible Yes  

View File JC's Blaster Visual Effects for K1 This mod changes the visual effects for all the laser blasts in the game. Energy blasters, ion blasters, disruptors, bowcasters - I've replaced them all. Except sonic, because really, sonic? In general, I've added more detail and made them match what's depicted on film as best as I could, when there was a visual reference. I took screenshots of the movies and got out my eyedropper tool and everything. The cores of the lasers are brighter so they look more like lasers, instead of having the whole thing as one flat color. I also messed around with light objects so each laser will illuminate surrounding objects in the appropriate color. For disruptors, I've included three color options: white, green, and yellow. The default install is white, like the original, and the other two are included as optional things. Submitter JCarter426 Submitted 06/04/2018 Category Mods K1R Compatible No  

What makes the ASCII look easier to me is that everything is listed together on one line - timecode, red value, green value, blue value. In this case it doesn't really matter much because there aren't a lot of animation frames but for a more complicated one that makes it easier to tell what's going on. Also, you can do a find/replace to change the "1.0 0.0 0.0" to whatever color you want. I do this all the time with ASCIIs when I forget to set the ambient and diffuse colors properly. But I was able to figure out how MDLEdit's thing works just by looking at it, so it could be a lot worse!

Ah. Yeah, I suspected that. I think MDLEdit can edit them, based on what I'm seeing here: timekey_0 0.0 timekey_1 0.0333333 timekey_2 0.166667 timekey_3 0.333333 timekey_4 0.466667 timekey_5 0.5 color_0_r 1.0 color_0_g 0.0 color_0_b 0.0 color_1_r 1.0 color_1_g 0.0 color_1_b 0.0 color_2_r 1.0 color_2_g 0.0 color_2_b 0.0 color_3_r 0.0 color_3_g 0.0 color_3_b 0.0 color_4_r 0.0 color_4_g 0.0 color_4_b 0.0 color_5_r 0.0 color_5_g 0.0 color_5_b 0.0 I'm guessing the color_# things are the keyframes and the numbers correspond to the list of timecodes at the top. In this case, it's clear that the frames with 100% red are the ones that need to be edited and the all zeros are the off keys. Though this is a bit messy so it may be easier to edit the ASCII as you say.

Oh, it's all fine now. I was just reminiscing about the dark ages.

No, it's only on the power blast models. They have a secondary emitter that also has colored particles and gives it a sort of glow effect. In the past it wasn't possible to change the color of this (or at least I didn't know of any way - every one I edited with KAurora crashed the game) so you'd be stuck picking one of the existing colors (red, blue, or white). The color you're seeing there on the light object doesn't effect the appearance of the laser, but it casts light on any other object it passes.

That's true, and that's how we made new colors back in the day. But if you only rely on that (as was necessary before) you lose out other stuff like the glow from the gas emitter. When I did my edits before it was always yellow or green lasers with a white glow and I was never happy with that. I suppose with the current tools a combination of both methods will be possible, retexturing the laser so it can be more complicated than a simple color hue shift, but also retaining the ability to change the glow color and such.

I did some messing around in MDLEdit and also took a look in KOTORMax. The last time I worked with this stuff was long before we could properly import or edit these, and back then I did some edits like making the blue lasers bluer and making yellow and green variants. It was interesting to take a look at them again with the new tools. So, it appears that only the red lasers really make use of the light color. Of course the light is white for the white lasers, but it's also white for the blue lasers. Only red has red light. Also, because the color is animated, I'm not sure how to edit the color in MDLEdit. I believe it's the colorkey controller, but I didn't try it. I used the white lasers as a template for my yellow and green ones and thought they looked decent as is, though I might fiddle with it at a later date.

You can edit it with MDLEdit. The controllers you want to change are color for the light and colorStart, colorMid, and colorEnd for the emitter.

Right, but what about before? I don't think there's anything you can do in Blender to get it to work, because it's most likely the KOTORBlender export script that needs to be fixed. But if the UVW map is the only thing you've edited - if you haven't changed the geometry, most importantly the number of vertices - it should be easy enough to copy the new map onto the original geometry (export through KOTORBlender -> import both versions in 3ds/Gmax -> Unwrap UVW -> copy from one to the other -> export via KOTORMax).

Yeah, although ironically you're not losing smoothing - you're getting smoothing where there shouldn't be, because the real smoothing data is gone. It looks like whatever Blender is doing, it's making the whole model have the same smoothing group and then MDLEdit is applying smoothing based on that. Is the UVW map the only thing you've changed?

This isn't necessary, as it has no effect unless you have other mods installed (and assuming they don't have their own fix, like Sithspecter's does). But I guess if you want to include it, knock yourself out.

If you only need different textures for each version, you can manage that without making any duplicate models by packaging the textures in module files rather than putting one in Override. That adds the annoyance of having to use module files for the installation, but it would get around the placeable limit. I'd lean more towards adding the maps to the room models if not for the mess of the scripts involved. They better all decompile or you'll be out of luck.

Ah, I was overthinking it, since changing the on/off sounds is a rather trivial baseitems.2da edit. But yes, the point remains - it can only be by type, not color. If it were any other weapon then it wouldn't be a problem to add a new type specifically for that sound, which mods have done in the past, but with sabers we're out of luck.