JCarter426

Oh, yeah, that's NWMax for you. That actually is ASCII, but you have to rename it to say that (for example, Model-ascii.mdl). And be careful about overwriting models by accident. when exporting because it will not warn you about that. Easy way to check if it's ASCII or binary: open it in Notepad. If you can read it, it's ASCII. Not sure about the runtime error, sorry.

It probably isn't reading the "original" binary model. Since our collective knowledge of the model format is incomplete, MDLOps directly copies data from binary models during compiling to compensate. In other words, there are parts that it's unable to translate from ASCII to binary, so it just copies that data from an existing binary model. Therefore, whenever you use MDLOps to compile something with animations (either on the model, or via a supermodel) you need to have an "original" binary model in the same folder. I'm using quotes all sarcastically because it does not have to be the actual original model. In this case you're making a new model, but it has to load a binary model from the game that it calls the "original" model. You can get different results by using different models, but generally you want the model that is most similar to yours, which is almost always whatever your supermodel is, though it's more of dark art than a science. So in this case, extract P_VisasBB.mdl and P_VisasBB.mdx and rename them to match your model, YourModel.mdl and YourModel.mdx or whatever it's actually called.

1. A supermodel is just a different model that has animations on it, and then your model takes animations from that model instead of needing animations itself. That way different models can share animations. So in this case, the best course is to use P_VisasBB so both Visas models will have the same stuff. If you select the base and go to the modifier panel, it's the first textbox under MDL Base Parameters in NWMax. It says "Super:" and then next to that is what you enter. For reference, almost every model in the game uses either S_Female03 (female) or S_Female02 (male, for some reason) as the supermodel. And they can be chained indefinitely, so P_VisasBB for example is parented to S_Female03 so she has her unique animations plus all the female ones. Anything higher in the chain will override anything lower. 2. What's warning you about them? If it's MDLOps and it's saying there are overlapping vertices, you can ignore it. Anything else, well, generally welding vertices is better than leaving them unwelded. Unless they're supposed to be weighted differently or part of different objects or elements, then there's usually no point to having them separate. I'm still speaking generally, but generally stuff only really needs to be on different elements if they have different smoothing groups and on different objects if they require different textures (that's a limitation of the game). Anything else is up to your personal convenience. MDLOps does have some issues about the number of geometric vertices matching the number of texture vertices, but that's probably not an issue here yet.

Oh, right. Bah. Meant in 16-bit.

Ah, I've never worked with Maya so I'm not sure. I would think, though, that it shouldn't really matter how you get the mesh in. So long as you're dealing with identical meshes, same vertices in the same place and so on, you can easily copy UVW and skin modifiers from one mesh to another. So you shouldn't have to worry about getting it from Maya onto that specific mesh. If you export as an OBJ or something and get it into 3ds textuerd correctly, you can unwrap it and then copy the skin over... I think. If you do it that way, be sure to convert to editable mesh, center all pivot points, and Reset XForm in NWMax/KOTORMax before applying the skin.

I've only ever manually weighted because I have a slow 3ds learning curve as well, and I agree with that assessment - not as bad as it seems... but still not fun. I've never done a character UVW map from scratch so I don't know how much I have to add, but I can say that any of those modifiers definitely have to be below the skin and probably should be below Aurora/Odyssey Trimesh if you're using that. Oh, and Flex too. Basically, below everything. It's also a good idea to convert to editable mesh before mapping, but if you've done the skin already then you've probably done that.

Interesting question. My appearance.2da file is currently at 862 lines, so my estimate is greater than or equal to 862. That puts us over 16-bit, so assuming it's 32-bit or greater (and not something weird) then we're dealing with more than 65,000.

No, cutscene animations ignore the walkmesh so every animation would have to be fixed in that instance as well. It's all doable, but it's annoying because there are six player models. As for skipping the scene, if there are no important scripts run through that dialogue then it would be a matter of deleting all the nodes so nothing fires and it continues to the next scene.

