JCarter426

I was afraid of that. The grenade script is set up similarly... it doesn't use cases but it does have an if tree for all the grenade types to run. I'll have to think about which way I prefer but I think I can still manage it all in the same code. Not as efficient as it would be if I were allowed to define my own actions but ah well. Thanks.

Nah, doesn't work. If I remove the parenthesis from the declaration but keep them in the body, it says it can't invoke that as a function - because it's not recognizing it from the declaration, I would assume.

That was one of the things I forgot I had tried... when I do it like that, I get a type mismatch for the AssignCommand. And that really shouldn't be the case, because I can use a subroutine with AssignCommand just fine otherwise.

Also, I'm not sure if removing the parenthesis would later allow me to run that subroutine with its own variables... I think it should, but obviously I can't test it until it actually runs at all.

This is kind of a stupid question. I was working on a script earlier and I was saying you can do this with loops instead of 600 lines of code, and then... well, now I'm wondering if you can. Of course there must be a way to do it, I thought... but every attempt so far to compile resulted in errors.

I'm trying to write a subroutine that will fire another subroutine repeatedly for any duration of time, and with any interval between each firing. For example, 5 seconds of blaster shot, with a quarter second between each actual shot. The code for the blaster shot goes in one subroutine, and all the looping code goes in another subroutine, and I want that to be able to fire the first subroutine as well as any number of others, and then finally I have the main body.

This is essentially the code that I want:
 

void JC_SUB_1() {

//Subroutine contents

}



void JC_SUB_2() {

//Another subroutine, why not

}



void JC_SUB_TRIGGER(void JC_SUB_HERE(), object oObject, float fDuration, float fInterval) {

int nDuration = FloatToInt(fDuration / fInterval);

int i;

for( i = 0; i < nDuration; i++ ) DelayCommand(IntToFloat(i) * fInterval, AssignCommand(oObject, JC_SUB_HERE() ));

}



void main() {

//Our first subroutine, with a duration of 5 seconds and an interval of one quarter of a second...

JC_SUB_TRIGGER(JC_SUB_1(), OBJECT_SELF, 5.0, 0.25);

//And later in the script, let's have the second subroutine, with a duration of 2 seconds and an interval of one tenth of a second...

DelayCommand(30.0, JC_SUB_TRIGGER(JC_SUB_1(), OBJECT_SELF, 2.0, 0.1));

}

And the problem is right here:

void JC_SUB_TRIGGER(void JC_SUB_HERE(), object oObject, float fDuration, float fInterval) {

I can't get it to accept a subroutine as one of a subroutine's variables... or to be more specific, I can't get it to accept any data type for that variable. It won't take a void. it won't take an action because only nwscript.nss can use action. I looked up data types on the NWN Lexicon and tried command, but apparently KOTOR doesn't support that type, as the compiler wouldn't recognize it. And it wouldn't take a few other things I tried and forgot what they were.

Now, I could get around this by removing the subroutine as a variable and defining it in the body, but that would mean duplicating all the trigger code for each different subroutine I want triggered. I could use ExecuteScript, but I'd rather keep everything in one script. So I know other ways to do it, but I want to do it my way.

I thought of course there must be a way to do it... but I've tried everything I can think of. But most of my scripting knowledge comes from modifying video games, so maybe I missed something.

File Name: JC's Saber Workshop

File Submitter: JCarter426

File Submitted: 06 Feb 2016

File Category: Mods

This mod adds a workshop to the Ebon Hawk's garage, with which you can construct or deconstruct lightsabers and lightsaber components.

One of the things Obsidian did differently was the way you make your first lightsaber. In the first game, you build it at the Jedi Enclave, so they have all the parts there. In K2, the Jedi are all gone, so you're given a scavenger hunt. You have to find three components, bring them to your buddy Bao-Dur, and then you get to make your lightsaber. With that in mind, I have designed the workshop to deconstruct lightsabers, giving you a color crystal and those three parts. Double-bladed lightsabers contain an extra focusing lens and emitter. With all these parts in hand, you can use the workshop to create lightsabers, as well. Furthermore, you can use the workshop to create or breakdown the individual components (provided you have the schematics for them - i.e. you've gotten them through the Crafting a Lightsaber quest - and the right skill points). So that means you can create as many lightsabers as there are color crystals; those crystals won't be burning a hole in your pocket.

In short, you have more control over your lightsabers; you can create sabers out of crystals and components, and you can change lightsaber type at will.

Oh, and you do not need to start a new game or anything of that sort. The
workshop will appear on the Ebon Hawk when you enter.

Click here to download this file

File Name: JC's Minor Fixes for K2

File Submitter: JCarter426

File Submitted: 06 Feb 2016

File Category: Mods

