In triggers Flag Set Random Value is not random

[Richrach]

When making a trigger to randomize the selection of an event in DCS 2.9, the FLAG SET RANDOM VALUE function will not randomize.  My settings:

FLAG SET RANDOM VALUE ("1", 1,10)

Conditions settings for the random event:

Event 1

FLAG IS MORE ("1", 0)

FLAG IS LESS ("1", 3)

Event 2

FLAG IS MORE ("1",2)

FLAG IS LESS ("1",5)

Event 3

FLAG IS MORE ("1", 4)

FLAG IS LESS ("1", 7)

Event 4

FLAG IS MORE ("1",6)

FLAG IS LESS ("1",8)

Event 5

FLAG IS MORE ("1", 7)

FLAG IS LESS ("1", 10)

Event 6

FLAG IS MORE ("1",9)

FLAG IS LESS ("1",11)

 

As I understand the logic, this should randomly produce Event 1 20%, Event 2 20%, Event 3 20%, Event 4 10%, Event 5 20%, and Event 6 10%.

 

The computer assigns Event 1 or 2 100% of the time.

Thoughts?

Richrach

 

[twistking]

is the flag defined (FLAG SET RANDOM VALUE) before you check the value? Maybe the issue is that the events check for the flag value when the flag is still undefined?
Just guessing...

[Grimes]

Ran it 100 times and got the following outputs. Left is the number and right is how many times it got selected.

 

nullJust showing to indicate that it is kind of random and the first selected item was always different for me. You could try increasing the range, random 0-100 with the flag ranges appropriately scaled might yield sufficiently random results. In the past the lua version of math.random had a tendency to randomly choose the first and last possible value much less often. Keep in mind I'm talking about running math.random 10000 times and see what the results were. Which doesn't quite jive with what you were experiencing here. 

[Tippis]

There's also the classic question of from what, where and when the random seed is picked.

A good experiment to run is to see if you get different results depending on where in the setup process you do your randomisation. Arguably, it shouldn't matter, but it can and when it does, it helps to know so you can work around it.

If you put the flag randomisation on a TIME IS MORE trigger so it fires a few seconds in — meaning a bunch of other stuff has happened before that may have affected the seed or (if the randomisation algorithm is truly antiquated) “eaten” early results — and see a different outcome, then that's one way of dealing with the matter.

Also, note that you have a couple of different occasions to set your randomisation and that this will actually cause different behaviours in other pares of the game. One notable example is the “initialisation script” section, which fires off before the mission is constructed in the game. That timing can be compared against ON MISSION START triggers which, well… fire on mission start. I.e. after the mission is fully constructed. This is important if you want to use the “State” conditions for spawning AI groups, for instance, since that check happens very early on. Similar timing issues can happen depending on loading order of triggers and scripts.

So if your setup is at all timing dependent, make sure the timing actually works so the check definitely happens after the flag setting. Delaying both the randomisation and the check will obviously have an impact here in making sure things happen in the right order. Similarly, with all the chaos going on at the setup phase, it's also depressingly easy to overlook when a trigger (or some loaded script) overwrites a flag that you thought you set up properly earlier in the sequence. On top of that, there's an oddball behaviour that as come and gone over the years, where DCS does… things… if you set and check flags immediately following each other. Or if you want to use triggers such as TIME SINCE FLAG, where the exact condition for when the game considers a flag “set” or “changed” seems to almost be astrological in nature.

 

Just to clarify: I've had similar issues to yours in the past when trying to introduce random elements in missions, and those have all been factors when I've forgotten to do it properly. Timing, sequencing, knowing when varying checks fire, and just making sure you don't accidentally reuse and overwrite a flag.

Edited March 10, 2024 by Tippis

[Richrach]

Twistking, thank you for the reply.  I have a trigger set right before the triggers I want to randomize.  It is ONCE / TIME MORE (510) / FLAG SET RANDOM VALUE ("1", 1, 10)

From there I have the triggers set to randomize 9-lines to an aircraft.  There are two sets six possible targets, separated by time.  The mission should randomly pick from the first set.  Once that is complete, another FAC takes over and has a different set of targets to choose from.

The randomization has gotten better with time.  It still picks one of the targets a disproportionate amount of the time.

[Richrach]

Tippis, if I understand you correctly, you are saying set FLAG SET RANDOM VALUE at the beginning of the mission or fairly close to that?  I have two periods of randomization, a flag one, and later a flag 2.

 

