How To: The Ancillary Guide

[Jurand of Cracow]

Thanks, Withwnar.
I wanted to make traits of a character CoA in a settlement dependent on the buildings which exist in this very settlement. The goal would be to force a player to care for his new characters - he'd make the fathers stay in the better settlements to have better children. But now I see even one more issue: if a father is in foreign lands, then the son/princess CoA in capital. So a player may abuse the system by just sending that father just on across the border and the result would be the same (assuming that the capital the the best settlement).
Perhaps it's not worth it.

[Withwnar]

if a father is in foreign lands, then the son/princess CoA in capital.

Oh, is that how the game works? Didn't know that. What if the father is in own-faction lands but not in a settlement? Does the child CoA at his location, out in the field with him?

So a player may abuse the system ... Perhaps it's not worth it.

Yet something that players who have no intention of abusing might really enjoy. At the end of the day if players want to cheat then they can find many ways to do so, like auto_win battles.

Nevertheless, what if instead the father gets a hidden trait when he CharacterTurnEnds in a settlement with the building (and the trait is removed when he does not) then use a FatherTrait test for it in the CoA trigger? It means "my father was near building x while I was coming of age, therefore so was I because I CoA at his location".

It could go a step further so that the father must spend (e.g.) 3 consecutive turn ends in such a settlement before he gets the hidden trait, and loses that trait as soon as he does not turn-end in such a settlement. This implies that the child not only CoA in a 'better' settlement but that he was there for the turns (years?) leading up to the CoA, while still a child, his formative years.

EDIT: ah, an obvious flaw: if the father dies then he'll be stuck with/without that trait for the rest of the game; his children (yet to CoA) will/won't get the proper trait regardless of where they eventually CoA.

[Jurand of Cracow]

What if the father is in own-faction lands but not in a settlement? Does the child CoA at his location, out in the field with him?

This is the situation I've experienced recently: the child lands in the settlment of the province. I don't know though how the game interprets the location for CoA triggers - is he already there, or he is somewhere being flied by the storks
The situation CoA in-foreign-lands (and sons landing in capital) I'm 99% certain, but I'll check and report here.

EDIT: ah, an obvious flaw: if the father dies then he'll be stuck with/without that trait for the rest of the game; his children (yet to CoA) will/won't get the proper trait regardless of where they eventually CoA.

I don't think it's a problem - we may craft the triggers it in such a way that the children get additional benefits if the father has the trait, but if he doesn't - they simply don't get them. Having no father has its drawbacks, after all.

[Withwnar]

the child lands in the settlment of the province

Yeah? Huh. Never really noticed. If that means that CoA always happens in a settlement then the EndedInSettlement condition from my earlier post probably isn't needed. No harm in having it though.

FatherTrait still works for his kids even if the father is dead. The game knows what traits he died with. e.g. If the father has that hidden trait when he dies then his CoA child will get the building trait even if the child does not CoA in a settlement with that building. Which is wrong.

[Jurand of Cracow]

Guys,
is there a condition which would relate a trigger for a trait with squalor in a settlement, or just the fact if the number of population is rising or decreasing?
JoC

[Withwnar]

Not that I know of. SettlementPopulationMaxedOut is the only thing that seems near relevant.

[Jurand of Cracow]

Thanks, Withwnar. It's what I thought, but what's the condition "HealthPercentage" - I've found it in Docudemons 4.0.
Just to make sure on another issue: the condition "and CharacterAge > 61" relates to age, not turns, right? The engine knows it, if a mod is 2TPY or 4TPY?
And one more question: if there're in the battle two generals of one army fighting, are they both checked for condition "GeneralHPLostRatioinBattle", or only the commanding one?
I'm really gratefull for your assistance!
JoC

[Gigantus]

Thanks, Withwnar. It's what I thought, but what's the condition "HealthPercentage" - I've found it in Docudemons 4.0.
Just to make sure on another issue: the condition "and CharacterAge > 61" relates to age, not turns, right? The engine knows it, if a mod is 2TPY or 4TPY?
And one more question: if there're in the battle two generals of one army fighting, are they both checked for condition "GeneralHPLostRatioinBattle", or only the commanding one?
I'm really gratefull for your assistance!
JoC

No idea what the HealthPercentage relates to, percentage remaining after deducting squalor etc?
CharacterAge is part of the info stored for a character, aging happens automatically at the change from winter to summer season - not turn based.
GeneralHP applies to all participating (only leading?) generals

[Jurand of Cracow]

No idea what the HealthPercentage relates to, percentage remaining after deducting squalor etc?
CharacterAge is part of the info stored for a character, aging happens automatically at the change from winter to summer season - not turn based.
GeneralHP applies to all participating (only leading?) generals

Thanks' Gigantus!
Is there a special condition for telling if there's a winter turn (or any another season), or the mod needs a trait counting the turns and telling the season for each general?
The last sentence I don' fully understand: all participating generals, OR all leading the armies (eg. there're two armies of my forces taking part in a battle , and only two generals are checked - one from each army)?
JoC

[Withwnar]

I haven't used any of those conditions.

[Gigantus]

Most mods use a season script, you can use the counters from there to establish the season. No other way I know of.

Regarding the 'last sentence': I am not totally sure if it applies only to the leading general (most conditions only test for the leading general) or for all participating generals in one army.

[Jurand of Cracow]

Thanks' Gigantus!

I've just fallen into the "GeneralHPLostRatioinBattle" issue. I couldn't find so much information, some thread (also with your participation), but no conclusive answers. In tha EDA is not used, but in the EDCT yes. What do you think about using it?

And one more issue: when the engine checks for triggers (eg. PostBattle or TurnEnd) which file is checked first: for traits (EDCT) or for ancillaries (EDA)?

