DarthParametric

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.

That would be my fault, since I was that one that modified the training script to accommodate @Stormie97's robes. The issue is that the mod changes the default fake PC that is used for two custom ones (male and female), and, naturally, there is no provision to properly destroy those once they have fulfilled their purpose. An unfortunate oversight on my part. As luck would have it, the script that controls destroying the fake PC can't be decompiled, so resolving that will take a different approach. I've suggested a fix to Stormie to resolve the problem for future users. But fixing that wouldn't help in your case regardless, since the scene has already been completed. As a temporary measure, try extracting the attached into your Override folder and loading a save in the Hawk (or re-entering it from outside). Stormie_Robes_Fake_PC_Temp_Fix.zip

I use the 3DS Max import script. There might be a Blender script, I don't know, I don't use Blender. You can try Googling for it. Otherwise Noesis with the TOR Python plugin is probably your only option.

It's not particularly painful. Grab TGA2TPC, load your TGA, set the export directory, set the compression to DXT5 (make sure your normal map has a solid white alpha), create an appropriate TXI or change the setting to text and paste it in the box. At a minimum you will need isbumpmap 1 If you have modified the diffuse, then it will also need a TXI that includes bumpmaptexture filenamehere that points to the filename of the normal map.

Due to the way lightmaps are baked, upscaling is unlikely to produce desirable results. You'll almost certainly end up with a lot of nasty artefacts. But yes, for K1 all you need to do is put TGAs in the Override. TSL uses TPC lightmaps, so if you are using TGAs you'll need to create matching TXIs. The engine only supports normal maps in TPC format, specifically RGBA DXT5. Given the fairly poor implementation, there's probably little to be gained trying to upscale them.

The dialog.tlk in the base directory.

Probably easier to just go into the install folder and delete the TLK in the base directory, the Override directory, and the Modules directory. Then in Steam you can do a local file integrity check and it will redownload the missing files. If you are using an edited exe for widescreen, just make sure to move that outside the game directory first, then you can put it back afterwards (so you won't need to patch it again).

I did tell you not to reinstall the mod over the top of itself. Ideally you'd want to nuke the entire install and start over entirely fresh - including deleting all your saves and starting a brand new game. You've not only got the minor Dantooine NPC problem, which on its own would be salvageable with a save edit, but you've also broken placeables.2da which is now suffering from wrap-around due to the row limit bug. That is going to cause problems throughout the entire game.

There are probably a few bits and pieces discussed here. You'll need to go to Xentax and read the big TOR threads which discuss what tools you need and how to use them.

So the backup is fine, and as far as I can tell this mod should be the last one in the build list that patches the TLK, assuming you followed the suggested install order. So the cause is presumably this mod, but I have no idea how it happened. If you can check what other mod backup folders also contain a dialog.tlk that would be helpful. In the meantime, you can extract the attached into your game's base folder, replacing the broken TLK. Fixed_TLK.7z Edit: The attached file has the added strings from the mod. The backup won't have those, so you are using that then if you click on the captured Jedi the DLGs will report StrRef errors. The attached should prevent that. Because of the placeables.2da row limit bug DO NOT reinstall the mod over the top of itself.

Did you keep all the installers and the folders they were extracted to? Any of them that uses TSLPatcher should have a backup folder. Since the strings from this mod have been correctly appended to the end of your TLK, I suspect the problem occurred before it was even installed. This can be ascertained by attaching the backup dialog.tlk from this mod's install folder for me to have a look at. Checking other folders for TLK backups could help pinpoint the root cause, which is why knowing the install order is important.