TSLRCM Compatible: Yes

This is a collection of various things that I found annoying enough to alter. It started with that crazy window on Nar Shaddaa, by the landing pad, that would mysteriously render anything that was behind it invisible. It turned out to be as simple as a missing TXI. But it was at this point that I decided to start collecting little things like that into a single mod, to be released to the general public when it became more substantial.

Due to the nature of this mod, I haven't bothered to make a proper installer with the TSL Patcher. Just install whatever you want to install. Don't install what you don't want to install.

Some of these fixes are included in TSLRCM, while others are not. Either way, it's compatible. Other mods may not be compatible; contact me if you have any questions.

Contents as of v1.2:

Click here to download this file

That's the standard PFBAM mdl, but heavily modified to match Mira's BB model almost perfectly (like the pronounced clavicles). My previous underwear mod was good, this one will be better.

 

That's good to know. I'll keep it in mind as a last resort, since it would mean a whole bunch of extra work to re-weight the shirtless male & Mira undies models. If MDLops is tweaked to work the smooth groups better, then they would be ready now (I still have to re-do her dancer model before releasing it).

I figured it had to be that, but I couldn't figure out how you had gotten it to be so accurate. You're scary sometimes.

And I'm seconding the request for the smoothing groups. I've been fiddling around with it some more and while everything does seem to be doable, the way many the models are set up would require a lot of editing just to retain the smoothing as is. A lot of them have the forearms on a separate mesh, and in my experience editing the arms is one of the trickiest parts. Simply running it through MDLOps loses the smoothing because of that. In contrast, a lot of them have the feet on the torso mesh and splitting them is required to keep everything as is.

Great video. You had some fantastic ideas for Malachor. I get why you gave up though... getting just that much fully executed in the game must've taken ages.

Looking forward to seeing more.

3ds Max only displays three decimal points for me... I don't know if that's just a setting that could be changed, or if it's a limit of the version I use. (3ds Max 8... no, not 2008. 8.) I usually use the snap toggle to have vertices overlap exactly, but even so, giving it a range three decimals or less would be safer. 0.01 sounds too broad to me, though. That's one centimeter, so accidental overlaps could happen. I'd say something between 0.001 and 0.005 should do it.

For the model I was working on, with the shadow issues, I did have the shoes detached from the torso:

...and I haven't noticed any problems. I did just notice the same problem with the upper arms on mine, though.

Also, out of curiosity, what model(s) are you using for Mira there?

We've fixed the issue (either the face normals or plane distances) and uploaded a fixed version (now it's MDLOps 0.7 Alpha 2).

Ah, that's great! Thanks for the update.

Yeah, I noticed the shadows were coming from the bones. I was wondering about that. Like I said, though, I was still getting shadows with 0.6. And I've done it before without ever losing shadows. So I don't think it's a result of my messing... or not exclusively my messing, at any rate.

I hadn't touched the bones when I tried running it through Taina's Replacer, so I could try that later. Might not have access to the files for the rest of the night though.

Hadn't done the retexture yet... but the original model was PFBAM (in K2). The texture mapping is more or less the same, just the feet and the neck different.

All right... it's still a WIP though, so don't judge.

https://www.dropbox.com/s/nmd8lzq2hruh6w1/JC_HandA-ascii.mdl?dl=0

Nope, neither of those worked.

And I just tested again to be sure... converting with MDLOps 0.6 does produce shadows without editing the ASCII at all.

Sure:

node skin Torso

  parent JC_HandA

  position 0.0 0.0 1.11

  orientation 1.0 0.0 0.0 0.0

  wirecolor 1.0 1.0 1.0

  alpha 1.0

  ambient 1.0 1.0 1.0

  diffuse 1.0 1.0 1.0

  specular 0.0 0.0 0.0

  shininess 0.0

  bitmap JC_HandA

  verts 564

That's great work, guys. I can't understate the amount of mod ideas I've given up on because of smoothing issues, or the amount of time I spent looking through models in a hex editor to see if I could figure out the issue, to no avail. So this is a real boon to the community.

However... yes, of course there's a however...

However, I have a bug to report. I just edited a body model, and while the smoothing was retained very nicely, I noticed that the model's shadow is now gone, as you can see below.

There's the head's shadow, but the body's shadow is nowhere to be seen. Converting the model with version 0.6 does not result in this problem, but of course I lose the smoothing that way.

I've yet to determine if I can get around this using Taina's Replacer, but even so it would be nice to have it all in one package. (EDIT: Taina's Replacer did NOT work. Same problem.)

Since 0.6 didn't lose the shadow, I'm hoping it's just something missing from 0.7 that can be added back in.

Yes, it is. Did I not mention that? Bah. I'll mention it in the next one.