[herkie423]

Ok. I pkayed your test mission just now and read your events.

Just as I have suspected. You used the "event true delay" SEXP. The first cycle up is fine. But the second stage is the problem. You placed a condition that will be true all throughout even with the delay. Once an event is true, it will always be true repeatedly for 1000 times. Essentially, the computer executes these repeats in micro seconds. As if nothing has happen. The delay will not work because it ALREADY returned true the first time. What had happen is that the events "cycle trigger" a to c happened all at once for 1000 repeats. The ON and OFF were actually executed at the speed of electricity so, again as if nothing has happen. If you see command messages displaying alternately, it does not matter. Two messages will display one at a time even if chained with 0 time interval. Actually, the game already executed the 1000 message  repeats the moment first message was said and the game displays them one at a time. Like I said, use toggle and duration variables in conjunction with "everytime" or multiple triggers of "when" condition  I am making a test mission now and will send it to you.

[herkie423]

That was quick. I made this mission for your reference. The Orion ship will flicker on and off in 50 microseconds interval for 2 seconds each time you fire your weapons.

I did not use the "everytime" condition instead I use the "when" condition with a "trigger count" of 999999, not "repeat count." I used variables here to serve as logical switches.

This is just a matter of juggling the "toggle" variables to create a seesaw effect between the ON and OFFs. Of course, the duration between the ONs and OFFs must also be set in the "CycleInterval" variables. There are two of them. Each for ON and OFF.The default value for these "CycleInterval" variable is set to 5, that is 50 microseconds depending on the speed of your computer. You can adjust these variables to your preference. There is also the duration of the flickering cycle length set in the "Repeats" variable. The value set here is 15, approximately 2 seconds. You can also adjust this to increase the duration of the flickerings. There are a number of modify-variable SEXPs setting the default value for these adjustable variables and several condition checking for those default values. If you adjust the defaults for the 2 "CycleInterval" variables and the "Repeats" variable, they must all match. Lastly, the "Trigger" for now is tied to weapons firing. You can change this to any event of your choosing.

[attachment stolen by Russian hackers]

[karajorma]

I didn't see Herkie's reply until I'd already tested it myself but he's definitely correct about the cause. Let me explain how I realised what was going on cause it's a good example of the event.log being useful. First thing I did was go into FRED and tell FRED to log the last two events evaluating to true in the event log. When I ran the mission, I got this.

Code: [Select]

Mission lightshow test loaded.

Event: cycle trigger b at mission time 19 seconds (19712 milliseconds)
when returned TRUE
send-message returned TRUE
activate-glow-points returned TRUE
activate-glow-maps returned TRUE
and returned TRUE
or returned ALWAYS TRUE
is-event-true-msecs-delay returned ALWAYS TRUE
rand-multiple returned 1185
= returned TRUE
Variables:
trigger[1]

Event: cycle trigger c at mission time 19 seconds (19712 milliseconds)
when returned TRUE
send-message returned TRUE
deactivate-glow-points returned TRUE
deactivate-glow-maps returned TRUE
and returned TRUE
is-event-true-msecs-delay returned TRUE
rand-multiple returned 4934
= returned TRUE
Variables:
trigger[1]
from that you can see that cycle trigger b & cycle trigger c are evaluating to true in the same frame. If you look further down the log you'll see that's always the case. One event turns the lights on, but in the same frame they get turned back off again.


Just out of interest, how did you notice the problem herkie?

[herkie423]

In the events log. Those event were triggered at the same time. All with the same time stamp in my end. If you have a faster computer, still the difference is infinitesimal. Well, this created a computer dilemma. So nothing happened. I mean something did but we cannot see it.

Actually, I already know the moment I saw the events. "event-true-delay" or the one with "msec" dosen't work with re-triggers.

I made a mission that renders it properly. See my previous post.

[herkie423]

The events log is really helpful. It is a tracer to debug missions.

[herkie423]

Oh yeah, why didn't I think about it earlier? You can use two events for ON and OFF with logical operator "time-has-elapse" coupled with "mission time" + (msec) as its value and have them trigger multiple times. And only use one "toggle" variable for ON and OFF. The "mission time" + (msec) for ON event should be longer to make them execute alternately. I have not done this so it might not work. If it will, then this is simpler than the previous test mission i sent you.

[herkie423]

Ah bugger. I checked. The "has-time-elapse" SEXP does not accept microseconds value. This can work but the ON and OFF flickers will be in "seconds." I don't think that's what you want. So my test mission is still the viable solution.

[0rph3u5]

Ok. I pkayed your test mission just now and read your events.

Just as I have suspected. You used the "event true delay" SEXP. The first cycle up is fine. But the second stage is the problem.

I use the "when" condition with a "trigger count" of 999999, not "repeat count." I used variables here to serve as logical switches.

Okay, I got that. I will see if I can work up a new version once I am done with implimentation of the script which deal with mission critical IFF-changes (see here)