DarthParametric

If the end result is anything like Kaevee, don't bother.

There's not a single ready anim, there are multiple different ones to cover the different weapon types. You can use @JCarter426's combat animation guide and TSL's annotated animations.2da to help you find them, but they should be of the form gXrY, where X and Y are numbers that indicate wielding type and anim variation, respectively. For example, g2r1 should be the single saber/sword ready and g5r1 should be the single blaster pistol ready. Some of these appear to be recycled, for example g7r1 (rifle) and g9r1 (heavy carbine) are identical. If you are setting the piggy's anims as unarmed, then they'll presumably need a g8r1 for the ready anim. But since their UTCs force them to use melee anims, I'd just go with that. They obviously already have a limited set of anims by default, so duplicating the existing ones to cover the melee variations shouldn't be too much of a problem. The only question is whether the choreography limits the human anims when fighting a creature, or if it uses the full range of anims regardless. I'm not sure I ever noticed. There's nothing special in the DLG that would suggest the cause. Neither it or the ambush one have any forced or scripted talk anims. I'm not sure why it would work in one scene and not the other. You can export and import a text list of the node mapping, so it might be worth doing it that way to see if that gives you some more control.

Vanilla Force power values are declared in nwscript.nss. If you have added new ones (the errors are not vanilla powers) and want to use a constant then you need to declare it one of the scripts you are compiling (doesn't matter which, as the compiler will pull it in from an include if it is there). The value is an INT, derived from the row ID in spells.2da.

Interesting. That accounts for the differences in rig scales presumably? I've only ever tried it with similarly proportioned rigs before. Looks good though - can't see any problems with it. Edit: Having just tried importing the anims myself in Max, I spotted a problem that I can also see in your grenade tosssing GIF. The thumb on the right hand gets bent back to the wrist. Presumably that's an issue with reversed starting rotations or something, but whatever the cause that will presumably require some manual cleanup. The shield anim GIF is harder to see, but in Max the right thumb is also bent backwards in that anim. Yeah I suspected that would be the case. Probably the only thing to check would be the conversations/cutscenes with piggies involved. I know of two in K1 (both on Tatooine - the fake trapped woman ambush and Vorn Daasraad during the Genoharadan quest, as I mentioned above) and three in TSL (one on Citadel Station working for Luxa, two in the Exchange compound on Nar Shaddaa).

Is there a game-specific identifier in the NCS header? I thought both were flagged as NCS V1.0B.

No, the vanilla LS/default texture is fine, so only the DS textures are needed for that version, since only the eye itself is changed. The other two versions are upscaled, so they also get a new version of the LS/default texture.

View File Player Head PFHB02 Dark Side Transition Eye Fix The player head PFHB02 has an issue with the eyes of its Dark Side transition textures. Namely, whoever made them offset the eyeball overlay they were trying to blend over the top of the base texture, resulting in a progressively noticeable duplicated set of irises. This mod cleans up the irises so they look as intended. Three options are available. The original 256x256 textures with just the eyes edited, a version that has been AI upscaled to 1024x1024, and an version that is upscaled with the addition of eye textures taken from SWTOR. Installation Instructions Pick which version the want, copy those TPCs inside that folder to your Override folder. Known Issues The UVs of the head are terrible, so the pupils are a bit wonky. I didn't want to have to edit the head mesh to fix it, since that might affect other mods. Compatibility Won't be compatible with other retextures of PFHB02, obviously. Acknowledgements Thanks to @ndix UR for TGA2TPC Thanks to @StellarExile for an issue post on the K1CP repo about this, which prodded me into remembering I had something for this Original eye textures for one version ported from The Old Republic MMO Submitter DarthParametric Submitted 09/16/2020 Category Skins K1R Compatible Yes  

It is modified in TSL, but Obsidian fixed the If statement in their version. We were evaluating whether or not to fix the K1 version as part of K1CP, but there seems to be no need, since the vanilla version works as-is. Anyone wanting to add custom ones would need their own version of the script anyway, so it would be up to them to fix it.

@Alvar007 if Salk hasn't completely sapped your will to live, I have an animation suggestion for you. The Gamorrean model lacks the animations for both throwing grenades and activating shields, yet there's at least one example of combat in K1 where both actions are guaranteed to occur (Vorn Daasraad during the Genoharadan quest). Not sure about how much piggie action there is in TSL, but Obsidian didn't add those anims to that version either.

Concerning k_trp_generic... Yet it does actually work in-game: The poison damage applied per-tick is the correct amount int POISON_DAMAGE_VIRULENT = 5;

Stumbled on this one by chance while looking for conditional scripts: "But I think you just might be crazy enought that you don't care. Okay, I don't need no trouble, so here's the scoop." StrRef 17356.

These are destroyed by k_pkor_ther_dest fired by kor37_firescene.dlg (the cutscene of the pillar blowing up and the droids activating). I suspect a few more in your list are destroyed as well. Edit: However, it should be noted that those two only get deleted from the player's inventory during that cutscene. So if you happened to pick them up afterwards you'd be stuck with them. That script could be edited to also delete them from the placeables as well to prevent that.

https://deadlystream.com/topic/6507-disadvantages-of-mandalores-armor-in-game-without-a-helmet/

I'm sure @A Future Pilot is already rubbing his hands together at the prospect of stealing it for K1CP.

It's not the placeable. It's probably the crud overlay on the floor which floats a bit to eliminate Z-fighting. Make sure the height of the placeable is at least 0.15m and shuffle it to the right half a meter or so.

Your pic is too small and full of artefacts to see anything. ENHANCE!

It should be clarified that cameras actually use two values. A quat for the Z rotation (i.e. orientation) and degrees for "pitch", the X rotation (because in 3DS Max, cameras start off pointed straight down at the ground. As far as origin goes, values in GITs should always be derived from North as 0, whereas values in scripts take East as 0. Although from memory there are a couple of modules that don't use East as the origin, which can screw things up.

No. You are confounding 1 and 2. Both are quats, just stored differently. The game uses degrees, radians, and quats, depending on what specifically you are talking about. Broadly speaking, "facing", as used in scripting, is a cardinal (i.e. compass) direction and is specified in degrees. "Bearing", as used for placeables in the GIT, is specified in radians. "Orientation", as used for a number of things like cameras and creatures in the GIT, is expressed as two components of a quaternion.

So no bald bloke hitting them with a glowstick?

Is Jolee not there? Would probably explain why it hangs.

I'm not sure that I have seen the first two exactly. Although I have experienced numerous cases of one party member ending up hung up against a corner or doorway, or otherwise halting which invariably leaves them stranded halfway across the map. Presumably that was why Obsidian added the function in the AI script to teleport party members back to the party leader if they were too far away for more than 10 seconds or so. I tried to duplicate something like that for K1 but never got it to work (I believe JCarter may have fiddled with something similar at one point as well). The last one can at least be masked by manual adjustments of fade-ins if there are specific instances that are particularly egregious (might also be less apparent running the game from an SSD).

You can put LIPs in the Override, be they new custom ones or replacements for vanilla ones. However, since you are using existing LIPs to be repurposed in a different module whilst presumably retaining the same ResRefs, it would be better to inject them into the specific MOD for that that module's LIPs. Putting them in the Override would also affect the originals, which may cause problems if someone else wanted to edit those independently. Alternatively, you could give your duplicated VO and LIPs custom ResRefs, which would alleviate that concern and allow you to put them in the Override. That may ultimately be the more desirable root, since it means less likelihood of clashes with anything else.