59 réponses à ce sujet

[Clyordes]

:O:O
It works - thanks Lance!  
I tried it in my testing area on a specially trained stunt dinosaur - perfect.

Tried it in the area of the adventure where Mr Snippy resides & right on cue, he trundles down the hill to find out who's making all the noise.

Fantastic.

Now if I can just keep away from booting up XCOM for a few more dev hours to re-run the entire adventure and sort out what I hope is a minor issue with a conversation that's supposed to reward a party member with permanently raised stats - but doesn't - I'll be done - new bugs permitting.

And did I hear recently that people are having trouble getting things onto the vault?  

Not to worry, there's always the Nexus.





Oh no - the Sectoids are coming!

Cly.

[Tchos]

Okay, just a little followup -- were you testing this on a saved game instead of a new game? If that were the case, then Lance's code fixed it because of the change that set the "done" variable on the trigger rather than on the module. A saved game where you already entered the trigger would have the "done" variable already set to the tag you specified, and the trigger code would never run again unless you changed the tag or reset/deleted the variable on the module.

[Lance Botelle]

Tchos wrote...

Okay, just a little followup -- were you testing this on a saved game instead of a new game? If that were the case, then Lance's code fixed it because of the change that set the "done" variable on the trigger rather than on the module. A saved game where you already entered the trigger would have the "done" variable already set to the tag you specified, and the trigger code would never run again unless you changed the tag or reset/deleted the variable on the module.

Hi Tchos,

I imagine Cly would have been testing a new module (because I don't think you can do what you suggest unless testing via a hak/override), and my guess is that it was the ClearAllActions function more than anything else that helped the situation. Cly could try commenting out the ClearAllActions line to see if that is what made the difference. That said, this would also suggest there is a potential for the scorpion to possibly have their stack messed with again at some point, thereby (possibly) making the problem re-occur. Hard to tell what the problem is without seeing what else is going on in the area/module. (I only did the test on the trigger itself because I don't like placing all the variables on the module ... just a personal preference.)

Cly ... Good to hear the script resolved your problem.  I know what it's like when you have things not behaving properly.

Lance.

Modifié par Lance Botelle, 24 octobre 2012 - 12:05 .

[Tchos]

I'm not sure what you're talking about that can't be done, but I'm just talking about testing a module, saving it in a certain area, then reloading that saved game after making some change for testing. I've done that in the past, and I was advising against it for many reasons, including the ones I mentioned.

[Lance Botelle]

Tchos wrote...

I'm not sure what you're talking about that can't be done, but I'm just talking about testing a module, saving it in a certain area, then reloading that saved game after making some change for testing. I've done that in the past, and I was advising against it for many reasons, including the ones I mentioned.

Hi Tchos,

EDIT: Ah! I just understood what you mean Tchos. Let me explain what you and I are both saying in detail to Cly for clarification:-

When you save a game, you save an entire copy of the module in its current state. When you make any changes to the module in the toolset and save it in a new version, reloading a saved game will NOT show those changes unless you make the changes and place the changes in a hak or an override.

So, taking the above example, if Cly was making changes in his toolset and saving it, if and when (as you suggest) he reloads a saved game, then of course there will not be any changes because he is reloading the older module with all its saved variables! You can ONLY ever test comfortably by restarting the game from new, to ensure all variables have been reset.

If Cly only ever tests by making changes and reloading, then he will always have the same problem! As the variable will be set on the trigger just as surely as it was set on the module ... and reloading any save game where a variable has been set will always have that variable set, no matter what you do in the toolset.

Do you see what I mean?

If anybody else has been testing their "saved " games the way you describe, then they are surely going down a path of illogical testing and will run into all sorts of problems. Do a quick test on any module setting a variable on any object (module or trigger) and you will see what I mean.

IN BRIEF: Always test code changes by restarting the module from fresh! (Unless using a hak/override.)

Cheers!
Lance.

Modifié par Lance Botelle, 25 octobre 2012 - 11:08 .

[Tchos]

Okay, and now I understand what you were saying.  You're right, there wouldn't have been such a fine distinction in this case, since none of the changes would have shown up at all.

There's one additional place where changes will show up, along with the hak and the override folder, and that's the campaign folder if you're using a campaign.

[Lance Botelle]

Tchos wrote...

Okay, and now I understand what you were saying.  You're right, there wouldn't have been such a fine distinction in this case, since none of the changes would have shown up at all.

There's one additional place where changes will show up, along with the hak and the override folder, and that's the campaign folder if you're using a campaign.

Hi Tchos,

Funny enough, I am writing a campaign ... and the campaign folder is exactly where I will make changes if need be in the future for players (as a patch).  I used to use a hak in the "old days".

Cheers,
Lance

[Clyordes]

Er - WIBBLE? 

Actually, I think that was pretty well explained - thanks both of you!

To answer - I (amazingly) worked out fairly early on that when testing I needed to start the module afresh every time I'd made changes in the toolset, in order for them to show up in the 'game' itself.  For once, it seemed quite intuitive that any changes in the toolset wouldn't be carried over to a saved game in NWN2 itself.

Cor - I actually realised something useful myself for once!

So I'm still a tad baffled why a march copy of my module file would cause old scorpy to ignore my script compared to a more recent copy.  The only thing I can see that's changed is the HAK.  The old version used a group of HAKs - Various creatures, various RWS ones, scimitars & a few other things.  The new one uses a combined HAK taking the bits I needed from the various other HAKS - I was hoping one HAK to download would be more user friendly than 5 or 6 seperate downloads.

Both are set up as campaigns in order to use the party editor.

But, as far as I'm concerned - its working.  Or at least that is, and I've also changed the priestess' conversation so stats are increased in a different way - which works fine.  Hopefully this weekend I'll get to run through the adventure with my brother via LAN - to see if multi player works OK & see what other issues are thrown up.

Then I'll have to decide where I'm going to upload it.  Hope the vault is still live - I've not gotten my head around the Nexus yet.

Cly.

[Tchos]

Glad to hear we'll get to use the party editor!

Since campaigns are involved, that's one possible thing to watch for duplicates. I don't know if it's possible to accidentally create a resource (such as a script, blueprint, etc.) with the same name in both the module and in the campaign folder, but if it is, then the one in the campaign folder will override the one in the module folder.

Upload to both places! If you need help with the Nexus one, I'll help you through it. I know that place like the back of my hand by now.

[Clyordes]

Thanks Tchos, I may end up taking you up on that. I'd really like to update the other modules I've got on the vault so they flow together as series of linked adventures before I upload anything else, but I don't know how likely it is that I'll get the time.

Cly.