Does anyone know or have experienced triggers firing when their conditions have not even been met?
I know that appears insane, but I have a trigger (in a large area) that triggers an encounter event even before a player has entered the trigger.
Anyone any ideas?
No technical ideas other than you’ve got the script on something else too, but for the mechanical options I’d go through all the triggers and make sure I didn’t have one which is just a line or a dot that I put in by accident and has the same name etc. If not then I think there’s only one option, delete it and make a completely new one.
I can’t say for sure because this is NWN2, but NWN1 has this bug.
Certain areas are causing certain triggers to fire when nobody is inside them. This includes traps, area transitions and generic triggers.
There are two things you can do to battle this, but you cannot eliminate it completely.
//1.72: fix for bug where traps are being triggered where they really aren't if(GetObjectType(OBJECT_SELF) == OBJECT_TYPE_TRIGGER && !GetIsInSubArea(GetEnteringObject())) { return; }
Again, this is happening in NWN1, whether the same issue appears, and the same countermeasures applies, in NWN2 is not guaranteed.
Thanks for responding guys!
I am 100% certain that I do not have any rogue triggers. Furthermore, this only happens sometimes anyway. It is most peculiar. I have even redrawn this trigger a number of times in the past, just in case it’s broken somehow. (See my response to Shadooow next too.)
I believe there must be a similar related issue with NWN2 triggers as there are in NWN1 by the sounds of it. I too, had in the back of my mind, that area elevation may have a bearing, but is not something I have the time or patience to test. The issue only happens now and then.
I am also thinking there may be a small chance that this trigger is triggered in some way when the area loads and the PCs are entering the area. As if they pass through it on their way to where they should be upon arriving at the area. I remember that creatures can appear in the top left corner (if separated from the party due to a bad transition), and wondered if the whole area load routine actually does somehow pass through this area location before dropping the PCs where they should be.
As it happens, this trigger is near the top left corner of the area, and I am wondering if that is also contributing towards the issue. I am going to add a variable on the trigger to prevent it from firing until that variable is cleared - which I will now clear a second or two after the PCs have entered the area. I will only add this delay check on some triggers, and not ones where I want an instant on enter response of course.
I think (if my theory is correct), that may also explain why checking if a creature is within the sub-area may still sometimes fail to detect the problem, as they are (arguably) still passing through it on their way to where they should be. Being a “larger” area may also be contributing towards the trigger false activation.
I’ll report back in any future testing to let you know if this did not work.
EDIT: I am now considering setting all encounter triggers to “INACTIVE” and only making them “ACTIVE” when I intend to use them, as follows … My encounter triggers have unique tags.
object oENC = GetNearestObjectByTag(sEncounter, OBJECT_SELF);
SetEncounterActive(TRUE, oENC);
It"s firing beceause something else is entering it, or maybe it doesnt need to be entered to launch the script depending on what you are doing, or if it is really launching alone, you need to alter the script so it stop if it shouldn’t be fired, but I have nevers seen the case.
But NWN2 can be full of surprise.
Thanks for responding. 
No, nothing else but a PC (or party member) can trigger this trigger … The function GetMainPC checks if the entering creature is owned by a player. (I have a theory I am working on - see above.)
// FIRE FOR ANY PARTY MEMBER
object oPC = GetEnteringObject();
if(GetMainPC(oPC) == OBJECT_INVALID || GetIsDM(oPC)){return;}
One of the 2 condition is returning something “>0” when something cross the trigger.
Try this line on top
SendMessageToPC(GetFirstPC(FALSE), GetName(oPC) + " IsMainPC: " + IntToString(GetMainPC(oPC) + " isDM: " + GetIsDM(oPC))
And see which one return something above 0 and what object triggers it.
The error is happening in my wife’s SP test game (no DM), and so it must be related to a valid party member.
You may want to try this approach for NWN1 as well …
I am setting all encounter triggers properties (in a problem area) “Active” to FALSE. Then, only switching them to “Active” as TRUE at the time of triggering.
Note, I can do this because I have a standard trigger that calls the encounter trigger when it is required. However, I see no reason why a builder could not set all encounter triggers as “Active” as FALSE and then reactivate them with another trigger on after a full area entry check anyway.
This is also working on the theory that the triggers are erroneously “entered” and “triggered” as a player enters an area. This is more likely to happen with larger,undulating areas, and possibly where triggers are located in the top left corner of such areas. NB: I am also highly suspicious of any trigger passing a PC in error, including standard and trap triggers. Therefore, one may need to consider only turning some trap triggers “Active” this way too, as well as adding some check to standard triggers.
I’ll update this post again if after further testing this method fails to prevent the issue. If you don’t hear from me again, hopefully it means this sorted the issue.
For myself, I have added the following:-
Nope. That is not possible. It is clear with traps as the player gets damage despite he is nowhere near the trap.
This isn’t some assumption of mine. This bug is well documented. But it applies for NWN1. Whether the same bug exists in NWN2 I do not know and is just a speculation on my part. But it is likely given the similarities within the both games hence I mentioned this in first place.
Let me know if it helped you, because I know for sure that this is useless solution for the bug in NWN1. In NWN1 it has nothing to do with entering area, the bug manifests as triggering trap/area transition completely randomly in middle of area. And while it seems random, it is in fact very specific - players are just unable to reproduce it consistently, because the trap might trigger on very specific coordinates that players rarely move through again.
Also I don’t think that this issue is plaguing encounters in NWN1, just traps,area transitions and generic triggers. I am not 100% sure as I never tested this specifically and randomly activating some encounter in middle of area that spawns npcs behind or way ahead of you isn’t that straighforward to realize, but don’t think so. You do know that it affect encounters too?
I keep having this issue with overland map triggers firing off at seemingly random times.
A few observations: it was the same few triggers that kept on firing randomly. After doing some retexturing and redrawing triggers, the issue persisted, but it was different triggers that misfired.
Simply running a check to see if the entering PC is actually in the area by comparing location of PC to trigger sometimes works… but sometimes not.
At one point I had the entry trigger comparing OBJECT_SELF to GetNearestSubArea, and it returned an invalid match. However, when comparing names (and the names were unique), they were the same, so somehow it was confused into thinking it was a different object, but GetName() returned identical names (and again - they were unique names). Which is to say, it’s a weird bug.
My fix was to set the entry script to set OBJECT_SELF as a local object on the entering PC, then fire off the actual script with a 0.01s wait, where it runs a check to see if the local object it set is indeed OBJECT_SELF or not, and if not, aborts.
It’s overland map code, but you should be able to figure out what’s important pretty easily. Relevant parts of first script look like this:
object oEnter = GetEnteringObject();
location lLocation = GetLocation(oEnter);
object oArea = GetAreaFromLocation(lLocation);
object oTrigger = GetFirstSubArea(oArea, GetPositionFromLocation(lLocation));
int i=0;
while ( GetTag(oTrigger) != "nx2_tr_terrain" && GetIsObjectValid(oTrigger))
{
oTrigger = GetNextSubArea(oArea);
}
if (oTrigger != OBJECT_SELF)
{
SendMessageToPC(oEnter, "1: Trigger mismatch, attempted script for: " + GetName(OBJECT_SELF));
return;
}
SendMessageToPC(GetFactionLeader(oEnter), "1: Current trigger: " + GetName(OBJECT_SELF));
SetLocalObject(GetFactionLeader(oEnter), "oAttemptedTrigger", OBJECT_SELF);
DelayCommand(0.01, ExecuteScript("nx2_tr_terrain_en_actual", OBJECT_SELF));
And for the actual entry script:
object oEnter = GetEnteringObject();
location lLocation = GetLocation(oEnter);
object oArea = GetAreaFromLocation(lLocation);
object oTrigger = GetFirstSubArea(oArea, GetPositionFromLocation(lLocation));
int i=0;
while ( GetTag(oTrigger) != "nx2_tr_terrain" && GetIsObjectValid(oTrigger))
{
oTrigger = GetNextSubArea(oArea);
}
if (oTrigger != OBJECT_SELF)
{
SendMessageToPC(oEnter, "2: Trigger mismatch, attempted script for: " + GetName(OBJECT_SELF));
return;
}
SendMessageToPC(oEnter, "2: Current trigger: " + GetName(OBJECT_SELF));
if (GetLocalObject(GetFactionLeader(oEnter), "oAttemptedTrigger") != OBJECT_SELF) // Fix to get around a weird bug with misfiring triggers. No, it doesn't make sense, but neither does the bug.
{SendMessageToPC(oEnter, "Trigger issue."); return;}
Since implementing this I haven’t had any actual misfirings of entry scripts (debug code shows it attempts them still occasionally, but the failsafes prevent them from actually running the relevant code), nor have I ever had a trigger not run when it should. I’m not 100% sure the delay is actually needed, there was thought behind it and I had intended to test it, but… it works, and that did an excellent job ruining my interest in figuring it out further. Hopefully it’ll help out.
My “entering the area” causation is just a guess at this stage. All I know is that it is “consistent” when it happens, and there is no “obvious reason” for it to do so. Another thought is that somehow a trigger thinks it has been entered at some “rogue point” somewhere. I have now given my wife’s game some extra feedback to alert us when these creatures are spawned, playing from a saved game point prior their existence. In my own test of the same, I could not get the creature encounter trigger to spawn again … no matter whether I entered the area or not, but I was using the new “fixed” scripts. She is going to be running the same test again without some of the additional fixes. Neither of us have tested with the extra “Active” as initially FALSE step.
While it has not yet manifested in your encounter triggers, the principle appears to be the same, or at least similar. And in this case, my “encounter trigger” has an extra step prior its calling via a generic trigger of my own, so that may still be a valid point. I.e. If the generic trigger “failed” (by firing too soon), then it will also fire the encounter trigger.
In the way I currently have some of these encounters setup, I have no issue with activating an encounter trigger prior its calling. That’s why I can add this additional step in my testing, but that will be for a new module with them set “Active” FALSE already.
Thanks for the feedback and the scripts.
Yes, I am beginning to think the same, as there is no real consistency, but there is too. 
Well, this sounds promising. Although, I confess, at first glance, I cannot fathom what it is that works exactly in these scripts. 
I need to take a closer look at what you are doing to see if anything stands out… perhaps when I am less tired. Although, it does make me consider valid location checks as well.
Also to say, my wife has just replayed from the saved position with one of the fixes in place (the delay that prevents a trigger from firing until the PCs are in the area proper) (*), and did not have the issue again. So that is two of us who have played from the saved game without the issue raising its ugly head again … but, we all know that may not mean it’s totally fixed, as it is a little bizarre what actually triggers the trigger issue in the first place. 
(*) But, as @Shadooow says, it may also not be anything to do with area entry and just be some rogue element of the trigger that is somehow triggered from some weird location. Again, I’ll monitor this and let people know.
If it doesn’t make sense, it’s probably because the bug itself is a bit illogical. If we simplify it, what I do is:
object oEnter = GetEnteringObject();
SetLocalObject(oEnter, "oAttemptedTrigger", OBJECT_SELF);
This sets the trigger as a local object on the entering object (the PC).
Then we fire up the next script with:
DelayCommand(0.01, ExecuteScript("ActualEntryScript", OBJECT_SELF));
This makes OBJECT_SELF (the trigger) run the actual entry script.
And in there we have:
if (GetLocalObject(oEnter, "oAttemptedTrigger") != OBJECT_SELF)
{SendMessageToPC(oEnter, "Trigger issue."); return;}
Which means it’s comparing the local object it just set (which was itself) with OBJECT_SELF. It’s illogical, but since the issue seems to be the trigger getting confused about what object it is, it seems to work.
I also have the location checks in there as you can see, as I figure extra checks can’t hurt. Sometimes when a trigger misfires it fails the first location check, sometimes the second, and sometimes it fails on the third check. All three together seem to prevent the actual code from running though.
As for consistency, it’s definitely all over the place. Some times I’d have it happen constantly, other times not at all, it’s quite random. It’s probably a lot more noticeable on overland maps though since those are covered in triggers all over, which presumably means more chances of it happening.
OK, thanks for explaining your scripts and reasoning a little more, That did help.
I will consider this approach as a back-up if the current alterations I have made fail. As you know, it may take some time to “prove” one way or another, as the failure is sporadic. That said, I won’t hesitate to try something new if the bug rears its head again.
Thanks again all!
I’ll report back in this thread if I have any more failures.
Also, if anyone else had had any strange results, please post here too. Thanks! 
consider adding a delayed DeleteLocalObject() so the entering-object doesn’t get cluttered w/ refs to triggers … (possibly causing an unwanted match/mismatch later, though that seems unlikely)
you know, just 0.3 sec or smth
Does it actually clutter it up, rather than simply overwrite it? But nonetheless that’s probably a good idea regardless, thanks for the suggestion.
That’s actually quite a lovely idea that while the load screen is playing the party is rushing about to get to it’s starting point and pretend that nothing was happening and they’ve been there all the time… But the spawned creatures have given the secret away.
This is all very strange and I’ve never heard of it before, I’ve only ever had triggers that didn’t work !
Good luck and happy hunting.
yeh I misworded that … → don’t clutter (potentially) a bunch of (mysterious) entering-objects with refs to the trigger
Ah, it’s actually after a check to see if it’s a PC entering (NPCs aren’t really a big deal if they misfire here), so it’s probably not an issue, but I don’t like keeping things around unnecessarily, so it’s probably worth deleting still.
i agree its bizarre (how can entering-object not be entering-object)
/anyway