JCarter426

I've dug up some more links I've consulted in the past that I couldn't find the other day: FYI Tile Lighting About lighting in NWN

Yeah, it's on my list of things to fix. I ran into trouble with it the last time, so it didn't make it to release. It is indeed caused by animation frames being missing but apparently they are needed even on an animation in which the object is not animated or things will get scrunched up. I have a script that, thanks to some help from @bead-v, can copy/paste animation frames to fix the problem en masse... but something else went wrong when I did that. I'll have to try it again at some point.

There is some documentation here. Light Priority: Only 3 light objects can affect a given mesh at any time. This number determines the priority for rendering lights. Lower number = higher priority. Ambient Only: If this is set to 1, the light will only affect static objects such as areas and not dynamic objects such as creatures. Dynamic Type: 1 for animated lights. 0 for non-animated lights. Shadow: Determines whether the light will cast shadows when occluded by dynamic objects. Flare: Determines whether the light has a lens flare, which is a texture that's rendered in front of the light whenever you look at it. Fading Light: 1 if the light should fade in and out as an object approaches/moves away from the light. If 0, the light will just blink on or off like it was hit by a switch. I would say your best bet is to copy the settings from a similar light source such as blaster bolts or T3's welding arm. Apart from that, I would try setting the priority and fading light values to 1, and flare to 0 as I don't see a use for it here.

Hmm, I have g5g1 marked down as present on S_Male02. I'll take a closer look when I have the chance, though.

I might not be remembering this clearly since it's been a while since I took a look at custom tokens, but as I recall they are limited to the dialogue that's currently active. If you want to keep track of a value for longer than that, you need to use local or global variables. And if I'm remembering correctly, that would also mean it should be safe to use whatever number you want. The game uses some consistently, like 30s for computer spikes and 40s for repair parts, and it would be safe to avoid the ones used by the combat system, but apart from that it probably doesn't matter.

It's not possible to use both at because there is only one model slot for Jedi robes. Theoretically, one could remove one of the other models to replace it with a second robe option, but that's a bit on the impractical side and I have no specific plans to do so at this time.

Just checking that it's potentially an issue with both K1 and K2 and not just what was reported for K2. If I recall correctly, the original problem and the fix that I made for it were for both, so it's possible the current problem is a result of that on both.

It's trying to call it like: StartCreditSequence(0, ""); AmanoJyaku can correct me if I'm interpreting the bytecode incorrectly, being further along the get a degree in computer science in order to make better modding tools for a 15-year-old game career track, but I believe the number after the function is the number of arguments to call the function with, and then those arguments are taken off the stack. Things are taken off a stack last in, first out, so it takes the integer 0 and then the empty string. My guess is that at some point in development, the function took two arguments - maybe the string was for the name of a movie file - but they changed how the function behaves sometime after this script was compiled, and never recompiled it. That seems to be the case. I tested with the following: int testInt() { return 1; } int TEST_INT = testInt(); And that will cause DeNCS to fail to decompile any script that includes it. For completion's sake, I also tried it this way: int testInt() { return 1; } int x; x = testInt(); Interestingly, this would not even compile. It seems the tools aren't very fond of variables with global scope, but I'm not sure why it would care whether one was initialized or not.

That might be a problem with the individual models - since you say it's "sometimes" the only way I'd know for sure if it's "sometimes" for every model and not never for certain ones. But it's similar enough to some other reports I've gotten - and also the original problem this mod was meant to fix - to make me suspect maybe the fix wasn't enough. Could you confirm if you're using only the Supermodel Fix for K1 and not the ported K2 version version (through mods like Cloaked Jedi Robes or Slave Bastila)?

I'm not sure what module that is, but in KOTOR Tool it would be RIMs -> Modules -> whatever module it is, unk_something.rim (e.g unk_m41aa.rim) -> Dynamic Area Info.

You need to add a trigger to the area's GIT file and have it linked to a waypoint in another module. Your best bet would be to find an existing transition in the area and copy what it's doing.

The second one you can ignore. That's Gmax's way of saying what we were talking about before - certain edits to the modifier can potentially break a modifier higher up in the stack, in this case the skin. So long as you don't add vertices willy-nilly it should be fine, however.

That's the most up to date compiler we have for KOTOR, unfortunately.

I'm not familiar with most of those mods, but if I had to guess I'd say Weapons of the Old Republic. I wouldn't expect it to be compatible with most mods.

I compiled with the version of NWNSSCOMP found here. In KOTOR 2 mode, if that matters.

It's me again. The mod roundup has most definitely served its purpose this time. It tipped me off that I never got around to updating the K2 version of a mod that I updated for K1 in January. The work was nearly all done and I was just too lazy to take new screenshots at the time. So good job, mod roundup. Updates Robe Adjustmnet – Fixed an issue that made the training cutscene wonky if you skipped through dialogue too quickly. Jedi Tailor – While testing a while back, the Tailor's shop spawned inside a Jawa. So I tried to fix that for this update, but because it's a random occurrence I'm not sure if it actually worked. Also fixed another bug in the Tailor's dialogue. Fashion Line I: Cloaked Jedi Robes / Cloaked Jedi Robes & Supermodel Port – Redid all textures. Higher resolution and ideally higher quality. Lightsaber Visual Effects for K1 and K2 – Added new options for blue and green lightsabers and converted all texture files to superior TPC format. New Mods Player Soundset Restoration – Restores the player's voice to K2 so you say random stuff when performing actions like you do in K1. Romance Enhancement: Biromantic Bastila – Allows a female player character to romance Bastila. Something Completely Different I have two somethings this time. I suspect certain individuals might be experiencing an increase in productivity on account of having more extra time than usual for certain reasons. First, @VarsityPuppet has finally gotten around to announcing the winners of the 2018 Mod of the Year awards. I hadn't realized that my Cloaked Jedi Robes had won for one category, so thanks to whomever voted for that. VP has also promised to get the 2019 competition running soon. Second, @AmanoJyaku has been working on a new script decompiler to address some issues with DeNCS. If successful, it will be a boon to modding as there are many scripts that cause DeNCS to choke up, preventing us from fixing bugs in them or otherwise improving their performance. We ran into several such unfortunate cases during Community Patch development, and there are also many scripts in K2 still running the bugged original random loot code even though TSLRCM fixes some of those bugs because the scripts without source code couldn't be recompiled. Any progress on that front could help make those fixes and other mods possible.

It's like I'm looking at my future, and my future is written in assembly. I whipped up some tests and attached them. I don't know how much help they'll be, though, since if anything they only confirm what's already been said. The compiler we have, at least, does The preprocessor that we're using, at least, will only include code that is actually used. Which is good. My tests confirm that. Based on the garbage I've seen in decompiled game scripts, though, I think it's possible BioWare's might not have been as optimized. I often see tons of integers declared in decompiled scripts that are never used. I can't remember if I've ever seen any functions I was sure weren't used, though. I tried various things that should lead to dead code but I think it's all of the first variety. I tried to make an unreachable block in the 6th one, but I still see jump points in the disassembled code. ncstest.zip