JCarter426

All party members are made Jedi with the same script, a_makejedi, and it's already divided into different trees for each party member. So all you'd have to do is attach the item spawning to the appropriate trees and recompile. Of course, that will cause incompatibility with any other mods that alter that script, but it's the most minimally intrusive way I can think of.

Vrook and Vandar both went back and forth between Dantooine and Coruscant, at least in the comics. So you could make an argument that it was true for the others as well. I don't think there's a canon source that says with any certainty one way or the other. Personally, I don't like the idea of a permanent council in the first place. I like to think that twelve Jedi masters would have better things to do than sit in a room on Coruscant all day. I like to think the Council is just a quorum of qualifying Jedi masters who happen to be at the same place when the situation requires it. That would explain why only four seem to be involved in the Revan business, and only five are present at the Exile's trial in the original game. But if you follow my logic, and you wanted to have twelve present at the Exile's trial, you could make arguments for or against the inclusion of Zhar and Dorak. They may have been too busy on Dantooine at the time (especially with Vandar and Vrook absent) and had substitutes fill in, or they themselves may have been substitutes to other Jedi that did show up that day, but not with the Revan business.

Oh, d'oh, the Duros was one of the ones I hadn't initially done because of the smoothing. I forgot because it's one I have done since, but haven't uploaded. I'll be back with a link for those models later. EDIT: Here they are. And if anybody else wants to use it, just consider it an extension of the previous one and for permissions follow the guidelines in the readme of that, whatever they are (I don't remember).

I'm also willing to whip up a new one that I didn't do before due to the limitations at the time. Bith, for example. I've been meaning to go through them all and update the mod - that's why I never uploaded the older version here - but I just haven't had the time to do them all.

You could have a Duros wear robes if you use my heads resource. Also, point of fact, Tyvokka did wear Jedi robes. But surely it's a personal choice. I'd take less issue with a Wookiee choosing not to wear robes than I do with Thon's robe (previously never seen) being wearable by a human of average size.

Oh, I forgot about those. Assuming those are still valid at the end of the combat round, that could work. And I suppose even if one can't account for all the variables, it's at least better than nothing. Assuming Dexterity and everything else works out, then it would essentially amount to an extra attack without accounting for any of the weapon's modifications. Which is possibly better for balancing anyway.

That's not the problem. The problem is checking whether you are using that weapon during the combat round as opposed to casting a Force power or using another item such as a medpac. Yes, you can check the base item type of an equipped weapon, but that only tells you that it's equipped. I don't know of any script function to check whether it's actually being fired at the moment. The Dexterity modifier I'm not sure about. That might only be checking the character's actual dexterity modifier and not the one adjusted due to armor. It seems more logical that it would check the adjusted modifier, but you never know. As for the weapon modifiers, no, I meant modifiers on the weapon item itself from either the item properties or upgrade items on it. There's no way to check for that.

I'd suggest using a room animation rather than a placeable. At least, assuming room animations work - I've been told they do on the latest MDLOps but I've never tested it. It's the same amount of work on the model, but with a placeable you also have to make a UTP, edit placeables.2da, and therefore TSL Patcher work too, and spawn it in the game. With a new room that you can't actually enter, you only have to edit the layout and VIS files... and I guess you may still have to script the animation on, but I'm not sure about that. But anyway, editing two text files is easier, and there's no TSL Patcher work because compatibility is a non-issue. I can almost guarantee no mod has ever edited these particular ones, and it's very easy to fix anyway because they're simple text files, so there's no need for TSL Patcher. Making the model would still be a lot of work, though. You'd have to pick out each NPC and import them all separately, merge the head and body, put animations on the model, rename all the objects to avoid conflicts, scale them down, delete the Aurora base and such. Then merge every individual NPC together into one project and position them. And you'd have to fiddle with the animations so they aren't all doing the same thing at the same time, because that would look weird.

Well, it's been a month, so here's an update: The above is all in the game. No film trickery like I've relied on in the past. I figured out the procedure of translating my animation methods into data the game can read. So what you see above I'm aiming to do for every ship available to us.

