Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: karajorma on July 10, 2005, 09:55:35 am

Title: Non random behaviour in Random-Of
Post by: karajorma on July 10, 2005, 09:55:35 am

No idea what's causing this but I'm using the random-of argument in a mission and the last argument in the list appears to be getting picked much less than the others.

I put together a quick mission and it only picked the number 5 once in over 4 minutes of me running it (twice).

I then edited the mission so that the randomly picked argument was invalidated and the test mission started to work. I can't do this in the real mission as I want the random-of option to possibly pick the same argument more than once.


While I'm on about the new conditionals. How hard would an add-argument action operator be? I haven't got any current use for it but I'm sure I could think of some the second I had one. Especially if I could add the value of a string variable to the list of arguments :D


Anyway as always I'm including the test mission to make it easier for whoever takes a look at this. (You might want to try the mission before you look at it in FRED though). :D

Title: Non random behaviour in Random-Of
Post by: karajorma on July 11, 2005, 05:08:39 am

BTW this isn't exactly urgent cause I simply included the last argument twice and for now things are working (although if I forget to remove it once the problem is fixed it will screw up the mission by making the last argument twice as likely to appear).

Anyway if someone else can reproduce the error I'll mantis it.

Title: Non random behaviour in Random-Of
Post by: Goober5000 on July 11, 2005, 10:41:38 am

*grumble grumble*

Title: Non random behaviour in Random-Of
Post by: karajorma on July 11, 2005, 11:13:19 am

Try the mission. It will make you feel better about it :D

I didn't want you getting annoyed with me cause I keep spotting bugs in the marvelous new SEXPs you keep making for me so I made it a little um. different from my average bug report missions :D

Oh and turn on voice synth if you haven't already. It's worth it :)

Title: Non random behaviour in Random-Of
Post by: Kosh on July 12, 2005, 12:02:24 am

This is what I got when I tried that mission:


(http://web.engr.oregonstate.edu/~plankerj/thingy.JPG)


Is this what you had in mind? :p

Title: Non random behaviour in Random-Of
Post by: WMCoolmon on July 12, 2005, 01:05:27 am

Looks like the hud replacement SEXPs are working just fine....

Wait a minute. I never coded those... :nervous: :p

Title: Non random behaviour in Random-Of
Post by: FireCrack on July 12, 2005, 01:14:05 am

:wtf:

Title: Non random behaviour in Random-Of
Post by: karajorma on July 12, 2005, 01:48:08 am

Quote

Originally posted by Kosh
Is this what you had in mind? :p

Ummmm. No. What build were you using? It worked fine in Taylor's latest.

Title: Non random behaviour in Random-Of
Post by: Kosh on July 12, 2005, 02:00:35 am

Not the right one appearently. Just tried it with Taylors latest and I didn't get that wierd stuff.


It seemed to stay between 2 and 5. But it liked the numbers 2 and 5 the most.

Title: Non random behaviour in Random-Of
Post by: Goober5000 on July 12, 2005, 03:26:58 am

Erm.

It looks like you're misunderstanding what random-of is supposed to do.  More worryingly, it looks like I didn't get it quite right. :sigh:

Random-of is supposed to select a random argument only once.  In other words the first time the event is evaluated it selects an argument, which it then uses for every subsequent evaluation of the sexp.

What you should be getting is "Two.... Two... Two... Two..." etc. when you run the mission, but if you restart it you might get "Four... Four... Four... Four..." etc.  This is the same as the behavior of the "rand" sexp.

It shouldn't be hard to add a "random-multiple-of" sexp to pick a random argument every time you evaluate the sexp, but fixing the existing bug will be a bit harder.

Title: Non random behaviour in Random-Of
Post by: karajorma on July 12, 2005, 03:50:38 am

I'd rather have the random-multiple-of SEXP to be honest. If I needed to keep the selection I'd save it in a string variable. (In fact that's exactly what I've said to do in several examples I've given using the SEXP). For the vast majority of things I had planned using the random-of SEXP  I was planning to save the argument for later use anyway so that wouldn't be too much of a problem.

I can't see how random-of could work with every-time anyway. If the event gets flushed before every use then there's no way I can see for it to remember what was picked the previous time is there? (I assume that's why you're saying that it's hard to fix).

I'll have to give it a try with when-argument and see what it does there.

You may be able to get away with simply replacing random-of with random-multiple-of if it proves hard to fix anyway. Sadly only a handful of FREDders are using the new conditionals at the moment so as long as we make sure that Sesq, TP and the the others are aware of the change you may be able to get away with not having to spend ages fixing it.

Title: Non random behaviour in Random-Of
Post by: Goober5000 on July 12, 2005, 03:33:48 pm

Quote

Originally posted by karajorma
I can't see how random-of could work with every-time anyway. If the event gets flushed before every use then there's no way I can see for it to remember what was picked the previous time is there? (I assume that's why you're saying that it's hard to fix).

I'll have to give it a try with when-argument and see what it does there.

Hmm, that might actually be the problem.  Can you try that and tell me what happens?

Title: Non random behaviour in Random-Of
Post by: karajorma on July 12, 2005, 06:03:13 pm

Tried it. I got exactly the same thing actually.

 The fact I used every-time-argument can't be the only problem as it wouldn't explain why Bosch never sang about 5 bottles.

Nor would it explain why invalidating arguments makes the event suddenly start working properly.

I simply thought it might simply be an additional problem but it appears as though the problem lies elsewhere.

As always here's the mission