-
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Multiple similar events
Well, I think I have a new way of looking at MTTH... that comes from some of the events I've coded.... and this may get a little like quantum physics...
We've already discussed how to come up with a rough guide for estimating a decent MTTH for a single event... but what if you wanted to come up with a MTTH not for a single event, but for a range of similar events that you want perhaps one of many of them to go off during a time period.
When I first coded my new artistic events, I didn't get a lot of time to test just how much they would fire... and then I loaded up my game with them in it... and they fired way too often... so here is the math I had to do.
13 events/180 months(MTTH) X 16 provinces = roughly 1.16 instances PER MONTH
Now, that is way too many time for any artistic event from that range to be firing.... so I increased the MTTH something in the neighbourhood of 720 months and we get:
13 events/720 months(MTTH) X 16 provinces = .29 times per month
I think this is the reason why when people added the illness effects events to their games, people began complaining that they were happening to often... because each individual event was firing when it was roughly supposed to but because there were so many events generally, as a range, they DID fire a bit too often.
Now let's take the tournament events that aren't firing enough. If there are 4 events that have MTTH's of 960 months, then the MTTH for any single one should be roughly 240 months or 20 years which seems to be somewhat consistent with what is happening.
I have created 8 events for tournament with a mtth of 420 months each... so the probability that any single event from this series should fire is:
420 months/8 events = 52.5/12 months = 4.375 years
But say I wanted to have a tournament event fire roughly every three years.
3 X 12 months = 36 X 8 events = a MTTH of 288 months
Of course, we would have to factor in MrT's advice about the "effective" MTTH range as well to come up with something that is closer to reality.
Hmmm.. I don't know if I made any sense or not, but as I was writing some of this down, it became a bit clearer to me anyway...
Hope someone else get something out of this... hehe
M
Well, I think I have a new way of looking at MTTH... that comes from some of the events I've coded.... and this may get a little like quantum physics...
We've already discussed how to come up with a rough guide for estimating a decent MTTH for a single event... but what if you wanted to come up with a MTTH not for a single event, but for a range of similar events that you want perhaps one of many of them to go off during a time period.
When I first coded my new artistic events, I didn't get a lot of time to test just how much they would fire... and then I loaded up my game with them in it... and they fired way too often... so here is the math I had to do.
13 events/180 months(MTTH) X 16 provinces = roughly 1.16 instances PER MONTH
Now, that is way too many time for any artistic event from that range to be firing.... so I increased the MTTH something in the neighbourhood of 720 months and we get:
13 events/720 months(MTTH) X 16 provinces = .29 times per month
I think this is the reason why when people added the illness effects events to their games, people began complaining that they were happening to often... because each individual event was firing when it was roughly supposed to but because there were so many events generally, as a range, they DID fire a bit too often.
Now let's take the tournament events that aren't firing enough. If there are 4 events that have MTTH's of 960 months, then the MTTH for any single one should be roughly 240 months or 20 years which seems to be somewhat consistent with what is happening.
I have created 8 events for tournament with a mtth of 420 months each... so the probability that any single event from this series should fire is:
420 months/8 events = 52.5/12 months = 4.375 years
But say I wanted to have a tournament event fire roughly every three years.
3 X 12 months = 36 X 8 events = a MTTH of 288 months
Of course, we would have to factor in MrT's advice about the "effective" MTTH range as well to come up with something that is closer to reality.
Hmmm.. I don't know if I made any sense or not, but as I was writing some of this down, it became a bit clearer to me anyway...
Hope someone else get something out of this... hehe
M
Last edited:
Orlando said:
reply:
Cat Lord said:
Actually, if I am reading MTTH right, the shape of the curve is not a bell curve, but instead a exponential decrease (for events that fire only once.) For events that can fire more than once, this would be a constant chance/day - the longer the MTTH the lower the chance.
For events that only fire once it is important to realize for an event with (actual, not file-value) MTTH of 50 months, that if it has not happened yet, the MTTH is still 50 months - even if it has been 500 months without the event firing. The average time till the event fires is always the MTTH - until it fires - then it is 0.
(The dynamic polling is a detail that makes the lives of the programmers at Paradox more difficult - the chance of an event with 1%/day chance of happening happening in 100 days is *not* 100%. On the other hand, since few of us own a Pentium-Infinity - it is necessary.)
No, this is not the case because you are under the false assumption that polling frequency is static - i.e. has a fixed and predetermined frequency. This is, to put it bluntly, utterly wrong and can lead to some rather nasty miscalculations. This is why I have always stressed in any post where I discuss events and mtth values that events are dynamic (i.e. even the polling frequency of them is dynamic) and that great care must be taken when chosing mtth values and that it should be followed up with playtesting to confirm that you are getting the desired results.
Yes, there is a very precise means by which you can collapse this to produce a statistically predictable model, but that method is covered by NDA.
Another consideration - affectionately called the "critical mass" issue in betaland - is that those character events that you write and then test by firing up a scenario and running 25-50 years and seem to be working wonderfully tend to become gigantic pain-in-the-ass events when you have a court of some 200+ people instead of the 20-50 that you've tested them with. When those events are firing every 20 seconds (particualrly in MP) the temptation to rem out the path in the events.txt file skyrockets.
Yes, there is a very precise means by which you can collapse this to produce a statistically predictable model, but that method is covered by NDA.
Another consideration - affectionately called the "critical mass" issue in betaland - is that those character events that you write and then test by firing up a scenario and running 25-50 years and seem to be working wonderfully tend to become gigantic pain-in-the-ass events when you have a court of some 200+ people instead of the 20-50 that you've tested them with. When those events are firing every 20 seconds (particualrly in MP) the temptation to rem out the path in the events.txt file skyrockets.
MrT said:
If this is a reply to me (and I don't see another post it is likely to be a reply to) I thought I made it clear in the third paragraph that I knew polling was dynamic.
For a distribution to have any (general) shape but a exponential requires keeping track of when the event last happened or when the character/province became eligible for the event. My main point is that a bell curve would require all this additional information for each (province or character) and event combination. Of course the shape will only be truely visible if the MTTH is significantly greater than the typical polling period. (For a MTTH of 100 days when typical polling is ~90 days the actual shape will be ... strange.)
If the form is not exponential - I am truly boggled.
MrT said:
For an exponential the probability of happening (at least once) in a period T is
Code:
1 - exp(-T/MTTH).I would assume that an event can only happen once each time polling occurs (otherwise programmers lives get too complicated) and thus any events where there would be a likelihood of multiple occurances in a polling interval (short MTTH) would be made less likely to occur. An event with MTTH of 1 day might be expected to happen every time that events were polled, and would thus have a real world MTTH of ~polling period.
Also, if the polling period covers all events that occur in that period before the polling date - the actual MTTH is increased by about ~polling period/2 for what should be obvious reasons (all events in period happen at end).
Yes, in that respect you're right.
The point I'm making (poorly) is that the polling frequency is also dynamic - to lessen the CPU load - so if you wrote 20 different events you could quite possibly also have 20 different polling frequencies. The way the dynamic polling frequency handling interacts with very large or very small mtth values is such that it can result in some very, very odd effects and thus using them is somewhat ill-advised if you're targetting a specific likelihood of them firing within a given period of game time.
The point I'm making (poorly) is that the polling frequency is also dynamic - to lessen the CPU load - so if you wrote 20 different events you could quite possibly also have 20 different polling frequencies. The way the dynamic polling frequency handling interacts with very large or very small mtth values is such that it can result in some very, very odd effects and thus using them is somewhat ill-advised if you're targetting a specific likelihood of them firing within a given period of game time.
Incidentally...should people need help with event scripting, I suspect Cat Lord and/or I could make ourselves available on IRC should the need arise.
so, if I have understood, an event cant fire as soon as the trigger is satisfied... right?
Right. It has a chance to fire - greater or lesser depending on the MTTH calculation - as long as the trigger is satisfied. The only exception is events triggered by other events, which only applies to character events - province events can't trigger other events, or be triggered by other events.Mikon Orod said:
I have tried to give to a test event a mtth of 1 day, but in 2 months it never fired.
Then, I have selected the char, F12 and charevent x... the event fired correctly (trigger satisfied)... it said the event got a dayly chance of 0.50000 and a mtth of 1.00 day.
0.50000?
It means 50% in a day?
And in two months this 50% never succeed?
Maybe I'm missing something...
Then, I have selected the char, F12 and charevent x... the event fired correctly (trigger satisfied)... it said the event got a dayly chance of 0.50000 and a mtth of 1.00 day.
0.50000?
It means 50% in a day?
And in two months this 50% never succeed?
Maybe I'm missing something...
Yes,
we have always warned that using very short MTTH or very long MTTH could result in strange effect, because the polling of events is dynamic (i.e. not all events are verified every day: That would be a massive CPU charge).
Cat
we have always warned that using very short MTTH or very long MTTH could result in strange effect, because the polling of events is dynamic (i.e. not all events are verified every day: That would be a massive CPU charge).
Cat
The early education events (choosing education track for children) have an MTTH of 1 day, but sometimes take 3 years to fire. I think somewhere MrT said that each event is only guaranteed to be checked about 3 times per year. Certainly when I was testing the bugginess of ai_chance in 1.02 I saw no significant difference in frequency of my test events firing whether the MTTH was 1 day or 1 month.
Actually, most events with "normal" mtth valuaes can be expected to be polled about 3-4 times per year, but that isn't guaranteed to happen.richvh said:
Unlike EU2-style scripting, there really isn't a way to make sure that an event fires unless it's a character event that is triggered from another character event. This is a limitation of sorts, however the underlying philosophy of CK events and event handling is that all events are of a random and unpredictable nature and that we are not scripting to force something to happen.
When testing the functionality of events that have short mtth values (to see if they trigger correctly or not) you can use the eureka cheat. Eureka turns of the dynamic polling function and, instead, causes every event to be polled for every available situation on a daily basis. WARNING: you will find that your game grinds to almost a halt when you use this cheat (depending on court sizes and a variety of other things it's not unusual to see it take 3-5 seconds to process each day's information) and that some very unexpected statistical results will occur. Use this cheat only to test functionality and be prepared to be patient.
What is the actual scale facotrs equal for 1 year? I the math for this was bad in 1.03x and from the looks of it in 1.04x...:
...they didn't change the math.
How is the old OR = { command used in CK?
Let me explain, I am currently trying to script my first event in CK, and I want a specific event to fire if the courtier has either of two traits (I.E Court education OR Ecclestical education)
How am I to do that?
Let me explain, I am currently trying to script my first event in CK, and I want a specific event to fire if the courtier has either of two traits (I.E Court education OR Ecclestical education)
How am I to do that?
Try this:
Code:
condition = {
type = or
condition = { type = trait value = court_education }
condition = { type = trait value = ecclesiastical_education }
}