Trigger count
Trigger count is a SCP feature developed as an alternative to repeat count, intended to function in a more intuitive fashion. Essentially, trigger count exists because repeat count doesn't do what a lot of people think it does. The bulk of this article comes from a post on the HLP Forums by Karajorma.
Quick explanation
Repeat Count - When a repeat count is set, the repeat delay is the time when the event will next be tested. A repeat delay of 10s means that the event will be tested at 10, 20, 30, 40..... seconds after the first time the SEXP is triggered.
Trigger count - When a trigger count is set the game waits the repeat delay and then sets the event back to being checked every frame until it is triggered again, when it waits the repeat delay again.
Longer explanation
I'll give an example of a SEXP and how you'd solve the problem in the past (using repeat count) and how you can solve it now using trigger count (or both).
Let's suppose I have a target ship in a mission. If Alpha 1 is less than 100m from the ship I want a message sent every 10 seconds. I set up this event.
|
Player near Target
when |
|
Repeat count = 9999999, Trigger count = 1, Repeat delay = 10
|
That probably seems reasonable, but if you ran it, you'd find it didn't work. What would happen with this event is that the player triggers the event after 5 seconds the first time by flying into range. 10 seconds later, the game checks if the player is in range again. If he is, another message is sent. Regardless of whether the message is sent or not the game now waits another 10 seconds to test again. In other words: if the player flies within range 13 seconds later and back out again 19 seconds later they'll miss the test 20 seconds after the SEXP triggered and won't get the message sent.
In the past, the solution was something like this.
|
Player near Target
when |
|
Repeat count = 9999999, Trigger count = 1, Repeat delay = 1
|
|
Reset Message
when |
|
Repeat count = 9999999, Trigger count = 1, Repeat delay = 1
|
Basically repeat count is simply being used to make the game check the event every second and the FREDder has to manually tell it to wait 10 seconds before checking by using a combination of variables to manually add the initial 10-second delay. But why should the FREDder have to tell the game to wait 10 seconds? Wouldn't it be nice if we could get the game to do all that for us instead? That's what trigger count does. It tells the game wait the amount of time specified in the repeat delay and then trigger normally. Here's the same event using trigger count.
|
Player near Target
when |
|
Repeat count = 1, Trigger count = 9999999, Repeat delay = 10
|
Notice how that is exactly the same as the original event except that I've swapped the trigger count and repeat count around? Trigger count works in the way many people think repeat count works.
As for using both together, yes you can, but it's really just a side effect of the way both work rather than a deliberately designed feature. Suppose we have a situation where you do want to check only every 10 seconds and want to stop sending messages after 3 have been sent regardless of how long it takes to get those three. Well in that case, you can either use a variable as a counter or you can do this.
|
Player near Target
when |
|
Repeat count = 9999999, Trigger count = 3, Repeat delay = 10
|
When both are specified, the repeat count takes precedence. The game will test at 10-second spaces. But due to the fact that the game decrements both counts every time the event triggers you can use the trigger count as a built-in countdown counter for how many times the event has triggered. As soon as it reaches 0, the game won't trigger the event anymore, regardless of what the repeat counter is.
