JCarter426

You should change it to whatever the model name is. Well, you don't have to, but it's a good idea to because then you know nothing else will be called that. But if you're only working with retextures, you don't actually have to make new head models at all. You can use the same model for everything but specify the textures in heads.2da.

My name has been uttered - lo, I have been summoned through the dark arts. Yeah, I've done some, and I've done some more that I haven't released yet. I've been going through all the viable ones that I didn't do before (and also fixing some of the ones I did) but I broke the game during testing, so progress has been slow. For the next release I want to do body variations as you mentioned; at the very released, I'll do two more size variations for all the armors - a tiny set for Gand, Gran, and other short individuals, and an XL set for Trandoshans and Malak-sized individuals. And then if I'm not lazy I'll consider the hands too. But like I said, progress has been slow. Yeah, it's certainly easier, but the tricky thing with humanoid aliens is you have to use a human head as a base, and then it's going to look like a head that's already in the game. So it makes it easier to add something to the game, but it doesn't exactly add variety. You can make some changes, of course, but that's easier with some species than others, and the more changes it needs the closer you are to making an entirely new head. So it's tricky. Still, there are a lot of possibilities here. There are some I have done and haven't released. I've got a Zeltron, a Sephi, and a couple Zabraks. Maybe I'll get some pictures up when I get a chance. I've considered trying a Cerean, actually. I never decided which head would be the best base for it, though. I've also thought about trying a Theelin. To add to the list, Falleen wouldn't be so difficult. These are a bit more out there, but I've pondered on the Vultan, Quermian, Mandallian, Skakoan, and Givin. I haven't had the courage to attempt any seriously, though.

Did you hex edit the model's Aurora/Odyssey base name as well? If the game spawns in different models with the same base name, it can get confused about their properties, resulting in problems like you're describing.

For the TXI file, you need a bit of code depending on what you want, something like: blending punchthrough or blending additive But that depends on having a properly working alpha channel. It's just telling the game how to blend what's already there. Some textures may be lacking all this if the blending is handled in another manner - for example, some windows might be a solid texture with the transparency simply applied on the mesh, and some visual effect textures don't need anything either because it's already handled through the particle system. But the vast majority should have a standard alpha channel. I'd suggest converting the same textures with KOTOR Tool to make sure it isn't your tool that's converting them wrong.

