DarthParametric

The problem with the animations in the attached ASCII is that the tracks are empty. MDLEdit is a primadonna. It throws a tantrum if everything isn't just right.

Aside from the global game sound settings, the only thing you can do is edit the file directly to boost its volume.

Have you tried it in the Override? Typically PlaySound is used for files from sounds.bif, not Streamsounds. You also want to make sure it is a mono WAV.

Using KSE is basically equivalent to using them as a disguise. Since they are full body models, a disguise is probably the most expedient route for a mod, albeit one saddled with a few potential issues. If you really want to make a version that turns up in the character creation menu then you'll need to split out the heads to their own model, make provision for them in heads.2da and portraits.2da, etc. Look at an existing head mod for an idea of how the setup works. The main difference would be that you'd need to set every body model to their matching custom body, not the regular underwear/clothes/armour/robes models. Note that since character creation ignores the head's appearance.2da row, the head will be slapped on the appropriate class outfit in K1 and commoner clothes in TSL for that bit.

The two heads are both shading issues. It's a common problem with a number of head models, usually down to the fact that there are UV seams in those areas and thus the mesh is split along those seams, causing hard shaded edges. Attempts to fix the issue are often mixed. A lot depends on the specifics of the particular head model. I'm not really clear on what you are referring to with Zaalbar. His texture is garbage, but aside from that it looks about on par. Edit: Here's a smoothed out Trask: Although he has a bigger problem, namely that his eyelid meshes clip pretty badly. That's probably more effort to fix. Edit 2: I tried a kind of simplistic fix. Turned off the render flags for the original eyelash trimeshes and weighted the upper edges of the eyesockets to the lash bones without creating any actual new eyelash geometry. It doesn't look as bad as I was expecting, but try it out and see what you think. Extract the attached into your Override folder. Trask_Head_Smoothing_and_Eyelids_Fix.zip

Disable grass in the options.

That just means they are the high polys for baking out the low poly textures. Of course the real problem with level models is never the geometry. That's the easy part. It's the generating new lightmaps that is the real killer.

Nice. The vista walkways look better than the actual ones. Those are billboards? You should use the source models to make some replacements for the existing level meshes.

The numbered ones are set dynamically via script, so technically they are all available in a given DLG (aside from whatever ones you are already using).

https://deadlystream.com/topic/7436-gender-check-with-k1s-tlk/

No, because those wouldn't be pulled into the compiled script if it didn't call them.

Interestingly though, most scripts that DeNCS chokes on do not appear to be due to recursion, at least judging by running said scripts through ncsdis, which reports the presence of recursion. In my experience, it's the use of per-planet includes that trips it up the most. The module OnEnter and OnHeartbeat scripts for Tatooine in K1 are a particularly good example of this.