cheers
JoC

[Withwnar]

Given the description - "Test to see what the HP lost ratio of the prior battle was" - seems to me it's a condition to be used with the PostBattle event. Vanilla Kingdoms EDCT does so, only with that event.

So it's more a question of who PostBattle fires upon. I have found that it seems to only fire on the commander of the battle, not reinforcement commanders nor other generals in the army(s). If the commander dies then it still fires, presumably on whoever was left commanding the army in his stead (not sure of that) even if its only a captain. It doesn't fire if there are no survivors. i.e. It seems to fire on whoever is leading the army after the battle.

So if you have two generals in an army (or one in this and one in the reinforcement army), PostBattle is only going to fire on one of them. So GeneralHPLostRatioinBattle can only be used with one of them, as there's no event to use it with for the other general.

However, the demons say its both a strat and battle condition. If there's a battle event that fires on any general, not just the commander, then perhaps it could be used there too and thus work on anybody. In battle that would be, not autoresolve. i.e. Battle-scripting, using the BattleXXX events. Not something I'm familiar with myself.

EDIT: it is also used in vanilla EDA, and in the four Kingdoms expansions' EDCT/EDA, always with PostBattle.

"Battle-scripting": a poor choice of words, as we're not talking about script here. "Battle-triggering" would be better. I guess that BattleXXX events can also be used as EDCT/EDA triggers (?).

[Jurand of Cracow]

Well, if you both - Withwnar and Gigantus - cannot tell if the postbattle triggers fire for the "secondary" generals in the armies, who can? I conclude that nobody knows it and I'll assume that the triggers do not fire for those secondary generals.

However, my question about GeneralHPLostRatioinBattle was a bit different: does it work at all? I've searched through fora and the conclusion I found was "don't use it" because triggers containing this condition behave in strange ways, eg. differently for manual and autocalc battles. The Docudemons present it as a viable condition but I have the impression it's not. Perhaps I'd better use PercentageBodyguardKilled, as it is in EDA.

And for synchronizing the effects of the triggers I'm very much interrested in the answer to the question: "when the engine checks for triggers which file is checked first: for traits (EDCT) or for ancillaries (EDA)"?

cheers
JoC

[Withwnar]

I'll assume that the triggers do not fire for those secondary generals.

PostBattle doesn't, no. I'm quite convinced of that. Unless the primary general dies, in which case one of the secondary generals will become the primary general and PostBattle will fire on him instead.

"don't use it" because triggers containing this condition behave in strange ways, eg. differently for manual and autocalc battles

That vanilla uses it in seven places suggests that it does work. But yeah, working in strange ways wouldn't be a first.

which file is checked first

EDCT then EDA for any given event type. campaign_script before both. EDG (guilds) and DFS (faction standings) have triggers too but not sure when they happen in the sequence.

Note that CharacterTurnEnd and CharacterTurnEndInSettlement are different events with different timings. CharacterTurnEnd fires first. i.e. That fires in EDCT then EDA, then CharacterTurnEndInSettlement fires in EDCT then EDA (I think). One might expect both events to fire in EDCT before either fires in EDA, given that they're both "Character Turn End" type events.

[Jurand of Cracow]

Thanks, this is very, very useful for me!
Also that strange difference between CharacterTurnEnd and CharacterTurnEndInSettlement.

I've checked how the engine behaves and after several dozen turns I see that the same percentages in GeneralHPLostRatioinBattle produce a point in a trait (Wounded) in autocalc, and no results in normal fights (while they should, they're quite high). So I conclude that this should not be used, and vanilla was already broken. I'm going to fix it in my fix...

[Jurand of Cracow]

Hi Guys,
I've got further, related questions:
- what is the order in which the following events happen: "ComesOfAge" and "CharacterBecomesAFather" and "CharacterTurnStart"?
- if a general had been adopted by somebody, will the triggers related to his father ("FatherTrait X") fire depending on the adopting character, or he is just considered fatherless?
- if father of a general is alredy dead and in a trigger there's a condition "FatherAttribute Piety > 3", will this trigger fire?
- which parameter should I modifiy to make deserting all the troops without a general and not in a settlement ?
- do we know how many hit points a general has by default?
cheers
JoC

[Gigantus]

ComesOfAge should be before BecomesFather - at least where logic is concerned
Adopting is always into the family tree, so I would guess that the FatherTrait condition will work as usual
FatherTrait will fire even if the father is dead
Troops deserting in a settlement is fairly impossible - it's the revolt of the settlement that triggers the 'desertion'
There is a parameter in descr_campaign_db that governs the desertion probability of captains, unceasing the value increases the chance of desertion:

   <revolt>
      <captain_modifier float="0.4"/>

We set that value to 12.4 in 1648 and with that value you are bound to loose that captain led army within 8 turns (latest).

[CavalryCmdr]

what did you set the ai_revolt_modifier float= to offset that? Or did you find a way to have the AI use generals more often?

If I'm not mistaken the captain_modifier float= only affects armies outside of a settlement. I think the line in descr_settlement_mechanics

<factor name="SOF_NO_GOVERNANCE">

would affect settlements with captains instead of generals.

[Gigantus]

We used <ai_revolt_modifier float="0.05"/>

It's possible that the captain_modifier setting gets ignored when in settlements - thus making the captain led army in a town\fort\castle basically impossible to desert (we never had captain led garrisons desert in 1648).

The settlement mechanic entry is supposed to affect settlements if no named character is present, but it doesn't work that way as no negative effect can be seen when compared to effects when a named character is present. It does however take effect if no garrison at all is in a settlement. SOF_NO_GARRISON would have been more descriptive but I guess it would have been easily mixed up with the positive SOF_GARRISON entry.