What controls blaster bolt textures, Really? (K1)

[ariankoochesfahani 6]

Through in-game testing, I've established that Fx_laser_01 and Fx_laser_02, the two textures that appear to be the only obvious choices for governing blaster bolts, directly modify the textures for Disrupter-type ammunition - not Blaster-type ammo, not Ion-type ammo. Now, the default versions of those two textures are white-colored. So, I'm wondering if Fx_laser_01 and Fx_laser_02 are used by the game to determine the textures of the other ammunition types at all (e.g., by somehow taking those textures as a base and then recoloring them), or if they are simply unrelated to the textures for the other ammunition types. If they are unrelated, what on earth does control blaster bolt textures? Is there something funny going on with the models?

[DarthParametric 3,704]

You might want to have a look at this - https://web.archive.org/web/20150925093208/http://www.lucasforums.com/showthread.php?t=168268

 

Although you can ignore the hex editing bit, assuming you wanted to go that route. The new model tools should mean that is no longer necessary.

[ariankoochesfahani 6]

I could indeed work around the problem by following the tutorial and recreating textures for each ammo-type. My question is more about how the game utilizes the default textures. For, as far as I can tell, the default textures (Fx_laser_01 and Fx_laser_02) are white. If each model for each ammunition type just uses Fx_laser_01 and Fx_laser_02, then why do some bolts appear white while others appear red or blue? Seemingly, every bolt should just be white! On the other hand, if each model for each ammunition type uses unique textures, what and where are these other textures?

[DarthParametric 3,704]

The models are VFX emitters. The colour is specified in the emitter settings. The texture is an alpha mask for the particles it emits.

[ariankoochesfahani 6]

6 minutes ago, DarthParametric said:

The models are VFX emitters. The colour is specified in the emitter settings. The texture is an alpha mask for the particles it emits.

ah HA. Thank you very much! Don't know what that means exactly but the gist is that the models do in fact specify the color. I haven't worked with the modeling tools yet so I guess I could have worked that out eventually, but that's exactly the kind of answer I was looking for

[DarthParametric 3,704]

There's also a light as well. There's are two animations, the default one which has the light turned off and the particle spawn rate set to zero, and the firing one which sets the light colour and fades it in and out, and also sets the particle spawn rate.

[ariankoochesfahani 6]

Do you happen to know where to find the relevant tutorial on editing such in Blender? Getting the .mdl into Blender with mdlops and kotorblender was simple (see image) but now I'm confronted with a labyrinth of mini-menus, none of which obviously govern emitter settings.

[DarthParametric 3,704]

I can't help you with Blender unfortunately, but I know they are currently working on fixing some issues with emitters in KOTORBlender, so I'd hold off for now anyway.

[JCarter426 1,192]

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.

[ariankoochesfahani 6]

Thank you so much, Jcarter426!

[JCarter426 1,192]

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.

[ariankoochesfahani 6]

Well, it is certainly true that once I used MDLEdit to change only those 4 controller settings in the w_laserfire_r.mdl file to 1.0s across the board, the blaster rifle bolts took on the same appearance as the disruptor rifle bolts - both became purple with a white core, as intended for testing purposes. Seemingly, as long as the emitter is tuned for white color,  the bolts in-game will faithfully reproduce a modified fx_laser_01.tga. Any potential funny stuff resulting from a clash between colorkey settings for the Light and color settings for the Emitter is not visible in-game.

 

But I still cannot fx_flare in the model information. Nor do I know when that texture appears in-game.

EDIT: fx_flare_02 is in v_muzflash_01.mdl and fx_flare_01 is in the model for powerblast bolts under "(emitter) gas." victory is mine

[JCarter426 1,192]

27 minutes ago, ariankoochesfahani said:

Seemingly, as long as the emitter is tuned for white color,  the bolts in-game will faithfully reproduce a modified fx_laser_01.tga.

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.

[ariankoochesfahani 6]

4 hours ago, JCarter426 said:

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.

By "glow from the gas emitter," are you referring to what is presumably governed by "colorkey" under the tree-heading for "Light" under the "travel" Animation branch (pic #2)?  Is the idea that this color encases the bolt? Sorry if this is stupid, but I have never even noticed a white glow around any of the original bolts (or a red glow when it comes to the original red bolts).

 

 

l

[JCarter426 1,192]

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.

[DarthParametric 3,704]

If you can't use GMax and KOTORMax, then then next best thing would be editing the ASCII.

[JCarter426 1,192]

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

[DarthParametric 3,704]

No I was referring @ariankoochesfahani . If Blender is currently not possible due to its emitter issues, and GMax is not possible for some other reason, then editing the ASCII directly is likely better than trying to do it in MDLEdit, given you will need to edit the animations if you want to change the light colour.

[JCarter426 1,192]

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.

[DarthParametric 3,704]

Yeah I think it is far more logical dealing with the ASCII:

newanim default w_LaserFire_R
  length 0.0
  transtime 0.0
  animroot w_LaserFire_R
    node dummy w_LaserFire_R
      parent NULL
    endnode
    node dummy AuroraLight01
      parent w_LaserFire_R
      colorkey
        0.0 0.0 0.0 0.0
      endlist
    endnode
    node dummy zap
      parent w_LaserFire_R
      birthratekey
        0.0 0.0
      endlist
    endnode
doneanim default w_LaserFire_R
newanim travel01 w_LaserFire_R
  length 3.93333
  transtime 0.0
  animroot w_LaserFire_R
  event 0 detonate
    node dummy w_LaserFire_R
      parent NULL
    endnode
    node dummy AuroraLight01
      parent w_LaserFire_R
      colorkey
        0.0 1.0 0.0 0.0
        0.0333333 1.0 0.0 0.0
        0.166667 1.0 0.0 0.0
        0.333333 0.0 0.0 0.0
        0.466667 0.0 0.0 0.0
        0.5 0.0 0.0 0.0
      endlist
    endnode
    node dummy zap
      parent w_LaserFire_R
      birthratekey
        0.0 2.0
      endlist
    endnode
doneanim travel01 w_LaserFire_R

Although this particular one is pretty simple given that the light is a straight red and either on or off. If you wanted different colours though, like say orange or purple, you'd have to convert the RGB to [0,1]. For example an orange of 255,120,0 would be 1.0 0.47 0.0 or thereabouts.

[bead-v 250]

1 hour ago, JCarter426 said:

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.

Would it be easier if the format of the values in that window would match the one in the ascii? I think that should be possible for me to do.

[JCarter426 1,192]

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!