21 réponses à ce sujet

[andysks]

I am starting this topic for a second time, because it's driving me nuts. The ga_lock is quite straightforward, yet it fails me like nothing else does. To take the matter from the top:

 

I have a door, which is locked. When clicked, a conversation starts. Through the conversation, it can be unlocked.

 

Here is what I've tried:

 

First of all, the gp_talk_door didn't work, so I made this, which actually fires a convo with an ipoint placeable. It worked.

 

void main()
{
    object oPC = GetFirstPC();


    object iPointSpeaker = GetObjectByTag("ips_door_hideout");
    AssignCommand(oPC, ActionStartConversation(iPointSpeaker));
}

 

On the conversation itself now, since this is solved. (However, gp_talk_door is bugged? No idea but I don't care since my script made it work after all ).

 

ga_lock with params "dr_doc_thug_out" , 0

Not worked.

Fine, I made mine.

 

void main(string sTag, int bLock)
{
    object oTarget = GetObjectByTag(sTag);

    SetLocked(oTarget, bLock);
}

 

Same params, didn't work.

Went to Lilacs:

 

void main()
{
    object oTarget;

    // Get the PC who is in this conversation.
    object oPC = GetPCSpeaker();

    // Unlock "dr_doc_thug_out".
    oTarget = GetObjectByTag("dr_doc_thug_out");
    SetLocked(oTarget, FALSE);
}

 

Nope. The only common things all these have, is that they try to unlock the same door, and use SetLocked. I checked the tags a thousand times and all are fine. Also, in case it matters, I've tried to make the door locked, with DC 200. Tried locked with key required, but the key tag blank, tried all together... nothing seems to work. What's going on ?

 

is it maybe that the ipoint placeable trying to unlock the door can't work? Shouldn't matter, it's just a conversation... Anyway, any ideas appreciated. Thanks a lot!

 

Edit: The door is from City Hak. Just in case... But I have set it with hp, saving throws and all.

[4760]

I am starting this topic for a second time, because it's driving me nuts. The ga_lock is quite straightforward, yet it fails me like nothing else does. 

[...]

ga_lock with params "dr_doc_thug_out" , 0

Not worked.

I can't really help, as ga_lock with the parameters you indicate works as expected in my module (through a conversation with an NPC).

 

I know you checked the tags a thousand times, but did you check if maybe there wasn't another door with the same tag?

And just to make sure it doesn't come from the door (apparently, you can't unlock it manually either), what gives with another door?

[Tchos]

Both gp_talk_door and ga_lock worked for me in level 1 of the lighthouse, where you can examine it if you like.  I gave the door a very unique tag to be sure, and I placed the gp_talk_door script in the On Fail To Open slot.

[andysks]

I am just looking at the lighthouse Tchos, and you do exactly the situation that fails me. Only difference, is that I am using a City Hak door, which has reflex and will save of 15 (By default there are all 0, but I put all these attributes to 15 to be certain that a convo will fire), and I don't have the OnDeath slot assigned as the default doors. I will check it out and see how it goes.

[kamal_]

I am starting this topic for a second time, because it's driving me nuts.

A pirate walks into a bar with a peg leg, a parrot on his shoulder, and a steering wheel on his pants. The bartender says, "hey, you''ve got a steering wheel on your pants."

The pirate says, "Arrrr, I know. It''s driving me nuts."

[andysks]

I heard that joke on My Name is Earl . Good one, lol.

 

As for the topic, I recreated the problem on a test area, and it wont work as well. Hmm...

[andysks]

Alright. Test area, on a test module, not on my main work. All worked fine. The news I didn't like...

First was some scripts of KevL, and now this. Something... is interfering with some functions. Something hidden there in my folders and I have no idea where. I guess I need to find it before I continue doing anything else. Thanks for the help though , and the funny parenthesis kamal .

[Tchos]

Just to confirm what you would already suspect, the script I have in the On Death slot isn't necessary for this situation, and in fact is pointless in the place where I have it, since my door is set to Plot and so the On Death can never fire.

 

Is the City hak door included by actually attaching the hak to your module?  Or are there any other foreign hak files attached to your module?  I'd check those to see if they include versions of the scripts that may be changing their behaviour.

[andysks]

I know, I just threw all information there no matter what. Tchos, all the haks I use as I build is Bob's extra item blueprints. Everything else, like placeables, hairs etc, are all in my campaign folder for easy access. And they are a lot! The weird thing is, that KevL scripts for example are custom made. So a duplicate is impossible to exist. It has to be some include, which changes the function? Will see. It has to be in the campaign folder. Or the OC folders? Good luck with that Andy... .

 

Edit: Funny thing is that the problem exists in random (as it seems), functions. Like ga_disease or ga_lock. But the spawn ipspeaker script I created and we were talking about worked flawlessly. The best hint, if I could say, is that the problem happens with ga_* scripts trying to fire from conversations.

 