For the record, I don't speak French either. And that definitely was better than what we had. It's just the Bink videos weren't a very good way to show the battle from the start, which is why TSLRCM didn't use them... I recall somebody (probably Avellone, but I don't recall for certain) specifically blaming the Xbox for those videos. It just couldn't handle a battle of such scale - particularly in that area, I suspect, as it already has lag issues. I think the movie terminal in 603 was only in there because they had to replace the battle with those videos at the last minute and decided to leave it in there.

It depends. Generally, transparency is handled through the alpha channel. Depending on things it may also need a TXI file or it may not even need an alpha channel. Which textures are you looking at? Also, what are you using to convert them?

This: ...is a big part of it, of course. Unfortunately that applies to most of what I think would be good ideas. As for the rest, some of it just seems a little convoluted or unnecessary, like adding a second ship for you to use in case you fail to take care of the Ebon Hawk, or changing a storm beast into a drexl. I don't have a burning desire for more fetch quests and puzzles so late in the game, either. I don't think Hanharr should come back just to be killed. That would take away the impact of sparing his life. It's fine as is. I'm not a fan of adding more regular, non-Force using Sith because Malachor was supposed to be the super secret training ground for assassins and a place to break Jedi. If anything, I'd get rid of the regular Sith troopers that are already there, but they're probably needed for variety in combat. I don't see the need to add more, regardless. I don't see the remote stuff working with the game mechanics. Even if he can be beefed up - and I'm not sure everything described can even be done without requiring some really annoying modding - he's still just a tiny droid that can only shoot a tiny blaster and it's not going to be fun to fight or run away from all those storm beasts. There's a better option - get rid of his solo mission and team him up with the Exile. That also addresses how the Exile knows about the whole mission later on. I believe that was in the works for Malachor VI. Finally, the permanent death thing doesn't sound fun. That sort of mechanic annoys me in every game I've ever played that has that sort of thing, even less severe cases like wound mechanics (for example, in Dragon Age: Origins). It feels like it's punishing me for succeeding but not well enough. I'm fine with reloading until I finally win the fight, but once I win the fight that's it. I've already won. I don't really get as much enjoyment out of winning but slightly more efficiently. But if you don't sort that out, then you're at a handicap for the next fight. So it annoys me. And that's with games that have an easy way of fixing it, be it a resurrection scroll for your dead party member or those special health packs or whatever. This would be irrevocable death for your party members, determined by random combat results and character building choices you made hours ago that can't be changed now. On top of that, it's a total change from how death usually works in the game, very late in the game. It wouldn't be fair without some sort of warning, but I don't even know how you'd handle that. If we want more chances for permanent character death, I'd rather they be determined by player choice alone.

Eh, some of those ideas sound good, some not so much. One part stands out, however:

The yacht is definitely the VIS file. I've noticed it before. Wouldn't surprise me if that was the case with the Refugee Quad as well. Looks to me like the problem is the corridors aren't visible from each other. I don't see 302narp visible from 302naraf or 302naraf visible from 302narp in the file. Yeah, that was it. I'll add 302 to my fixes, but I've attached it for immediate use if you want. You'll have to rename it to .vis since Deadly Stream doesn't allow attachments of weird KOTOR file formats. I still haven't looked at the yacht for the same reason I didn't look at it before - the ship has lots of rooms and it's annoying. But I'll get to it, possibly. 302nar.txt

I remember years ago running through either the first or second one in the beta release. I actually liked your original design because there was no proper hangar - the ship was just there on the street and anybody could see it as they walked by. It was like the planet is so polluted and overdeveloped they don't really have the space for that or even care to anymore. Like Nar Shaddaa. Some of that wonkiness might've been due to your skill level at the time, but I actually liked that. I really like the new one too, though. It's by far the most polished and looks exactly how you'd expect one of the game's hangars to look.

Like VP said, the more tools the better. We just got KOTORMax, MDLEdit, and an MDLOps, and now this year there's a whole line of new tools in the works for other areas that were in need of updates. It's nice that the community is still so active even after 15 years. And a Linux version would be most welcome. I run Mint on my laptop, and seriously the only reason I ever boot into Windows is if I need to run KOTOR Tool. Either that or I overcome my laziness and go to my desktop. So with a KOTOR Tool replacement, even just being able to look at the files would further enable my laziness.

The heads are just missing the mask and goggle hooks, so I added them.

Batch conversion in KOTOR Tool worked with MDLOps 0.7. You just need to replace the EXE. I haven't tried it with ndix UR's either though. Already have every single model converted to ASCII in the old archives.

The commoners can't wear masks in either game. I've already edited all the commoner heads for the second game so they can wear masks as part of an update to my heads mod resource, but it's for the second game. So they'd be useless for the first game. But I will make them available for the second game when they're ready.

Without testing that I can't be sure, but it sounds like that only worked because not all the lines in upgrade.2da are used for lightsaber crystals, making it possible to hack the upgrade system. But all the lines in placeables.2da are for placeables. To clarify, the limitation is due to the way a computer stores information. In the UTP file, the placeable's appearance is stored as an 8-bit integer. Basically, the computer can only count to 256. It knows there are 256 placeables and then it can say this is the 0th placeable, this is the 1st placeable, all the way up to the 255th placeable. It doesn't know how to count beyond that, so it thinks the number 256 is the same as the number 0. So if you input 256, it will read it as 0, and then it will look at line 0 in placeables.2da and it doesn't matter what line 256 was. As far as the game is concerned, it doesn't exist. Other variables in the game use larger data types, like for appearance.2da, and apparently upgrade.2da uses an even smaller one. My guess is at some point in production they counted up how many things there were so they could use the smallest type necessary. It's good for efficiency but it's bad for modding.

Wow, I never realized that. My placeable entries for K2 number in the 400s, mostly from testing things, so I never even thought it would be a problem. For K1 it's dangerously closed to the limit at 248. Not that there was much room left in the first place. With this game, I shouldn't be surprised. I don't believe they do in K1, but even if they do, the dynamic lighting value in the GIT file could be copied to the model's ambient lighting. They're both standard RGB values (although the way GIT stores those values is... terrible). Of course, the dynamic lighting is only there to help the placeable blend into the area lightmap better. So the point would be moot if you redid the area lightmap entirely with all the new objects. Or throw away the terrible concept of lightmaps completely. The engine should be able to handle dynamic light objects for everything. In the past there has always been a "three at a time" limit, but the game areas have hundreds of them and I think we'd notice if they were blinking out to only show three at a time all the time. I'm also certain I've had more than three at a time via other models with Aurora lights in them (placeables, visual effects, etc). I suspect the limitation was a legacy of the NWN tools and may not be relevant anymore. But redoing the lighting for every area seems as unrealistic a proposition as replacing every placeable in the game. But getting back to the main point, another option would be to convert some placeables to visual effects. Those number in the thousands, so they must use larger data type, meaning more room for us. This could be executed by changing the placeable's appearance to invisible and having a script to apply the visual effect on it on spawn, assuming there's no chance of the effect being cleared by the game. I don't know of anything that would, but I'm not certain. Visual effect replacements could still be animated, provided they utilize a single looping animation, but they couldn't change animations and therefore you couldn't interact with them. And lightmapping would probably be out of the question. The other 2DA files likely do have a limitation, but it's at least a 16-bit integer for some of them, meaning over 65,000 possible lines.

Wow, that's quite a difference. I don't think I've ever seen Canderous as a hologram, so I didn't know how bad it was.

Yeah, that's why I suggested to disable it. The game's fog is terrible in general, usually a waste of time to mess about like that. However, if you do want to keep it and mess about like that, I'd suggest disabling it for the palace and then changing its self illumination. That's pretty much what the fog does anyway, and you'll be able to set it to whatever color you want and reach a happy medium.

The Leviathan bridge crew should already have sitting cutscene animations from other scenes, although I recall in at least one case it deforms the head. Still, there should be some usable ones already.

It's probably the fog doing that. Does the same to the original palace. Might be better to turn it off for that module. Progress looks good, though.

There are plenty of animations available, just no convenient one on the supermodel that anybody can use anywhere like K2 has. In K1 all sitting is done either through a cutscene animation or with an animation on the model itself (usually an animated placeable). I'm not sure why they did it that way, seems really inefficient. For example, every single bridge officer on the Leviathan uses a different cutscene model. So there's no lack of sources for sitting animations, but the way cutscene animations work you'd need a new model for each character, so it can be a pain. K1 has another big problem in that there are a very limited number of animations that can be scripted. So even if you wanted to mess around with the supermodel to add a generic animation, you'd be limited to utilizing one of the unused animation constants, such as ANIMATION_LOOPING_KNEEL_TALK_ANGRY. So that's even more of a pain than making new cutscene animations. Or you can teleport them out of the scene.

Sitting cannot be scripted in K1. To have Mission and Canderous sit in that scene would require new cutscene animation models.

"Bao-Dur . . . we just didn't have time to finish his thread, but if I recall (it's been a while), he was supposed to die on the attack on Telos to help HK-47 get to the HK-50 factory and shut it down to save the planet." -Chris Avellone

Hah, there's actually more I'd have to do but that'll certainly save lazy JC some time, thanks.

All the extra bones? That's how S_Female03 is. I'll take a look at it later, but it seemed to be fine in the game. EDIT: Yeah, there's a problem. A combination of me being dumb and the game being dumb. The model I used as a reference for the skin, PFBCM, had broken weighting on the fingers, probably a conversion error. Garbage in, garbage out, so of course my model has the same problem. Stay tuned for the fix.