Interesting idea. My filmmaking time is currently spent, but after I finish my work on the KOTOR Episode I Special Edition I might take a look.

I've been thinking about it, and I don't think there's a way to do it. Yes, it's possible to attach extra damage to the combat round script. However, there are two hurdles preventing the desired effect here. First, the combat round script fires at the end of every combat round. You don't want it to fire all the time, only when you're using the weapon, and not when you're using a Force power or item or such. And I don't believe there are any script functions that can check that. So that script would fire, and the extra damage dealt, on every round - even when you're not firing the weapon. Second, let's assume you were able to resolve the above, with the script only firing when it's supposed to fire. Then there's the matter of writing the script. There is no script function to simply make an extra attack, so you'd have to write a new one based on the formula the game uses, which is, I believe: Attack Roll (d20 + base attack bonus + Dexterity modifier + weapon modifiers) vs Armor Class (10 + armor bonus + dexterity modifier) And the problem is there isn't a way to check every one of those variables with script functions.

Yeah, but animations are applied to the heads and bodies separately. So the body will be playing the Canderous versions of those animations, but the head will still play the one on the supermodel. Although since they're just a couple idle animations they might not look bad even if they are different, they still will be different.

Well, it's not quite that simple. Canderous' clothes use different animations than the player heads. For best results you'd have to make a clothing model stripped of those animations, or hex edit all the heads... and I guess all the bodies too, for only the player characters, so that's a bad idea. Maybe it looks fine is, though. It's only a couple idle animations anyway.

Script looks fine to me. I'd suggest taking k_ptat17_enter, renaming that to something, and then adding ExecuteScript("WHATEVER_YOU_NAMED_THE_OTHER_SCRIPT", OBJECT_SELF, -1); to the end of your script. You'll run into compatibility issues with other mods that edit the on enter script, but those are few and it's relatively easy to fix on a case by case basis. Also I don't think this matters, but if it does matter I might as well tell you: GetIsObjectValid(object oObject) That's the function I usually use to check if an object is valid. I think your way should work, but just in case it doesn't, you know.

Hmm, I must be misremembering then. It was probably just a precaution on my part, or perhaps necessary for some other part of the script. But it shouldn't affect switching back to the PC anyway. I second that. If the character being switched is the owner or initiator of the conversation, that could cause problems that have nothing to do with the switch itself. I only ever scripted it outside of dialogue, so I'm not aware of the complications there.

Yeah, but unfortunately I'm not. I have weighted stuff from scratch before, and it was not fun. There are some possible shortcuts with 3ds' modifiers but I've never managed to consistently get them to work with the game, so I try to avoid losing that data. As far as remapping it... well, technically I know how, but I don't think I have the patience or skills to do it well. It certainly wouldn't look as nice as the above images. In general if I could do that sort of thing I'd be making new models for these projects instead of hacking up the game models. But regarding my specific problems, I did manage to work around most of it. Detaching faces to a new element allowed for the un-mirroring, and the smoothing didn't even look too bad. And for the other project, I'm looking into using other models for the legs.

My party script is six hundred lines long and I spent about a week debugging it almost five years ago. But let's see if I can recall some things. One thing I do remember, because this was the last thing I had to fix and it took a while to figure out what was wrong. I had to run NoClicksFor() for the duration of the switch, because any sort of player interaction with anything seemed to crash the game. After I had finished all the other debugging, I still got crashes that were seemingly random, and went away once that function was added in. The character you're switching to must also be physically present and available as a party member, or else the game will crash. But that shouldn't cause an issue if you're trying to switch back to the PC. For switching back to the PC, however, it looks like in my script I make sure the temporary PC is set as the party leader before the switch occurs. Additionally, I have two separate cases for the switch. Case 4 sets up the switch, and then case 8 executes the script. I can't remember why I did this... I think it might've been so I could retain the temporary PC as a party member after the switch occurs, so you might not need that. I'm going to assume we can scrap all that, and I'm also ignoring a ton of safeties I built into my script. But with that in mind, I'd say it would look something like this: void SwitchPC(int iNPC) { AssignCommand(GetFirstPC(), ClearAllActions()); ActionWait(0.5); SwitchPlayerCharacter(iNPC); SetPartyLeader(iNPC); } void main() { int iNPC0 = 0; // Put in Atris' NPC integer here SetPartyLeader(iNPC0); NoClicksFor(1.5); SetGlobalFadeIn(2.0, 1.0, 0.0, 0.0, 0.0); DelayCommand(0.2, SwitchPC(-1)); }

