DarthParametric

This Dodonna hologram is driving me mental. It works fine in the DS custcene, but for some reason, even after adding custom keyframes to all fifty freaking animations, in the LS cutscene her torso still momentarily goes to an alpha of 1 before reverting in the next shot to 0.5 as intended. I cannot work out how this is happening. I think I have identified the specific animation being called during that line of dialogue, but the way it works is weird. The DLG references animation 1251, but the animations on the model are named CUT001W etc. It looks like the LS cutscene animations start at CUT051W (the previous one being CUT025W), but it seems that CUT052W must be the one being used for that line. So it seems like 12XY = CUT0(XY+1)W. Anyway the relevant portion is: newanim CUT052W S_HoloDodonna length 4.0 transtime 0.0 node dummy TOR_Chest parent S_HoloDodonna alphakey 0.0 0.0 0.666667 0.5 4.0 0.5 endlist endnode All the alphakeys for that animation lacked the additional keyframe at 4 seconds, so I added that just in case, to no effect. Interestingly, when looking at the 60fps video the first frame of her reveal the chest mesh is completely gone (presumably alpha 0) while all the other meshes are visible: Edit: I just noticed the upper arms are also both missing in that single frame, and turning to a solid alpha 1.0 in that shot. So three meshes are affected, the rest not.

Look at the Misc TOR Ports WIP thread. K1 uses a texture-based approach for the hologram effect. I am swapping that to mesh alpha instead, but that requires animating the alpha value because they fade the models in and out, and they also had to hide eyeballs in certain shots because of the whole bug-eyed thing (plus they cheat with Vandar's eye blink, swapping between two sets of eye meshes with different textures rather than using physically animated eyelids).

As I said above, that was an animation issue due to it not setting the alpha value of the mesh to its intended value. That's fixed now, at least in the DS cutscene:

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.