DarthParametric

There's something weird with the animations for vanilla K1 models for hologram Dodonna and Vandar. MDLEdit will crash on loading the ASCIIs with animations, either vanilla or passed through KOTORMax. It has no problems with an ASCII that has been stripped of the animations. @ndix UR: MDLOps will successfully compile a vanilla ASCII and it will work in-game. It will also compile an ASCII passed through KMax with no errors, but in-game it will be stuck in the t-pose (i.e. no anims presumably). Interestingly, I can edit the vanilla ASCII and have MDLOps compile a working model, although so far I have only tried editing existing values and adding additional keyframes. K1_Holo_Vandar_Dodonna.7z The additional problem I am having - and I am unsure if this is a problem with these particular models, or something more general - is that the game is not respecting my mesh alpha animation values properly. For example, when Vandar first appears, part of the animation fades him in, so all the skins/trimeshes have an alphakey animation going from 0 to 1. Since I wanted to swap from texture blending to mesh alpha for the hologram effect, I changed all the alphakey values so that the upper value was 0.5 instead of 1. However Vandar still fades in to, and stays at, fully opaque (so I assume alpha 1). Any idea what is going on here? Edit: I managed to get my custom Dodonna model working properly when I use an edited copy of the original (with added dummies for my new meshes to add alphakey animations) as a supermodel. I'm doing exactly the same thing for Vandar, but he doesn't properly use the alphakey values, as stated above. K1_Custom_Holo_Vandar.7z For area models, yes. It may also apply to placeables, I can't remember. For area models, strictly speaking it is supposed to use the OdysseyBase name with an "a" appended I believe. I know @ndix UR and/or @bead-v provided a breakdown of the specifics somewhere, but possibly it was in a PM. Sure would be good if we had that wiki about now to document this sort of thing.....

I've given Dodonna the admiral's sash and swapped out the gloves for her original hands (necessitating grafting some sleeves back on). She seems to have a man-hands thing going on, but I don't want to have screw around with it further given her limited screen time. I'm also working on changing the hologram appearance. That is such a pain in the ass with the way Bioware did it vs what Obsidian did in TSL. I'm also fixing up holo Vandar at the same time to make them consistent, although trying to get his eyes to show up properly is proving difficult. Edit: Fixed the eyes, but now I am fighting the animations. Besides compiling issues, for some reason I cannot get the animations to respect the partial alpha values it is supposed to be using. You can see an example of the sort of thing in the Dodonna pictures - her face isn't transparent. The rest of the body parts haven't had custom animations added yet, so they are just using the base alpha value (which is 0.5).

You can try replacing the TSLPatcher.exe with the one from here and see if that works.

No, don't suggest that. If anyone had done it, they would have posted about it.

For some scripts, not all scripts. Most, if not all, of the module-specific scripts have no included source and must be manually decompiled.

Exactly what JCarter said. KTool will let you extract the compiled scripts (NCS) from each module. You'll want DeNCS to decompile them (NSS) which you can then edit in a text editor. You'll then need to recompile the modified scripts, which can be done in KTool, via NWNSSCOMP directly, KOTOR Scripting Tool, etc. Depending on the script names and their uniqueness, you'll probably have to inject them into MODs to avoid clashes, for which you'll want the ERF/RIM Editor. And if you plan on a public release, you'll need TSLPatcher in order to make your mod compatible.

Rarely are things as simple as using KTool. In many ways it's just a can opener (or rather a Swiss army knife). It can get you access to the juicy contents, but it can't make you a meal.

The script spawns the item. It isn't attached to the item itself. There's any number of ways you can fire the script, but the item is the endpoint, not the beginning.

There is no "modified" script. It's a custom script unique to the mod. There is no compatibility issue, unless someone literally steals it and copies the name.

No, you have one spawn script. It looks at the player's appearance and spawns the UTI that matches. If you are talking about compatibility, JCarter's script works in a fundamentally different way.

That's only required for JCarter's approach. The other approach only requires a simple spawn script to initially generate the item. It doesn't affect anything to do with actually creating the armour, which was ultimately what I was getting at.

No, it wouldn't. That's my point. It's just a different way of doing it.

Like I said, JCarter's script approaches the problem from a different angle. It assigns the head dynamically, while the other approach is to have separate appearances for each head and have a script assign the correct one based on the player's current appearance. The advantage that JCarter's approach has is that it will work with any custom head the player might have, whereas the other approach would require the manual addition of support for said heads by the user (in other words, unlikely to happen).

You can already do it. It doesn't remove or change the fundamental underlying limitation of the game, it's just a different approach in dealing with it.

All a disguise is is an appearance.2da row. That's it. JCarter's script is an attempt to deal with the issue of assigning heads dynamically to minimise some of the hassle, but really it's just moving the hassle to a different area. It doesn't add something that was unavailable before, and if he released it tomorrow fully working we wouldn't suddenly be inundated with new armour mods.

No it wouldn't. It's still just using disguises. If people can't even manage setting the basics of that up, they are never going to come at some convoluted script setup.

Couldn't you just spawn them out in space somewhere? Like a mile up in the air, or under the ground.

It would probably look more impressive with a disguise that didn't hide the head.

If you want to learn to swim, you have to jump in the water.

All a disguise does is point to a specific appearance.2da row. This completely replaces the appearance of the creature it is equipped on. This means it will use whatever appearance is dictated by that appearance row, including the head. So if the armour in question specified a Duros head, then when Carth equipped it he would have a Duros head. There's no easy way to dynamically assign a creature's normal head, outside of ridiculously impractical scripting such as JCarter outlined in the Republic armour thread. Either you have your disguise use a full helmeted head, or you create separate unique appearance rows for every single player and companion head, each of which requires its own matching UTI. You then have to have the player manually pick out the right UTI, or you use scripting to provide the correct one based on a script function to check the player's current appearance. The former is what I did for the TSL Jolee outfit, the latter for the hoodless/maskless Revan robes. Either way you are going to be making like 40 UTIs and appearance.2da rows. And that only accounts for vanilla appearances. That method has no provision for dealing with 3rd party custom heads.

There is no provision for adding a new armour class. That would require adding a new column to appearance.2da but those are hard coded.

I have no idea what you are trying to say, but the way armour works is that each armour class has a single model. Variants of that class just use a different texture. Weapons also have classes, but they don't share a common model. Instead, each variant uses its own unique model.

The way KOTOR works, the only way to add a new outift without replacing an entire armour class is as a disguise. Because this means it will replace the entire character, including the head, it's not overly practical to use it for anything that doesn't have a full helmet, unless you are making it for your own personal use and only care about having one head.

The Dark Side option is to force C8 to return to Elise to become her sex bot, if that's the reality you are talking about. I have no interest in making a lesbian sex box mod. If that's what you are after, you'll need to make it yourself. Yes, it would be possible, with varying degrees of effort required. However, I have no plans to port any of those myself. The latter part you describe is a disguise, the same as when you equip the Sand People outfit, Sith Trooper armour, or Space Suit/Underwater Suit.

Yeah that makes no sense. C8-42 is a stand-in for her dead husband. Definitely one droid in the game that is not open for a female replacement.