DarthParametric

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.

I figured I'd keep this in here rather than spam the forum with a bunch of different topics about the site updates. I think I asked about/suggested this once before, but do badges, like the kind LucasForums implemented towards the end of its life, figure in to this sort of thing at all? Those were kind of cool, and the kids these days love achievements, right?

You could always do the smoothing in GMax if necessary. Or get someone else to run it through Max/GMax for you.

Download the newer version of TSLPatcher - Delete Install Kyle Katarn.exe and use TSLPatcher.exe from the link above instead.

You've lost all the smoothing information by the looks. I gather the Blender script doesn't export that data.