In retail FS2 (as well as FS1), repeating chained events don't repeat if the next event of the chain has been triggered. (Note that this does not apply to the first event of a chain, since it is not a chained event.)

However, r8603 (which resolved Mantis 0000082) changed this behavior so that such events always repeat, regardless of the status of the next event of the chain. This change potentially breaks missions that rely on retail behavior.

One minor example of this is found in the first FS1 training mission. At one point in the mission, the player is supposed to match speed with the instructor. If he doesn't do so, the instructor will say "Match my speed now" and return to the first waypoint. However, because of the change made by r8603, this happens even if the player is matching speed.

Steps To Reproduce

The attached mission lets you test this. At 0:02, a message will display. That message should not repeat at 0:15. If it does, that indicates incorrect behavior.

Additional Information

This bug is also present in 3.6.14 RC6 (can someone please add that to the Product Version list?).

It looks like Karajorma's r8603 did a little bit more than fix the bug; it also removed part of the chaining mechanism. The attached patch restores it without reverting the timestamp fix. See if that works.

This needs a mod.tbl setting that means repeating events can actually repeat the way the FREDder requested them to, same as I did when I fixed arguments to loop in the way most FREDders expect them to. Having events not work properly simply because they didn't work properly in retail is a bad idea. We should give the user the decision about whether or not they want to support the old broken code, not foist the choice on them.

Oh and I'm highly suspicious about that patch too. I removed that part of the chaining code for when you have 3 events in a row which are chained.

This patch actually fixes the repeat count the way Volition originally intended it, and I've confirmed it in a test. It turns out that none of us, including the SCP coders, really understood the chaining mechanism until Yarn pointed out the behavior of Training Mission 1.

The chaining mechanism is something like having a "current event pointer" that always allows a *single event* in the event chain to repeat, but no others. If the next event in the chain becomes true, then *that event* will be allowed to repeat, and the first event will quit repeating. If any future events then become true, then they will be allowed to repeat, and so on. In this case the mechanism really is like a "chain", because it joins all the events into one conceptual group.

To see an example of the correct usage of a chained repeat ("correct" in the sense that Volition intended, anyway) take a look at the "Match Speed" event in btm-01 in FS1 or the FSPort. This requires learning about the rare feature of training-msg which allows a secondary message to be played if the event repeats. The event is set to repeat two times, playing both training messages, but it is intended for the second message to *not* play if the player successfully matches speed. This is accomplished by having the repeating event stop repeating if the subsequent event in the chain becomes true.

In fact, and in light of this, we now need to re-evaluate whether it's actually correct to swap "timestamp" with "satisfied_time" in your fix for 0000082. This would depend on a precise understanding of the difference between those two fields.

It's an eminently reasonable way for chains to work. Just because it doesn't meet your expectations, or CP5670's expectations, doesn't mean it's "horrible". The problem is not that the code is wrong; the problem is that nobody realized what the intended behavior was supposed to be.

That said, a mod.tbl setting is a reasonable way to control the behavior of chains. But the default will have to be Volition's old code because existing missions rely on that behavior.