They are set as follows:

ONCE / TIME MORE (510) / FLAG SET RANDOM VALUE ("1", 1, 10)

ONCE / TIME MORE (1021) / FLAG SET RANDOM VALUE ("2", 21, 30)

 

Interestingly, the second flag seems to be more random than the first.  It does take a while to get through both flags, so I do not get to run a repeated test.  The first flag has definitely gone to a specific pair of targets most of the time, which is a bit irritating as one of them is the most heavily defended.  Getting whacked on that target happens pretty frequently.

 

 

Thank you for your insight!

 

Grimes, what you are seeing is about what I have been experiencing.  The "random" is not truly random, but play favorites to a certain extent.  Many years ago this was a problem in Microsoft EXCEL formulas.  It was based on how the random seed was chosen.

 

Good to know I am in good company and not losing my mind or doing something wrong!

Richrach 

[Tippis]

2 hours ago, Richrach said:

Tippis, if I understand you correctly, you are saying set FLAG SET RANDOM VALUE at the beginning of the mission or fairly close to that?  I have two periods of randomization, a flag one, and later a flag 2.

[…]

Grimes, what you are seeing is about what I have been experiencing.  The "random" is not truly random, but play favorites to a certain extent.  Many years ago this was a problem in Microsoft EXCEL formulas.  It was based on how the random seed was chosen.

I have this sneaking suspicion — and absolutely nothing to support it, just to be clear — that this is the heart of the matter: the randomisation happens once, some time during the start, and then you're just given a fixed stream of psuedo-random numbers that depends on that first seed. That it's not calling some kind of system randomisation that pulls from a shared random pool at the system level, but rather that your mission pulls its string of numbers from its own separate stream so what matters most for getting different outcomes is how far into the mission you've gone and how many other randomisations have happened before that. So if that initial random seed doesn't rely on a lot of entropy, you get very similar results early on.

But that's the annoying part about randomisation: good luck proving it!

After all, [1 1 1 1 1 1 1 1 1 1 ] is a perfectly reasonable string of random numbers.

[Priest]

There's definitely something "weird" going on, whether that is because of a bad pseudo-random number generator or we just don't know how it really works (or both) well I don't know.

Probably related somewhat but I have found it better to affirmatively specify what happens for all outcomes rather than leave anything "open" because otherwise for who knows why 1-1-1-1-1-1-1-1 is a perfectly good string of numbers!

Say for example if want to make the path an AI unit takes in a series of waypoints less predictable, why not just create one advanced waypoint action at each waypoint that selects an out of sequence waypoint with a 50% chance to trigger? Should work right? It doesn't the AI falls into a repetitive loop if do that.

Instead, set up two advanced waypoint actions (1) select out of sequence waypoint 50% chance to trigger then (2) select normal sequence waypoint 50% chance to trigger.

Attached is a little path test mission I made, all AI units running in a box using couple different variations of the above. Haven't collected actual distribution of "choices" just observed via F10 map at 20x speed see what happens and the unit in the RED box always eventually gets stuck going back and forth exact same leg. Science!

 

Random Path Test.miz

[Nealius]

I've been wondering about this as well, as I often have 4~5 random scenarios generate when a player enters a trigger zone, except when I play test it seems like the scenarios always generate in sequential order rather than randomly.

[Priest]

18 minutes ago, Nealius said:

I've been wondering about this as well, as I often have 4~5 random scenarios generate when a player enters a trigger zone, except when I play test it seems like the scenarios always generate in sequential order rather than randomly.

I've noticed things like this too. Part of me thinks maybe random number generator uses time of day somehow? And then part of me thinks well I know the possible outcomes in my mission and it just doesn't "seem" random enough to me because I have this expectation bias that each time should be different, and then it's just randomly NOT that different over a few sessions.

Who knows. ED!

[Tippis]

In a flash of… lesser sanity, I decided to set up a simple RNG collection thing: Random.miz to just see how it behaves when you ask for a lot of random numbers.

Basically, it sets five flags at mission start and then reads back their values 2 seconds in. And I think that, while on the hole it's probably ok, there still some oddness going on that may be related to a kind of sample bias more than anything. Usually for mission design purposes, you use maybe a handful of random values and the spread of them is low because it's a lot of effort to design umpteen different outcomes for each test.

