multi-condition triggers and debugging

[acidcrash 0]

Ok guys, I'm way out of touch with scripting, so there will no doubt be a more efficient way of doing this than what I'm trying!
 
I'm trying to create a 3 condition trigger that I can debug by way of a radio trigger to see which conditions have been met. 
 
Condition 1: Is a certain character alive?
Condition 2: Has players faction been detected?
Condition 3: Has an action been performed? (a power switch)
 
There are individual triggers for condition 2 and 3 (#2 simple bluefor detected by opfor with on activation of bluefordetected = true and #3 addaction trigger with condition of bluefor being present, activation: player addAction ["Turn off power", "power = false'") The initial state of power and bluefordetected are set in player char init (will do in init.sqf when I get around to it) (looking for a way of removing the action once used too which I thought removeallactions player would do)
 
There are eight possible variations, so I have for debugging purposes created eight radio triggers with the conditions for that permutation.
 

this && ((!alive teamleader) && (bluefordetected isequalto false) && (power isequalto false)) 

So, the radio trigger & the character is not alive, player faction has not been detected and the trigger power switch has been set to off.
 
They all have individual radio triggers to check if they are set to true/false (or alive/dead) which work fine and the combined conditions check also works fine. The only issue is, there has to be an easier way of doing this that isn't so trigger intensive? (both for my debugging purposes and for the actual purpose I'm trying to achieve)

 

 

Link to mission file

[rübe 127]

First I'd suggest to create an "init.sqf" file which get's called before the mission starts. Then you can put things like this:

init="recon = group this; power = true; bluefordetected = false; power = true";

there instead.
Guess the "recon = group this;" part is fine, but power (listing it once should be enough) and bluefordetected stuff does not really belong here.
 
Now that you have an init.sqf file with something like this:

power = true; 
bluefordetected = false;
// ...

you can for example spawn a thread for debug purposes that monitors these conditions.
So instead of having all these triggers with stuff like this:

expCond="this && ((alive teamleader) && (bluefordetected isequalto true) && (power isequalto true)) ";
expActiv="hint ""Teamleader is alive, they know you are here and have power""";

you could make live way easier by simply spawning a single thread that writes the state of your mission to the RPT file. Keep some tail-tool running (BareTail for example) to watch the output while playing, given you have a second monitor or are testing the scenario in windowed mode.
Or, if you like that better, make use of hintSilent. Anyways, this could like this (in the init.sqf file):

[] spawn {
   while {true} do
   {
      diag_log text format["alive: %1, detected: %2, power: %3", (alive teamleader), bluefordetected, power];
      sleep 2;
   };
};

Adjust the delay (sleep x) as you like.
If there's indeed a need to be notified only if these values change, then simply keep a private copy and then only hint (or diag_log) if one has changed. E.g.:

[] spawn {
   _power = power; // private copy of initial/current state

   while {true} do
   {
      if (_power != power) then {
         hintSilent format["POWER: %1", power];
      };
      _power = power; // update last known state
      sleep 2;
   };
};

You get the idea...


Anyways, once your scenario/mission logic starts to deviate too much from a linear story (or get's too complicated otherwise...), I'd really encourage you to start looking at FSM and making good use of them.
FSM are really awesome to handle the flow of a mission (or other actions) and they're easy to use too. Which could look something like this:
 

 
Note how:

• The mission can be completed by being detected first, then the power goes out (1), by killing the power first and then still getting detected (2), or by killing the power and not getting detected at all (not the transition to "stuff").
• The power has to be cut off, or "stuff" can't be done and the mission never be completed.
• There is a transition to the dead teamleader from all intermediate states, and then the mission is lost.
• Put debug hints (and code - of course) in any state you like.

 

Give it a try, FSM are really the best for mission flow. It's easy, fast and fun too! :)