Works now I really should trust my gut instincts more often
From the first time I read this post I was rather disturbed by this bit
Originally posted by Black Wolf
The Apo (Ship A) arrives with initial orders to attack the GTCv Dignity (Ship B).
The first sexp checks for two things
- Is the Apo Less than 1000m from the Dignity
- is the Variable (Interstingly enough, also called "Apo") equal to 0 (It's initial value)
It then clears the Apos goals, gives it new orders to head for a waypoint about 7000m away and sets the Apo variable to 1
The next sexp checks for three things.
- Has the above event happened
- What's the status of the Apo variable (ie. is it = to 1)
- Has the Apo either reached its waypoint or gotten at least 3500m from the Dignity
If it all three return true, its orders are cleared, the variable is set back to 0 and the Apo is given orders to attack the Dignity.
The variable already gives you the ability to check whether the above event has occured or not so why are you also doing a is-event-true check? I thought about posting and saying you should remove it cause it's redundant but thought I was just being pedantic. After all what harm was it doing?
Turns out that that check is the cause of the problem. I can't explain it but either chaining or checking that the first event occurs causes the second event to fail. (BTW are you sure you wrote those two events down the right way around? When I tried this the apo just flew away and never came back rather than endlessly circling).
I suspect that this is an FS2_open bug/feature cause I'm surprised if it would have occured under FS2. What appears to be happening is that event 1 repeats before event 2 comes true. Since the apo is now far away enough event 1 evaluates to false which means that event 2 never fires.
Anyway just in case your problem was different I've included the mission file of my working version
Either way I think I've uncovered a serious trap for unwary FREDders using repeating events.
