Something Flakey with how #Trigger working!

[DarkHorse2]

I have the following script in mobilization_2.txt

I am expecting to fire 35% of the time. But it is firing way too often.

As a result, I have had to reduce the trigger from 35 to 15.

Perhaps I am confused on how #TRIGGER= is supposed to work?

But even after reducing it to 15%, it has fired the 1st 3 turns of the game!

The chances of that are just 0.3 %

Code: Select all

{
#NAME= Turkey Leans Toward Allies While USSR Neutral (Continuous) (Turkey->Allies)(35%)
#POPUP= TEST: Turkey's relationship with the Allies improves
#IMAGE=
#SOUND=
#FLAG= 1
#TYPE= 2
#AI= 0
#GV= 1[1,100]
#LINK= 0[0]
#LEVEL= 0
; Turkey(111)
#COUNTRY_ID= 111
#TRIGGER= 15
#DATE= 1939/09/03
; 1-5% mobilization increase towards Allies
#MOBILIZATION= [1,5] [2]
; USSR(116) Allied and not active
; Turkey(111) Allied and Not Active
#VARIABLE_CONDITION= 116 [2] [0] [0]
#VARIABLE_CONDITION= 111 [2] [0] [0]
#CONDITION_POSITION= 0,0 [0,0] [0,0] [0] [0]
#PRIVATE= 1
}

I am beginning to suspect that something is broken!

What is the RND algorithm you are using? Mersene Twister?

https://en.wikipedia.org/wiki/Mersenne_Twister

[DarkHorse2]

Something flakey is going on with the #TRIGGER= implementation.

Another game where the #TRIGGER=15 is firing too often.

TurkeyTrigger.png (141.45 KiB) Viewed 538 times

[DarkHorse2]

The chances of 1 game with the 1st three #TRIGGER=15 rolls occuring are.

0.15 * 0.15 * 0.15 = 0.003375.

Now couple that with the next 2 in the very next game...

0.15 * 0.15 * 0.15 * 0.15 * 0.15 = 0.0000759375

Can't tell me that something is not broken somewhere.

I have been noticing this weirdness for a while now....

Even when I previously had it at #TRIGGER=35, it was occuring too often to be random.

[DarkHorse2]

1. There is nothing in the logs to indicate what #TRIGGER= value is being used.

2. And nothing to indicate what the internal RND value generated was either.

... both of which would be useful right now.

[El_Condoro]

I agree that #TRIGGERs fire too often. I have seen the same thing with even 5% chances firing more than expected. Yes, probablility is fickle but the ongoing frequency of low-chance triggers firing more often than expected makes me, too, wonder if the % chance is working as it should.

[DarkHorse2]

As a software engineer, when I see things like this, it makes me wonder if the random number generator was properly seeded.

Even when using the standard C random number generator via the rand() function, you are required to seed it the first time it is called. Otherwise you will get a pattern of reproducible results - which defeats the purpose of rand() to begin with.

https://en.cppreference.com/w/cpp/numeric/random/rand

---

Another possibility is that there was an error in parsing the event script and internally the wrong value for #TRIGGER= is being used. (one of the reasons I am fussing over the logging... because there is noway to know what is being used without stepping through the code)

[Hubert Cater]

I can confirm the use of a random number generator class that is seeded once at the beginning of each game.

The random numbers are used throughout for everything, from combat randomness to events and so on.

Imagine a spread of random numbers where maybe the 50th applies to your event, then maybe the 275th applies to your event the next time around and so on.

Which arguably could make the analysis a bit different as it is not a unique random number generator just for your event where having 3 numbers in a row under <= 15% would be less likely etc.

[DarkHorse2]

One way to know for sure is to log it.

I know I have made mistakes in code before that was not revealed until it was logged.

I will keep an eye one it as I am not convinced something isn't wrong.

[Hubert Cater]

I can add that it's not the first time the concern has come up, we've run a number of internal tests because of that, and it just kinda is what it is, but I can look into adding a log for it perhaps one of these days if there is ever time for it.

In the meantime you can see some of the random numbers generated in the logs, e.g. if you run AI vs AI games using F3 and then use the F2 key to record longs, in the planning, research, diplomacy, weather log files.

The planning log shows you the 10 random numbers assigned to global variables, and the rest are more for when to determine 'hits' like when there should be a hit in diplomacy, research and weather etc

[DarkHorse2]

The random numbers for the global variables are handled differently - completely differently, than the way trigger is handled.

So seeing the log entries for #GV= 1[xx,yy] is completely unrelated to #TRIGGER=xx.

Of course, you know this already.

[Hubert Cater]

What those logs I referenced does is give you an idea on how random numbers are generated, which I believe was part of the original concern.

The Global variables log shows 10 random numbers from 1-100, one right after the other.

Again just to give you an idea if there was something simple amiss with the random number generation, even these simple logs that show random numbers and how they are used in game would likely indicate if there was an issue.

Specifically as to how TRIGGER is handled, the trigger value is stored (and yes it could be stored incorrectly) and then after that a random number is picked from 1-100 and if the random number is <= to the trigger number, the event fires.

If there is a concern with the Mobilization #2 event, a simple test would be to create a small map test campaign, with only one Mobilization#2 event, Type=2, and run an AI vs AI game and record the logs to see how often the event fires.

A second test would be to add some units so that there is some combat as well, and this way you get some similar spread of random numbers being picked from the random number generator as we do in the default campaigns. Maybe add other events as well so it is not just the Mobilization#2 event.

There might be no difference, or there could be some difference when there are dozens of calls to the random number generator each turn before the Mobilization #2 event fires.

e.g. to see the difference between flipping a coin over and over again and seeing how many times you get heads in a row, versus flipping a coin over and over again and picking a random spread of flips to see how many times heads shows from these random selections, e.g. the 5th flip, the 27th flip, the 90th flip and so on.