DarthParametric

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.

Game meshes are not suitable for 3D printing. You want a watertight mesh to print with, and game meshes are full of all sorts of intersecting geometry and other various issues because that's fine in a game engine.

There are 3 different die/dead animations. The combat animations (actually falling down) are die and die1. The matching dead animations (laying on ground) are dead and dead1. There are also getupdead and getupdead1, which should be self-explanatory. You can just duplicate the existing ones and rename them, since they are just variations of the same thing (falling over face-first). There is also die3/dead3, which is the prone/laying on back anim, the difference in this case being that die3 is dying while already prone, not falling from standing. I'm not sure if those two are used in combat. Possibly some Force powers may end in that prone state. If you want to test it you could always make a duplicate of something really obvious (like dance, assuming you made that) and see if/when it gets triggered. Regarding the insane Selkath, the Race model is set to N_SelkathCr, so it is presumably using that, not N_Selkath. Although the latter is set as body model A (naked/underwear model), and most of them don't have any equipped clothes/armour. Perhaps when a RaceTex is specified the Race model overrides the body models, not sure. I would suggest editing those rows in appearance.2da and changing the A model to N_SelkathCr to be safe. When you have a finalised mod ready for release, a TSLPatcher setup can be made that will dynamically edit appearance.2da.

Never use any mod that hard overwrites a 2DA if you can avoid it. That will always cause problems unless it is the very first mod installed. Can't say I have ever experienced the subtitle problem, nor do I recall seeing it reported elsewhere. The only missing subtitle issues I know of are a couple of very specific cases that should be rectified by K1CP (and you wouldn't have seen those yet if you haven't been past Taris). If you are getting a repeatable issue with the first line of every conversation then that points to some other problem. The only thing that comes to mind as a potential source would be the letterbox scaling option of ndix UR's High Resolution Menus patch for the game's exe, which does explicitly warn it can obscure subtitles and dialogue choices if used for some resolutions. But if that was the cause then the problem should exist for every single line in a conversation, not just the first. Beyond that, I have no idea.

Yes. No need for the 2DA. Just post a link to the mod's page.

Yes, that one. Run that installer, then copy the textures from Silveredge's original mod. As the readme states: People were copying across the appearance.2da from Silveredge's original mod, overwriting the one already present in the Override (and already patched by K1CP). This causes the lite commoner appearances to break, amongst other problems. I see now though that the build install order has been changed to put K1CP after the Ajunta Pall mod in order to forestall further occurrences of this. Simply creating TXIs for the textures should be sufficient. Extract the attached into your Override and you shouldn't need a 2DA edit/replacement. I would advise that you delete Svosh's mod from your post. Rehosting/redistributing people's mods without permission is against the rules and will possibly get you banned. Bastila_TXIs.zip

You followed the /r/kotor build list I gather? Your problem is a combination of poorly worded instructions on their part and failing to properly follow them on your part. A number of people seem to be doing the same thing. You overwrote appearance.2da, thereby effectively destroying your current install. You'll need to scrap everything and start again from a clean install. That means deleting your saves and starting a new game as well. Pay attention when you get to the Ajunta Pall mod this time. DO NOT install Silveredge's mod. Only take the needed textures from it, as instructed.