JCarter426

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.

Yeah, I actually implemented that in an old mod a looooong time ago, and I was planning to get around to it once I update that. The update would also edit appearance.2da so the mod would not have to rely on a texture rename, making it more compatible with other mods. Just haven't felt like messing with TSLPatcher yet. Been lazy.

Sure, no problem.

Got it. I'll knock a few off your plate when I get a chance then. I've been in the process of updating my old heads resource so applying this there would probably be a good idea too, saves future annoyance.

Sounds like a plan. I just remembered there's also Visquis. I'd be interested in doing a few if only to learn the procedure for future reference. From your screenshot I can guess how you broke up the face so certain elements will be obscured by the head object (mouth, nostrils, etc) but I'm not sure what the method for changing the hierarchy is. Do you just unlink it from the base and then relink it in the order you want? Or do you change it in MDLEdit after export? I don't see any means of doing it in there. I'm sure it could be done by editing the ASCII in Notepad, but I'm hoping that's not the answer.

It's not just your edits though. It's more of a problem on some models than others, even without mods. Carth's eyes were already fine, and only his mouth was problematic, whereas other models have everything wrong with them. I suspect it's the same case with the rest - by chance the hierarchies are arranged nicely for some but not others. Strange. That's funny. I guess that makes sense, in its own nonsensical way. And I bet that explains other issues we've noticed like windows blocking out characters when they shouldn't - again it probably has to do with the order in which the models are drawn.

I checked what BioWare did for the dueling Sith, and it looks like they had one of the character scripts heal them up between combat. The scripts I tried to look at wouldn't decompile, so copying what they did directly probably isn't an option, but repeating the effect certainly is. The 1 HP hack sounds a lot easier if it would work though.

Interesting. Very interesting. I still maintain there was no reason for Carth and Cede to be that different (your edits aside) since they have the same object names and supermodel structure and such so why would the hierarchies be different? But clearly they were different so whatever. Weird game. Weird problem, weird models, weird game. As for other holograms in the game, there's Goto, but I don't recall him having this problem. There's also the reporter on Onderon, and the Twi'lek dancers there as well. And the Sith officer on Dxun. I feel like there must be more incidental ones I'm forgetting. Oh, and also Bastila. I'm definitely forgetting some.

Hmm, that would imply that Carth's model actually is obscuring all the stuff that should be obscured, but Cede's isn't. Well if we knew how that worked, that would make things a lot easier. One thing does come to mind. If you put one lightsaber in front of another, the game has an issue of the lightsaber that was rendered into the game most recently always being on top. So its hilt will always render on top of the other lightsaber's blade, even from behind. It may be a similar case here, of just which object on the model happens to be loaded in the game first. If that was something that could be predicted (like alphabetical by name or something) then maybe it would be of use. But I'm pretty sure it's not, because the models' objects are usually named the similarly with little variation, so there should be no reason Carth and Cede are different if that's the case.

Huh, I could swear I have had placeables that were lightmapped (or rather, kept their existing lightmaps). This was in K2, so maybe that makes a difference, or it could've been a trick of the light...

We never considered it for the main events - despite all the other visual changes, Mr Director still wants his Revan to look like his Revan. However, we have tinkered with some of what you mentioned in the event that we have flashbacks and such. It's definitely still on the table at some point.

Ten years... I'm glad to be able to share this old stuff with you all, both you old people and some new ones too apparently. Yes, my artistic skills certainly have improved over the last ten years. Good luck with your own comics too.

The model format has a means of having some geometry not be shown on the hologram model. I haven't tested it, but there's something there, so let's assume it works for now. In that case, you could split the problematic objects in half and set one half to not be shown in holograms. So you'd be free to remove as much as you want on the hologram model without messing up the regular appearance. Still a lot of modeling work, but I think that's the best option. The issue with the K2 holograms is that they apply the same hologram texture to the all the geometry, and it's a transparent texture so anything that would be normally obscured by other geometry being in front of it no longer is. There's no getting around that without hacking away at the geometry.

Nice idea. Editing the area models is definitely preferable, but just so you know you actually can lightmap placeables. You can lightmap any model, really - it's just an extra texture applied to the model. It's just not usually done because a placeables are usually meant to be placed in a variety of lighting conditions and thus lack lightmaps themselves, but it can be done.

That's strange. It's in the UTC regardless. I believe it's the Interruptable boolean. It all shows up if you edit with K-GFF instead. There are lots more booleans that don't show up in KOTOR Tool, some of which aren't even used in the game, so it's possible there's one that does what you want. Maybe.