Home Trending Latest threads New posts Developer diaries

Errors in Havard's scripting Bible and other notes

Jump to latest Follow Reply
  • 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.
YodaMaster said:
Clarification for random events (section 3.3):
As I figured out in AGCEEP with "Petty Kingdom of the Barabary Coast" random events, and checked in other random events:
Date, offset and deathdate are not taken in account in random events. In order to check dates in random events, use of "year" condition in triggers is the only one solution.
Click to expand...

If this is correct , then you can never have a deathdate , but you can have a start year. Am i correct in assuming this??
 
Toio said:
If this is correct , then you can never have a deathdate , but you can have a start year. Am i correct in assuming this??
Click to expand...
YOu can have both set in the trigger like this:
year = 1520
not = { year = 1530 }

Then the time span will be between 1520 and 1529.
 
Toio said:
clarification on this please\:



If I read this correctly, then if an event has an offset of 1095, and it has a start date of year 1500 and deathdate was 1520, then it would work like this,

check trigger at anytime between year 1500 and 1503, when checked and not able to fire, check every 980 days from that checkpoint to check for firing. It would then only check a total of 6 times.


Is this correct????????
Click to expand...
I would say this is correct, but after the first period it would check every 1095 day.
 
Norrefeldt said:
I would say this is correct, but after the first period it would check every 1095 day.
Click to expand...

correct , my error in putting 980 insteadf of 1095.

Being this is the case , then why have offsets that are longer than 365 days as the likelihood of these events firing is minimal and a strain on the CPU to keep a tab on the next firing day.
 
Toio said:
Being this is the case , then why have offsets that are longer than 365 days as the likelihood of these events firing is minimal and a strain on the CPU to keep a tab on the next firing day.
Click to expand...
I think the reasons for longer offsets is to make it more uncertain of when an event can occur. Less exploitable in many ways. I don't think it's noticable whether events are checked every seven days or every 700th days. If anything, shorter offset ought to demand more.
 
New stuff about the "vassal" command I have noticed while playing AGCEEP.

The command works even if the two countries involved are at war when the event fires, whichever one was the offender.
Note that this will not end the war, so you will have a country at war with his vassal. This happened to Milan and Genoa around 1421, I think event MLO228000 (Milan vassalise Genoa) caused it.

Maybe events using the "vassal" command should have a trigger checking if the two countries are at peace with each other since there is no command to force them and a war between vassal and liege looks rather stupid.


The command also works if the country receiving the event is already vassal of the country he is to vassalize in the event. I saw Austria and Hungary being vassal of each other around 1450 but I have no idea how it happened.
Note that if the "breakvassal" command is used in this kind of relationship, both countries will try to break the first relation (which means it won't work for the first liege if the game is not reloaded in-between).

Maybe there should also be a trigger to check if the country that is to become the liege is not already vassal of his would-be vassal. Another solution would be to have the new liege/ex-vassal break vassality in the same event (it works, I tested it too).
 
Last edited:
You're right. Vassal command is not tied to wars (as breakvassal) and vassal able to vassalize the liege was discussed in Bugs Thread here.
Third Angel said:
Maybe events using the "vassal" command should have a trigger checking if the two countries are at peace with each other since there is no command to force them and a war between vassal and liege looks rather stupid.
[...]
Maybe there should also be a trigger to check if the country that is to become the liege is not already vassal of his would-be vassal.
Click to expand...
Yes, it's not "maybe", it's "always" ;) => it's up to the event scripter to check the conditions for these two cases.
Third Angel said:
Another solution would be to have the new liege/ex-vassal could break vassality in the same event (it works, I tested it too).
Click to expand...
IMO, first solution is better but maybe some situations really need this.
 
I think these two notes are worthy of an inclusion as tips to modders. It's rather frequent that modders only think of the historical situation and doesn't concider what can be the case in the game. Just like I didn't do with the Genoa vassalage to Milan event... ;)

21. The vassal command can create weird situations. It still works if the two countries are at war with each others and can also create situations where they are vassals to each others.
Click to expand...
OK?
 
Just add "It's up to the event scripter to check conditions in trigger for these weird situations not to happen." and it will be fine :) .

I already faced (and fixed ;) ) the problem in AGCEEP with Modena and Tuscany vassalization by Austria (post 477 in Italy Thread)...
 
Last edited:
I don't know if this has been suggested before, or even if this is the right place for it. Anyway, if you have been coding events and are then have issues getting a scenario to open, you should first check the last events in every file you modified. Unlike if you have a scripting error in other parts of the file, where you would get some sort of notification, the game won't make any notification if there is an error at the end of the event file and will just refused to load instead.
 
XANG XONG III said:
The relation trigger should be

relation = { country = PAP data = 120 }

instead of

relation = { country = PAP value = 120 }

which will give false positive whenever relations are positive (positive relations = positive trigger)
Click to expand...
I checked, this is unbelievable, but true! :eek:
I understand why this condition is never used in vanilla's triggers... :wacko:

Little problem in AGCEEP... Don't know for other mods.
 
Havard's Eu editing bible said:
command = { type = province_revoltrisk which = x value = y }

Modify the revolt risk in province x with value y indefinitely, until lowered by another event, or until the province is in the hands of another nation (this also applies to nations changing tags).
Click to expand...
I did a small test to confirm something I vaguely remembered. I tried to lower the province RR to under 0, and it cannot be done. It's doesn't appear and is not stored in the save file. Useful when one wants to clear a province of revoltrisk but isn't sure of it's value.
 
Some additional, rather well known information on monarchs:
when a new monarch is available, either because his start date is reached or he is woken within his life span, he will replace any current monarch at once. The replaced monarch is removed from the game, even if his death date isn't reached. So, there's no way to use a monarch twice.
If there is no new monarch to replace a monarch after his death date, he will stay as on until replaced. Duty before death.
 
I found that the triggers for monarchs and leaders (that check if they are alive) works differently. The monarch trigger only trigger if it's the monarch of the country recieving the event, while the leader trigger seems to work no matter what country owns the leader. Strange. I will try it again just to be sure.
 
To Norrefeldt: can you add the non dormant monarchs thing for a country released as vassal or revolter, or is this behavior obvious? I had the doubt, clarification is good anyway.
 
You must log in or register to reply here.
Top Bottom
Back