[FUBAR-BDHR]

Before someone else asks.  The first event isn't entirely necessary but I've found it does make the rand-multi function actually act random. 

Eh?

Sounds like a bug in rand-multiple then.

Bear in mind that I improved the way the random SEXPs work about 6 months ago as there was a problem with them which caused them to be less random than they should have been.

Maybe it does work now.  I just got so used to doing it that way I've never tried it.  I do remember when you modified it for that bug I found with big values. 

[karajorma]

None of that should be the slightest bit different from simply using rand-multiple directly though.

In fact I wouldn't be at all surprised if someone pointed at maths that proved that storing 1000 random numbers and picking one at random is actually less random than the method used for generating random numbers.

[Razial]

In the second one it checks for the mission time being greater then delay[15]

Dude I almost completely understand now, the only thing is the 'adding to mission time'. I dont understand what 'mission time' has to do with any of the repeats after the intial trigger (5 seconds after mission start, triggers first of the emp blasts). Wont adding anything to mission time just add a random variable between 5-15 to the mission time, which could be anything from 5 seconds to 2 minutes, added to 5-15 seconds?

[FUBAR-BDHR]

mission-time is a sexp that returns the current mission time in seconds.  So you add 5-15 to that value and store it to delay each time.  It doesn't adjust the mission time or anything.  

@Kara. I know it doesn't make sense but it always seemed like rand-multi when used in certain instances has an uncanny knack of returning the same sets of values.  Having it process repeatedly and probably more importantly in a separate event seems to get around that.  But like i said I don't think I've tried it any other way in ages so who knows it might work fine now.