It returns the module itself, the ones in the RIM and MOD files.

View File JC's Supermodel Fix for K2 This is a fix for a number of issues present on the supermodels, the stock animations used for most characters in the game. First, Obsidian added several combat animation variations for K2, but they messed up a couple of the names, causing the game to play animations that don't exist and resulting in characters freezing in place. This mod fixes that. Second, the animations for dual blasters had the hand objects in the incorrect positions. For male characters, the blasters would clip through the hands, and for female characters they would hover above the hands. I've restored them to the positions they were in K1. Third, when wielding dual melee weapons, male hands would clip through the weapons for some animations, notably the looping ready pose. The issue seemed to be that the fingers were gripping the weapon too tightly, so I loosened them up for the male models. I have also added an option to change the melee running animations to match how they are in K1. I included this as an optional part of the installation as it's an issue of preference rather than a straightforward fix. If you think you've spotted any other issues, send me a picture so I can confirm what the problem is and whether it's an issue with the supermodels. If so, I'll add it to my to-do list.  Submitter JCarter426 Submitted 08/26/2017 Category Mods TSLRCM Compatible Yes  

If you're talking about the taunt animation in the opening, I believe that was Jenks. I doubt it would be viable, though. Malak has no facial animations due to having no face, and he's a lot taller than the other characters, so that usually causes problems... problems that possibly can be fixed, but it's not fun. The alien heads have already been released for K2. I'm in the process of updating it and doing a K1 version. I guess they aren't on Deadly Stream because I meant to update them, but you can find them here.

The Kreia animations I put together, and I would have no problem releasing them, but I believe there are other problems that Yce had to cover up with movie magic. The main issue is Malak does not have enough animations; Obsidian added a bunch of variations to the combat animations and the Malak model lacks corresponding ones. The best way to go about it would be to keep the original animations as a base and edit the left arm data - which is a thing I could do, but it would take a while. And I would want to fix some other issues with the supermodels before doing that, also. So it would take a while and I'll have to think about whether I want to do it, but that's a good suggestion. I kind of forgot about it after Knights and the Darkness because I haven't worked with K2 since then.

We could probably make some of that happen, but it's kind of a tricky issue for us. I have no problem with people playing as a Zabrak or whatever, but if material we made specifically for our films turns up in another film it's a different matter. And again I have no problem with the material being used for other things - I have released some mod resources already, in fact - but there are things with which we would feel comfortable and things we would not... it's a matter of context. Once it's out there, it's out there, and we can't really dictate how it's used, or expect people to understand our contextual feelings. But I would like to release what we can if possible. We just have to figure out the appropriate way to do it. My cinematic mod here is a good example of that. I've gotten requests for this sort of thing before, but I've always had to refuse due to conflict of interest. With our films, we go out of our way to make new things, do things a bit differently than they are in the game. I've been worried if I did something for a mod that we would later want in one of our films, then it would seem like we were just using a mod and that it was not something new made for the movie. So I've been trying to think of something I can do that avoids that issue. With these cutscenes, I know most of them probably won't end up in any future movies, and even if they were to, I'd probably do them differently anyway. These scenes all have to take place in specific places on the Ebon Hawk and play out in a specific way, which I would be free to change up for a movie in the way that I usually do. And, worst case scenario, if we end up just reusing the scene exactly how it is in the mod, well, that's not any worse than reusing one of the original game cutscenes, which we do from time to time anyway. In short, these cutscenes are straight from the game, and everybody knows they are from the game, and if they end up in a film they're either going to be straight from the game because they are game cutscenes, or they'll be completely different in a way that wouldn't fit in the game. So no conflict of interest. The other stuff, like characters, locations, or animations made for a specific movie in a specific context, is a trickier matter. We'll have to discuss that. But for now, when I have the chance, I'll be bringing the same methods we've used in the films for almost ten years now... but for other things.

