skacky on 6/12/2015 at 13:48
I'm having some pretty big issues with the objectives in my mission. I have 7 goals which are as follow:
0: Steal some object (it's a No Type objective that gets cancelled)
1: Go to a room (invisible until triggered, final)
2: Steal loot (normal / optional)
3: Steal loot (hard / optional)
4: Steal loot (expert / optional)
5: Don't kill bystanders (hard)
6: Don't kill anyone (expert)
7: Return to your starting point (it's a No Type objective that gets cancelled)
So, by reading a scroll, objective 0 and 7 become inactive, and 1 becomes visible. I have three QVarTraps CD'd by this scroll. They are:
=2:goal_state_0
=2:goal_state_7
=1:goal_visible_1
The problem I have is that when I read that scroll, objectives 0 and 7 become inactive and 1 becomes visible, but objectives 2 to 4 become inactive as well AND objectives 5 and 6 get ticked off as complete while they are, naturally, reverse objectives that should be completed only when I reach the room of objective 1. As soon as they are ticked off the mission ends, while the final objective (1) has an empty box. The weirdest thing is that this also happens on Normal difficulty where there is no kill restriction.
I'm not too sure what I'm doing wrong here. Anyone here to help a taffer in need?
Yandros on 6/12/2015 at 14:52
I've encountered this many times before. QVarTraps all linked simultaneously actually get processed with some tiny delays in a particular order (based on the link IDs or order probably) by the engine. So if 0 and 7 are cancelled by Dark before 1 is made visible, then for a tiny instant all visible goals have been fulfilled and the endgame is triggered, even though 1 is visible and incomplete by the time you can check them. Try directly linking to the =1:goal_visible_1 trap to insure it gets triggered first, and then put a very short delay (50 msecs) between the trigger and the other two traps for 0 and 7. That should at least prevent the mission from ending.
As for the loot goals, since they have _optional set on them, that would explain why they get marked as canceled when all other conditions are met.
skacky on 6/12/2015 at 15:11
Thanks, CD'ing two RelayTraps themselves CD'ing the inactive goals fixed the issue. I tried the opposite (one RelayTrap on the invisible goal) and that didn't work earlier, hence why I didn't try that.
Can't believe it was that simple. :tsktsk:
Yandros on 6/12/2015 at 21:14
Well, that works I guess but is a bit of a kluge - I'd recommend actually using a specified delay on an NVRelayTrap or a TrapTimedRelay if you're not using NVScript (although why wouldn't you?)
...
* And then I realize your mission is probably for TG and there is no TrapTimedRelay, so you should use NVRelayTrap. A single trap with two copies of the script (and the delay given on only one of them), and two link flavours to differentiate, would work fine here.
john9818a on 6/12/2015 at 22:55
I wouldn't rely on just the double RelayTrap because you are depending on your own PC's processing speed. I might be wrong but I feel it will be hit and miss on player's PCs. I agree with Russ to force the order of the events to occur when you want them to occur and put short delays on the traps for 0 and 7.
