DarthParametric

You need to enable the bumpmappable/tangentspace flag when compiling the model, then specify the normal/bump map in TXI of the diffuse map. Creating the map itself is done in the standard manner for any game engine, but as @ndix UR pointed out above, normal maps need to be converted to a RGBA TPC in order to work. TGAs will cause the game to hang/crash. There will be more detailed, step-by-step information available once @Tyvokka implements the wiki.

The fake WAVs aren't mono though. It would be interesting to see - for experimental purposes if nothing else - whether simply adding the fake WAV header to a stereo MP3 is sufficient, or whether there is indeed some other processing they did via Miles K1 is mostly all the same, although they do have some that go the other way - WAVs with fake MP3 headers (e.g. al_xxxx). TSL though has a few different variations (based on Obsidian using at least two different encoders, from what I can glean).

The originals are just MP3 with a fake 199 58 byte WAV header. I wonder what would happen if you added that to your files? Do you have a sample MP3 that we can try it with? Or presumably you can just hex edit one/some yourself. Edit: Doing some tests, it's pretty easy to set up batch processing, assuming it works. You can just export the first 199 58 bytes from the header of an existing WAV from a hex editor and then create a batch file: @echo off for %%F in (*.mp3) do copy /b "header.bin" + "%%~nF.mp3" "%%~nF.wav" pause Edit 2: Actually, comparing to other MP3s, it looks like the fake header is only 58 bytes. I was going too far into actual relevant MP3 header data. Trimming 199 would allow it to play in Wnamp, etc. but I don't know how the game would react.

Looks like the primary ground texture is LTA_wall00 with darker edge/corner areas using LTA_wall00a . As the name suggests, these textures are likely used elsewhere for wall textures, so replacing them outright is probably not the best idea. The easiest way to check what textures are being used and how retextures will look is to extract the room models and load the entire module into Max/GMax (I'm not sure if Blender's script has a module loading capability as yet).

Can you get it here? https://deadlystream.com/store/category/5-modders-account/

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.

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.

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

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.

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.

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

Like I said, you don't have to create it from scratch, you just use a modified copy of the original. Here: https://www.darthparametric.com/files/kotor/k1/[K1]_PFHA03_ebmar.7z Here's the vanilla head model, along with an edited copy with a unique filename and unique texture name. I've included the ASCII (decompiled) models so you can see what was changed, and in case you want to make further changes yourself, as well as the supermodel if you make changes and recompile. You can use MDLEdit to do so.

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.

You can use that head. If you want to use it straight vanilla, just set the normalhead value in the added appearance.2da row to whatever the heads.2da row ID is for that head. If you want to use a custom head texture, you'll need to create a custom named copy of that model and point it to your new texture. It's a fairly painless procedure. Then you add that to heads.2da and set the normalhead value to that.

In K1 in order to use a custom head texture you must create a new model for it, unlike in TSL where you can just specify a texture override in heads.2da. So even if you don't want a physically different mesh, you still need a custom model that points to your new texture. For appearance.2da you can control what body models are used, so even if you don't want actual custom meshes/textures,. you can still have the appearance use any body model you want, regardless of what equipment they are actually wearing. For example you could equip them with heavy armour, but have their appearance be a Jedi robe. As to the UTC, that's the simplest part. You just find the UTC in the appropriate module in KTool, and, assuming your edited 2DAs are in the Override folder so KTool can see them, open the UTC in KTool's editor and choose the new appearance from a drop-down menu, then save it. In the case of K1, you can typically just put the loose UTC in the Override folder, because they gave them all unique names. Unlike in TSL, where they use generic UTC names that cause clashes between modules and thus must be packed into MODs. Of course if you want to publicly release something, you'll need to create a TSLPatcher setup that will dynamically create and inject your changes to any pre-existing files if necessary, rather than just dumping pre-edited stuff in the Override.

It's the same routine as for any other unique NPC. Add a new heads.2da row with a custom head, and a new appearance.2da row that points to the head row ID. Specify custom meshes/textures in either/both 2DAs as appropriate. Edit the NPC's UTC to point to the new appearance row ID.

I thought it might work since most of the game's audio is MP3 with a fake WAV header, but I guess not. Sounds like it is more a case of mono vs stereo (although I wonder in that case if mono MP3s would work).

Interesting. If you compile and decompile with MDLEdit, you can see it adds in blank chunkname and render variables to each node. So I guess @bead-v added in a failsafe for missing variables, which is why it doesn't crash. Although presumably it would not function correctly in-game, given it is missing all the specific render semantics like Motion_Blur, Billboard_to_Local_Z, etc.

Have you tried encoding it as an MP3? 44.1KHz, joint stereo. 128kbps or 320kbps should be fine.

MDLEdit compiles it with no errors but can confirm that MDLOps is choking on it. Loading it into KOTORMax causes the script to throw an error at line 2547, which is the end of node emitter Projectorflare. Edit: A quick comparison to the vanilla indicates that the Blender version is missing "chunkname" and "render Motion_Blur" from that node. After replacing that node with a copy from the vanilla version, KOTORMax throws an error at the next emitter node, so presumably KOTORBlender needs a tuneup in that regard.

Your problem will be a malformed ASCII. The easiest solution is just to post a copy for someone to look at.