How is X% Yearly Calculated For Firing of Events?

Solution 1:

Internally, Crusader Kings 2 bases event triggers¹ upon mean time to happen (abbreviated MTTH). The weighting formulas for different events are in the game files, often in plain text. One of the simplest ways of modding the game works by editing these text files to provide different values. The game UI will translate that value after all modifiers into the rough percentage chance you see².

Behind the scenes, the actual engine calculations are something different. Paradox Game developer Johan shared this snippet of source code:

float daylyChance = float(1.0f - exp( log(0.5f) / MeanTimeToHappen ));
float chance = float(1 - exp( noOfDays * log(1 - daylyChance)) );
return chance;  //0-1% chance of event happening that day

Which basically says that every event has a percentage chance of happening that day. The inclusion of the noOfDays is a bit misleading, as the same post says it is "basically, how many days are between checks. (currently 1)". In other words, it's a tuning factor for the game engine to perform checks less often (improving performance) and arrive at the same odds. exp() is apparently a C/C++ library function for natural exponential function with Euler's number, e^x.

A few posts down in that thread, user Hakkapeliitta explains the code better than I could:

Let's have a concrete example: an event with a modified MTTH of 3 months. 3 months = 90 days. Log is the natural logarithm in C++.

chance per day p:

P = 1 - exp(log(0.5)/90)
  = 1 - exp(log(0.5))^(1/90)
  = 1 -         (0.5)^(1/90)

i.e. aproximately p=0.007672053737056518974464631174 chance per day.

Since currently noOfDays=1 then chance per check is the same as daily chance.

With the above daily chance p the following holds:

1. The expected value for the number of times that the event triggers during 3 months is not 1 (as it would be if the wiki was right), but 90*p, i.e. aproximately 0.69.

2. The amount of days k that one has to wait for the event to have had a 50-50 chance of triggering (at least once) is 90 days (i.e. exactly the MTTH):

   (1 - p)^k = 0.5
k*log(1 - p) = log(0.5)
           k = log(0.5)/log(1-p)
           k = 90

I bolded the last bit of his explanation, as it is the most pertinent to your question. The last thing to figure out is how the game translates the MTTH in the code. Considering the example of MTTH = 3 months again, let's try the simple conversion of 50% per 3 months to 16.7% per month, which would mean the game would give you a 16.7%/30 days =~ 0.55% chance per day of firing that event - that would be an exceptionally high chance of a councillor accomplishing anything.

So let's go back to your example of 8.29% yearly success. That would equate to a MTTH of 50%/8.29% = 6.031 years, or 72.4 months. Translating that to a daily chance means the code would give you a roughly 0.046% chance of getting the 'Claim Fabricated' event on any given day³. Presumably, the code would then roll a random number and compare it agains this daily chance value.

You are never guaranteed success in this game. All you can do is improve your chances. For your case, it sounds like your ambassador has a diplomacy value of 10 or so. It would (apparently) be very much to your advantage to find someone with a 13+ score.

¹: This is true for most long-term events. There are other event types that are "triggered only", which means they have to be chosen through a dialog box/AI decision as a direct and exclusive result to another event. For example, the dialog that pops up upon a successful claim fabrication gives you an option to use the claim or let it go; each of these corresponds to another event in the game engine, and each options' subsequent event is responsible for granting you the claim or the piety from letting it go.

There are other events that trigger from weighting factors in the short term. Apparently events with short timelines place more load on the game engine, so the game does a cheaper calculation to decide whether the event occurs or not. The example the wiki gives is some weighting calculation for whether or not a failed assassination will result in a wound or a maiming.

²: This is true for the events that you can see the odds for, which generally include councilor missions, intrigue plots and faction rebellion chances. Many more events, such as fertility, child rearing and tutoring, disease and death, are either completely hidden or only show the barest hints from traits and opinion modifiers (e.g. strong gives +1 health and +10% fertility, decreasing your chance for death and increasing your chance to have a child; a -100 opinion is more likely that someone will attempt to assassinate you).

³: This is how it really works for true random events: assuming that future probabilities are more in your favor due to past failures is called the Gambler's Fallacy. Imagine your Ambassador trying to fabricate a claim; it's easy to think that it wouldn't be a true-random event, but rather a goal he would progress towards, making it more likely to succeed with each passing day. He doesn't wake up, attempt forging documents all day long until he has a reasonable facsimile, throwing away failed attempt after failed attempt. Instead, he would be bribing people to get looks at official documents or seals to improve his forgery, spending time carving or finding a carver for a wax mould for the seal, aging parchment or finding appropriate parchment until he eventually creates a successful document.

Unfortunately, any reasonably accurate testing will show you that accumulating and increasing the probability over time will radically skew your events. This may sound like it'd be more fun to play – who wants to wait 20 years for your first Causus Belli or your first born heir? – but imagine if every assassination or claim plot against your lands were guaranteed eventual success. You would find your rulers even more death-prone and your lands much less likely to remain under your control. After all, for any simulation to be accurate, the chance for real, total and lasting failure must be an option.