[ForeignAnomaly]

Alright, so I have two events that (according to the wiki) should correspond properly and spit out a simple variable-based outcome. The goal is to have a message sent when all 4 fighters from a hostile wing are detected as destroyed via variable usage (I am aware there are infinitely easier and faster ways to accomplish this; I'm just wading into the variable section of FRED now and wanted to try something easier at first.) The events are as such:

Code: [Select]

Event 1
 --> when-argument
  -->any-of
   --> Red (fighter designation) 1, 2, 3 and 4
    --> is-destroyed-delay
          (0)
          (<argument>)
     --> modify-variable
      --> Destroyred(0)
       --> +
        --> Destroyred(0)
         --> (1)

The event that calls on the Destroyred variable is laid out as:

Code: [Select]

Event 2
 --> when
  --> =
   --> Destroyred(0)
    --> (4)
     --> send-message
           (#Command)
           (High)
           (Message Name)

I figure this is likely a beginner's trivial mistake and as such is easy to solve, but after several hours of try-and-fail, I've gone braindead. Thanks in advance for any advice.

[General Battuta]

I'm guessing what happens is that as soon as one fighter (say Red 1) is destroyed, the event fires?

You forgot to invalidate-argument <argument> in the first event. It should go at the end. Right now, Red 1 remains a valid argument once it's been destroyed, so the variable increases infinitely (or until the event runs out of trigger count).

Add that missing invalidate-argument <argument>, set to trigger count 4, interval 0, should work fine.

[ForeignAnomaly]

That did it, thank-you sir. I presume that from now on, the trigger count has to be the same as the 'any-of' extensions (i.e. Red 1 to Red 8 would call for a trigger count of 8?) Also, should the interval always be set at 0, or does adding an interval create a delayed effect of sorts (or am I missing the mark entirely?)

[General Battuta]

Increasing the interval above 0 basically says 'once the event has triggered, wait this long before it's triggerable again'. You don't want that here because if two ships died within the same second, you want them both counted!

[ForeignAnomaly]

Aha, gotcha.

[FelixJim]

Increasing the interval above 0 basically says 'once the event has triggered, wait this long before it's triggerable again'. You don't want that here because if two ships died within the same second, you want them both counted!

They would still both get counted, surely? The second one would just get counted later.

[karajorma]

Yeah, it would be counted later. But this could throw off any messages you are generating by having them report the wrong number for Destroyred. The message

Code: [Select]

You have destroyed $Destroyedred ships

could easily report the wrong number of ships if it is triggered during the 1 second interval.



With any-of the issue isn't as bad as it would be with random-of, random-multiple-of or sequence-of though. Those SEXPs can only trigger for one argument for each repetition. If you change from an interval of 0 to 1 and have a long argument list you could change things from happening in a second to happening several seconds or minutes after you expected them to.

[General Battuta]

Increasing the interval above 0 basically says 'once the event has triggered, wait this long before it's triggerable again'. You don't want that here because if two ships died within the same second, you want them both counted!

They would still both get counted, surely? The second one would just get counted later.

It's not a good habit to be in because you use the same structure with SEXPs like primary-fired-since or whatever it's called - ones that look not at 'has this happened' but 'has this happened within the last few milliseconds'.

[FelixJim]

True, I agree having an interval here is not a good idea, I just thought Battuta's reasoning was a bit misleading.

[karajorma]

That said, it is worth being aware of overusing the 0 second interval. The amount of time the game spends in the SEXP system is not negligible and anything that cause the game to have to repeated calls to the string comparison functions (pretty much any SEXP involving the name of something calls it at least once) can actually slow the game down.