Jenks and I are two of the animators for them, actually. I know it's confusing because we go by our real names in the credits, and also my YouTube isn't my usual alias. But the three animators for the Logan films are, by our aliases here, Jenko, DarthYcey, and myself, and KOTOR_Trilogy is our director. The stuff we do for the films relies on a lot of tricks, stuff that gets fixed in editing. And any camera trickery with GLIntercept cannot be utilized for mods. So making cutscenes for mods is a bit more difficult, and that's one of the reasons I want to do this. It's a bit of a challenge and a bit of practice, and I get tired of seeing the original cutscenes in their current buggy and sort of dull forms. The developers understandably didn't have the resources to make every scene perfect, mostly due to how finicky the engine is, so I have a lot of reasons to want to give them an overhaul.

Oh, I'll be sure to. I'm not sure I can really say any more yet... I haven't made any decisions. I'm used to making it up as I go. But I watched it last night and I can say that HK crosses the line several times (looks left in one shot, then right in the next) and there's an awkward pause before T3 actually zaps him. Those both have to go. There's also one angle that's used for most of the scene, and it's kind of awkward. But on the subject of how to do the scenes, it seems that k_003ebo_enter and a_next_scene won't decompile. If anybody could get me .nss of those, that would really help with testing. Fortunately there are a few that I can do in the meantime that are easy to trigger, HK/T3 included. But it would be nice not to have to rely on that.

I don't use AniCam anymore, so it's not hard. But the cameras won't all be animated. I'll still make use of static ones, most likely, but my aim is to reduce the reuse of the same static angles, the default three angles that have a tendency to screw up, crossing the line issues, and in general frame them better and get rid of some awkward timing. I'll explain how it works a bit more as I do the scenes. I'm thinking of doing the HK & T3 scene first, as that has examples of everything I just mentioned.

Hassat Hunter mentioned that he wanted but was unable to get a camera similar to one TSLRP did for TSLRCM. So, I decided to do one. Here's the original, for reference: That's just the camera, not the scene from the mod. And here's my recreation, as it were: I've been thinking for a while of doing some more of this, making the game cutscenes more cinematic so they aren't using the same few static angles repeatedly and to do some other improvements. It's going to take a while and I may be posting scenes as I do them for suggestions. I won't be doing all the cutscenes, but I'll do some of the more prominent ones, and for both games. For now, though, my focus is just the Ebon Hawk cutscenes in K2. They're all in one location, and I have a general idea of what all of them are, so that makes them relatively easier to access and I can release them in one batch when they're done. Also, this may come as a surprise, but I have not played TSLRCM because I have not played through the whole game since TSLRP was still going. So I don't know a lot of the changes in it and I haven't seen many of the new cutscenes. I don't know where this camera would even fit in, for example. I'm planning to get through it soon, but I'd welcome any suggestions or other information in the meantime.

Is this the one?

I believe he wrote a fancy GUI file editor to do that. But if you don't want to spend that much time on it, or stray too far from the original, at the very least it should be possible to fill in the buttons with a solid color so they stand out against the new menu background.

Well, we talked about doing it by planet before, and I did write the code for it, but the problem is getting it into the game. I wouldn't say this is the easiest, but it's certainly the most all-inclusive way to get it into the game, to replace every OnEnter script so they're all firing the same thing before firing their different things. But that means editing the modules' ARE files. And that means it can't be done with the TSL Patcher in one go. It can't check if there's a MOD file already present in the modules folder. I still haven't figured out the best way to do that for compatibility.

I've never noticed any drawing distance limitation with cutscene cameras - static module ones, or animated ones, or even the standard angles - but I can confirm that not all cameras are created equally. The camera modes left over from Neverwinter Nights have a much shorter distance, so it's conceivable that the menu does as well.

Oh, I see. If there's a hook then it most likely can be animated, since the other cameras are the same way. I'll check it out when I get a chance.

They should all be in the same place, 2da.bif.

The stealth speed is a hard-coded element of the combat system. The only remotely viable way would be to edit the heartbeat script to give a movement speed effect when stealth is activated, but that would cause other problems.