The thing is, the DCS random generator seems to love to repeat numbers when looking at small series. That's not something that's technically wrong from a statistical standpoint, but it's perhaps not what the designer actually wants. I ran two tests, one where it rolled three numbers in a row, and one where it rolled five (this is the version linked above). Then I ran those until I had 100 rolls in total, and looking at that total, it looks... entirely sane. But looking at each set of rolls, it gives results that create annoying outcomes in the mission.

(In spoiler tags because they're long lists of numbers and would look horrid if just shown as continuous text)

Spoiler

1 1 3
5 5 1
3 3 5
4 3 2
2 1 2
1 5 4
2 2 2
1 1 1
1 5 3
5 1 4
4 2 4
2 2 2
1 2 5
3 5 2
5 1 3
4 2 2
5 1 1
5 5 5
3 4 1
5 5 3
1 1 5
2 2 4
4 2 2
1 3 1
3 4 4
1 2 2
1 1 4
2 4 1
4 5 5
1 1 3
3 5 1
5 1 5
5 4 3
5 4 4

Spoiler

5 5 4 1 2
3 3 1 1 4
2 2 3 5 1
4 1 4 5 4
2 1 2 4 5
5 3 2 2 5
3 5 3 3 1
2 4 5 2 1
5 2 5 1 1
3 4 4 5 4
4 3 4 1 4
2 3 5 4 5
3 1 1 5 3
4 1 3 2 2
4 5 1 3 3
1 5 3 4 1
3 5 2 1 1
3 1 1 3 3
5 4 1 5 1
3 2 2 4 4

Average result for the first test was 2.88 with a standard deviation of 1.53.
Average result for the second test was 2.98 with a standard deviation of 1.50.

Pretty darn close to the expected outcome for the entire population.

But then we look at what each set of rolls produces:

A whole bunch of sets with low deviation - two sets in the 3-roll variant with the same number repeated for all rolls. Again, not technically wrong, but annoying for creating a feeling of variation and randomness.

Some of this could probably be fixed by scripting up what is probably what is more often the desired outcome: a specific set of numbers, but in random order, or at least some kind of weighted function where previous results are less likely to reappear. I.e. not random at all in the literal sense, but more appealing to the intuitive sense of what a random pattern should look like.

[Wrecking Crew]

On 3/26/2024 at 8:02 AM, Tippis said:

Some of this could probably be fixed by scripting up what is probably what is more often the desired outcome: a specific set of numbers, but in random order, or at least some kind of weighted function where previous results are less likely to reappear. I.e. not random at all in the literal sense, but more appealing to the intuitive sense of what a random pattern should look like.

Hi Tippis, folks.  I did this, in my clunky way   I have five sets of coordinates and want one set chosen randomly, for the first objective.  When the objective is complete, another one can be accepted and the next coordinate set is randomly selected from the remaining four.  Rinse and repeat.  For the set up, Flag 5 is set to a random value between 1 - 5 at mission start.  Then scripting will define a dictionary with values {1, 2, 3, 4, 5}.  

Mission Start: Flag 5 set to a random value from 1-5

Mission Start: Create a "F5Dict", and remove the current value of Flag 5 from the dictionary.  Flag 5 value determines the coordinate set (one of five) for the objective

-- MS, code.Create F5Dict
Flag5Dict = {1,2,3,4,5}
do
 local Flag5Value = trigger.misc.getUserFlag('5')
 local indexsearch = 0
 for index, data in pairs(Flag5Dict) do
  if (data == Flag5Value) then indexSearch = index end
 end
 table.remove(Flag5Dict,indexSearch)
end

After the first objective is complete, the player can select to attack a second objective from the remaining four values in the dictionary; Flag 75 goes True, so Switched Condition Do Script..

-- SC, Select Next Killbox, F75T
do
 if #Flag5Dict > 0 then
  local indexRand = math.ceil(math.random(#Flag5Dict))
  trigger.action.setUserFlag(5, Flag5Dict[indexRand])
  -- remove the new value
  table.remove(Flag5Dict,indexRand)
 end
end

Complete the objective.  Rinse & repeat.

 

Credit for the code help goes to Franze

Boxcutter Hari 02.lua Boxcutter Hari 29S1g.miz

Edited March 27, 2024 by Wrecking Crew
docs

[Tippis]

Nice!

[Mistermann]

Thanks for the post @Wrecking Crew - I was going to suggest a script, but didn't have a great example.  Not only did you post the text, but also the mission using it.  Downloading for my usage later on.