DarthParametric

It probably will be once all the bugs are ironed out, just because of the ease-of-use factor. Under the hood, bead-v and ndix UR are working together to make both MDLEdit and MDLOps function the same/produce the same outputs.

Keep in mind that some practices/advice regarding MDLOps from posts that originate before the second half of 2017 are now deprecated due to fairly drastic improvements in MDLOps and the emergence of an alternative in the form of MDLEdit.

The model itself also needs to be edited to enable it. You can do this interactively in MDLEdit, or by recompiling an ASCII in the latest version of MDLOps with the tangentspace 1flag for any mesh the normal map is applied to. Additionally, the diffuse texture needs a TXI with the addition of bumpmaptexture XYZwhere XYZ is the name of the normal map. Alternatively, to use an envmap in conjuction with a normal map, your diffuse needs these TXI semantics (substitute your envmap of choice): bumpyshinytexture CM_baremetal bumpmaptexture XYZwith the caveat that the alpha channel now controls both the envmap and normal map distribution/intensity. Unfortunately there doesn't seem to be a way to utilise both independently. You may wish to also experiment with some of the following TXI semantics for the normal map: isdiffusebumpmap 1 isspecularbumpmap 1 bumpmapscaling 3The first two values are boolean (0 or 1 for false/true). The last entry appears to be an intensity scaler, and seems to accept integer values of at least up to 3, although I am not sure of what the engine's limits are.

Both K1 and TSL use 001 to 005, with TSL additionally using 011 and 012 as well (the values in between are used for props like Bith musician instruments). Are you sure the weapon you are attempting to change actually uses the w_blstrpstl_001 model?

If you are just trying to replace vanilla textures, then w_blstrpstl_001 through to 005 will replace the 5 variants of the basic blaster pistol in K1, with the addition of 011 and 012 in TSL.

Is your texture actually specified in your model? Does the texture follow texture variant naming conventions and match the variant specified in your UTI?

That's because they are tangent space normal maps. It's a single RGB map comprising one channel per vector, not three separate greyscale bump maps.

Blending additive is a semantic used for transparency, not envmaps. Refer to - http://deadlystream.com/forum/topic/5992-tpc-compressed-texture-transparency-alpha-blending/ You can only have a single alpha channel. Multiple alphas is really only a thing in programs like Photoshop. I don't know of any game engine that handles that (or even what image format supports it, beyond a PSD or nearest open source equivalent).

I find for testing purposes it's easier to use one of the various saves available from the saves sub-forum.

Only in TSL. There's no provision for a texture override in K1's heads.2da, so you have to edit the model. The OdysseyBase/AuroraBase name must match the filename. MDLEdit will only allow you to change the textures in a binary model. To change the name of the OdysseyBase (or anything else), you'll need to either decompile the model, edit the ASCII and recompile, or hex edit the binary model. It always used to be wiser to do the latter, since ye olde MDLOps would typically break a lot of models in the decompiling/recompiling process, but that's not as much of an issue with MDLEdit and new MDLOps. MDLEdit does still have some bone index issues though, messing up skin weights in some cases, so that's something to keep an eye out for.

beginmodelgeom rep_soldierYeah, there's your problem. Try this: K1_N_RepHB02_Renamed.7z

The Kel Dor modder's resource was released for both K1 and TSL. It primarily needs someone to texture it, but the model could also use some skin weight adjustment for the face if it was going to be used for NPCs engaged in dialogue. The problem with the Nautolans was the skin weights for the head-tails. I could never get something that worked for a player (or NPC engaging in combat) that didn't have massive deformation issues. They could work for standing-in-place NPCs, but they'd still need to be textured (and 99% of people would cry about lack of a player head version anyway). I never bothered releasing them because who exactly was going to both texture and skin them properly? Nobody. The problem with threads like this is always "who's going to do all the work?". Even if the JKO/JKA modders gave you permission to port their already textured models, who's going to rig them for KOTOR? There are already a bunch of threads about the same thing for other JKO/JKA models that have gone unfulfilled for years. If you want a realistic chance of actually seeing something materialise, you'd be far better served sticking to the existing pool of models available in the game. Plucking the heads off full body models to allow them to use the regular clothes/armour models is a much more practical goal, and has already been done previously in some cases (both RedRob and JCarter have done so, off the top of my head). You could even extend that to add in hands for those species with unique ones, which requires extra work but is not impossible.

Look for a file named AR_ERROR.LOG in the game's base directory. It should list model name errors if they exist.

I think you need to provide a detailed step-by-step description of everything you have done. You may also need to provide the files so they can be checked.

I assume you mean the normalhead value for your added row in appearance.2da is 110? Does your UTC have a unique resref/tag?

You'll need to create a new heads.2da row and a new appearance.2da row. Reference the row ID of the former in the latter. Point your NPC UTC/s at the new appearance. K1 or TSL? If TSL you can specify a texture override in heads.2da, which makes things easy. For K1 you will need to have a custom head model edited to point to your custom texture.

Yes, if you want them to be unique. The only other option would be to incorporate them into the room model. It may still be possible to call the animations via script in the same fashion as the vanilla game. You can do so in TSL at least, not sure about K1.

At this point only the protocol droids and astromechs are "confirmed". There are some technical issues with the models that need to be resolved, and some texture adjustments required, but otherwise they are more or less done and will probably/hopefully be released at some point this year. The only other thing close to a realistic prospect in the short term is the Imperial Autotrooper as a replacement for either the Assassin Droid or War Droid. The low poly model is complete and unwrapped, but I haven't done any high poly bakes or texture work as yet. Beyond that, I was thinking about maybe revising/updating the HK models and textures, but I'm not in any particular rush to do so. The hold-up at the moment is that I have some persistent and seemingly unresolvable system issues preventing any modelling work, so things have been on a forced hiatus since the end of last year. I probably need to do a clean install and start fresh, but that's always such a pain in the ass so I have been looking for any alternative to avoid that (with no success so far).

That was for K1. TSL already has those values so it doesn't require changing.

The ModelB and TexB columns. You should be able to use N_CommF for both if you want regular clothes. This is how TSL's player rows are set up, so you can use those as a guide.

The only way around that is to edit appearance.2da.

The TXI data is a mixed bag. Some are perfectly fine, some are complete garbage, some are the data surrounded by garbage. I've never seen KTool spit out an ABGR normal map. However, it quite often crashes when trying to display them. Maybe that's the difference?