What does work works great. Smoothing on individual mesh elements is fine. No more ugly seams on arms and legs and such. But it won't do smoothing between different meshes or mesh elements - essentially, across seams in the UVW map. It's only a problem depending on what model you're working on. Many of the armors are fine. Where their meshes meet, there isn't supposed to be smoothing, because there's armor or whatever in between the joints. The underwear models are particularly problematic, though, because they're meant to be smooth all over. The issue also crops up on models that have... the nice word would be questionable, questionable UVW mapping. The Jal Shey armor and the Twin Sun models, for example, have faces on the UVW map that are isolated for seemingly no reason, on the pants. The original models get away with it thanks to the smoothing, but MDLOps loses that.

I see. I suspected that might be the case. So the only way to have separate UVW maps is to have separate meshes or elements. I can live with that. But then that does leave the matter of the smoothing. For that matter I can only hope that one of you enables smoothing group in a future update. I believe I tried this already, but I could go back and try again. I may have been doing it wrong before. But it sounds like it wouldn't resolve the smoothing issue anyway, since they would still be separate elements. For un-mirroring, in the past I've split it into two different meshes and it had a visible seam in the middle. Seems like the result would be the same for that. And in the case of PFBAM it has all the duplicate vertices already, but still no smoothing. EDIT: Yeah, I tried welding the vertices and then used the detach as element function. Still no smoothing. It basically set the model back to the way it was before.

That may be the case, but that's not what I want to do with the model. I'd like to fix the smoothing to use it as shorts or pants and so on. And as I pointed out, that's not a matter of a simple retexture.

I have two more MDLOps issues to report. We talked before about how MDLOps does not currently allow for smoothing between different meshes. Well, I just discovered that this also applies to different elements within a single mesh. So, you can see here I have the model PFBAM, which is made up of a few elements. They are all set to use smoothing group 1. The individual elements smooth just fine, as do the arms, however... There's a rather nasty seam around her shorts, and it's not really visible but the same issue occurs in the shoulder region. And here's the same model again with the textures removed, so you can see this is a smoothing issue and not a texture issue: I tried welding vertices but that led to more trouble. It was actually a bit serendipitous because it helped confirm the source of another problem I've been having. The second issue is... this is hard to explain, but basically MDLOps does not allow for faces that are connected on a mesh to be unconnected in the UVW map. 3ds has a break function that lets you do this - you can map faces to wherever you want, so even though if they share vertices on the mesh, those vertices don't have to be in the same place on the UVW map. I was using this function to un-mirror Bastila's underwear model, so the left and right sides of her body could be textured differently. It looks fine in 3ds, it exports fine, and I can even import the new ASCII file and it still looks fine. Once it's run through MDLOps, however, it looks like this: Not what I was going for. MDLOps stretched the UVW map, as you can see below: A similar thing happened after I welded vertices on PFBAM. The faces on the map there were already separate because they were originally on separate elements. And then after I welded the vertices, I got the same problem, stretched mapping at the edge of the faces. In both cases, I have faces that are supposed to be separate on the UVW map even though they're adjacent on the mesh, and it seems like MDLOps thinks it has to connect them. So to summarize, if adjacent faces are to be mapped to different parts of the texture, then they must be separate elements or meshes, and in either case MDLOps doesn't allow smoothing. I can have something with smoothing, or I can have it with UVW mapping the way I want - or in some cases, the way the game already is - but not both.

I have done it, and I don't recall having to make a new skin. His bone structure was close enough already. It's a moot point, though, because there are no bones for Malak's skirt on the player supermodel, so they won't animate. It's the same issue as Revan - the skirt bits would have to be animated by hand for every conceivable animation. Unless you could get away with turning them into dangly meshes, I don't know.

No idea what that is.

It's just a lot of simple tricks and nonsense.