Edit 2: Another thing that didn't work from convo, is the ga_mapnote. Now I know something screws the conversations. Easier to find it if you know what about you're looking for.

[Tchos]

Well, an include can only change the script if you recompile the script.  As long as you leave it alone, and don't hit "compile all scripts", it wouldn't affect it.  But one function that many of the ga_ scripts use from one of the includes is GetTarget(), if you need a random lead.

[kevL]

the only experience i ever had that is like this, Andy,
is when i started tampering with 'nwscript.nss' -- that's the file that declares all the functions/constants that are hardcoded for use by our scripts.

( just started putting in some of the missing spell-constants, that's all o'really )

a few days to a week later i notice that some scripts no longer fire. It was mind-boggling, I compile enmasse, and everything compiled -- like, everything, no errors. But once 'nwscript.nss' was reverted to the SoZ version and all scripts recompiled the problem disappeared. So,

have you mucked with Nwscript.nss or have an extra copy that might have gotten changed, or anything like that

 

 

 

ps. & The scripts that failed had nothing to do with spell constants ... 

[andysks]

You might have something there KevL. Quite a while back, I was reading the comments on a script (don't remember which unfortunately), and it was saying "as defined on nwnscript.nss." Being the curious cat I am, I think I searched for it, opened it, looked at it... something could have happened. Revered to SoZ version... what do we mean? And also, you said all scripts recompiled... you mean the ones that were not firing right? Even if stock scripts? I never compile stock scripts... not intentionally at least .

[kevL]

there are 3 stock editions of 'nwscript.nss' : they reside under <install>\data\scripts.zip, scripts_x1.zip, scripts_x2.zip

SoZ version is in data\scripts_x2.zip


Now, I don't think you could accidentally overwrite that .... In my case, however, i keep a copy on the root of my F: drive for convenience. Another difference, i keep a copy of all stock scripts in my Override, so when i do extensive changes to #includes, I just set the Advanced Script Compiler to work recursively against my Override folder.

so yeah, perhaps it's a long shot but keep yer eyes peeled; maybe do a search for a stray copy of 'nwscript.nss', that'd be outside of the <install>\data\ folder + .zips


"reverted" -- not revered Lol -- means i copied the file from scripts_x2.zip back to the root of F: and overwrote my (borked) external copy of nwscript ...

[Lance Botelle]

Hi,

Do a debug script that "counts" the number of doors with that TAG in your MODULE.

It is still possible that you have a second rendition of that door off to one side somewhere that you cannot see ...

Alternatively, you could open every area and look at the doors in the area and check their tags, but you could still miss it doing it this way ... I know I have done.

A little story for you:- I had a script that relied on a WP for an area, and when I was working on the script, I found it simply did not behave as expected. It was as if another WP had to be somewhere else, but I simply could NOT find it. So, what I did, was to make my PC JUMP to this "supposed" WP on module entry ... and you know what ... after entering the module, my PC jumped to an area I never expected ... and sure enough, when I checked the module, there was the offending WP!

My point is, using a script to determine/check something for you is MUCH more reliable than checking manually.

EDIT: I have NEVER had a problem with this function. I have had another script revert the locked state unexpectedly, due to a timing error ... like a HB checking a night/day state without putting in an overall state for a door, but that's it.

Cheers,
Lance.

[4760]

A little story for you:- I had a script that relied on a WP for an area, and when I was working on the script, I found it simply did not behave as expected. It was as if another WP had to be somewhere else, but I simply could NOT find it. So, what I did, was to make my PC JUMP to this "supposed" WP on module entry ... and you know what ... after entering the module, my PC jumped to an area I never expected ... and sure enough, when I checked the module, there was the offending WP!

Exactly the same happened to me!

[andysks]

Lance: That could not be the problem unfortunately. The area is just created, and the door the first work I did in it. All other doors are taged PLC_ etc etc. Also, for the shake of testing I gave it a tag of: lockunlockabcdlock. Now, I am certain that such a tag is nowhere else, firstly because it doesn't match my tagging method, and secondly... I mean, come on . It is something in my campaign. Don't know what, but it is there. The scrpts from KevL and these ones, are in different modules, but on the same campaign. It appears to be quite random to be honest.

 

ga_timer_set from Tchos works

ga_move party from ColorsFade works.

ga_add_companion mine, works.

ga_disease from KevL not

ga_mapnote stock script not.

ga_lock stock script not.

 

i am certain that the list can go on, but from this is quite clear that it's quite random.

[andysks]

Could the problem be much bigger that I thought? I was testing a conversation for sripts that would fire or not, and out of hunch I thought I'd put some static cameras as well. They didn't work. To be certain I put one far far away, but the guy talked in a close up fashion. What's this now? My whole conversation system is borked, or am I just being paranoid now ?

[Lance Botelle]

Exactly the same happened to me!

Glad I'm not the only one.
 

Lance: That could not be the problem unfortunately. The area is just created, and the door the first work I did in it. All other doors are taged PLC_ etc etc. Also, for the shake of testing I gave it a tag of: lockunlockabcdlock. Now, I am certain that such a tag is nowhere else, firstly because it doesn't match my tagging method, and secondly... I mean, come on . It is something in my campaign. Don't know what, but it is there. The scrpts from KevL and these ones, are in different modules, but on the same campaign. It appears to be quite random to be honest.<SNIP>

Hi Andy,

I know you said it was an area you just created, and is why I said test a count for your whole module, and not just that area.

As you say, I reckon the chances are highly unlikely to next to no chance, but this is a sure fire method (as far as I have experienced) of convincing me that it really is the only object with that tag in the whole module!

Back to my story ... I think the WP got there by me "accidentally" pasting it by mistake ... or possibly having it on my mouse and clicking where I thought all was fine. I have also used a similar test script to find objects and discovered them at the very corner of an area ... not even in the working environment ... and not even visible! i.e. The objects can be "there" as far as the engine is concerned, but not as far as we builders are concerned.

The other issue might be if you call a lock that door by another script.

Or, as you say, your campaign is borked.

Is the offending section able to be uploaded so we can check it outside of your own testing? At least that would test to see if you might have another issue to do with your computer acting a little awry as well.

Cheers,
Lance.

This should work if you want to try ... Put on a useable lever (On Used Hook) somewhere in your module and pull!
 

void main()
{

	object oPC = GetLastUsedBy();
	
	int iCount = 0;
	
	object oCheck = GetObjectByTag("lockunlockabcdlock", iCount);
	
	while(oCheck != OBJECT_INVALID)
	{	
		iCount = iCount + 1;
		oCheck = GetObjectByTag("lockunlockabcdlock", iCount);
	}
	
	SetNoticeText(oPC, "DOORS FOUND>>>> " + IntToString(iCount));
	SendMessageToPC(oPC, "DOORS FOUND>>>> " + IntToString(iCount));

}

[andysks]

OK. That was just paranoia. Cameras work, maybe it was just that the convo was imported and it already had some cameras set, they might need to be changed completely to function in the new area, and not just give the cameras the same tag as before. Anyway. Some news... good I guess.

 

Same module that had problems, but a test area. One commoner with a conversation to test some ga_scripts. All worked as intended, even ga_mapnote and ga_lock. Because of the previous problems I had with KevL's scripts, I tried firing via different methods, and it seems to work with all. Attaching the convo to the NPC and clicking him, via ipspeaker spawn... all work, all scripts work inside. I guess the problem was that the conversation that has problems is an imported one, and had quite some scripts inside. Maybe these scripts and their tags need to change, in order to function in the new area, and not just create a mapnote with the tag given in the convo. Maybe even rewrite the convo to be certain, we'll see. I still don't know why on the other module the KevL's scripts were failing, but since they work now, on the same campaign, different module... I might be getting close to the solution there as well.

 

Edit: Areas have been reworked, and Lance's script showed some same tags. What I had done, was rework the docks area. Then I imported the old docks area to this module, in order to find where everything was and recreate it. This created same tags all over the place. Case solved, thanks for the help.

Example. Old area mapnote tagged do_mp_hideout, new area same mapnote tag. Since the old area is imported for re-vamping, I guess it enabled the mapnote on the old area.

[Tchos]

Example. Old area mapnote tagged do_mp_hideout, new area same mapnote tag. Since the old area is imported for re-vamping, I guess it enabled the mapnote on the old area.

 

As Lance was explaining, and which may be unintuitive for many modders, scripts operate on every area in the entire module, including areas where the player isn't currently in.  This allows me, for instance, to send an NPC to a different area and bring it back whenever I want, or activate placeables in a different area when a quest begins, etc.  Thus, tags should be unique, unless you're using some other kind of method to get the object, like GetNearestObjectByTag, GetFirstObjectInArea(), or one of numerous other variants.

[andysks]

Yes I know that because I often destroy objects and found out that it works when in different areas. I think one of the few systems that won't work like that is the group system. But then again, I don't really remember which one I use. Could be AddNearestTagToGroup... or something like. So it's all the same after all . It just got me confused because I didn't take into account that the previous area was imported, with all its tags and such.

[Lance Botelle]

<SNIP>Edit: Areas have been reworked, and Lance's script showed some same tags. What I had done, was rework the docks area. Then I imported the old docks area to this module, in order to find where everything was and recreate it. This created same tags all over the place. Case solved, thanks for the help.<SNIP>

Yeh!

I'm glad you ran that script! Those sneaky duplications can get you every time.

Lance.