Presumably you want to ask @DrMcCoy. Xoreos has done the most recent and thorough (publicly available) work on it. I gather you have perused their repo? I'd advise against any incorporation of "DeNCS" in the name. Xoreos has already taken "ncsdis" and "ncsdecomp". You could perhaps go with something like "NCS2NSS". That's fine. The Xoreos tools are all commandline, and real men compile directly with nwnnsscomp which is commandline as well. Batch scripts are easy enough to write. And as with nwnnsscomp, if someone was keen enough they could always write a GUI front-end for it (ask @JCarter426 - he'll need a GUI project for his course later in the year presumably). Yes. It's presumably due to the way that DeNCS interprets the bytecode, since there's obviously not a 1:1 match between it and the source NSS. I would suggest you try decompiling some of the global scripts that have Bioware source available and compare DeNCS's output with the original NSS. There are certain quirks in the way DeNCS likes to format things, which, while functionally the same, may introduce the subtle differences it complains about with partial matches.

Reset XForm only applies to Max. I don't know if Blender has/needs something equivalent. It is short for "reset transforms". In Max, when you move, scale, or rotate an object, it is only applied as a transform to the original values. Thus if you export the model you get the objects in their original positions/rotations/scale. Doing a Reset XForm bakes the changes into the object. I'm reasonably certain this is a behaviour unique to Max though. Other programs typically just apply such changes permanently as you make them. Beyond that it is difficult to diagnose remotely. If you post the ASCII model I can take a look at it.

Specific model and texture references are not saved. The appearance.2da row ID of all creatures is stored in the save. The heads.2da row and body models are defined in that. You can dynamically edit the heads.2da row ID and the body models/textures for a given row and the changes will be reflected in-game, but you can't change the row to a different one, at least not without editing the save. For player characters it's a little different, since there is also portraits.2da that controls the DS transition textures as well as the sex and appearance.2da rows used. The base texture of the head is purely dictated by what is assigned by the model in K1, although in TSL there is a texture override option in heads.2da. The engine seems to choke on single skinned meshes that hit around 10K tris, causing massive deformation problems. The game will crash if you have shadows enabled on a mesh over around 2,500 tris. Your current model is fine, just make sure you don't have shadows enabled for the head mesh. The head bone is the shadow caster. At a guess, it could be that your face mesh has non-world zero pivot. Try weighting it 100% to the head bone and see if it shows up. It could also be that it lacks a render flag. Make sure you can see "render 1' in its specific node in the ASCII. Some sort of transform issue is the mostly likely culprit if it was exported from Max. All meshes need to have a Reset XForm run on them and their stack collapsed before skinning. It's just a linear gradient. I have some crappy ones here you can use as a basis if you need.

Like I said, the problem you are having is that the vista buildings, which are just flat planes in the background, are not being alpha masked. The problem is not the skybox, although Kex's mod does alter the texture used on the vista planes (which is why I offered that TXI). What happens when you delete LTS_Bsky01.tga from your Override folder?

You can add Kex's mod back. It isn't at fault. Are you using an upscaled textures mod? Looks like the vista buildings are not being alpha masked. Edit: Actually it doesn't seem like the are being properly textured at all. Check your Override folder for the presence of LTS_Bsky01.tga and LTS_Bsky02.tga. Edit 2: OK, that actually is part of Kex's mod. Try putting this in your Override rather than deleting the TGA. What's your OS and graphics card? LTS_Bsky01.txi

Because M4-78 nuked your heads.2da, probably. If you must use M4-78 then it should always be installed straight after TSLRCM. And you never install it part way through a game.

One thing to keep in mind is that doing any sort of significant character movement while using dynamic cameras is generally not advisable. It often leads to unpleasant bobbing and jerky camera motion (most pronounced if the character is running). Ideally you'd use a static camera or animated camera for such shots.

Your SetCommandable commands are reversed. The proper form is: void SetCommandable(int bCommandable, object oTarget=OBJECT_SELF); You had the order right in your original script. Although note that assigning it via ActionDoCommand will add it to the creature's Action stack, not carry it out immediately. I would suggest: AssignCommand(oPC, SetCommandable(TRUE, OBJECT_SELF)); And it still needs to be assigned first anyway for non-script owners, like the PC in this instance (the script presumably belongs to Carth if it is his DLG). But it's debatable whether you actually need it anyway in typical use outside of setting NPCs to not be commandable. For example when setting them to exit an area you set commandable to false so the PC can't interrupt them by trying to talk to them. Also, you should never need to use ActionForceMoveToLocation. The only difference (as far as I know) is that it adds a timeout to trying to path to the destination. In my experience though it makes no difference. If ActionMoveToLocation fails then so will ActionForceMoveToLocation.

Easy - I didn't do it. Those are the original TOR weights, just mapped to the KOTOR rig, merged from multiple source bones as required. Yes, you can adjust the hooks if needed. As I said above, skinned meshes can just be parented directly to the OdysseyBase. Most of the vanilla KOTOR head models that have separate hair meshes use danglymeshes (i.e. static meshes that use vertex buffer animation), so those are parented to the head bone.

Command the PC to walk presumably. Something like this should work. void main() { object oPC = GetFirstPC(); object oCarth = GetObjectByTag("carth", 0); location lPC = Location(Vector(85.9,146.6,0.0), 0.0); location lCarth = Location(Vector(85.9,146.6,0.0), 0.0); AssignCommand(oPC, ActionMoveToLocation(lPC, FALSE)); AssignCommand(oCarth, ActionMoveToLocation(lCarth, FALSE)); } Just change the PC's location values as appropriate.

Only mesh alpha, not texture alpha. So mostly just for holograms. No, do not adjust the bone positions. You should look at the vanilla models for hierarchy clues. But the basic gist is skinned meshes are always direct children of the base. Only trimeshes (i.e. static meshes) need to be children of bones if they need to inherit movement. So hair meshes (typically) will be children of the head bone, lower teeth are children of the jaw bone, etc. Note that because Odyssey uses meshes as bones, a given mesh can be both a bone and a rendered object in the game. The eyeball and eyelid meshes are the most obvious head model examples of this (other examples are droids, which are mostly all rendered bones). Although you can create your own custom skinned eyeball/eyelash meshes, or assign weights to those sections of a face mesh. Just be aware that Odyssey has a maximum bone count of 17 bones per mesh (MDLEdit will probably bitch at you that the max is 16, unless @bead-v has fixed it in the most recent version). That means that a typical head mesh - assuming you split out the tongue, eyes, and teeth to separate meshes - will have one bone too many if you try skin the eyelashes (18 bones total). Since only the very bottom ring of verts on the neck typically need to be weighted to necklwr_g, splitting off the bottom ring of polys to a separate mesh before export might be one option, since smoothing across meshes should be fixed in MDLEdit.