Traits that are bugged in 1.2 with fixes. Part 1: Scarred, Farmer, Trader

[gregab25]

Scarred:

This is the most obvious so I'll start here first. Here are the triggers.


;------------------------------------------
Trigger battle1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle > 0.3

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

;------------------------------------------

Translation:

After a battle if your general has greater than 30% of his hit points remaining you have a 30% chance of receiving one point of BattleScarred and a 15% chance of receiving one point in Brave.



;------------------------------------------
Trigger battle1R
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle > 0.3
and CultureType roman

Affects BattleScarred 1 Chance 30
Affects RomanHero 1 Chance 15

;------------------------------------------

Translation:

After a battle if your general has greater than 30% of his hit points remaining and you are roman you have a 30% chance of getting one point in BattleScarred and a 15% chance of getting one point in RomanHero.

Why it is bugged:

1. The greater than signs should be less than signs. You should be scarred when you are seriously wounded. IE LESS than 30% of your hit points should be remaining. As it is now you automatically trigger this test if your general does not even fight b/c he WILL have 100% of his points remaining.

2. If you are roman you are tested twice per battle. It is obvious by the name of the triggers that one is meant to be for romans only and the other for non roman cultures. I'll take a wild guess and say the "R" in trigger battle1R stands for Roman.

How to fix:

Make these changes highlighted in bold to the export_descr_character_traits file.

;------------------------------------------
Trigger battle1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle [B]

[gregab25]

Damn, it truncated my post and i don't know why. I don't see an edit button either. Here is the rest of the post.

How to fix:

Make these changes highlighted in bold to the export_descr_character_traits file.

;------------------------------------------
Trigger battle1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle [B]

[Red Harvest]

Most likely you are using some combination of symbols that it sees as an arrow. It truncates when you do this (very irritating.) Use "preview post" before you submit to see whether or not it is going to truncate.

[gregab25]

Seems to be a bug with using bold. So i cannot highlight the changes. Just make the triggers look like these to make the fixes.

How to fix:

Make these changes highlighted in bold to the export_descr_character_traits file.

;------------------------------------------
Trigger battle1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.3
and not CultureType roman

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

;------------------------------------------
;------------------------------------------
Trigger battle1R
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.3
and CultureType roman

Affects BattleScarred 1 Chance 30
Affects RomanHero 1 Chance 15

;------------------------------------------

Now, you will only be scarred if your general has LESS than 30% of his hit points remaining, and you will only be tested once if you are roman.

Please do not reply yet unless you have info on how to tidy up this post and clear the errors. IE an edit button.

[hrvojej]

Use code tags to post code fixes (the # symbol aobve the text).

[gregab25]

Farmer

Default Triggers:


;------------------------------------------
Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished >= farms

Affects GoodFarmer 1 Chance 100

;------------------------------------------

Translation:

When a character is a governor and a building is completed in his town and the level of the building finished is greater than or equal to the level of the farm in the settlement then you have a 100% chance of getting 1 point of GoodFarmer.


;------------------------------------------
Trigger governing6
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished >= farms

Affects BadFarmer 1 Chance 8

;------------------------------------------
Translation:

When a character is a governor and a building is completed in his town and the level of the building is NOT greater than or equal to the level of the farm then the governor has a 8% chance of receiving one point in the BadFarmer trait.

Why it is bugged:

1. Again the greater than signs should be less than signs. You should be a good farmer when your level of farms is greater or equal to your other buildings not the opposite.

2. You should be a bad farmer only when you ignore farms and build other buildings first. IE you built a building that is NOT LESS than the level of farms in the settlement.

The fixes:

Make the triggers look like this.


;------------------------------------------
Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished < = farms

Affects GoodFarmer 1 Chance 100

;------------------------------------------

*do not leave a space in between the less than and equal sign. i had to leave a space there or the board will truncate this post.


;------------------------------------------
Trigger governing6
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished < farms

Affects BadFarmer 1 Chance 8

;------------------------------------------

Now, any time you build building that is less than or equal to the level of farms you will get one point in GoodFarmer, and if you build a building that is NOT less than the level of farms you will get an 8% chance at becoming a bad farmer.

I am 99% sure this is the way CA intended it to be, but CA would need to comment for certainty.

The thresholds are very high for becoming a Good Farmer. For the first level you need 6 points. So even if you build a farm first you still need to build 6 more other buildings that are of equal or less level than your farms before you will receive the first level in GoodFarmer which is "Grower."

[therother]

Seems to be a bug with using bold.Bold works fine. You were using "< " in a way that the board suspects might be html tags, which is a serious security worry for forums, and hence everything after it is removed. Just don't put anything directly after a < and you'll be fine.

[gregab25]

Trader

Default Triggers:


;------------------------------------------
Trigger governing10
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished >= trader

Affects BadTrader 1 Chance 1

;------------------------------------------

Translation:

When a governor completes a building and the level of the building is NOT greater than or equal to the level of trader building the you have a 1% chance of receiving 1 point of BadTrader.


;------------------------------------------
Trigger governing11
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished >= trader

Affects GoodTrader 1 Chance 50

;------------------------------------------

Translation:

When a governor completes a building and the level of the building is greater than or equal to the level of the trader you have a 50% chance of gaining one point in GoodTrader.


;------------------------------------------
Trigger governing11b
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished >= port

Affects GoodTrader 1 Chance 80

;------------------------------------------

Translation:

When a governor completes a building and the level of the building is greater than or equal to the level of the port you have a 80% chance of gaining one point in GoodTrader.


;------------------------------------------
Trigger governing11c
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished >= roads

Affects GoodTrader 1 Chance 80

;------------------------------------------

Translation

When a governor completes a building and the level of the building is greater than or equal to the level of roads you have an 80% chance of gaining one point in GoodTrader.

Why they are bugged:

Again its those damn greater than signs being reversed! ~D

How to Fix:

Make these corrections to the triggers:


;------------------------------------------
Trigger governing10
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished > trader

Affects BadTrader 1 Chance 1

;------------------------------------------

Here I removed the NOT from the condition. So if the building IS greater than the trader you have a chance for BadTrader. Or you could leave the NOT in the condition and make the sign a less than or eqaul to sign.


;------------------------------------------
Trigger governing11
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished > trader

Affects GoodTrader 1 Chance 50

;------------------------------------------

Here i added the NOT to the condition and removed the equal sign so that now if the building finished is NOT a level greated than the level of trader you have a chance at GoodTrader.


;------------------------------------------
Trigger governing11b
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished > port

Affects GoodTrader 1 Chance 80

;------------------------------------------

Again, I added the NOT and removed the EQUAL SIGN from the condition so that now if the building is not a level greater than the level of the port you have a chance at GoodTrader. Again, you could also try just reversing the sign in the orginal to a less than or equal sign.


;------------------------------------------
Trigger governing11c
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished > roads

Affects GoodTrader 1 Chance 80

;------------------------------------------

Same as above. Added NOT and removed EQUAL.

NOTE:

For all the above fixes I added a NOT or removed the NOT depending on which ever the condition did not have. I also removed all the equal signs from the arguments. You could just as easily leave the NOT conditions as they were and instead reversed the signs from greater than to less than signs. Ultimately the effect is the same I believe.

I believe the above corrections make the traits behave as CA intended them to. These are not intended to be mods. Again however, CA would have to comment for me to be 100% sure.

Also, the Thresholds on gaining a rank in GoodTrader are the highest in the game I believe. They are 24, 48, and 60 for each rank respectively. So they are still very difficult to receive.

[gregab25]

I am now done with this post so please reply if you wish. If you suspect another trait might be bugged please mention it. I would like to look at. The above three traits seemed the most obviously bugged to me.


Bold works fine. You were using "< " in a way that the board suspects might be html tags, which is a serious security worry for forums, and hence everything after it is removed. Just don't put anything directly after a < and you'll be fine.

Yes, I finally figured that out. Thanks. ~:)

[screwtype]

Nice piece of detective work. I 've only played through half a campaign with 1.2 and I already have scarred, farmer and bad trader traits all over the place!

Thanks I will try those changes. BTW have you tested your theories to see if they work?

[Jambo]

Interesting.

But I'm not sure that the scarred trait, amongst others, is so easily fixed as originally thought. You might want to pop over to this thread in twcenter for some more information on the various traits that involve HPs and Generals in battle:

http://www.twcenter.net/forums/index.php?showtopic=21798

The problem seems to be the general being awarded these traits when not getting involved in the battle. This is irrespective of which way the ratio is annotated. Whether this means the HPs condition isn't working or more likely, the GeneralFoughtInBattle condition, i'm not entirely sure. However, it appears this can be somewhat remedied by the using the GeneralNumKillsInBattle condition instead.

Cheers

[Simetrical]

Are you sure that "farm" and "trader" in the SettlementBuildingFinished compare the level of existing farms/traders to the newly-finished building? I assumed that "Condition SettlementBuildingFinished >= farms" returned true if, when the trigger was checked, the settlement in question had any farm, no matter what building was finished. In other words, if you build something when a farm exists in the settlement, you get +1 to GoodFarmer (which, as you noticed, really isn't a lot), while if you build anything before a farm, you risk getting BadFarmer. In this case, the current sign makes sense.

I don't know which of us is right. Yours makes more sense, I must agree. It should be fairly simple to test.

-Simetrical

[gregab25]

BTW have you tested your theories to see if they work?

Yes. I have tested them and I am 100% confident in the BattleScarred and Trader fixes.

However I did some more testing on the Farming triggers and I am now recommending anyone that wants to apply these fixes, fix the farming triggers as I fixed the Trading triggers. In other words use NOT in the condition and remove the EQUAL SIGN. This is they way I had it in my file.

In the Farming post above, I simply reversed the greater than sign because I thought it would be simpler for everyone to see and to fix. However, after more testing it seems the game has a problem using the < = argument. It seems to either ignore the < sign and only use the = sign or the not work at all.

So, use the NOT condition and remove the EQUAL SIGN.

If you need to see what the fixes look like for the farming section using the NOT condition and without the EQUAL SIGN, request it and I will post it.

Once you make these corrections, I am sure the farming trigger section will be 100% good as well.

If you want to test it, drop the threshold down to 1,2, and 3 in the trait data section and you will see in a few turn that they are working.

BTW, everyone should backup there file and store it in a safe place before making changes.


The problem seems to be the general being awarded these traits when not getting involved in the battle.

This is exactly what the corrections above fixed. The general was getting tested even when he did not fight because the default argument called for him to be tested when he had greater than 30% of his hit points remaining. If the general does not fight, how many hit points will he have remaining? That's right, 100%. 100% is > than 30% which triggers the test. So the general had a chance of becoming scarred even though he did not fight.


Are you sure that "farm" and "trader" in the SettlementBuildingFinished compare the level of existing farms/traders to the newly-finished building? I assumed that "Condition SettlementBuildingFinished >= farms" returned true if, when the trigger was checked, the settlement in question had any farm, no matter what building was finished. In other words, if you build something when a farm exists in the settlement, you get +1 to GoodFarmer (which, as you noticed, really isn't a lot), while if you build anything before a farm, you risk getting BadFarmer. In this case, the current sign makes sense.

I don't know which of us is right. Yours makes more sense, I must agree. It should be fairly simple to test.

I thought this too at first, because I like you, was not sure what "SettlementBuildingFinished" meant. However, I kept getting BadFarmer traits and never any GoodFarmer Traits. So, after a bunch of testing, I am convinced it compares the level of farms vs the level of building completed.
Apply the fixes above and you will see it works. Don't reverse the greater than sign. I don't recommend that now. Use the NOT in the condition and remove the equal sign.

It also makes more sense this way. If you prioritize farms and build them first, it makes sense that you would be more likely to receive the GoodFarmer trait.

[Jambo]

Hi, gregab25, I take it you didn't read that thread at twcenter then?

Here's a quote from that thread of one of the recent tests I did:


Ok, regarding the GeneralHPLostRatioinBattle and GeneralFoughtInCombat conditions, this is far more complicated than first expected. Or least it certainly seems to be.

To try to fully understand the function of these I set up a test based on the heroic_saviour ancillary. For my heroic saviour trait I had already removed the conditions WonBattle and not Routs and for the test I increased chances of being awarded the ancillary to 100% - so it looked like this:

Trigger trigger_heroic_saviour
WhenToTest PostBattle
Condition GeneralHPLostRatioInBattle "less than"= 0.2
and GeneralFoughtInCombat
and IsGeneral
AcquireAncillary heroic_saviour chance 100

For the test I changed the 7 ancillaries down from heroic saviour to have the same conditions but each with a varied HP condition. Inclusive of the heroic saviour these were "less than"= 0.2, 0.5, 0.8 and 1 and >=0.2, 0.5, 0.8 and 1.
So, armed with this I started a new Julii campaign and marched my leader to assault Segesta. When I assaulted the rebels I kept my leader out and away from the battle. I won the battle and upon returning to the campaign map I found I had received the first 7 of the 8 ancillaries (possibly a limit?). Repeating this battle changing the values to actual percentages rather than ratios didn't alter the outcome and neither did involving the general in the battle. It's fair to say I've reached a standstill and the only thing I could see governing these ancillaries seemed to be the chance of receiving them.

Take it from me, the stated change to the scarred trait doesn't work as you expect. I'm not sure whether the GeneralFoughtInCombat or the HP condition is bogus, but something isn't right.. The only way I can envisage some results is using the GeneralNumKillsInBattle condition. I havem't tested it in full, but at least this one forces the general to get involved for the traits to be awarded.

maybe someone can test and verify?

Cheers

Edited for the "less thans"

[gregab25]

Hi Jambo, I think I know why that wasn't working for you.

First of all I can see that by doing the math that ancilliary is going to be very hard to receive.

Second, i have found that using "less than"= does not work for some reason as i stated above. Maybe it is like html code in some way. To be honest i don't know the reason, but i know it doesn't work from all the tests i ran trying to figure out farming. You can make the same argument as a < = to though by using the condition "NOT" though.

Third, lets clarify that "GeneralHPLostRatioInBattle" is the general's HP at the end of battle divided by his HP's at the start of Battle.

Let's take a look. Here is the trigger you were using.


Trigger trigger_heroic_saviour
WhenToTest PostBattle
Condition GeneralHPLostRatioInBattle "less than"= 0.2
and GeneralFoughtInCombat
and IsGeneral
AcquireAncillary heroic_saviour chance 100


Your argument says: After a battle if a General has less than or equal to 20% of his hit points remaining and he fought in combat then you have a 100% chance of receiving the ancillary Heroic Saviour.

I believe, correct me if i am wrong b/c i am not sure about this, that the default HP's for a General's Bodyguard of Heavy Cavalry is 2HP. So, it would be mathematically impossible to receive that ancillary with a default general, because to go below 20% your general would have to be dead.

IE:

2/2 = 100% - is not below the 20% requirement.
1/2 = 50% - is not below the 20% requirement.
0/2 = 0% - meets the requirement but your general is dead.

However, it is my understanding that a general that is also the faction leader receives 5 more HP for a total of 7HP. So it would be mathematically possible for him to receive the ancillary using your arguement if he had only 1HP remaing of his 7HP. 1/7 = 14%. But that still is a very low probability.

I have not investigated any of the ancilliaries yet or possible bugs with them. So I am not really familiar with the Heroic Saviour Ancilliary, but he sounds good. And, looking at the math, it may be that CA intended for it to a) only your faction leader or faction heir to be able to receive it, and b) the mathematical probability even with a faction leader or heir is very low.

But As i said above i believe the < = argument to be bugged. so i would still switch this trigger to read like this no matter what other changes you should make.

----------------------------------------------------
Trigger trigger_heroic_saviour
WhenToTest PostBattle
Condition Not GeneralHPLostRatioInBattle > 0.2
and GeneralFoughtInCombat
and IsGeneral
AcquireAncillary heroic_saviour chance 100
----------------------------------------------------

All i did was change this:

Condition GeneralHPLostRatioInBattle "less than"= 0.2

To this:

Condition Not GeneralHPLostRatioInBattle > 0.2

If you think about it, it is still the same arguemnt just said in a different way.
And it avoids using the < = to sign which I believe is bugged or non functional.

Now if you are dead set on getting the ancilliary Heroic Saviour, you have the option to change several things in the trigger to get it.

For Example:

Ex. 1:
----------------------------------------------------
Trigger trigger_heroic_saviour
WhenToTest PostBattle
Condition GeneralHPLostRatioInBattle > 0.2
and GeneralFoughtInCombat
and IsGeneral
AcquireAncillary heroic_saviour chance 100
----------------------------------------------------

Here I removed the word "Not" from the condition so that now at the end of battle if my general has more than 20% of his HP's remaining he has a 100% chance of receiving the ancilliary. Very good Probability.

Ex. 2:
----------------------------------------------------
Trigger trigger_heroic_saviour
WhenToTest PostBattle
Condition Not GeneralHPLostRatioInBattle > 0.8
and GeneralFoughtInCombat
and IsGeneral
AcquireAncillary heroic_saviour chance 100
----------------------------------------------------

Here I simply changed the value for the qualifier from 0.2 to 0.8. Now if the general does NOT have more than 80% of his HP's remaining he will qualify. Good probability with your general having to fight as the 2nd condition.

Anyways, there are several ways to get that ancilliary if you want him. I hope I have shown you why you were having such a hard time getting the ancillary and ways to fix it. For some generals it was just mathematically impossible and extremely hard for others.

Also thanks for bringing this to my attention as it seems there are some bugs in the ancillary triggers too that I want to look into.

[tai4ji2x]

gregab:

"< 0.3" is a little extreme, i think - meaning you'll have to lose 70% of your HP. campfreddie's fix brings it to "< 0.7" which is likely to be what CA originally intended, with 30% HP lost as the trigger. however, i still think that's a little too extreme as well - in the OTHER direction (ie, still too easy to get scarred). i myself put it to "< 0.6"

[tai4ji2x]

also: could you post a more current version of your farmer/trader fixes?

[gregab25]

"< 0.3" is a little extreme, i think - meaning you'll have to lose 70% of your HP. campfreddie's fix brings it to "< 0.7" which is likely to be what CA originally intended, with 30% HP lost as the trigger. however, i still think that's a little too extreme as well - in the OTHER direction (ie, still too easy to get scarred). i myself put it to "< 0.6"

Hi tai4ji2x,

Well, the value you, or anyone, wants to set it at is just a matter of personal preference. For me, less than 30% is good because a) I believe to be scarred you should be seriously wounded and 2) the value of .3 is the value CA intended it for it to be.

I think anyone should be able to surmise that 0.3 is the correct value if you look at this threads first post. The error in the Scarred trait trigger was a reversal of signs not in values. Reversal of signs is a simple and common error to make if you are not careful, and much more likely than CA not knowing what value they wanted.

With any of these corrections, I am not not trying to mod the game to my own personal tastes. I want to play the game the way CA intended it to be. I am just trying to make corrections to errors in math, coding, or whatever you want to call it.

With that said, you can mod the game however you like, so slap any value in there that floats your boat. ~D

To each his own.
~:cheers:

[tai4ji2x]

i'm actually not sure if that's what CA intended either... for the logic i'm trying to explain, here's a excerpt from the campfreddie fix's readme (http://www.twcenter.net/forums/index.php?showtopic=21549 and http://www.twcenter.net/downloads/db/?mod=359)


The trait triggers for scarred and berserk traits use the GeneralHPLostRatioinBattle query.

They were supposed to give you a 30% chance of getting scarred traits if your general lost >30% of his hitpoints in a battle - but the developers messed it up.

GeneralHPLostRatioinBattle is supposed to find the ratio of hitpoints lost by your general, from 0 (full health) to 1 (dead).

In v1.0 and v1.1, the developers mistakenly used a percentage figure (>30%), which meant that the trigger neverworked (your general would have to be 30x dead to give you the trait).

In v1.2 they set it to a ratio instead of a percentage (30% = 0.3 ratio). However, this revealed that the trait trigger GeneralHPLostRatioinBattle was bugged. All generals would get scarred in battle, even if they didn't get involved in the fight!

I discovered that the query GeneralHPLostRatioinBattle was actually giving you the ratio of hitpoints remaining and NOT the ratio of hitpoints lost. Therefore, I've changed the triggers to GeneralHPLostRatioinBattle "less than" 0.7, so that the trait is gained when you have "less than" 70% of your hitpoints remaining at the end of the battle (i.e. you've lost more than 30%)

This reflects what was obviously the original intention of the developers.

The trait is still a little bugged, and seems to be tested for multiple times in one battle. If you really get your general beaten up, you can still jump to hideously scarred in one go (I managed to do this once). That shouldn't happen often though, and it'll never happen if your general avoids getting beaten up.

though i agree with your feeling that the trait should be much harder to get

[hrvojej]

Second, i have found that using "less than"= does not work for some reason as i stated above. Maybe it is like html code in some way. To be honest i don't know the reason, but i know it doesn't work from all the tests i ran trying to figure out farming. You can make the same argument as a < = to though by using the condition "NOT" though.
Well, if this is indeed true, then the character traits file needs some serious rewriting, especially if the >= doesn't work either.

[gregab25]

also: could you post a more current version of your farmer/trader fixes?

Sure. The trader corrections above are still the right ones, but here is how i would correct the farmer triggers now.

Corrected Farmer Triggers:


;------------------------------------------
Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished > farms

Affects GoodFarmer 1 Chance 100

;------------------------------------------

Translation:

When a Governor completes a building and the level of that building is NOT GREATER THAN the level of farms you have a 100% chance at receiving 1 point in GoodFarmer trait.

You could also read this as: When a Governor completes a building and it IS LESS THAN OR EQUAL to the level of farms you have a 100% chance at receiving 1 point in GoodFarmer trait.


;------------------------------------------
Trigger governing6
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished > farms

Affects BadFarmer 1 Chance 8

;------------------------------------------

Translation:
You can probably figure it out from the above translations.

Notes:

2 Notes worth mentioning.

1) the indentions in the triggers I copied and pasted here are not lined up exactly as in the actual export_descr_character_traits file. Use the the spacing for indentions like it is in the file. Just look at the other triggers in the actual file for examples. This is not a biggie, I don't even know if it effects any thing.

2) Remember to backup the traits file, and remember that both trader and farmer traits have high thresholds before you actually qualify to recieve the trait.

For example: The threshold to get the first level of farming is 6. So you will need to build at least 6 buildings at a level below or equal to your level of farms before you will receive the trait.

[Jambo]

So gregab...

Are you saying that all "< " signs do not work in the VnV's file? Would that include BattleOdds, etc, too?

And, one thing that doesn't hold up quite correctly is that in my tests I used the >= signs too. In each test I did the general was awarded the ancillaries when the general wasn't involved in the battle. Thus, the GeneralFoughtInCombat condition doesn't seem to work as intended, and that was the point I was trying to make. I was being awarded the ancillaries even though my general just sat back and admired the battle from afar.

This kind of makes the hitpoints lost settings irrelevant does it not? And, this was the reason I was suggesting using the GeneralNumKillsInBattle condition for the scarred/brave traits instead....

If you have some time, please try and read that thread at twcenter to get a more detailed understanding. I've been working on these traits and their nuances with the CVP team for a long time now.

[tai4ji2x]

jambo:

what about gregab's farmer/trader fixes?

[hrvojej]

And, one thing that doesn't hold up quite correctly is that in my tests I used the >= signs too. In each test I did the general was awarded the ancillaries when the general wasn't involved in the battle.
Have you tried it with just > instead of >=? Maybe it's all of the "or equal to" operators that are bugged?

[gregab25]

Are you saying that all "< " signs do not work in the VnV's file? Would that include BattleOdds, etc, too?

No. First of all i am only talking about "= signs extensively, but I seem to remember not having a problem with these. Beyond that I'm not ready to comment on them without more testing. However if it is like HTML code the < = sign makes an arrow while >= does not. But that comment is pure speculation.

Like I said above I have only worked on the Scarred, Farmer, and Trader traits so far because these were annoying the hell out of me. So, I am not going to speculate if things are bugged until I have a chance to look at them.

Likewise, I haven't looked into any traits that use the GeneralFoughtInCombat condition so I cannot comment on it now. But I have read your post and if what you are saying is true it might be bugged. I would like to look into it later.

I would like to reiterate though that the corrections i have posted thus far do work and have been tested. Please at least try them in game before you arbitrarily dismiss them. If you still think there is something wrong with any of those 3 trait corrections (scarred, farming, trader) we will probably just have to agree to disagree.

[gregab25]

Oops i got cut off again in that last post the first paragraphs are:

No. First of all i am only talking about < signs immediately followed by an equal sign. For now all I am saying definitively is that farming traits did not behave like expected until i got rid of them and instead use the NOT condition as above.

I have not tested >= signs extensively, but I seem to remember not having a problem with these. Beyond that I'm not ready to comment on them without more testing. However if it is like HTML code the < = sign makes an arrow while >= does not. But that comment is pure speculation.

[unseen11]

Wow thnks man, i've been meaning to find out how to fix up some of the bugs in rome and you've helped me big time

Just one question:

You said that for Trader, the lower or equal to building requirements are steep to get Good Trader virtue so maybe the amount of buildings you have to build to get Good Trader are bugged and need to be edited?

[tai4ji2x]

unseen:

i think it SHOULD take a lot to get such a good trait, so i would say that that aspect of it is NOT bugged

[unseen11]

unseen:

i think it SHOULD take a lot to get such a good trait, so i would say that that aspect of it is NOT bugged

Really? having to build 24 less or equal to buildings to get level one Good Trader is allright too you? ok man what ever you say...

though i have to admit im no expert in this whole subject anyway :dizzy2:

[tai4ji2x]

huh? the first threshold is 6, not 24

EDIT: oh, whoops, i was thinking about farmer. well, trader is a powerful trait - i think for most factions, once you get some sea trade going, you're making enough money as it is already. but like you said, to each their own ;)

just another note - there are three building triggers for goodtrader: road, port, and trade. so you could easily have 3 points added in one turn from the building triggers alone. plus, there is also a trigger if your governor stays where there's a trading temple - and that alone is a big 12 point jump

[unseen11]

yeh i suppose i didnt take the 3 trade opportunities in consideration but the level one roads might not count as trade.

I suppose as long as when you get a new governors building upgrade and build a trade or port or road building up to its max level then the good trader trait won't be to hard to get (as long as the governor lives long enough to get it)

[Sinner]

just another note - there are three building triggers for goodtrader: road, port, and trade. so you could easily have 3 points added in one turn from the building triggers alone.

You can't get 3 points in one turn by building because you can only complete one building per turn. Instead you'd be able to get a maximum 3 points per level of settlement (excluding temple effects), and once you've got those 3 you have to wait until the settlement grows to the next level or move your governor to another settlement.

Regarding the Farmer/Trader traits, I've been reading the triggers as follows...

Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished >= farms

Affects GoodFarmer 1 Chance 100

To me that says when a building is completed and it's any level of farm then you have a 100% chance of getting 1 point towards GoodFarmer. This sounds logical to me, your governor oversees the building/improvement of his settlement's farmland and his agricultural skills improve.

Trigger governing6
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished >= farms

Affects BadFarmer 1 Chance 8

While this says that when a building is completed and it's not a farm then you have a 8% chance of getting 1 point towards BadFarmer. Again it sounds logical to me, by effectively ignoring farming your governor's agricultural skills perhaps atrophy and he maybe becomes a bad farmer.

There is what I consider a bug with the latter since that trigger occurs even if you've already built the farm for that level of settlement and so have no farm available to build. Perhaps that's why CA set the chance of acquiring GoodFarmer to 100% and BadFarmer to just 8%, even with the BadFarmer trigger occuring more frequently your governor should hopefully gain more GoodFarmer points and thus force the opposing BadFarmer trait to be ignored.

[Jambo]

I'm in agreement with Sinner here.

Reason being "trader", "roads", "port" and "farms" are only the lowest building in the corresponding upgrade tree. Respectively, the upgrade trees are "market", "hinterland_roads", "port_buildings" and "hinterland_farms".

Therefore, I'm not sure how this factors into the calculations and reasoning here? For instance, what happens when the "> ______" no longer becomes relevant, e.g. for "> trader" and the trader becomes a market, forum, great_forum or curia?

[gregab25]

Just one question:

You said that for Trader, the lower or equal to building requirements are steep to get Good Trader virtue so maybe the amount of buildings you have to build to get Good Trader are bugged and need to be edited?

I think tai4ji2x answered this pretty well here so i won't go over it again:


just another note - there are three building triggers for goodtrader: road, port, and trade. so you could easily have 3 points added in one turn from the building triggers alone. plus, there is also a trigger if your governor stays where there's a trading temple - and that alone is a big 12 point jump



Regarding the Farmer/Trader traits, I've been reading the triggers as follows...

Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished >= farms

Affects GoodFarmer 1 Chance 100

To me that says when a building is completed and it's any level of farm then you have a 100% chance of getting 1 point towards GoodFarmer. This sounds logical to me, your governor oversees the building/improvement of his settlement's farmland and his agricultural skills improve.


You are right that the game reads the default triggers in that manner. And that is precisely why they are broken. Let me explain.

How many farms can you build that are greater than the first level of farms? Answer = 4.

Now, what is the threshold for receiving the first level in GoodFarmer? It is 6.

Therefore, you can see that with the default settings your governor will never receive the first level of GoodFarmer which is "Grower." Because you cannot break the threshold.

This is why in default patch 1.2 you never see your Governor getting any GoodFarmer traits. ~:eek:

I believe the corrections i posted fix this problem. Where if you prioritized farms, and then built 7 more buildings of equal or lesser value you would then meet the threshold and receive first level of the GoodFarmer trait.


Trigger governing6
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished >= farms

Affects BadFarmer 1 Chance 8

While this says that when a building is completed and it's not a farm then you have a 8% chance of getting 1 point towards BadFarmer. Again it sounds logical to me, by effectively ignoring farming your governor's agricultural skills perhaps atrophy and he maybe becomes a bad farmer.

There is what I consider a bug with the latter since that trigger occurs even if you've already built the farm for that level of settlement and so have no farm available to build. Perhaps that's why CA set the chance of acquiring GoodFarmer to 100% and BadFarmer to just 8%, even with the BadFarmer trigger occuring more frequently your governor should hopefully gain more GoodFarmer points and thus force the opposing BadFarmer trait to be ignored.

Again, you are right about the game reading it that way, and again that is why it is bugged and you yourself take note that something is amiss. However, you did not account for the factor of thresholds. Lets look at it:

The Threshold for BadFarmer is only 1 compared to the 6 for GoodFarmer. This means with the way you are reading (which is the way the game was handling it), that EVERY TIME you build a building that is NOT a farm, you get tested for BadFarmer. Since the threshold is only 1, that means you have an 8% chance of becoming a BadFarmer every time you complete a building.

This is why in default 1.2 the governors are picking up BadFarmer traits very quickly. The buildings early on only take a couple turns to complete, so your governor is being tested every turn or every other turn for the trait.

Again, the correction i suggested fixes this problem. And i explained how it does so in that post.



I'm in agreement with Sinner here.

Reason being "trader", "roads", "port" and "farms" are only the lowest building in the corresponding upgrade tree. Respectively, the upgrade trees are "market", "hinterland_roads", "port_buildings" and "hinterland_farms".

Therefore, I'm not sure how this factors into the calculations and reasoning here? For instance, what happens when the "> ______" no longer becomes relevant, e.g. for "> trader" and the trader becomes a market, forum, great_forum or curia?

I'm not sure I understand your question, but I'll try to stab at it anyway. You can tell me if you were talking about something else.

As I said, it is my belief that the "SettlementBuildingFinished", the "trader", "roads, "port", and "farms" used in the triggers refer to any level of that respective building. e.g. "farms" can mean "land clearance", "communal farming", "crop rotation", "irrigation", and "latifundia."

Have you had a chance to try the corrections yet?

Also, I replied to your thread over at TWcenter. ~:)

[Ginger]

Can I just say, this is a really useful thread, Keep up the good work guys!

~:cheers:

[Jambo]

Greg, I've sent ya a PM. I'll try having a look into these in more detail and see if I can verify your theory. I do agree that the way both myself and Sinner have interpreted it doesn't make much sense.

Cheers

[drone]

Can I just say, this is a really useful thread, Keep up the good work guys!

~:cheers:
No doubt. Two questions.
1. Is there a common thread/doc on the Org that contains all of the mod-fixes to bugs like this? (bugged VnVs, the HA fix, jumping horses, build/recruiting bugs, etc.)
2. If not, can we get one stickied? Sort of like one of the guides, with someone in charge of editing/updating the list.

Not saying I'd like a mod thread (not everyone is going to want the same "adjustments" to units, etc.), just a single point of reference for true fixes that the players can do. Maybe call it "Things to do AFTER installing the game". ~D

[Sinner]

You are right that the game reads the default triggers in that manner. And that is precisely why they are broken. Let me explain.

How many farms can you build that are greater than the first level of farms? Answer = 4.

Now, what is the threshold for receiving the first level in GoodFarmer? It is 6.

Therefore, you can see that with the default settings your governor will never receive the first level of GoodFarmer which is "Grower." Because you cannot break the threshold.

You can quite easily break the threshold, simply move your governor to another settlement. Remember he only needs to be present the turn that the farm is completed so if you stagger the building times correctly you could have a governor circling around a group of cities arriving just before a farm is completed, thus gaining a point towards GoodFarmer every turn.

Personally I don't like the logic of changing the trigger conditions to give GoodFarmer points on buildings other than farms. It might make acquiring the trait easier, but it's not for me.



Again, you are right about the game reading it that way, and again that is why it is bugged and you yourself take note that something is amiss. However, you did not account for the factor of thresholds. Lets look at it:

The Threshold for BadFarmer is only 1 compared to the 6 for GoodFarmer. This means with the way you are reading (which is the way the game was handling it), that EVERY TIME you build a building that is NOT a farm, you get tested for BadFarmer. Since the threshold is only 1, that means you have an 8% chance of becoming a BadFarmer every time you complete a building.

This is why in default 1.2 the governors are picking up BadFarmer traits very quickly. The buildings early on only take a couple turns to complete, so your governor is being tested every turn or every other turn for the trait.

The problem with the triggers lies in two areas: the most important being that the condition doesn't allow for the possibility that the appropriate building has already been built for that level for settlement, it's only then that the effects of the unbalanced thresholds become a problem. If you correct the first problem then the thresholds don't matter so much. Conveniently enough, there's already an official example shown in the handling of the BadMiner vice - simply add the condition that the Advisor is recommending a farm/trader is built, although like the BadMiner triggers this will probably require one trigger for every level of building.




As I said, it is my belief that the "SettlementBuildingFinished", the "trader", "roads, "port", and "farms" used in the triggers refer to any level of that respective building. e.g. "farms" can mean "land clearance", "communal farming", "crop rotation", "irrigation", and "latifundia."

I think you're wrong here... the label of farms simply refers to the first level of farming building, the label for all levels is hinterland_farms. Following your reasoning the label mines should mean all level of mines, however the two BadMiner triggers refer to the labels mines and mines+1, but why bother with mines+1 - the second level of mining buildings - if mines covers all levels?

The use of the greater than & less than signs together with the equals in the conditions is how you refer to multiple buildings:
- If you want all levels of farms, you can use '...>= farms'
- If you wanted all but the first level of farms you could use either '...> farms' or '...>= farms+1'
- If you wanted all but the highest level of farms you could use either '...< farms+4' or '...< = farms+3'.

Examples of this occur with the triggers for temples which read '... and SettlementBuildingExists >= temple_of_fun_temple', ie. you only get the trigger on temples or greater, not on shrines.

[tai4ji2x]

:dizzy2: hehe, man, now i'm all confused... whomever can sort all of this out in their head has my respect. oh and please also post your final fix suggestions as well ~;)

[Jambo]

Ok, I have some interesting results performed today:

I modded several traits and ancillaries and then used the non-faction leader Julii general to assault Segesta on the first turn of the Julii campaign. These were the modded traits and ancillaries:


Trigger battle1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.7
and GeneralFoughtInCombat

Affects BattleScarred 1 Chance 100
Affects Brave 1 Chance 100


Trigger battle1R
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.7
and GeneralFoughtInCombat
and CultureType roman

Affects RomanHero 1 Chance 100


Trigger trigger_heroic_saviour
WhenToTest PostBattle
Condition GeneralHPLostRatioinBattle < 0.3
and GeneralFoughtInCombat
and IsGeneral

AcquireAncillary heroic_saviour chance 100


Trigger trigger_shieldbearer
WhenToTest PostBattle
Condition GeneralHPLostRatioinBattle > 0.2
and GeneralFoughtInCombat
and WonBattle
and not Routs
and IsGeneral

AcquireAncillary shieldbearer chance 100

During the battle I charged the general in and he survived with 14 men left (obviously a tough battle). I have slightly modded thresholds to cover the fact that traits obtained from the battle map are doubled. Anyway, on returning to the campaign map, my general had received the following things:

First level Battlescarred
First level RomanHero
Heroicsaviour
No Brave (Romans are excluded from this trait)
And no Shieldbearer

I'm not quite sure on the ramifications of this yet and whether the shieldbearer HP condition is broken with the sign that way around... anyone? As far I was aware the shieldbearer was supposed to be the easier of the two ancillaries to acquire?!

Regards

[gregab25]

You can quite easily break the threshold, simply move your governor to another settlement.

I am not Kreskin so i cannot read CA's mind, but I don't think they meant for your governor to run around all the time to get a single virtue. Of course like I said this is just my opinion and your opinion is as valid as mine. We just disagree.

Another thing to support my reasoning though: Remember you want to get your virtues to a high level in part because they then have a chance to be passed down from father to son. However, in order to qualify for these inherited virtues the father must have a very high level of that virtue. Getting the Farmer and Trader virtues to the level they need to be passed down would be nearly impossible with the default triggers even if you did run your governor from province to province.




Personally I don't like the logic of changing the trigger conditions to give GoodFarmer points on buildings other than farms.

This is just an erroneous statement as that is not what is happening at all. If you apply the corrections i suggest you get points for GoodFarmer because you build Farms before other buildings, not because you build buildings other than Farms. That would just be silly. ~D


The problem with the triggers lies in two areas: the most important being that the condition doesn't allow for the possibility that the appropriate building has already been built for that level for settlement, it's only then that the effects of the unbalanced thresholds become a problem. If you correct the first problem then the thresholds don't matter so much. Conveniently enough, there's already an official example shown in the handling of the BadMiner vice - simply add the condition that the Advisor is recommending a farm/trader is built, although like the BadMiner triggers this will probably require one trigger for every level of building.


Please clarify what the "appropriate building" you are referring to is and why it you came to the conclusion it is the "appropriate building"? Im trying to understand what you are saying. Perhaps you can post an example of how you think the trigger should look?


If you want all levels of farms, you can use '...>= farms'


I'm sorry but I just do not understand this. The >= sign is part of an equation to compare Farms to the previous subject which is "SettlementBuildingFinished." It is not there as a stand alone arguement to qualify Farms. You cannot just arbitrarily remove the subject "SettlementBuildingFinished" and use half of an equation.


Again, if you would try the corrections i suggested before commenting you could at least see that they work precisely as I explained them.

As far as how CA intended them to work, that is open for disagreement. I have tried to use what mathematical evidence that there may be in the files to support my arguements. No one can claim to know for sure what CA meant unless CA stated what they meant. So argueing about what CA intended is really just an exercise in futility. If you disagree with the supporting evidence i gave then just don't make the changes.

Quite frankly, I wish CA would respond with what they intended so we could quit the speculating and get on to fixing the problem. I especially would like them to comment if I am giving wrong advice, because i don't want to that, even if it meant a bunch of egg on my face.

If we knew what they meant it would probably take all of five minutes to fix the problem if the corrections i suggested do not fix it already.

[gregab25]

Heya Jambo ~:) , this is just a quick reply.

I think shieldbearer is for non roman cultures.

And also I sent you a PM.

I'll look at the rest of your post in more detail now.

[gregab25]

Jambo:

From the Ancilliary Data Section -


;------------------------------------------
Ancillary shieldbearer
Image helmeted_soldier_ancillary.tga
ExcludedAncillaries swordbearer
ExcludeCultures roman
Description shieldbearer_desc
EffectsDescription shieldbearer_effects_desc
Effect BodyguardValour 1

;------------------------------------------

If you remove the line ExcludeCultures roman I think it might work.

[Jambo]

I repeated the battle above and got what i was looking for: a battle which awarded the BattleScarred and RomanHero trait, but NOT the heroicsaviour ancillary (meaning that the HP's lost weren't sufficient to award the saviour).

I was never awarded the shieldbearer ancillary and therefore the > sign doesn't appear to work for this condition.

As a result, I can recommend the following GeneralHPLostRatioinBattle conditions for the following traits (as CA intended, but got wrong):

For BattleScarred/RomanHero:

GeneralHPLostRatioinBattle < 0.7
For heroicsaviour:

GeneralHPLostRatioinBattle < 0.3
For shieldbearer (the easiest to get):

GeneralHPLostRatioinBattle < 0.8

Now on to test Greg's Good/Bad Farmer and Good/Bad Trader traits... :)

Regards

[tai4ji2x]

Quite frankly, I wish CA would respond with what they intended so we could quit the speculating and get on to fixing the problem. I especially would like them to comment if I am giving wrong advice, because i don't want to that, even if it meant a bunch of egg on my face.

the more i think about it, i don't think they'll ever tell us, since if they admit that something's screwed up, that would justify a patch... and we wouldn't want that, now would we? :smartass2:

[Jambo]

Ah, well spotted mate! Maybe GeneralHPLostRatioinBattle > 0.2 for the shieldbearer will work just fine then! ;)

[Jambo]

Remember the biggest bug of them all:

The fact that traits obtained from the battle map are giving twice their supposed amount towards the trait's threshold - this means super fast climbing of the traits, e.g. gaining the first two levels of GoodCommander, BattleScarred, RomanHero after just one battle.

To counter this, double the threshold of traits you can receive on the battlefield, particularly the combat related ones as these can really offset the game's balance in favour of the human. Alternatively, look for the next release of the CVP. :)

[gregab25]

the more i think about it, i don't think they'll ever tell us, since if they admit that something's screwed up, that would justify a patch... and we wouldn't want that, now would we?

Hehe, are you being tongue'n'cheek tai4ji2x? I'm not that cynical. ~D

Besides didn't your momma teach you can catch more flies with sugar?
Hehe. ~;)

[Simetrical]

If we have an arithmetic comparison, the two sides of the comparison must be members of ordered sets. According to gregab25's interpretation of the game files, in "SettlementBuildingFinished >= farms", "SettlementBuildingFinished" and "farms" are both variables that the game sets as numbers depending on the situation. "SettlementBuildingFinished" would become the number equal to the level of the structure built in the trigger condition, while "farms" would become the number equal to the level of the farms in the settlement.

But Sinner raises an objection. "Farms" is already used by the game as a building name. That is, the first level of the hinterland_farm tree is known as "farms". Building names are evidently valid arguments in export_descr_character_traits.txt, as evidenced by all sorts of triggers. gregab25's interpretation would require that "farms" be used in EDCT.txt as an entirely separate variable—but how would you check anything relating to the structure "farms" if the game reserves that word for a special purpose?

The answer to this is that even if "farms" is reserved for special use, the SettlementBuildingFinished condition under gregab25's interpretation wouldn't accept a building name as an argument. Therefore, the game would know not to parse the term as a building name, but rather as a special reserved term. In this, it would be distinct from SettlementBuildingExists.

So what's Sinner's approach? Seemingly, the same one I stated before: that the variable SettlementBuildingFinished returns the building name, not the level number, and ">= farms" means what you'd think it means, that the previous argument is checked as to whether it's at or beyond the level "farms" in the ordered set of hinterland_farms. Thus, the trigger would work if and only if the building built was a farm of some description.

It should be very easy to test this. First of all, set the threshold of Grower to 1. According to gregab25's approach, building any nonfarm building equal to or greater than the farm level would cause the governor to gain a level of GoodFarmer; according to Sinner's, it wouldn't. I'll run the test in a minute. I'm betting that Sinner's right, but we'll see.

-Simetrical

[gregab25]

According to gregab25's approach, building any nonfarm building equal to or greater than the farm level would cause the governor to gain a level of Growing

Maybe you just made a typo but to be sure i'll correct you. According to my approach, building any nonfarm building equal to or LESS THAN the farm level would cause the governor to gain a level.

Not greater than... EQUAL OR LESS THAN.

[gregab25]

BTW, I still cannot believe you guys are still so vehemently argueing without running the tests first. That's pure folly! :duel:

Run the tests first and I'll be happy to admit that I am wrong if I am!

Cheers.
~:cheers:

[therother]

The fact that traits obtained from the battle map are giving twice their supposed amount towards the trait's threshold - this means super fast climbing of the traits, e.g. gaining the first two levels of GoodCommander, BattleScarred, RomanHero after just one battle.
Sorry, trait newbie butting in, but has this been confirmed as a bug in the code, rather than in the traits file? Could there perhaps be another explanation? For instance, have you doubled the "Standard_Battle_Any_Victory_VnV_Trigger" to "Affects GoodCommander 4 Chance 100" to see if your general becomes a Great Commander (Threshold 8) after one battle? I ask as after reading a few threads about the scarred issue, I was surprised to get only the first level (Been in the Wars) after a test battle for something else (the effect of Command (https://forums.totalwar.org/vb/showthread.php?t=43670)).

[gregab25]

Sorry, trait newbie butting in, but has this been confirmed as a bug in the code, rather than in the traits file? Could there perhaps be another explanation? For instance, have you doubled the "Standard_Battle_Any_Victory_VnV_Trigger" to "Affects GoodCommander 4 Chance 100" to see if your general becomes a Great Commander (Threshold 8) after one battle? I ask as after reading a few threads about the scarred issue, I was surprised to get only the first level (Been in the Wars) after a test battle for something else

Sorry, beyond the obvious Scarred trait bug, i had not heard about a problem with the GoodCommander or RomanHero traits. So I don't know much about them.

Briefly looking at the triggers reveals there is one trigger for GoodCommander and it seems in order.

The RomanHero Trait has 3 seperate triggers 2 with a 20% chance and one with 15% i think. So, it is not surprising that your general would receive this trait quickly.

I did not see any doubling of the triggers left by the omition of the condition Culture Type Non Roman. Which was why you got tested twice in the case of the Scarred trait.

Maybe Jambo has more information.

[Simetrical]

The results are in. I modded the file as I said, then built a Shrine to Ceres in Arretium. The governor gained no traits. Then I built a Communal Farming—and the governor gained Grower. Bingo. Question answered.

But gregab25 might be a little confused at this. After all, he's been playing for a while with his mod, and he's been gaining GoodFarmer traits. If I'm right, then he should have been setting the trait trigger so that it only rewarded him for building the first level of farms and no other buildings—i.e., it should be extremely unlikely that he'd gain even Grower. So what gives?

The answer is that he's confused ≯ with ≤—"not greater than" with "less than or equal to." He assumed that they were equivalent, when they're not. What's the difference? None, if you're only dealing with elements in an ordered set. gregab's belief was that both terms represented numbers, so that's fine—all real numbers are elements of the same ordered set. If a real number isn't greater than another, it has to be either less than or equal to.

But if you read my (admittedly a bit technical) explanation of how the condition in question actually functions, you may have realized that not all elements in question need to be in the same ordered sets. If the ordered set in question is hinterland_farms and I build a dirt road, the road isn't greater than or equal to the farm—but it's not less than it, either, since they aren't in the same ordered set. ~(Roads ⋚ farms) in the same way that ~(i ⋚ 42). (Dang, I wish Unicode specified a "not greater than, less than, or equal to" symbol.)

gregab25 therefore thought that the ≺= operator was bugged, so he changed it to NOT >. Unfortunately, this made every non-farm building increase his traits, tricking him into thinking that his interpretation of EDCT.txt was right.

Maybe you just made a typo but to be sure i'll correct you. According to my approach, building any nonfarm building equal to or LESS THAN the farm level would cause the governor to gain a level.Of course, you're right. Typo.

Sorry, trait newbie butting in, but has this been confirmed as a bug in the code, rather than in the traits file? Could there perhaps be another explanation?I don't think so. There aren't any duplicate triggers that could explain the observed phenomena.

I ask as after reading a few threads about the scarred issue, I was surprised to get only the first level (Been in the Wars) after a test battle for something else . . .It's not certain that you'll gain any Scarred trait at all after battle—most trait triggers have a percentage chance associated with them. The trigger could have been checked twice, but only returned positive once.

-Simetrical

[Jambo]

It's particularly noticeable with the combat traits (or rather easier to test). Try a battle with a fresh naive general (no GoodCommander trait). If he wins and the odds make him elligible to receive the 1 Chance 100 in the GoodCommander trait, what you find is that he skips Confident Commander (+1) which has threshold 1, and goes straight to Good Commander (+2) which has threshold 2.

On occasion it's actually possible to get straight to Superior Attacker/Defender (threshold 4) from just one battle. The battle has to be a crushing victory with battle odds of >=0.5 to less than 1.5. According to the character_traits file, this awards GoodAttacker/Defender 2 Chance 100. Due to the doubling bug this gives 4 Chance 100 instead.

This isn't for autoresolved battles, only those fought out on the battle map.

[Pode]

Bugger. I was really hoping double tests for romans would be the explanation for the double awarding "feature". There's no good way to mod around this one. Doubling the threshold prevents the AI from leveling up appropriately, and God knows it needs all the help it can get. Halving the odds for each comabt trigger would be slightly better, since it would tend to keep AI and player generals mired down in mediocrity, but where's the fun in that?

[tai4ji2x]

ugh... this is SOOOO confusing :dizzy2: i wonder if there will ever be a definitive answer... ~;p

anyways, simetrical, i don't understand this:


gregab25 therefore thought that the . Unfortunately, this made every non-farm building increase his traits, tricking him into thinking that his interpretation of EDCT.txt was right.

seems like your sentence got cut off?

[Jambo]

double post somehow....

:embarassed:


EDit: may as well use this slot.

Pode, there's a cunning strategy that the CVP uses, which helps this unfortunate doubling problem. Basically, it uses the BadCommander traits as a means to combat the meteortic rise that's possible with the GoodCommander trait. Essentially, the higher a general is in the GoodCommander trait, the greater the BadCommander award he'll receive should he lose a battle. For instance, a general at level 4 GoodCommander will have a bigger fall in the trait should he lose a battle than a mediocre commander at level two would get.

[hrvojej]

Sooo... Do you think that maybe adding "and AdviseBuild >= farms" to BadFarmer trigger would counter the apparent abundancy of this trait while also preserving the actual probabilities?

[Kraxis]

This is getting highly confusing... I'm lost.

Simetrical what did you do? And what was the effect?
Temple of Ceres grants 3 points out of 6 right? And building another farm adds 1 point? But that is only 4 out of 6 so how come you got the trait?

[tai4ji2x]

Pode, there's a cunning strategy that the CVP uses, which helps this unfortunate doubling problem. Basically, it uses the BadCommander traits as a means to combat the meteortic rise that's possible with the GoodCommander trait. Essentially, the higher a general is in the GoodCommander trait, the greater the BadCommander award he'll receive should he lose a battle. For instance, a general at level 4 GoodCommander will have a bigger fall in the trait should he lose a battle than a mediocre commander at level two would get.

won't this make the AI's generals worse?

[hrvojej]

won't this make the AI's generals worse?
I think so too. I rarely (if ever) lose with 4stars or better, since they command my largest, main, armies. The AI, however, is prone to have them wondering alone etc. Unfortunatelly, from what I can gather this is not the best fix for doubling IMHO.

[gregab25]

Okay, after Simetrical's good, albiet immature, post, and some retesting i must admit I am wrong on the farmer and trader corrections. :embarassed:

I suggest everyone go back to the default triggers for farmer and trader.

However, in the default setting if you desire to become a good farmer or trader you will want to build all other buildings before the farm or trade buildings.

This seems counter intuitive to me personally, and was why i thought the trigger was bugged.

This led me to initially reversing the > = sign to a < = sign in the triggers. However, this did not reverse the results in game.

This led me to the using the NOT condition and > sign because i believed it to be the same arguement as using a < = to sign.

Which has now been shown to be incorrect.

So I do apologize for my mistake and any confusion it led to. I hope you will bear in mind i was trying to help the community with what i thought was a bug.

To follow up I would like to ask 2 questions that maybe the community would be willing to answer in layman's terms:

1) Does it makes sense that a governor becomes a GoodFarmer or GoodTrader by ignoring building the Farm and Trade buildings?

2) Would someone please look into or explain why reversing the > = to a < = sign in the triggers does not reverse the results in game? Especially in relation to the farming triggers. Is a = < arguement a vaild arguement that might work?

Again. Apologies.

And Thanks.

[hrvojej]

1) Does it makes sense that a governor becomes a GoodFarmer or GoodTrader by ignoring building the Farm and Trade buildings?

Someone correct me if I'm wrong, but on the contrary you *only* get points in GoodFarmer for building the farm buildings, any of them; you get points in GoodTrader for building either traders, roads or ports. It is, however, very unlikely to gain good traits due to high thresholds (unlike the bad traits, and this is why I had modified the thresholds in a first place - the game is in effect punishing you for being successful).

edit: And I'd really like to know the answer to your 2nd question as well. Maybe you used the first level of farms, and both < = and > = include that one?

[tai4ji2x]

so BOTH gregab25's attempted fix AND the default triggers are wrong? NOOOOOOOOOOOOOO

[Jambo]

I think so too. I rarely (if ever) lose with 4stars or better, since they command my largest, main, armies. The AI, however, is prone to have them wondering alone etc. Unfortunatelly, from what I can gather this is not the best fix for doubling IMHO.

Have you ever seen a Superior, Great or Legendary AI commander? Personally I haven't in the entire time I've played. Coupled with the fact that they progress more slowly than the human player's generals due to the battle map doubling, the AI generals never live long enough or win consistently enough to reach the higher levels of the combat traits.

Therefore, this is really only relevant for the human player should they slip up in battle with their top commanders.

[Pode]

OK, I'll *try* to explain how I *think* these triggers work, in layman's terms as requested. SettlementBuildingFinished returns the name of the building just built. If that name is not part of the hinterland_farms build tree, a value of zero assigned to whatever temp variable is being used. If the name is part of the hinterland_farms build tree, the temp variable is assigned the number corresponding to that level farm. This number is then compared to the number corresponding to the building name on the other side of the arguement, namely farms (=1). The building name on the other side is also what specifies which build tree to use for the evaluation.
So, if you build a port, SBF = 0 and farms = 1, so the trigger goes to false and nothing happens. If you build a farm, 1=1 and you get a point for good farmer. For farms+1, 2>1 and you get another point. So maxing the farms in a settlement should give you 5 points. Why is the threshold 6? I have no clue. Chalk it up to piss poor playtesting, not that there's any OTHER evidence of that.

[gregab25]

Someone correct me if I'm wrong, but on the contrary you *only* get points in GoodFarmer for building the farm buildings, any of them; you get points in GoodTrader for building either traders, roads or ports. It is, however, very unlikely to gain good traits due to high thresholds (unlike the bad traits, and this is why I had modified the thresholds in a first place - the game is in effect punishing you for being successful).

Easiest way is to see it for yourself. It will take less than 5 minutes. Simply set the thresholds for farming to 1, 2, and 3. Then go into the game and build various buildings and look at the results.

This is what i just did with the default triggers, and I was receiving the traits by building all the non farm and trade buildings first.


so BOTH gregab25's attempted fix AND the default triggers are wrong? NOOOOOOOOOOOOOO

Mine are definitely wrong. :embarassed:

No one is saying the defaults are wrong though.

I just mentioned that it seemed counter intuitive. But that is just an opinion and very possibly wrong as well. :dizzy2:

[tai4ji2x]

wow. this is all very frustrating.

[Jambo]

has anyone tried changing it from "Condition SettlementBuildingFinished >= farms" to "Condition SettlementBuildingFinished >= hinterland_farms" and seeing if that does anything??

[Jambo]

I guess what this saying then is that as long as you have the basic farms in place, it will award you GoodFarmer each time you build another building?

EDIT: Conversely, one can only get BadFarmer if you constuct buildings before you have the basic farms in place?

[Kraxis]

No gregab I think it is very odd really... I doesn't make sense the way we have to do it now and with all the badfarmers out there it can't be right.
But I still wonder how Simetrical could advance the trait he did. And what was the intented result?

[hrvojej]

Have you ever seen a Superior, Great or Legendary AI commander? Personally I haven't in the entire time I've played. Coupled with the fact that they progress more slowly than the human player's generals due to the battle map doubling, the AI generals never live long enough or win consistently enough to reach the higher levels of the combat traits.

Therefore, this is really only relevant for the human player should they slip up in battle with their top commanders.
Well, no, I haven't seen the AI at those levels either, but neither do I "slip" with my generals of that rank. Don't get me wrong, please, I would also like it best if we could get the AI generals to those heights (or at least near the player's general's levels by eliminating doubling), I was just saying that in my opinion this fix unfortunatelly won't help close the gap between the player and the AI.

[hrvojej]

Easiest way is to see it for yourself. It will take less than 5 minutes. Simply set the thresholds for farming to 1, 2, and 3. Then go into the game and build various buildings and look at the results.

This is what i just did with the default triggers, and I was receiving the traits by building all the non farm and trade buildings first.


I did, and it works as I said.
All thresholds are at 1,2,3, all triggers are at 100%. I build anything other than a farm building, regardless of the relative or absolute farm level, I get +1 in BadFarmer. I build a farm of any tier, I get +1 in GoodFarmer.
For example, I build communal farming, I get grower. I build basic trader after that, and I lose grower. Also, I build a temple (the one after the shrine) in a town with land clearance, and I get poor farmer.

Or am I completely off base as to what we're talking about? ~:)

[Hambut_bulge]

has anyone tried changing it from "Condition SettlementBuildingFinished >= farms" to "Condition SettlementBuildingFinished >= hinterland_farms" and seeing if that does anything??

No noticable effect, unless you bring the threshold on Grower down to 1, in which case it does work. But then so does "SettlementBuildingFinished >= farms" if the thresholds are low. I've been following this thread with interest, and I'm starting to think that maybe its meant to be that way. Maybe we all have too many generals so that they're sat around in the same city, going out to fight the odd battle, but always remaining in charge of the same province. Thus in the course of a typical general's lifetime he'll never get past the thresholds for traits such as good farmer. Of course, if over the course of his career he's running around all over the place, then'll he'd get up there in no time at all.

[tai4ji2x]

This is what i just did with the default triggers, and I was receiving the traits by building all the non farm and trade buildings first.


which traits are you referring to here that you were receiving?

[Sinner]

Dammit, I just wasted an hour confirming my beliefs? Oh well.

The answer is to copy how the BadMiner triggers work, replacing the current BadFarmer trigger with the following...

;------------------------------------------
Trigger governing6
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = farms
and AdviseBuild = farms

Affects BadFarmer 1 Chance 100
;------------------------------------------
Trigger governing6a
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = farms+1
and AdviseBuild = farms+1

Affects BadFarmer 1 Chance 100
;------------------------------------------
Trigger governing6b
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = farms+2
and AdviseBuild = farms+2

Affects BadFarmer 1 Chance 100
;------------------------------------------
Trigger governing6c
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = farms+3
and AdviseBuild = farms+3

Affects BadFarmer 1 Chance 100
;------------------------------------------
Trigger governing6d
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = farms+4
and AdviseBuild = farms+4

Affects BadFarmer 1 Chance 100

Do the same sort of change with BadTrader's trigger as well.

It seems almost pure chance whether the Advisor will recommend that you build an available farm building out of the possible buildings available to queue, although at least it doesn't recommend you build a farm that simply isn't available. If you don't follow its advice then you're guaranteed you'll be stung, at best you'll just negate one of your hard earned GoodFarmer points, at worst you'll now have an active BadFarmer trait.

In the quick test game I ran just now I avoided farms and built 7 non-farm buildings before I got the BadFarmer trait which sounds about fair to me, but it'd be worthwhile having this tested some more if anybody cares to try as well.

[tai4ji2x]

do you actually have to click on the advisor button to activate this trigger?

[unseen11]

So um let me just get this straight.When I upgrade my Governors house and I firstly build a farm upgrade or trade/port upgrade before anything else i will get the Good Farmer/Good Trader virtue after building a bunch of other buildings that are either less then or equal to in level to the farm/trader? if i mod it

Ok that makes sense to me, just gotta first build farms/traders when i upgrade my governors house ~:cheers:

[frogbeastegg]

I tried reading parts of this thread but it made my eyes spin since I don't understand the modding stuff. However the subject is one dear to my froggy little heart, so I'll toss my two [pence in. Apologies if I am repeating or being redundant.

I saw someone say 'good farmer' has a 100% chance if you build [something, a farm most likely]. I have got this trait ... oh, maybe twice. I do build farms, actually I build almost every farm level in all my cities, only avoiding the higher tier ones if the population already has a very high default growth. I build farms quickly; I want the population boost in place as soon as possible, because then it provides the most benefit.

Bad farmer I get on almost every single governor within 10 turns of their appointment. Every governor will have it eventually, within 15 turns, I estimate. That is probably a generous set of estimates; I don't take a count, I just know the traits appear very, very quickly on everyone.

Ditto useless assessor. I always leave taxes on medium unless I have to reduce them for happiness reasons, something very rare. I like the balance between pop growth and income. Low taxes producing useless assessor I can understand, but medium seems quite stupid.

I don't recall ever getting the good taxman family of traits, even in cities I have occasionally run on high taxes.

Scarred and family, well I think everyone is well acquainted with this now. The AI does not appear to be getting this trait in any of my games; it is just me.

Bad/good miner I have not seen, despite always building mines very quickly in provinces capable of them.

Good/bad trader. I see less of these two families, but with a definite lean towards bad trader. No idea why; trade is also one of my high level priorities in almost every city.

I really do hate the way this is currently working; my people are getting the same few repetitive vices over and over, and quite harmful ones too. I am actually far more bothered about the harm this does to the immersion factor provided by the otherwise excellent trait system; having so many people with the same few traits harms the feeling of individual characters, it reduces them to clones.

If CA won’t/aren’t going to fix this I want to mod it, but I have no idea how to. I presume from the mostly incomprehensive modding talk that people are still trying to work out how to edit these trait families for best effect?

[Sinner]

do you actually have to click on the advisor button to activate this trigger?

Nope, I was just queuing up buildings and clicking end turn.


So um let me just get this straight.When I upgrade my Governors house and I firstly build a farm upgrade or trade/port upgrade before anything else i will get the Good Farmer/Good Trader virtue after building a bunch of other buildings that are either less then or equal to in level to the farm/trader? if i mod it

If by mod and the build order you described, you mean the change gregab25 proposed then unfortunately it doesn't work as intended. Completing any non-farm building gave you points towards GoodFarmer, even if the settlement had no farms. Completing the first farm, Land Clearance, also gave you a point towards GoodFarmer, but every other farm level gave you a point towards BadFarmer instead.

With the unmodded game it doesn't matter what order you build farms and trade buildings since the game does not compare the newly completed building with what has already been built. If you complete a farm or a trade building you get a point towards GoodFarmer or GoodTrader respectively, with the latter also getting points for ports and roads. If you complete a non-farm or a non-trade building you run the risk of getting BadFarmer or BadTrader points respectively.

If people are really that worried about getting BadFarmer in the unmodded game then the possible solutions are a pain in the ass, but still just about workable: simply never complete a non-farm building with your governor in the settlement, alternatively get to the third level of GoodFarmer, Agriculturalist, since this is a 'no going back' level and you can't subsequently lose it to BadFarmer.

If you're very lucky your governor will have started with Grower through random chance when he comes of age, although this is rare - only about 2% if I recall. If you have access to a temple of farming greater than shrine level your task just got a whole lot easier: drop your new governor-to-be into the settlement and as long as he doesn't move he has a 10% chance each turn of getting 6 points towards GoodFarmer.

(If your trainee is the governor of the farming temple settlement you perhaps want to avoid completing any buildings so that you don't get any BadFarmer/BadTrader vices, but you can still try to improve him further by setting the taxes to Very High and completing a troop every turn which has a small chance - about 3% - of gaining him a point in GoodAdministrator. You do run a very small risk of getting BadBuilder points with an idle building queue, so to avoid this simply queue up a building that you never allow to complete, removing it from the queue entirely and then restarting it each time it nears completion - this does waste money, but the choice is yours, cash or BadBuilder.)

If you don't have access to a farming temple and you're still trying to get a governor to Agriculturalist then your only option is to send him on a tour of your settlements, stopping off in each one as it completes a farm so that he gets the point of GoodFarmer. Given the micromanagement and build times required this is very awkward to achieve and I personally didn't find the effort worthwhile.

[Sinner]

Frogbeastegg, try the fix I posted for BadFarmer a couple of posts up. While it doesn't make getting GoodFarmer more likely, leaving it a rare and thus valuable achievement, it does avoid governors getting BadFarmer simply for doing their job.

To simplify it for people here's the same change done for BadTrader...

;------------------------------------------
Trigger governing10
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = trader
and AdviseBuild = trader

Affects BadTrader 1 Chance 100
;------------------------------------------
Trigger governing10a
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = market
and AdviseBuild = market

Affects BadTrader 1 Chance 100
;------------------------------------------
Trigger governing10a
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = forum
and AdviseBuild = forum

Affects BadTrader 1 Chance 100
;------------------------------------------
Trigger governing10a
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = great_forum
and AdviseBuild = great_forum

Affects BadTrader 1 Chance 100
;------------------------------------------
Trigger governing10a
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished = curia
and AdviseBuild = curia

Affects BadTrader 1 Chance 100

For GoodTaxman you need to set your taxes to Very High while maintaining a settlement loyalty level of disillusioned, giving you a chance each turn of gaining 1 point in GoodTaxman. If your taxes are Low or Normal and the settlement's loyalty greater than disillusioned then you risk getting a point in BadTaxman, since your governor is obviously not taking the opportunity to squeeze more money out of the settlement.

Personally I think the GoodTaxman trigger should be changed to allow you to get the trait if the happiness level is disillusioned or higher, not just disillusioned. To do this change the current GoodTaxman trigger as follows...

;------------------------------------------
Trigger governing18
WhenToTest GovernorBuildingCompleted

Condition GovernorLoyaltyLevel >= loyalty_disillusioned
and GovernorTaxLevel > tax_high

Affects GoodTaxman 1 Chance 75

Overall the problem is that it seems CA don't really intend for you to have family members sitting around for very long as governors, we're instead meant to get them out into the field as generals or at least a mix of the two.

An idea I've been thinking of to totally revamp the traits system is to predispose the majority of characters towards being a general or a governor, with a few rare individuals able to function equally well as both. This does fit real world examples where great generals are often terrible civil leaders and vice versa. This would be done with a couple of new traits, General and Governor, possibly hidden, that are assigned to every character with the former finding it easier to gain combat traits and the latter governing traits. It would be possible for a general to build up his governing skills and even over time gain the Governor trait, possibly even lose his General trait, and vice versa for governors. It's only in the rough planning stage so far and since it'll require a huge increase in triggers to allow for seperate general and governor versions for many of them it might be that I'll hit a possible hardcoded limit... or alternatively I just give up from sheer exhaustion! ~:)

[RJV]

My own solution to this whole messy affair is rather simplistic and probably not as God intende, but anyway...

1) Never leave your generals in towns

2) If you get do happen to get new family members either through marriage or birth - leave them in a city with taxes set to HIGH for a few turns (unless they have excellent battle stats of course) , build as normal and see if they get anything good. If they do, keep em there or move them to a good city. If they don't, ship em out to the battle field.


It's a pity that I feel I have to play like that, but I don't trust what is happening with the traits, and it's too easy to get the bad stuff, and seems too hard to get the good stuff. Admittedly it seems that fighting makes it too easy to get the good stuff but you can't have everything... ~D

If we get a definitive answer or relatively simple (ie something that isn't going to take me hours to mod, or a download that isn't going to mess with too many other areas of the game) then maybe I'll re-introduce the governor side of things. As it is, my generals are just fighters.

Cheers,

Rob.

[Jambo]

OK, rather than dwell on and tinker with the current bizarrely operated GoodFarmer/Trader triggers, I thought I'd post an alternative idea for a fix. This involves what is known as "self-perpetuating" triggers. What this will mean is that any character with the GoodFarmer/Trader trait has a small chance at the end of any turn to progress further in this trait. So a character with Grower will have a 4% chance of receiving 1 towards the next threshold level at the end of each turn.

Here's what the self-perpetuating triggers would look like with these traits:


Trigger selfperpetuating49
WhenToTest CharacterTurnEnd

Condition Trait GoodFarmer >= 1

Affects GoodFarmer 1 Chance 4

Trigger selfperpetuating50
WhenToTest CharacterTurnEnd

Condition GoodTrader >= 1

Affects GoodTrader 1 Chance 4
Reducing the GoodFarmer and GoodTrader thresholds from 6 and 24 to something like 4 and 16, respectively, would go somewhere in helping these self-perpetuating triggers come into effect.

Lastly, one might also reduce the chance for BadFarmer from 1 Chance 8 to something like 1 Chance 4, so that the BadFarmer trait is relatively less likely to be acquired..

[hrvojej]

I really do hate the way this is currently working; my people are getting the same few repetitive vices over and over, and quite harmful ones too. I am actually far more bothered about the harm this does to the immersion factor provided by the otherwise excellent trait system; having so many people with the same few traits harms the feeling of individual characters, it reduces them to clones.

The problem mostly lies in the fact that it takes several (as in 8 or even 24) instances of triggers to get the good trait up one level, whereas it usually takes way fewer (read: a single one) instances to get one level of the corresponding bad trait. Or the triggers are set up in such a way that it's hard to avoid the annoying VnVs. That's why the game gets this punishing feeling, even if it appears that you're doing everything right.

For example, you'll always get useless assessors for having taxes lower than high. Simply, the trigger is set that if loyalty is greater than disillusioned (the blue face, i.e. 75-80%) and taxes are less than high, you have a chance to get badtaxman vice. You'll never be able to get goodtaxman virtue with the setup you described above (taxes on medium) since you have to have blue face loyalty and very high taxes, and not only that but also you'll never be able to counter the badtaxman progression (it's like a + - scale, one point in positive direction decreases the badtaxman). Another example is goodfarmer vs. badfarmer, where you need to build 6 farm buildings to get the first level of goodfarmer, whereas only a single non-farm building will net you a level in badfarmer. Although each farm building increase the goodfarmer with a 100% probability and the probability of getting a badfarmer from building anything else is 8%, I find that I'm way more likely to build "anything else" despite the apparently low probability than to build 6 farms under the same governor - and hence all the poor farmers out there.
Since I find this imbalance detrimental to my gaming experience, I have modified both the triggers and the thresholds for certain vices (farmer, trader, taxman...) to at least neutralize the effects you were talking about. In other words, it's not just the triggers IMO: you would have to build *24* bleeping farm buildings under the same governor to get the third level of goodfarmer virtue!! I'm tempted to say that most governors don't live that long, not even in 1.2. Of course, that's assuming you never build anything other than farms... or that you always pass the badfarmer check. Naturally, it only takes 3 failed checks (if you haven't build any farms and hence have no positive increase) to get the third level of badfarmer...

Sorry, a bit long and a bit of a rant, but you hit the nail on the head with one of the biggest things that (used to) bother me with the strategic map.

edit:
And from reading the posts after yours I see that I'm not the only one in this feeling. Sorry for the repeats, folks, I went straight to writing without reading on.

[Hambut_bulge]

Self-perpetuating triggers? Now that's a good idea! :bow:

I'm not so sure that the issues surrounding the badtaxman traits are necessarily broken though. Remember this is ancient Rome, not a modern democracy. Tax was all about squeezing as much cash as possible out of the newly conquered. Tom Holland touches on the subject in his book Rubicon. I don't have it in front of me right now, but from what I recall his argument was that the Western civilisations originally didn't bother with regular taxation. Why go to all that bother when you could simply beat up your neighbours and take everything they had? Eastern empires, being much larger, had developed the necessary adminstration skills to levy regular taxes. Then, so Holland's argument runs, the Romans acquired Pergamum and everything changed. Now the Romans (particularly in the days of the Republic), if they got hold of a city that had a smoothly functioning administrative service tended to leave that service intact. Pergamum, being a relic of an old Eastern empire had the neccessaries to levy regular taxation on its subjects. And the Romans suddenly realised what an easy, and lucrative, task it actually was.

So in that light, the game is actually correct in punishing those generals who keep taxes too low. What I don't get though is why the tax farmer ancillary pops up if you go down the badtaxman trait tree. Tax farmers were sub-contractors used by Roman governors to increase tax revenues. So I would've thought they should be on the goodtaxman tree ~:confused:

[Pode]

If you had total authority over a city and found that you were no good at taxing, wouldn't you delegate the task to someone who was? I think the tax farmer ancillairy belongs on the bad taxer side.

On the larger issue, is there an agreed upon set of triggers for the farmer and trader traits that doesn't depend on the advisor? I've found her to be more like a trophy wife than an advisor: pretty to look at until she opens her mouth. The woman is utterly daft, and I don't want anything important like economic traits left in her clueless hands.

[Kraxis]

I'm with Jambo. Upping the chance of GoodFarmer (lower threshold) and lower the one for BadFarmer is the way I have followed. Now with the perpetuating trait I have gone a little back towards vanilla but it is much altered still.

[Kraxis]

Damn! Just noticed another badly made traittrigger. Look up the risky battles and you will notice that the battles that are supposed to be won = clear are in fact set to be = crushing. That means that every time you win a crushing victory that is risky you gain no less than 3 points in whatever risky-type you fought. But if you won a clear victory you gained nothing. That is unmodded. Personally I have modded crushing to grant only 1 point but give a 25% chance of skilladvance.

[Bob the Insane]

I think I am in need of a clearer explaination of what the problem is here...

I have been running tests with slightly modified export_descr_ancillaries.txt and export_descr_character_traits.txt files. I have modded them simple to set the chance values to 100 (or in the case of comingofage, marriage and adoption test I have set chance to 1). In export_descr_character_traits.txt I have also modded the trait threshold to be single point steps...

Concentrating on the farmer and Trader triggers the logic appears to be:

1. Build a farm build and get a GoodFarmer point (but you also get a BadTrader point)

2. Build a trade building and get a GoodTrader point (but also get a BadFarmer point)

3. Build a road or a port and you get a GoodTrader point and a BadFarmer point.

4. Build anything else and you get both a BadTrader and a BadFarmer point.

Before arguing whether this is right, is it what everyone else expects with the default trigger setup?

[Sinner]

Yup, with the default triggers amended to have a 100% chance to acquire traits if the conditions are otherwise met, that's what I'd expect.

[gregab25]

Yes, Bob. That is how it seems to work with the default triggers.

I spent some time today looking for a solution withot having to change the default threshold values. But I couldn't find one.

Without knowing more about all of the information that is returned from the "SettlementBuildingFinished" and "Farms" queries, I dont think any of us can get it working as CA intended.

To me the Farmer and Trader traits are broken unless CA intended for a governor to not be able to receive these traits without moving your governor from town to town solely building farms and then removing the governor when you build every single other building in the game.

As a player, i have reached my own threshold, and have received "frustration" level 1. :angry: This bug kinda ruins the game for me. It whispers to me in the back of my mind when i'm trying to play saying that i'm not actually playing the game. Just some sort of half game.

Anyways If I play anymore with 1.2, I will probably just disable the farmer and trader traits altoghter. Which, when i think about it, doesn't make me any happier really. :sad3:

I wish CA would fix this stuff.

[tai4ji2x]

As a player, i have reached my own threshold, and have received "frustration" level 1. :angry: This bug kinda ruins the game for me. It whispers to me in the back of my mind when i'm trying to play saying that i'm not actually playing the game. Just some sort of half game.


lol, gregab. me too... me too... ~:mecry:

"apologists" for CA (somewhat harsh term, i concede) rationalize that just as a good chess player will play with missing pieces or other handicaps against a lesser player, so too must an RTW player do all she/he can to avoid exploiting the AI. i'm fine with that IN THEORY... the problem is, here it's like you're constantly having to add new restrictions and limits on yourself as you realize your opponent is even worse than originally claimed. sometimes you even see that the opponent doesn't even know certain rules or inadvertently breaks them on a consistent basis since it doesn't know any better.

[hrvojej]

To me the Farmer and Trader traits are broken unless CA intended for a governor to not be able to receive these traits without moving your governor from town to town solely building farms and then removing the governor when you build every single other building in the game.

I'm pretty sure that's how they're supposed to work. For example, tell me how many high-star generals in MTW did you have that were also *not* inbred unhinged loons? I think that the rationale behind it is that otherwise it would be too easy.

The simple solution is to just lower the positive trait thresholds, or make the triggers give you more points for the good traits.

[Simetrical]

seems like your sentence got cut off?Yes, because vB 3 is moronically paranoid about less-than signs. The paragraph now reads "gregab25 therefore thought that the ≺= operator was bugged, so he changed it to NOT >. Unfortunately, this made every non-farm building increase his traits, tricking him into thinking that his interpretation of EDCT.txt was right."

Simetrical what did you do? And what was the effect?I just modded the basic EDCT.txt to have a threshold of 1 for GoodFarmer, then I built a farm building and a non-farm building with different governors. The governor who built a farm building got a point of GoodFarmer, and the one who didn't didn't. This proved that the intuitive reading of SettlementBuildingFinished (that it returned the name of the building constructed) was the correct one. If gregab25 had been right, and SettlementBuildingFinished had just returned the level number of the building constructed, the non-farm building should have given my general a point of GoodFarmer (since its level was equal to the level of farms in the settlement).

Okay, after Simetrical's good, albiet immature, post . . .Okay, I may have been a bit on the gloating side.

However, in the default setting if you desire to become a good farmer or trader you will want to build all other buildings before the farm or trade buildings.No. In the default settings, building any farm would give you +1 GoodFarmer, and building any other building might give you +1 BadFarmer. The GoodFarmer trigger doesn't care about which non-farm buildings you've built, and the BadFarmer trigger doesn't care about which farm buildings you've built.

Would someone please look into or explain why reversing the > = to a < = sign in the triggers does not reverse the results in game?Depends on which sign you're thinking of. If you change "SettlementBuildingFinished >= farms" to "SettlementBuildingFinished ≺= farms", then you'll see no difference at the level "farms" (Land Clearance), since both settings trigger off "= farms". The latter shouldn't trigger on any higher levels of farm, however. Did you observe differently in your tests?

Easiest way is to see it for yourself. It will take less than 5 minutes. Simply set the thresholds for farming to 1, 2, and 3. Then go into the game and build various buildings and look at the results.

This is what i just did with the default triggers, and I was receiving the traits by building all the non farm and trade buildings first.I suspect your EDCT.txt may have some lingering changes from your earlier modding which are throwing off the results. What's your full trigger for GoodFarmer?

I guess what this saying then is that as long as you have the basic farms in place, it will award you GoodFarmer each time you build another building?No. I'm not sure that's implementable, actually. You'd have to compare the level of the finished structure to the level of existing farms, and I'm not sure that's possible.

I saw someone say 'good farmer' has a 100% chance if you build [something, a farm most likely].Close, but one important mistake. If you build a farm, you have a 100% chance of getting one point in GoodFarmer. The threshold for "Grower" is six, so your governor has to finish six farms to get it that way. In other words, it's exceedingly unlikely that you got any GoodFarmer trait from building farms. You probably got them from temples of farming (Ceres, Freyja and the like).

Bad farmer I get on almost every single governor within 10 turns of their appointment.Another problem with the thresholds. You have an 8% chance of getting BadFarmer every time you build a non-farm building—but the threshold of BadFarmer is only one, as opposed to GoodFarmer's six. The thresholds need to be modded to something reasonable, preferably symmetrical.

Without knowing more about all of the information that is returned from the "SettlementBuildingFinished" and "Farms" queries, I dont think any of us can get it working as CA intended.I'm pretty sure we understand those queries. "SettlementBuildingFinished" returns the name of the building that was just finished, and "farms" is just a building name. The comparison sign checks the relationship between the finished building and the named building: if they're in the same build tree, their level is compared, and the condition returns true iff the relation is true; if they're not in the same build tree, the condition returns false. I think we have ample evidence to support this interpretation, and nothing seems to contradict it.

-Simetrical

[Pode]

I'd like to look at the vanilla expected trait levels for farming. A 16 yr-old governor who dies at 66 governs for 100 turns, which I like 'cause it keeps the maths easy for me. During that time he can build no more than 5 farms max, right? 5 points of good farmer total.

How many other buildings can he build in that time? It takes 14 turns to build the governors houses, and 15 to build the farms, so he has 71 turns left in which to possibly get bad farmer traits. Anybody know off hand how many buildings he can build in that time frame, max? Until someone posts that number and makes a fool of me, let's assume the average building takes 3 turns, which makes for 27 buildings. 8% of 27 (so much for easy math) is 2.16 levels of bad farmer.

Net: ~2.8 levels of good farmer, from a life spent neutral on the farm subject. I would conclude from this that the threshold for grower should be no less than 3. Considering that the temple of farming adds 6 points every 10 turns on average, he who honors the farm gods gets 60 points of good farmer from that. Thus the threshold for Agriculturalist should not be greater than 62, and probably less.

I conclude from this that good farmer was intended to be a trait that only those with farming temples acquired, and everyone else washed out even in the long haul. I think 3, 18, and 36, would make good thresholds. Someone who builds farms first has a shot at getting grower for a while, even if he will eventually lose it for failing to honor the farm gods properly (which plays for me since he's not the onee actually DOING the farming). A man who is dilligent about farming and is seen to worship the farm gods, otoh, gets grower within his first 2.5 to 5 years, then after 15 years he gets level two, and after 30 years as a farmer, he spends the remaining 20 years renowned as an agriculuralist.

[tai4ji2x]

probably got them from temples of farming (Ceres, Freyja and the like).

those are fertility temples, i believe. not farming.

[Sinner]

I'd like to look at the vanilla expected trait levels for farming. A 16 yr-old governor who dies at 66 governs for 100 turns, which I like 'cause it keeps the maths easy for me. During that time he can build no more than 5 farms max, right? 5 points of good farmer total.

He's limited to 5 farms if he stays in the same settlement for his entire life, but how many governors do this? With few exceptions I leave a governor in a city while it's growing or to help deal with unrest, then once the city is established and/or remains loyal with just a garrison I move my governor on to the next settlement or out into the field to lead an army.


...I conclude from this that good farmer was intended to be a trait that only those with farming temples acquired, and everyone else washed out even in the long haul. I think 3, 18, and 36, would make good thresholds. Someone who builds farms first has a shot at getting grower for a while, even if he will eventually lose it for failing to honor the farm gods properly (which plays for me since he's not the onee actually DOING the farming). A man who is dilligent about farming and is seen to worship the farm gods, otoh, gets grower within his first 2.5 to 5 years, then after 15 years he gets level two, and after 30 years as a farmer, he spends the remaining 20 years renowned as an agriculuralist.

Nice reasoning and solution for GoodFarmer, providing some reward for the average governor while still keeping the trait a relatively rare and thus precious virtue to possess, which seems to have been CA's intention. ~:)

[therother]

I've opened up a Ludus Magna thread (https://forums.totalwar.org/vb/showthread.php?t=44048) to research trait bug fixes of the type discussed here. I'd greatly appreciate it if those who have devised fixes could post (or in some cases repost) them over there, so that we can have them all in an uncluttered thread.

Thanks.

[Bob the Insane]

To continue Pode's discussion I we should discuss what we want to get out of the Goodfarmer and Goodtrader traits (and their opposites) and who should get them and for what reason...

I also like the concept that the dizzing heights of these traits are reservered for those governors that not only build loads of farms/trade buildings but also builds the farmer/trade temples...

Is it really only a change of the threshold values that is required to achieve this?

One thought I have been considering is a check to see if the the farm or trade build had been built before any other building of the same tech level (looking for which building ware upgraded first). And handing out GoodFarmer or GoodTrader points if those are first... Though thinking about it having Godfarmer and Goodtrader points gained simply by building the coorect building should be pretty easy to balance out with the threshold values.

And for handing out BadFarmer and BadTrader point a check to see whether those building had been upgraded as far as possible before the settlement itself is upgraded... So if you had a large town and a sufficient population to upgrade to a city, if you had not maxed out your farm and or trade buildings before upgrading the settlement you would get poorfarmer and/or poortrader points... This would make the slide into those traits much slower..

[gregab25]

I'm pretty sure we understand those queries. "SettlementBuildingFinished" returns the name of the building that was just finished, and "farms" is just a building name. The comparison sign checks the relationship between the finished building and the named building: if they're in the same build tree, their level is compared, and the condition returns true if the relation is true; if they're not in the same build tree, the condition returns false. I think we have ample evidence to support this interpretation, and nothing seems to contradict it.

Sorry if I'm slow on the uptake, but could you help me out here by explaining a couple of things?

If "SettlementBuildingFinished" and "farms" just return the names as you suggest, why would the equation not compare the names alphabetically?

Thus:

Condition "Market" >= "Farms"

Why would this not just compare the letter "M" to the letter "F", and return true?

I know this doesn't work, but is that not what the equation calls for if "SettlementBuildingFInished" and "farms" just return names.

And, If "SettlementBuildingFinished" and "farms" look up the level of the building in the file EDB.txt, does that not make them variables as i originally proposed, and which we know believe to be wrong?

So, isnt the trigger actually working in game by only returning the name and saying:

"farms" = "farms"

Which returns True.

and "anyotherbuilding" = "farms"

will always return false.

I don't believe the level is even checked and therefore the > sign in the equation is pointless. Which raises the question why is it there?

Both the > sign being irrelevant and the threshold being so high for GoodFarmer still leads me to believe that these traits aren't working the way CA wanted them to.

[gregab25]

Oh, and the above explanation i made would also explain why reversing the > and < signs did not have any noticeable effect on the results in game.

Am I on to something?

[Sinner]

In a word: nope.

From what you've said, apparently your problem is that you're viewing the condition as a mathematical equation, with SettlementBuildingFinished as a variable, but that isn't the case. SettlementBuildingFinished is a function and the rest of the condition are parameters. Go read the Events, Conditions, & Commands thread (https://forums.totalwar.org/vb/showthread.php?t=43121) for further info, although to save time I'll copy the SettlementBuildingFinished info here...

Identifier: SettlementBuildingFinished
Trigger requirements: prior_build
Parameters: building description, logic token, test level
Sample use: SettlementBuildingFinished = governors_house
Description: Test to see what the last finished building was
Battle or Strat: Strat
Class: SETTLEMENT_BUILDING_LEVEL_FINISHED_TEST
Implemented: Yes
Author: Guy

From the Parameters and Description we can see the intended use and intent of the condition and from testing we can deduce how it operates: the function first compares the completed building with the test building parameter to determine if they're in the same building tree, if they are it then compares their levels using the logic parameter, returning true or false as appropriate.

[gregab25]

Ok, if that is true, and i'll take your word for it that it is, is there another Identifier in the game that would compare the levels of buildings from different trees?

[gregab25]

For example maybe something like this might work:

Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingExists

[gregab25]

Ug.. damn < = to sign...


For example maybe something like this might work:


Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingExists < = farms

Affects GoodFarmer 1 Chance 100

[Old Celt]

This may seem like a silly question, but I'll ask anyway:

If the VnVs were much better with version 1.1, then has anyone thought to just copy the file information from there and paste it into the 1.2 files to fix the VnVs??

[gregab25]

Sinner, why does it only check buildingsfrom the same tree? If it checked the level of buildings from different trees it seems like everything else would work out?

[Sinner]

The SettlementBuildingExists condition can be used but you get a very cumbersome trigger like so...

Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished = farms
and not SettlementBuildingExists >= wooden_pallisade
and not SettlementBuildingExists >= muster_field
and not SettlementBuildingExists >= trader
and not SettlementBuildingExists >= roads
and not SettlementBuildingExists >= mines
and not SettlementBuildingExists >= temple_of_battle_shrine
and not SettlementBuildingExists >= temple_of_battleforge_shrine
and not SettlementBuildingExists >= temple_of_farming_shrine
... (all the other shrines)...

Affects GoodFarmer 1 Chance 100

With this trigger you'd only get a point towards GoodFarmer when you build Land Clearance and you haven't yet built any other building of the Town level.

You'd have to repeat this for each level of farm, changing the conditions to compare against the appropriate building for each building tree available at that level of settlement. Here's the Large Town/Communal Farming trigger as a further example...

Trigger governing5a
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished = farms+1
and not SettlementBuildingExists >= wooden_wall
and not SettlementBuildingExists >= militia_barracks
and not SettlementBuildingExists >= stables
and not SettlementBuildingExists >= practice_field
and not SettlementBuildingExists >= market
and not SettlementBuildingExists >= blacksmith
and not SettlementBuildingExists >= port
and not SettlementBuildingExists >= sewers
and not SettlementBuildingExists >= paved_roads
and not SettlementBuildingExists >= mines+1
and not SettlementBuildingExists >= tavern
and not SettlementBuildingExists >= temple_of_battle_temple
and not SettlementBuildingExists >= temple_of_battleforge_temple
and not SettlementBuildingExists >= temple_of_farming_temple
... (all the other temples)...

Affects GoodFarmer 1 Chance 100

With this trigger you'd only get a point towards GoodFarmer when you build Communal Farming and you haven't yet built any other building of the Large Town level.

I've no idea if triggers this big would even work and if I did use an idea like this for GoodFarmer, I'd personally drop the condition checking walls, roads, farming temples and perhaps fertility temples.

EDIT: SettlementBuildingFinished only compares levels of buildings in the same tree because that's how CA wrote the function!

[gregab25]

Ah, thanks for the excellent help, Sinner.

With the threshold so high in the GoodFarmer and GoodTrader traits i thought that the trigger you just showed was how CA possibly intended for it to work.

Now, I just don't know.

To me it doesn't make sense the way it is now, and looking at those big triggers i just don't know what to think.

But, thanks a lot for the help and showing me how it works and also for giving me the link to the Events, Conditions, and Commands thread.

Cheers.
~:cheers:

[Pode]

Greg, look at the effects of the temple of farming and temple of trade triggers to help you understand why the thresholds are so high. temple of farming gives 6 points of good farmer every 10 turns. I can't check from work, but I suspect temple of trade pays out similarly well. I think the design concept is that a governor's individual ability may help some, but in the long run unless the townspeople see him honoring the gods appropriately, there won't be much change in the output of the town overall. The age of reason is still a LONG way away in game

[gregab25]

Greg, look at the effects of the temple of farming and temple of trade triggers to help you understand why the thresholds are so high. temple of farming gives 6 points of good farmer every 10 turns. I can't check from work, but I suspect temple of trade pays out similarly well. I think the design concept is that a governor's individual ability may help some, but in the long run unless the townspeople see him honoring the gods appropriately, there won't be much change in the output of the town overall. The age of reason is still a LONG way away in game

Yes, I am aware of the effects of the temples, and it may be you are entirely right. Of course this would mean all that factions that cannot build those specific temples would still have a very hard time getting those traits, which may be how it is intended to be. IE. Each faction has stengths and weaknesses in their ability to gain traits based on what temples they can or cannot build.

[Pode]

It certainly makes the Julii pantheon seem a bit less pathetic in comparison to the other Romans. The troops aren't as good, but there can be a WHOLE lot more of them.

[tai4ji2x]

^
again, i think the julii temple (ceres) is a fertility temple, giving fertility bonuses. it is not a farming temple.

[Bob the Insane]

Sinner, you are a saint... ~D

That would work beautifully for my Badfarmer and Badtrader idea...

The following would test when a settlment is upgraded to see if the govern had bothered to upgrade the farms first, if not he is a bad farmer. The fact that this only occurs rarely (up to 4 times in the life of a settlement) ties in well with the low threshold settings in the default trait. If you have left the triggers for GoodFarmer as default it is also pretty easy to recover from getting BadFarmer points simply by building farms. Thus to become an unredemably bad farmer (Loathes_Farmers) your general would have to been the govern during the upgrading of a settlement 3 times without having any farms built...

--------------------------------------
Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished = governors_villa
and not SettlementBuildingExists = farms

Affects BadFarmer 1 Chance 100


--------------------------------------
Trigger governing5a
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished = governors_palace
and not SettlementBuildingExists = farms+1

Affects BadFarmer 1 Chance 100

And so on....

Using the same idea with Badtrader is slightly more complex because of the combination of buildings; trade, road and ports. Although, the only action to gain BadTrader points by default is not building trade buildings. So using the same triggers as for BadFarmer but checking for trading buildings not being built/upgraded instead. The slightly higher thresholds in BadTrader mean that to get the worst you would have to govern the growth of at least two settlements without building or upgrading the trade buildings...

The fact that there are three times as many opportunities to gain GoodTrader points is of set by the huge threshold levels...

[Bob the Insane]

Arrgghhh... Double post hell...

[Sinner]

Good idea Bob! ~:)

I'd only give BadTrader for the trader line of buildings (trader, market, forum, etc) as it does now, without worrying about ports & roads, the other ways to gain GoodTrader. It'll simplify the trigger and keep closer to the vanilla intention.

EDIT: Perhaps the second trigger should be like this, changing the '=' for the farm condition to a '< =' ...

WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished = governors_palace
and not SettlementBuildingExists < = farms+1

Affects BadFarmer 1 Chance 100

That way you'll also get BadFarmer if you haven't built farms or farms instead of the just the latter.

[Bob the Insane]

Good idea Bob! ~:)
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished = governors_palace
and not SettlementBuildingExists < = farms+1

Affects BadFarmer 1 Chance 100

That way you'll also get BadFarmer if you haven't built farms or farms instead of the just the latter.

Surely that would make it too hard to get the BadFarmer trait as you would have to never build any farms to get BadFarmer points, and if you built even the lowest level of farms you never have to worry about getting the BadFarmer points...

Using = means that you have to keep upgrading your farms to avoid he BadFarmer traits, nad even if you do gain badfarmer points you can negate them by building the farmer later (which gets you a GoodFarmer point)... You would really have to make an effort to not keep you farms updated to gain the BadFarmer trait...

I guess this is down to personal opinion. Just how bad a farmer do you have to be to get the vice??? (same logic applies to BadTrader)

[Sinner]

Yup, my bad.

[Bob the Insane]

Another trait I would like to discuss is Smoothtalker:

Trait SmoothTalker
Characters family
AntiTraits Feck

Level Plausible
Description Plausible_desc
EffectsDescription Plausible_effects_desc
Threshold 2

Effect Bribery 10

Level Slick
Description Slick_desc
EffectsDescription Slick_effects_desc
Threshold 4

Effect Bribery 20

Level Smooth_Talker
Description Smooth_Talker_desc
EffectsDescription Smooth_Talker_effects_desc
Threshold 6

Effect Bribery 30



;------------------------------------------

You can see that while this trait improves the chances of bribing someone (Effect BribeResistance is for preventing someone beeing bribed) and it can be gained through bribary missions. Yet it is own available to family members and not to diplomates... Surely this can not be right??

[Pode]

^
again, i think the julii temple (ceres) is a fertility temple, giving fertility bonuses. it is not a farming temple.

Tai, think about the word cereal for a minute ~D

[Pode]

Correct me if I'm wrong, it happens a lot, but when a dip opens talks with your general, if you counteroffer and they reject that outright, doesn't the full diplomacy menu, including bribe, come up if you try to make a new offer? Is that the situation that smoothtalker was meant for? Defensive bribing of a diplomat that has approached your general?

[tai4ji2x]

Tai, think about the word cereal for a minute ~D

yes, but in the game it acts as a temple of fertility. look inside EDB.txt

only dacia, carthage, and macedon have farming temples.

[Pode]

:oops: :shame: Well, at least I did just say that I was wrong a lot, now we have proof. Mea Culpa

[Bob the Insane]

Correct me if I'm wrong, it happens a lot, but when a dip opens talks with your general, if you counteroffer and they reject that outright, doesn't the full diplomacy menu, including bribe, come up if you try to make a new offer? Is that the situation that smoothtalker was meant for? Defensive bribing of a diplomat that has approached your general?

Good point, so the trait is having a positive effect as it is, cool...

Do you think it would be reasonable to mod this trait to make it applicable to diplomats as well as family members? Or could make the diplomats overpowered? Considering how much more expensive bribing is in 1.2 I don't think applying this to diplomats would be unbalancing...

[Sinner]

As I recall family members can counter-bribe when a diplomat contacts them, they just can't initiate a bribe themselves. So Smoothtalker would help in these circumstances.

[therother]

Counter-bribe? How does that work? I've both bribed family members and had family members bribed, and I've never either lost my diplomat to the other side or received the option to bribe the opposing diplomat, although I admit I haven't had too many family members bribed. Perhaps they didn't have the necessary skill?

[Bob the Insane]

As I recall family members can counter-bribe when a diplomat contacts them, they just can't initiate a bribe themselves. So Smoothtalker would help in these circumstances.


This should be quite easy t test for (at least whether the general actually picks up the trait is asy to test)...

With the modified trait file I am using if I can get myself into the position of a diplomat contacting one of my generals to negotiate something, if I counter by bribing the dilpomat and succeed the general should automatically get the trait (if it is all working)...

[Sinner]

theother, when a diplomat contacts you, eg trying to negotiate a trade agreement, you have the option of sending a counter-proposal. Bribery is one of the options on the list, so instead of negotiating the deal the AI wants you 'steal' his diplomat. ~:)

[Olmsted]

I would like to see this thread get a bit back on topic. Perhaps it was a mistake, but I read all 5 pages of this thread. Now, having read all that I am confused as can be. What changes should I make to fix the bugged traits? I would really appreciate a final version of the changes that takes into account what has been said for the past five pages. Thank you for your time.

[Bob the Insane]

I would like to see this thread get a bit back on topic. Perhaps it was a mistake, but I read all 5 pages of this thread. Now, having read all that I am confused as can be. What changes should I make to fix the bugged traits? I would really appreciate a final version of the changes that takes into account what has been said for the past five pages. Thank you for your time.


I think the reason for your confusion is because it has not been decided or agreed what the final solution should be...

We seem to have broken down into a couple of basic groups. The first is to simply adjust the threshold values for the traits in question to balance out the problems. The second is to alter how the triggers that generate these traits work.

The first is justified in that it is the least intrusive makes only a minimal change to improve the way the game plays. The second is justified if it is found that the triggers that power the traits are fundimentally broken and no amount of balancing the threshold values will fix things...

In some instances this is obvious like for the Scarface issue where the trigger is fundimentally flawed and needs to be fixed.

In other cases like GoodFarmer and BadFarmer it is less clear as we have not fully agreed how common these traits should be. The only thing that is obvious is that the poor manner in which the BadFarmer trait is triggered combined with it's bizaarly low threshold values makes the BadFarmer trait rediculously common...

I for one am a fan of altering the main trigger that generates the BadFarmer trait....

[Hobart]

Can someone clarify for me what GeneralHPLostRatioinBattle actually measures? Is it (hitpoints lost)/(total hitpoints) as the name sugegsts?

I only ask because I thought from some other posts that it might in fact be (hitpoints left)/(total hitpoints). It would seem from Gregba's suggested fix (some pages back) that he believes it is this latter formula. I say this because he suggests you should get scarred if GeneralHPLostRatioinBattle is < 0.3. iirc that is, I haven't checked ...

This (obviously) affects what the scarred trigger will do. I gather from discussions that the consensus is that you should get scarred if you lose 70% or more of your hitpoints. Am I right about that?

Anyway, can someone set me straight on what the this function actually returns, and I giess I can make my mind up on where the break should be. I, too, am sick of getting horribly scarred people who lose influence as a result, when the most they have done is ride down a few routers.

[player1]

And I thought that concensus was
GeneralHPLostRatioinBattle is < 0.7
or scarred after losing 30% of HP.

And that's probably what CA wanted, but reverted the function from HPlost to "HPleft".

Giving it to just those with less then 30% hp would make it very, very rare trait.

[Olmsted]

Thank you. I will make that adjustment to the battle scarred trait in my file.

[tai4ji2x]

i personally think only losing 30% is still too little (ie, still too easy to get the trait). i set the trigger to 0.6 (%40 HP lost).

[player1]

i personally think only losing 30% is still too little (ie, still too easy to get the trait). i set the trigger to 0.6 (%40 HP lost).

Well, there are multiple level of that same trait, so it takes time for it too form.

And since 0.3 number was CA choice so be it (for a fix, not mod).

[Bob the Insane]

Has anyone suggested yet doubling the threshold values for all the traits gained through combat to counter the apparant doubling effect that occurs when you fight battles on the battlemap??

[therother]

Has anyone suggested yet doubling the threshold values for all the traits gained through combat to counter the apparant doubling effect that occurs when you fight battles on the battlemap??Yeah, but the problem is that the AI doesn't often fight on the battlemap. So if you doubled all the thresholds, it would take the AI twice as long to get each trait, which is no better than not doubling it (where the human player take half the time to progress up the levels).

One possible workaround would be to create a line of doubled battlefield traits that only the human player uses.

[Simetrical]

Except that you'd have to figure out a way to only have the player use them, which is tricky. There aren't any strat-map conditions (https://forums.totalwar.org/vb/showthread.php?t=43121) that can limit a trigger to a player, unfortunately. You'd have to do it faction by faction, changing it for every game. Also, it would get screwed up if the player auto-resolved or the comp fought on the battle map, but both of those scenarios favor the AI, so that's okay.

How to work around this . . . you might be able to make some kind of conditional statement. Hmm. Wait, maybe I have something. What about this? Double all relevant thresholds, so my the last level of my example trait (GoodAttacker) has a threshold of 32. Then add a trigger (actually, two triggers, in case there's a limit on condition number) like so:

Trigger EvenGoodAttacker1
WhenToTest PostBattle

Condition IsGeneral
and Trait GoodAttacker = 1
or Trait GoodAttacker = 3
or Trait GoodAttacker = 5
or Trait GoodAttacker = 7
or Trait GoodAttacker = 9
or Trait GoodAttacker = 11
or Trait GoodAttacker = 13
or Trait GoodAttacker = 15

Affects GoodAttacker 1 Chance 100

Trigger EvenGoodAttacker2
WhenToTest PostBattle

Condition IsGeneral
and Trait GoodAttacker = 17
or Trait GoodAttacker = 19
or Trait GoodAttacker = 21
or Trait GoodAttacker = 23
or Trait GoodAttacker = 25
or Trait GoodAttacker = 27
or Trait GoodAttacker = 29
or Trait GoodAttacker = 31

Affects GoodAttacker 1 Chance 100This solution isn't perfect. For it to work, you'd need to make all battle triggers have a 100% of giving you the trait(s) when their trigger conditions are met, which would make combat traits somewhat deterministic. To compensate, you could add selfperpetuating-type non-combat triggers to modify the traits up and down randomly, if you want.

Another problem is that battle triggers couldn't add any number of points other than one. AFAIK, we don't know how the triggers for a given event are parsed—if they're done sequentially, we could theoretically get around this problem by interspersing combat triggers with my new triggers. But it would probably be easier to just adjust all combat trait thresholds so that they work with two points per battle (which is what they'll get with the triggers set to give one).

Anyway, assuming that all battle triggers have a 100% chance of giving their traits, any general who fights exclusively on the battle map will always have an even number of points in his combat trait. If a general autoresolves, however, and no trait trigger gives a number of points other than one, he'll gain an odd number of points. The triggers above will immediately find combat traits with an odd number of points and bump them up by a point, effectively compensating for the lower payout of autoresolve.

Thoughts?

-Simetrical

[Bob the Insane]

Simetrical - sorry mate, you have complete lost me on that one...

I was thinking however that we could assume that the player largely fights on the battlemap and adjust the threshold to allow for that (doubling them)... We already know that the AI does not tend to gain high star rated general through fighting much, so we could try looking into a mechanisim to deliver high star rated generals outside of the battlefield...

Perhaps create a perpetual trigger for GoodCommand and BadCommander..

Theamin thing to consider is that anything we do will apply equally to player and AI..

[RJV]

Except that you'd have to figure out a way to only have the player use them, which is tricky. There aren't any strat-map conditions (https://forums.totalwar.org/vb/showthread.php?t=43121) that can limit a trigger to a player, unfortunately. You'd have to do it faction by faction, changing it for every game.

But would that really be too much of a problem? Just add in the 'and not faction = whatever' condition, make n copies of the file, edit each to add the relevant faction name and voila. Couple this with a little batch file to rename the file from the faction-specific one to the genuine one before firing off the RTW exe and away you go. I'm skipping steps here of course, and you'd have to make sure you played the right faction once you loaded the game, so it's not all that elegant. But if it made it work....

Anyway, just something to think about.

Cheers,

Rob

[Sinner]

Simetrical, I get what you're thinking, but since the triggers are processed sequentially as far as I can tell I think we'll need something like this...

Trigger GoodAttacker1_31plus
WhenToTest PostBattle
Condition IsGeneral
and Trait GoodAttacker >= 31
Affects GoodAttacker 1 Chance 100

Trigger GoodAttacker1_30
WhenToTest PostBattle
Condition IsGeneral
and Trait GoodAttacker = 30
Affects GoodAttacker 1 Chance 100

Trigger GoodAttacker1_29
WhenToTest PostBattle
Condition IsGeneral
and Trait GoodAttacker = 29
Affects GoodAttacker 1 Chance 100

etc

This way, if I have 29 points in GoodAttacker, the only trigger I match is GoodAttacker1_29. It then increases my points to 30, but I don't trigger GoodAttacker1_30 since I'm already past it. There are a couple of potential problems though: as yet do we know if the game is scanning the list of triggers twice, in which case the second time around it will trigger GoodAttacker1_30 after all; the other possible flaw is that there might be a limit on the number of triggers, which we could very possibly hit given the number we'd need to have for each current trigger condition.

As for the faction specific idea, that could work albeit with a lot of effort to set up, with the easiest solution being to set up each faction as a mod and then running that faction specific version of the game using the -mod:XXXX switch in the command line options.

[therother]

As for the faction specific idea, that could work albeit with a lot of effort to set up, with the easiest solution being to set up each faction as a mod and then running that faction specific version of the game using the -mod:XXXX switch in the command line options.Yeah, I've had much the same idea as Rob. The use of the mod is possible I guess, setting up a .bat script to run the game perhaps - press 1 to play Julii, and so on. I suppose that would be the least amount of work, in some respects, for the players and coders.

Still pondering the Simetrical/Sinner idea - has it been tested, or is anyone planning on testing it? So far, the best working solution that I've seen will just make the trait work as intended on average, and not for all instances. As I understand it, this would be a complete solution.

[SilverEye]

to get back on topic : the farmer/trader issue

Here's another 2 cents from from a fellow RTW player suffering from chronical poor farming at Frustration Level 1 Chance 100

reading through the entire 5 pages of this thread for the modding/scripting noob that i am and still trying to make sense out all of it i would like a conclusive answer to the issue.
Someone already said the same thing a few posts back without much result so it seems i will just have to give me the answer myself.

Well here goes: there is none...

I think it's safe to say that the trade/farm triggers are NOT bugged, but on the other hand saying that the default settings are a bit 'flawed' would be putting it mildly.
Well, with all the ideas, suggestions, testresults, modding examples etc given up until this point there is enough information here to play around with the trigger chances and trait thresholds to tweak and finetune it to your own preferences and playing style. Wich is exactly what i did, much to my own happiness.
I suggest that all of you who also cannot wait for the next CherryVanilla patch to adress this issue do the same, trust me you'll feel a lot better and no longer have that urge to throw R:TW out the window.

2 more things i want to say, then i'll shut up again.

First an example of what i mean with flawed default:
Aside from random births the only way to get BadFarmer is by building something other then a farm and the only way for BadTrader is by building something else then a trader, not building Ports and Roads do not affect BadTrader they only affect GoodTrader when you do build them , right ?
Then why is BadFarmer 1 chance 8% /building with trait thresholds of 1,2 and 3 and BadTrader only 1 chance 1% /building with thresholds of 1,3 and 6 ?!?

The default system is setup in such a way that only those few factions with an Agriculture or Trade Deity in their Pantheon will have a chance of avoiding the negative traits other then keeping their family member out of cities for their entire life, wich the other factions are condemned to.
Sure you may get 1 guy somewhere to go beyond the first level of the positive side of the trades with some absurd insane micromanagement, if he doesnt die of old age first before reaching NoGoingBackLevel 3. But even then there is no SelfPerpetuating or even a Genetics trigger to pass the hard earned virtue on to the next generation.
Specially in the later parts of the game you'll eventually run out of new farms to build since they can never be destroyed in newly conqured lands and you will end up with all your governors being Clones with the all the same negative Vices instead of unique characters with depth and personality no matter what you do...

thats what i mean with 'flawed' , its not bugged but it **** well needs fixing.
So either wait for a mod or patch or do it yourself.

Second ...
This is for the CherryVanilla mod people , both creators and users. Not sure if this has been adressed already somewhere else but i'll mention it again. After reading through this entire thread word for word and gaining some understanding of the Governing6 and Governing10 triggers and some modding of myself i noticed the following changes that were made:

Trigger governing6
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished > = farms

Affects BadFarmer 1 Chance 8
Affects BadAdministrator 1 Chance 10

Mod218 - 11/14 : added bad admin effect

Trigger governing10
WhenToTest GovernorBuildingCompleted

Condition not SettlementBuildingFinished > = trader

Affects BadTrader 1 Chance 1
Affects BadAdministrator 1 Chance 10

Mod221 - 11/14 : added bad admin effect

Now correct me if i am wrong, but does this not mean that building any trader or farm will give my governor a 10% BadAdmin chance and any other type of building a 20% BadAdmin chance ?!?

Ok that was all , i'l crawl back under my rock now.

[Sinner]

You are correct with your last statement, SilverEye. If that's CherryVanilla then it hasn't addressed the fundamental flaw with the BadFarmer trigger, if anything it's made the situation worse for governors in that they'd get BadAdministrator as well.

I personally consider the trigger condition for BadFarmer to be bugged in that it occurs even if you've already built the farm for that level of settlement, so it's impossible to avoid, but that's just my opinion.

I think the the most palatable answers so far are to either add the AdviseBuild condition since at least that takes into account whether that settlement level's farm is available to be queued or not, or to use SettlementBuildingExists to check if the farm has already been built for that level. Either method requires the single current trigger to be replaced by 5, one for each level of farm, and both need the % chance of getting BadFarmer points increased else the trigger becomes nearly ineffective.


Switching back to the battle triggers problem: from my testing it appears that they only get tested once for autocalced battles, but twice for tactical battles. I think there's a clue for what's happening in the code in the Events, Conditions, & Commands thread (https://forums.totalwar.org/vb/showthread.php?t=43121), if you look at many of the battle conditions, they can occur either in Battle or Strat (ie. Campaign map). I think what happens is that autocalc battles cause the triggers to be checked by the Strat game engine, while player-fought battles first get checked by the Battle game engine at the end of the combat and then again by the Strat game engine upon return to the campaign map.

Whether this is what is occuring or not doesn't really matter, since the effects are what's important for us and the simple and sad fact is that we're getting two trigger checks for every player-fought battle.

As a note, my testing method was as follows: I played as the Julii, first editting Vibius Julius to remove his GoodCommander 1 trait. I editted the V0090_Standard_Battle_Any_Victory_VnV_Trigger trigger to remove the BattleOdds condition since I wanted it to return a result simply upon victory, so the trigger looks like this...


Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger

WhenToTest PostBattle

Condition IsGeneral
and WonBattle

Affects GoodCommander 1 Chance 100


The only other triggers that give GoodCommander are those for adoption, random birth and worthy of marriage, so I know that no other trigger will be effecting my tests since I'm using an already established family member.

As I've already said, on autocalc victories Vibius gained only 1 point towards GoodCommander as would be expected, but for battles I fought he gained 2 points per victory.

I then tested the idea initially proposed by Simetrical although I used my slant on it, replacing the standard V0090_Standard_Battle_Any_Victory_VnV_Trigger trigger with the following...

Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_8plus
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and Trait GoodCommander >= 8

Affects GoodCommander 1 Chance 100

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_7
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and Trait GoodCommander = 7

Affects GoodCommander 1 Chance 100

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_6
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and Trait GoodCommander = 6

Affects GoodCommander 1 Chance 100

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_5
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and Trait GoodCommander = 5

Affects GoodCommander 1 Chance 100

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_4
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and Trait GoodCommander = 4

Affects GoodCommander 1 Chance 100

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_3
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and Trait GoodCommander = 3

Affects GoodCommander 1 Chance 100

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_2
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and Trait GoodCommander = 2

Affects GoodCommander 1 Chance 100

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_1less
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and Trait GoodCommander < = 1

Affects GoodCommander 1 Chance 100

I only went up to 8 points since I expected significant results long before I'd get any higher. I ran my tests again and for each autocalc victory Vibius gained a point towards GoodCommander, and yet again for each player fought battle he gained two points per victory, so this method will not work either.

So what answer is left? I think that leaves only the faction-specific option even though it's a major pain in the ass. It would also kind of force the player into fighting out every battle since he wouldn't get double points for autocalcing.

[therother]

So what answer is left? I think that leaves only the faction-specific option even though it's a major pain in the ass. It would also kind of force the player into fighting out every battle since he wouldn't get double points for autocalcing.I'm beginning to think that there is no way around using player faction specific traits. Have been doing some tests of my own. However, things were delayed a little by me using Sobriety as one of the traits I used to test the triggers. With a British General. Yes, I know now...

[therother]

I'm beginning to think that there is no way around using player faction specific traits.Okay, got the GoodCommander working properly using this idea.

I've made a new trait line, PlayerGoodCommander, as below:


;------------------------------------------
Trait PlayerGoodCommander
Characters family
AntiTraits PlayerBadCommander

Level Confident_Commander
Description Confident_Commander_desc
EffectsDescription Confident_Commander_effects_desc
GainMessage Confident_Commander_gain_desc
Threshold 2

Effect Command 1

Level Good_Commander
Description Good_Commander_desc
EffectsDescription Good_Commander_effects_desc
GainMessage Good_Commander_gain_desc
Threshold 4

Effect Command 2

Level Superior_Commander
Description Superior_Commander_desc
EffectsDescription Superior_Commander_effects_desc
GainMessage Superior_Commander_gain_desc
Threshold 8

Effect Command 3

Level Great_Commander
Description Great_Commander_desc
EffectsDescription Great_Commander_effects_desc
GainMessage Great_Commander_gain_desc
Threshold 16

Effect Command 4

Level Legendary_Commander
Description Legendary_Commander_desc
EffectsDescription Legendary_Commander_effects_desc
GainMessage Legendary_Commander_gain_desc
Epithet Legendary_Commander_epithet_desc
Threshold 32

Effect Command 5

I've also added/changed both these triggers:


;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and not FactionType britons

Affects GoodCommander 1 Chance 100

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_Player
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and FactionType britons

Affects PlayerGoodCommander 1 Chance 100
To change faction, all you'd need to do is replace "britons" with whatever faction you intend to use.

You would, of course, need to do this with every trait line which is affected by the battlemap (GoodAttacker, BattleScarred, BadCommander, etc.). Hmm, it's not a great solution by any stretch of the imagination, but at least it works.

(Quote the post to get the correct formatting.)

[player1]

Ok is this the way how Scarred and Coward traits and
Shieldbearer and Heroic Saviour ancillaries should work:

in export_descr_character_traits.txt:


Trigger battle1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.7 ;was > 0.3

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

;------------------------------------------
Trigger battle1b
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.7 ;was > 0.3
and Trait Berserker >= 1

Affects Berserker 1 Chance 30

;------------------------------------------
Trigger battle1R
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.7 ;was > 0.3
and CultureType roman

; Affects BattleScarred 1 Chance 30
Affects RomanHero 1 Chance 15

and:


Trigger battle4
WhenToTest PostBattle

Condition GeneralNumKillsInBattle = 0 ;was not GeneralFoughtInCombat
and PercentageEnemyKilled > 0 ;was = 0

Affects Coward 1 Chance 10


And in export_descr_ancillaries.txt:


Trigger trigger_heroic_saviour
WhenToTest PostBattle
Condition GeneralHPLostRatioinBattle = 80
and not Routs
and WonBattle
and GeneralFoughtInCombat
and IsGeneral

AcquireAncillary heroic_saviour chance 50

and:


Trigger trigger_shieldbearer
WhenToTest PostBattle
Condition GeneralHPLostRatioinBattle >= 0.2 ;was 5
and WonBattle
and not Routs
and IsGeneral

AcquireAncillary shieldbearer chance 30

[player1]

Disregard last post, < = got truncated

Ok is this the way how Scarred and Coward traits and
Shieldbearer and Heroic Saviour ancillaries should work:

in export_descr_character_traits.txt:


Trigger battle1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.7 ;was > 0.3

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

;------------------------------------------
Trigger battle1b
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.7 ;was > 0.3
and Trait Berserker >= 1

Affects Berserker 1 Chance 30

;------------------------------------------
Trigger battle1R
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.7 ;was > 0.3
and CultureType roman

; Affects BattleScarred 1 Chance 30
Affects RomanHero 1 Chance 15

and:


Trigger battle4
WhenToTest PostBattle

Condition GeneralNumKillsInBattle = 0 ;was not GeneralFoughtInCombat
and PercentageEnemyKilled > 0 ;was = 0

Affects Coward 1 Chance 10


And in export_descr_ancillaries.txt:


Trigger trigger_heroic_saviour
WhenToTest PostBattle
Condition GeneralHPLostRatioinBattle < = 0.2 ;was >= 80
and not Routs
and WonBattle
and GeneralFoughtInCombat
and IsGeneral

AcquireAncillary heroic_saviour chance 50

and:


Trigger trigger_shieldbearer
WhenToTest PostBattle
Condition GeneralHPLostRatioinBattle >= 0.2 ;was 5
and WonBattle
and not Routs
and IsGeneral

AcquireAncillary shieldbearer chance 30

[player1]

I just realized that GeneralFoughtInCombat is always true, even if general in not actually fighting, but just standing in the battle (that why I thought it was bugged).

But if you withraw general from battle then it will be zero.

So original trigger would trigger coward, if you retreat all your units at start without any fighting. Also, if enemy does the same instead.

[Sinner]

I don't think the faction-specific method will actually work 100%. theother has shown how I thought we'd need to set it up and I'll use that to explain what I believe the problem is...

I think it can now be accepted that while autocalcing only checks the triggers once, player-fought battles check them twice and that all AI vs AI battles are autocalced.

Using theother's handy example, while considering that similar changes will be needed for BadCommander, let's consider possible battle outcomes...

AI vs AI: The winner gets a point in GoodCommander and the loser gets a point in BadCommander. This is the desired result and is in effect the baseline to which we compare player vs AI battles.

Player vs AI autocalc, Player wins: The AI gets a point of BadCommander and the player gets a point in PlayerGoodCommander (ie. in effect half a point of GoodCommander). This is undesirable since the AI has gained an advantage over the player compared to an AI via AI battle.

Player vs AI autocalc, AI wins: The AI gets a point of GoodCommander and the player gets a point in PlayerBadCommander (ie. in effect half a point of BadCommander). This is undesirable since the player has gained an advantage over the AI compared to an AI via AI battle.

Player vs AI fought, Player wins: The AI gets two point of BadCommander and the player gets two point in PlayerGoodCommander (ie. in effect a point of GoodCommander). While the player result is as desired, the AI is suffering unfairly.

Player vs AI fought, AI wins: The AI gets two point of GoodCommander and the player gets two point in PlayerBadCommander (ie. in effect a point of BadCommander). While the player result is as desired, the AI is benefiting unfairly.

Note that I'm ignoring battle odds for this to simplify the tests.

[therother]

To get the GoodCommander working right, you also need the BadCommander anti-trait.


;------------------------------------------
Trait PlayerBadCommander
Characters family
AntiTraits PlayerGoodCommander

Level Indifferent_Commander
Description Indifferent_Commander_desc
EffectsDescription Indifferent_Commander_effects_desc
Threshold 4

Effect Command -1

Level Incompetent_Commander
Description Incompetent_Commander_desc
EffectsDescription Incompetent_Commander_effects_desc
Threshold 8

Effect Command -2

Level Poor_Commander
Description Poor_Commander_desc
EffectsDescription Poor_Commander_effects_desc
Threshold 12

Effect Command -3

Level Pathetic_Commander
Description Pathetic_Commander_desc
EffectsDescription Pathetic_Commander_effects_desc
Threshold 16

Effect Command -5



Similarly, I've also added/changed both these triggers:



;------------------------------------------
Trigger V0100_Standard_Battle_Any_Loss_VnV_Trigger
WhenToTest PostBattle

Condition IsGeneral
and not WonBattle
and not FactionType britons
and BattleOdds > 1.5

Affects BadCommander 1 Chance 50

;------------------------------------------
Trigger V0100_Standard_Battle_Any_Loss_VnV_Trigger_Player
WhenToTest PostBattle

Condition IsGeneral
and not WonBattle
and FactionType britons
and BattleOdds > 1.5

Affects PlayerBadCommander 1 Chance 50


As before, replace "britons" with whatever faction you intend to use.

This faction specific thing is a little more complicated than I previously thought, as you'd also need to replace all the battlefield traits in the descr_strat.txt file for the player's faction. Hmm, it's never easy, is it?

Anyway, I've had a few battles with these traits, and they certainly seem to get the job done.

Edit: Of course, there is nothing you can do, with this system, to prevent the AI getting double traits (both good and negative) from the battlemap battles. And it means that you have to work twice as hard if you like to auto-resolve your battles. Meaning the more I think about this solution, the less I like it.

(Quote the post to get the correct formatting.)

[Sinner]

I think I've cracked it, can somebody try this as well to make sure I'm not influencing my own results and seeing what I want to see...

First I doubled up the thresholds, so GoodCommander will be...

Trait GoodCommander
Characters family
AntiTraits BadCommander

Level Confident_Commander
Description Confident_Commander_desc
EffectsDescription Confident_Commander_effects_desc
GainMessage Confident_Commander_gain_desc
Threshold 2

Effect Command 1

Level Good_Commander
Description Good_Commander_desc
EffectsDescription Good_Commander_effects_desc
GainMessage Good_Commander_gain_desc
Threshold 4

Effect Command 2

Level Superior_Commander
Description Superior_Commander_desc
EffectsDescription Superior_Commander_effects_desc
GainMessage Superior_Commander_gain_desc
Threshold 8

Effect Command 3

Level Great_Commander
Description Great_Commander_desc
EffectsDescription Great_Commander_effects_desc
GainMessage Great_Commander_gain_desc
Threshold 16

Effect Command 4

Level Legendary_Commander
Description Legendary_Commander_desc
EffectsDescription Legendary_Commander_effects_desc
GainMessage Legendary_Commander_gain_desc
Epithet Legendary_Commander_epithet_desc
Threshold 32

Effect Command 5

Then, thanks to player1 noting that GeneralFoughtInCombat is always true in battle, I created an autocalc and a non-autocalc version of combat triggers like so...

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_autocalc
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and not GeneralFoughtInCombat

Affects GoodCommander 2 Chance 100

;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger_fought
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and GeneralFoughtInCombat

Affects GoodCommander 1 Chance 100

As a note, the autocalc version awards double the points since it only gets checked once, while the battle-fought version gets checked twice.

[player1]

I ugre more testing with GeneralFoughtInCombat.

In my last test I just put coward chance to 8/100, with original equation, and after retreating from battle I haven't got coward tarit.

So, maybe it's when general retreats, but not other troops.
Not sure, anymore, needs more testing.

But, at least for Coward there is alternative...

[therother]

I think I've cracked it, can somebody try this as well to make sure I'm not influencing my own results and seeing what I want to see...
Looks promising. Will get to it asap.

Edit: Any reason why you knocked off the battleodds restriction, or did you remove it just for testing?

[Sinner]

I removed it just for testing

[player1]

Back after some more testing.

It seams that GeneralFoughtInCombat is always true.
Both in cases when general remained (both standing or fighting) in battle and when I withrow him from battle, the condition with generalfought was true.

[therother]

I'm having difficulties getting Confident Commander from an autocalc victory. Fought two battles, won both, but only got a Battlescarred trait and a Galloper - nothing in the GoodCommander line. I also removed the battle odds, so that can't be it.

Edit: Okay, this doesn't work properly. The GeneralFoughtInCombat condition can be true for Autocalcs as well, so it doesn't differentiate.

To test this, I created a new trigger:



;------------------------------------------
Trigger FoughtTest
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and GeneralFoughtInCombat

Affects GoodCommander 16 Chance 100
After an autocalc batte, my general was a Great Commander (16 points), which means the GeneralFoughtInCombat was true. Which is a shame: it was a great idea. Perhaps there is another condition that might do the job though?

[Sinner]

Yeah, I just started getting the same issue trying to get BadCommander from a defeat.

I think what it does with autocalc is randomly determine whether the general fights or not based upon how many troops he has. I attacked Segesta with my general, a triarii, 6 hastati, a velite and an archer, and my general obviously didn't need to fight to get an autocalc victory so I triggered my 2 point award trigger. I repeated the attack with just the general and 2 hastati and this time the general must have fought - his unit suffered casualties - and I must have triggered the 1 point award trigger.

So it looks as though GeneralFoughtInCombat works correctly for autocalc, but since it always returns true in player-fought battles it's bugged in that instance.

[player1]

If anybody is interested I made fixed version of Scarred/Coward trait at Scarface thread at twcenter.net

http://www.twcenter.net/forums/index.php?act=Attach&type=post&id=1811983775

[Simetrical]

This way, if I have 29 points in GoodAttacker, the only trigger I match is GoodAttacker1_29. It then increases my points to 30, but I don't trigger GoodAttacker1_30 since I'm already past it. There are a couple of potential problems though: as yet do we know if the game is scanning the list of triggers twice, in which case the second time around it will trigger GoodAttacker1_30 after all . . .Look at my previous post a bit more closely—I left out the even numbers for the triggers. Only the odd numbers triggered.

Anyway, I've thought of another way to do this, a rather better way. It's still not perfect—its flaw is that it only allows each affected trigger to trigger once per turn. But it's a far sight better than what we have so far.

Take any affected trigger—say, hate_n_fear1. Now create two traits, like so:

;------------------------------------------
Trait Phnf1 ; That's for "prevent hate_n_fear1"
Characters family
Hidden
AntiTraits AntiPhnf1

Level Phnf1
Description Phnf1_desc
EffectsDescription Phnf1_effects_desc
Threshold 1



;------------------------------------------
Trait AntiPhnf1
Characters family
Hidden
AntiTraits Phnf1

Level AntiPhnf1
Description AntiPhnf1_desc
EffectsDescription AntiPhnf1_effects_desc
Threshold 1Add the following to text\descr_VnVs:

¬--------------------

{Phnf1} Prevent hate_n_fear1

{Phnf1_desc}
Hidden VnV to stop double trait bug

{Phnf1_effects_desc}
No Effects

¬--------------------

{AntiPhnf1} Unprevent hate_n_fear1

{AntiPhnf1_desc}
Hidden VnV to stop double trait bug

{AntiPhnf1_effects_desc}
No EffectsBack in EDCT.txt, modify the hate_n_fear1 trigger like so (changes underlined):

Trigger hate_n_fear1
WhenToTest PostBattle

Condition IsGeneral
and not WonBattle
and BattleSuccess = crushing
and I_ConflictType Normal
and BattleOdds >= 0.5
and BattleOdds < 1.5
and GeneralFoughtCulture roman
and Trait Phnf1 < 1

Affects HatesRomans 1 Chance 40
Affects Phnf1 1 Chance 100Finally, create a new trigger immediately after like so:

Trigger unprevent_hate_n_fear1
WhenToTest CharacterTurnEnd

Condition Trait Phnf1 > 0

Affects AntiPhnf1 1 Chance 100So in other words, hate_n_fear1 gets checked the first time for any battle. This then gives the general the Phnf1 trait. If the battle is on the battle map, the trigger is checked again—but the condition is false, so it fails. At the end of the turn, any character with Phnf1 loses it.

I originally tried using the PreBattle trigger from here (https://forums.totalwar.org/vb/showthread.php?p=705638&posted=1), but that doesn't seem to be implemented. I can't find any other triggers that reliably occur between every battle, so this is the best I can do. Anyone who can either get PreBattle working or find an equivalent will pretty much make this fix a perfect workaround.

-Simetrical

[Slaists]

was i was browsing through the same exp_file noticed the following about the drinking traits:

;------------------------------------------
Trigger temple_of_fun_vnv_trigger
WhenToTest CharacterTurnEnd

Condition EndedInSettlement
and RemainingMPPercentage = 100
and SettlementBuildingExists > = temple_of_fun_temple

Affects Drink 1 Chance 10
Affects Gambling 1 Chance 10
Affects Arse 1 Chance 2
Affects Girls 1 Chance 5
Affects Perverted 1 Chance 5

The way it is set now, it appears, the trait is penalizing for having any building in the settlement that is higher than the level of the drinking establishment... Was wondering if that's actually what we want? Probably, the intended trigger is to penalize for building the driking temple before all other buildings are finished. Thus, a corrected version would be:


;------------------------------------------
Trigger temple_of_fun_vnv_trigger
WhenToTest CharacterTurnEnd

Condition EndedInSettlement
and RemainingMPPercentage = 100
and SettlementBuildingExists < temple_of_fun_temple

Affects Drink 1 Chance 10
Affects Gambling 1 Chance 10
Affects Arse 1 Chance 2
Affects Girls 1 Chance 5
Affects Perverted 1 Chance 5

[Sinner]

Look at my previous post a bit more closely—I left out the even numbers for the triggers. Only the odd numbers triggered.

Yeah, I'd noted you'd left out the even numbers, but that created a flaw I sought to correct with my variant of your idea, since your suggested trigger didn't account for generals that didn't have the trait at all, so they'd never match the conditions as shown, plus my suggestion would have been able to get around the 1 point per trigger limitation. In the end it doesn't matter since neither method solved the root problem that autocalcing - and thus all AI vs AI battles - only check the triggers once and player-fought battles check them twice.

Your new method is more promising, since it does balance the effects of autocalc and player-fought battles, but it does have a flaw that I'm not 100% happy with: the general will only get traits from the first battle in the turn, which seems odd if he gets, for example, a point towards GoodCommander for winning a skirmish against a bunch of peasants, but then gets his ass kicked and loses his entire army while suffering no negative traits. OK, that will occur for both AI & player generals, but the player is smarter and could exploit this by targeting small, easy stacks first in the turn, before attacking larger stacks which might beat their army.


Slaists, you're apparently falling into the common trap of assuming SettlementBuildingExists >= temple_of_fun_temple and similar conditions are mathematical equations, when they're not. SettlementBuildingExists is a function and >= temple_of_fun_temple are two of its parameters.

The way SettlementBuildingExists works is that it first checks to see what building tree contains the building declared as the second parameter, in this case temple_of_fun_temple is in the temple_of_fun line of buidlings. It then checks to see if the current settlement has a building from that tree. If it does it compares the building it's just found with the building declared as a parameter using the logic declared as the first parameter, returning true or false as appropriate.

So SettlementBuildingExists >= temple_of_fun_temple says if there is a Temple of Fun, Large Temple of Fun, Awesome Temple of Fun or Pantheon of Fun present in the settlement then the condition is true, for any other building including a Shrine of Fun or no buildings at all then the condition is false.

[Bob the Insane]

was i was browsing through the same exp_file noticed the following about the drinking traits:

;------------------------------------------
Trigger temple_of_fun_vnv_trigger
WhenToTest CharacterTurnEnd

Condition EndedInSettlement
and RemainingMPPercentage = 100
and SettlementBuildingExists > = temple_of_fun_temple

Affects Drink 1 Chance 10
Affects Gambling 1 Chance 10
Affects Arse 1 Chance 2
Affects Girls 1 Chance 5
Affects Perverted 1 Chance 5

The way it is set now, it appears, the trait is penalizing for having any building in the settlement that is higher than the level of the drinking establishment... Was wondering if that's actually what we want? Probably, the intended trigger is to penalize for building the driking temple before all other buildings are finished. Thus, a corrected version would be:


;------------------------------------------
Trigger temple_of_fun_vnv_trigger
WhenToTest CharacterTurnEnd

Condition EndedInSettlement
and RemainingMPPercentage = 100
and SettlementBuildingExists < temple_of_fun_temple

Affects Drink 1 Chance 10
Affects Gambling 1 Chance 10
Affects Arse 1 Chance 2
Affects Girls 1 Chance 5
Affects Perverted 1 Chance 5

Hi, I think you have made a slight mistake in this...

The line "and SettlementBuildingExists > = temple_of_fun_temple" is not making a comparison against all buildings, but only against the "temple_of_fun" line of buildings (see the temple_of_fun entry in export_descr_buildings.txt). The "temple_of_fun_temple" valuse is the second of the buildings and thus the condition only becomes true after you upgrade your shrine to a temple building...


Edit: oops, Sinner already explained... ~D

[therother]

Okay, I think I may have a slightly improved solution to the bugged battlefield traits, although I haven't tested it fully - just the key concepts. But I think I'll throw it open for others to try before I log off.

It's a modified version of Simetrical's cracking idea.

Edit: But as Sinner points out below, it does quite work properly. I'll leave it here in case anyone can fix it.

First, create 2 new trait and anti-traits in the mould of Simetrical outlines above. For brevity, I'll call then double, antidouble, count, anticount. The first set needs two levels, threshold 1 and 2.

Create the descriptions as above.

Then the triggers:

First triggers in the file must be these, in this order:



;------------------------------------------
Trigger V0010_DoubleCombat
WhenToTest PostBattle

Condition IsGeneral
and Trait count = 0
and Trait double = 1

Affects antidouble 1 Chance 100
Affects count 1 Chance 100

;------------------------------------------
Trigger V0010_DoubleCombat2
WhenToTest PostBattle

Condition IsGeneral

Affects double 1 Chance 100


The last triggers must be these:



;------------------------------------------
Trigger V0010_DoubleCombat reset
WhenToTest PostBattle

Condition IsGeneral
and Trait double = 2

Affects antidouble 2 Chance 100

;------------------------------------------
Trigger V0010_DoubleCombat2 reset
WhenToTest CharacterTurnEnd

Condition IsGeneral
and count = 1

Affects anticount 1 Chance 100

;------------------------------------------
Trigger V0010_DoubleCombat3 reset
WhenToTest CharacterTurnEnd

Condition IsGeneral
and double = 1

Affects antidouble 1 Chance 100


Now put "and Trait double = 1" as a condition for each battlefield trait (i.e. one that is tested "PostBattle").



;------------------------------------------
Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger
WhenToTest PostBattle

Condition IsGeneral
and WonBattle
and Trait double = 1

Affects GoodCommander 1 Chance 100

;------------------------------------------
Trigger V0100_Standard_Battle_Any_Loss_VnV_Trigger
WhenToTest PostBattle

Condition IsGeneral
and not WonBattle
and BattleOdds > 1.5
and Trait double = 1

Affects BadCommander 1 Chance 100


Okay, so what should this do? The first trigger is important, but for reasons that will become apparent later.

The 2nd trigger is always triggered in any conflict, and gives your general the trait double at level one. We'll use this to allow all battlemap triggers to be tripped normally. For the 2nd read, if you are fighting on the battlemap, they will not be tripped twice as double will be 2 for the second run. The 1st of the 2nd group of triggers removes this trait, at level two, for all battlemap battles.

So, this setup should make the battlemap traits work for all battlemap battles. The problem is, of course, autocalcs, which the AI does most often. So the problem becomes, what if the double trait is only triggered once (as in autocalc)? This is where the 1st trigger comes into play. It tests to see where double = 1 at the start of the battle (by using the 2nd new trait, count). If it is, then double is reset it to 0, and makes count = 1. The file is then read as before, except trait count will now be 1 for the 2nd read, stopping the 1st trigger activating a 2nd time.

It should be straightforward to scale this idea to have double1, double2, double3, double4, etc., to allow for multiple battles per turn for each character, each triggering a new trait when necessary, and each being reset, if necessary, at the end of turn.

I know I haven't explained this very well, I'm quite tired, but there should be enough there to get the gist of what I'm suggesting. I have the feeling that I'm missing something simple that would remove all these unnecessary complications, but I can't think at the moment.

[Sinner]

I don't think that'll work, theother. :(

I don't have the game in front of me right now, but working through the logic it doesn't look promising.

Running through step by step for autocalc:

1. Initial traits are count 0, double 0 and GoodCommander 0.
2. My general autocalcs a battle with 1-to-1 odds and wins.
3. Trigger V0010_DoubleCombat doesn't fire because the condition '...and Trait double = 1' isn't met.
4. Trigger V0010_DoubleCombat2 fires, setting double to 1.
5. Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger fires, setting GoodCommander to 1.
6. Trigger V0010_DoubleCombat_reset doesn't fire because the condition '...and Trait double = 2' isn't met.
7. Trigger V0010_DoubleCombat2_reset doesn't fire because the condition '...and Trait count = 1' isn't met.
8. Trigger V0010_DoubleCombat3_reset fires, giving antidouble 1 which sets double back to 0 since they're antitraits.
9. End conditions are thus count 0, double 0 and GoodCommander 1, which is what we want.

But the problem comes with player-fought battles:

1. Initial traits are count 0, double 0 and GoodCommander 0.
2. My general fights a battle with 1-to-1 odds and wins.
3. Trigger V0010_DoubleCombat doesn't fire because the condition '...and Trait double = 1' isn't met.
4. Trigger V0010_DoubleCombat2 fires, setting double to 1.
5. Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger fires, setting GoodCommander to 1.
6. Trigger V0010_DoubleCombat_reset doesn't fire because the condition '...and Trait double = 2' isn't met.
7. Trigger V0010_DoubleCombat2_reset doesn't fire because the condition '...and Trait count = 1' isn't met.
8. Trigger V0010_DoubleCombat3_reset fires, giving antidouble 1 which sets double back to 0 since they're antitraits.
9. After the first run through the triggers, the conditions at that point are the same as if I'd autocalced, namely count 0, double 0 and GoodCommander 1.
10. The bug then occurs and the game loops through the triggers again.
11. Trigger V0010_DoubleCombat doesn't fire because the condition '...and Trait double = 1' isn't met.
12. Trigger V0010_DoubleCombat2 fires, setting double to 1.
13. Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger fires, setting GoodCommander to 1.

I'll stop there since we've got GoodCommander a second time at that point for the results of the same battle.

[therother]

Yeah, I know. I've been fighting with it for the last half hour or so. I just can't seem to differentiate between a second read and an autocalc battle. If we could do that...

But the one trait thing still stands: we could use that to solve the problem for one battle per turn at least. Best we have so far.

[therother]

Actually, can we use WhenToTest PreBattleWithdrawal? I know this condition works.

[Jambo]

Regarding the coward trait, one thing I noticed with the modified version was that the AI generals were getting a lot of coward traits when I set the GeneralNumKillsInBattle = 0. Most likely this is due to the autocalc function for AI to AI battles as general units don't get so involved when battles are autocalculated.

[therother]

Okay, this is far from ideal, and there are some consequences, but I'll throw it out there:

Add these triggers to the bottom of export_descr_character_traits.txt:

Edit: needs to be 2 withdrawals, or if you autocalc a battle after an army retreats, the AI general will get no traits.

My custom traits:

;------------------------------------------
Trait DoubleCombat1
$ Characters family
$ Hidden
$ AntiTraits AntiDoubleCombat1
$
$ Level DoubleCombat1
$ Description DoubleCombat1_desc
$ EffectsDescription DoubleCombat1_effects_desc
$ Threshold 1
$
$ Level DoubleCombat2
$ Description DoubleCombat1_desc
$ EffectsDescription DoubleCombat1_effects_desc
$ Threshold 2
$
$
;------------------------------------------
Trait AntiDoubleCombat1
$ Characters family
$ Hidden
$ AntiTraits DoubleCombat1
$
$ Level AntiDoubleCombat1
$ Description AntiDoubleCombat1_desc
$ EffectsDescription AntiDoubleCombat1_effects_desc
$ Threshold 1
$
$ Level AntiDoubleCombat2
$ Description AntiDoubleCombat1_desc
$ EffectsDescription AntiDoubleCombat1_effects_desc
$ Threshold 2

My additions to RTW/data/text/export_VnVs.txt:



¬--------------------

{DoubleCombat1} DoubleCombat1

{DoubleCombat1_desc}
Hidden VnV to stop double trait bug

{DoubleCombat1_effects_desc}
No Effects

¬--------------------

{AntiDoubleCombat1} AntiDoubleCombat1

{AntiDoubleCombat1_desc}
Hidden AntiVnV to stop double trait bug

{AntiDoubleCombat1_effects_desc}
No Effects


Add these triggers to the bottom of export_descr_character_traits.txt:



;------------------------------------------
Trigger Player marks start of battlemap
$ WhenToTest PreBattleWithdrawal
$
$ Condition IsGeneral
$ and Trait DoubleCombat1 < 2
$
$ Affects DoubleCombat1 1 Chance 100
$
;------------------------------------------
Trigger Remove marker after battle
$ WhenToTest PostBattle
$
$ Condition IsGeneral
$ and Trait DoubleCombat1 = 2
$
$ Affects AntiDoubleCombat1 2 Chance 100
$
;------------------------------------------
Trigger Remove marker at end of turn
$ WhenToTest CharacterTurnEnd
$
$ Condition IsGeneral
$ and Trait DoubleCombat1 = 1
$
$ Affects AntiDoubleCombat1 1 Chance 100
$
;------------------------------------------
Trigger Remove marker at end of turn2
$ WhenToTest CharacterTurnEnd
$
$ Condition IsGeneral
$ and Trait DoubleCombat1 = 2
$
$ Affects AntiDoubleCombat1 2 Chance 100

Then add this condition for each battlefield trait (i.e. one that is tested "PostBattle").


$ and not Trait DoubleCombat1 = 2


In this scheme, the player withdraws twice before fighting a battle (you don't go to the battlemap, you just press withdraw on the popup box). This gives the general the DoubleCombat1 trait at level 2 (one for each withdraw), and marks the coming battle as a battlemap battle. For the first read, the "and not Trait DoubleCombat1 = 2" condition stops the general from getting any traits. This trait is removed at the end of the file. The 2nd read goes as normal, with the general picking up the appropriate traits. This should have no effect on autocalc or AI battles, unless they also do a PreBattleWithdrawal. In which case, that general will get not battlemap traits for that turn.

At the end of turn, the DoubleCombat1 is removed from all characters, as it can only ever be at level 0, 1 or 2.

Edit: Due to a board optimisation, whitespace at the start of a line is removed. To counter this, I've put $ signs at the start of each line. Just delete them, and everything will to formatted correctly.

[Sinner]

Not too keen on the idea of withdrawing from battle just to set up the required traits to avoid the double bug.

This is killing the game for me. People are saying what they'd like to see in the expansion pack, I simply want the bugs fixed. :(

[Zrave]

I am the developer of the CVP and I've been working on a fix very similar to what therother has just suggested.

I believe that the triggers in export_descr_character_traits are applied in sequential order, and that the double "bug" is a full sequence followed by a full sequence. This is presumed for my fix to work.

My fix is applied thus:

The two very last triggers:

;------------------------------------------
Trigger bugfix1
WhenToTest PostBattle

Condition Trait Bug = 1

Affects Fix 2 Chance 100

;------------------------------------------
Trigger bugfix2
WhenToTest PostBattle


Affects Bug 1 Chance 100



and similarly, a "condition not trait bug = 1" is added to all combat triggers.

[therother]

Not too keen on the idea of withdrawing from battle just to set up the required traits to avoid the double bug.Yes, it's not great, but it's fairly straightforward to do. It's the only condition that I know of that is tested before the battle, and that the player can control.

[therother]

I believe that the triggers in export_descr_character_traits are applied in sequential order, and that the double "bug" is a full sequence followed by a full sequence. This is presumed for my fix to work.I think this is the way it works also.

About your fix, the problem is still that of multiple battles per turn for the AI, or the player autocalcing. I think, overall, this is probably the best we have. The withdrawal thing, whilst being an interesting proof of concept, is really too fiddly for my liking.

[Zrave]

Yeah I wish I had a better fix, but this is certainly better than the other fixes I have attempted (doubling thresholds, etc).

Forgot to add in the first post and couldn't find an edit option to include it, I also included an eot trigger to make bug = 0. I don't know if this will work as intended, for example if computer attacks you, and you autocalc, will you go into your turn with bug = 1?

Still it is a good fix in that all of the player's non-autocalc battles will be figured, and the first autocalc of every "turn" will be counted as well.

I think two autocalcs per turn is rare enough for this fix to be acceptable.

[Sinner]

Zrave, unless you have a trigger at the end of a characters turn to tidy up, you're going to be causing problems for autocalc - and thus all AI vs AI battles - for more than just a turn.

Your suggestion in effect produces the opposite to theother's in that yours does work correctly for player-fought battles...

1. Initial traits are Bug 0, Fix 0 and GoodCommander 0.
2. My general fights a battle on the tactical map with 1-to-1 odds and wins.
3. Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger fires, setting GoodCommander to 1.
4. Trigger bugfix1 doesn't fire because the condition '...and Trait Bug = 1' isn't met.
5. Trigger bugfix2 fires, setting Bug to 1.
6. After the first run through the triggers, the conditions at that point are Bug 1, Fix 0 and GoodCommander 1.
7. The bug then occurs and the game loops through the triggers again.
8. Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger doesn't fire because the condition '...and not Trait Bug = 1' isn't met.
9. Trigger bugfix1 fires, setting Bug to 0 and Fix to 1 since they're antitraits.
10. Trigger bugfix2 fires, setting Bug to 0 and Fix to 0 since they're antitraits.
11. End conditions are thus Bug 0, Fix 0 and GoodCommander 1. Which is what we want.

But, there's a problem with autocalced battles...

1. Initial traits are Bug 0, Fix 0 and GoodCommander 0.
2. My general autocalcs a battle with 1-to-1 odds and wins.
3. Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger fires, setting GoodCommander to 1.
4. Trigger bugfix1 doesn't fire because the condition '...and Trait Bug = 1' isn't met.
5. Trigger bugfix2 fires, setting Bug to 1.
6. End conditions are thus Bug 1, Fix 0 and GoodCommander 1. While the latter is what we want, the value of Bug will cause problems with subsequent autocalc battles.

If this general now fought another autocalc battle...


1. Initial traits are Bug 1, Fix 0 and GoodCommander 0.
2. My general autocalcs a battle with 1-to-1 odds and wins.
3. Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger doesn't fire because the condition '...and not Trait Bug = 1' isn't met.
4. Trigger bugfix1 fires, setting Bug to 0 and Fix to 1 since they're antitraits.
5. Trigger bugfix2 fires, setting Bug to 0 and Fix to 0 since they're antitraits.
6. End conditions are thus Bug 0, Fix 0 and GoodCommander 1. This isn't good since the general hasn't been awarded for his victory.

If the general instead fought another battle but on the tactical map...

1. Initial traits are Bug 1, Fix 0 and GoodCommander 1.
2. My general fights a battle on the tactical map with 1-to-1 odds and wins.
3. Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger doesn't fire because the condition '...and not Trait Bug = 1' isn't met.
4. Trigger bugfix1 fires, setting Bug to 0 and Fix to 1 since they're antitraits.
5. Trigger bugfix2 fires, setting Bug to 0 and Fix to 0 since they're antitraits.
6. After the first run through the triggers, the conditions at that point are Bug 0, Fix 0 and GoodCommander 1.
7. The bug then occurs and the game loops through the triggers again.
8. Trigger V0090_Standard_Battle_Any_Victory_VnV_Trigger fires, setting GoodCommander to 2.
9. Trigger bugfix1 doesn't fire because the condition '...and Trait Bug = 1' isn't met.
10. Trigger bugfix2 fires, setting Bug to 1.
11. End conditions are thus Bug 1, Fix 0 and GoodCommander 2. Again, while the latter is what we want, the value of Bug will cause problems with subsequent autocalc battles.



One thought: has anybody checked to see if the AI suffers the double bug from player-fought battles? As far as I'm aware that's just assumed at the moment. We need somebody to test a battle that they win, but let the enemy general live, while using a spy to check their stats pre- and post-battle. Awkward to do I know, but it's hopefully possible that only the player's general is effected which makes the faction-specific fix workable providing the player never autocalcs.

[therother]

Zrave, unless you have a trigger at the end of a characters turn to tidy up, you're going to be causing problems for autocalc - and thus all AI vs AI battles - for more than just a turn.Yeah, he mentions that in his 2nd post.


One thought: has anybody checked to see if the AI suffers the double bug from player-fought battles?Yes, the double read from the battlemap happens for the AI as well.

[Sinner]

Ah, that's what happens when I post while working, takes me over an hour per post at times. ~:)

As for the AI also getting the double bug, one word: damn.

[therother]

I'm doing a full scale test of the PreBattleWithdrawal method (note to self: need to be careful when describing this method ~;)). I'm beginning to warm a little to it. Short of someone pulling something out of their hat, I think this is the one I'll be using myself. However, for the consensus patch, I think we'd rather have a more seemless trait system, so IMO the double/bug trait method is probably the best we have.

[player1]

Regarding the coward trait, one thing I noticed with the modified version was that the AI generals were getting a lot of coward traits when I set the GeneralNumKillsInBattle = 0. Most likely this is due to the autocalc function for AI to AI battles as general units don't get so involved when battles are autocalculated.

Well, that means that trait is actually working.


P.S.
I guess that same thing would happed even with original IsGeneralFoughtInCombat, since it works for autocalc, when PercentageEnemyKilled > 0 (or not PercentageEnemyKilled = 0), is used.

[Sinner]

To save anybody else wasting their time, it doesn't look like the PreBattlePanelOpen event works for what we want - I think the reason being that the only value it returns is the faction and we need the character record as well.

[Simetrical]

Zrave's fix seems best for now. To improve on it slightly, we might be able to remove the Bug trait every time some other common inter-battle triggers fire, like maybe GeneralCapturesSettlement, GeneralAssaultsResidence, CharacterTurnStart (all three of which may not work, since CA didn't use them, and we'd have to make sure the first two wouldn't get checked in between the double check), HireMercenaries, EnslavePopulation, Exterminate Population, and PreBattleWithdrawal. BecomesFactionLeader, CeasedFactionHeir, AcceptBribe, GovernorBuildingDestroyed, and a host of LeaderX are also possible and non-redundant, but probably too marginal to bother with.

Edit: CharacterSelected would probably work, Sinner, although probably only for the player's selection of his own characters.

-Simetrical

[therother]

CharacterTurnStart definitely works. CharacterSelected: hmm, has possibilities...

[player1]

ALERT!
Scarrface fix is not working well!

It seems that GeneralHPLostRatioinBattle is working as itended when doing autocalc battle (checking % of health lost).

Only in manual battle it checks % of health remaining.

So, the fix for Scarrface has fixed the trait for manual battle, but broke it for autocalc.


P.S.
As sideffect, there would be more brave and scarred AI generals.

[therother]

Okay, tested CharacterSelected. It works well; using the trigger below, I removed the DoubleCombat1 trait by clicking on the general.



;------------------------------------------
Trigger CharacterSelected Test
WhenToTest CharacterSelected

Condition CharacterIsLocal
and IsGeneral
and Trait DoubleCombat1 = 1

Affects AntiDoubleCombat1 1 Chance 100

[therother]

Okay, putting ideas together.

Do the steps in the first 2 code boxes in this post (https://forums.totalwar.org/vb/showpost.php?p=706542&postcount=170), just forget about the 2nd level.

At the end of the Character file, add this:


;------------------------------------------
Trigger Remove DoubleCombat1 if = 1
WhenToTest PostBattle

Condition IsGeneral
and Trait DoubleCombat1 = 1

Affects AntiDoubleCombat1 1 Chance 100


;------------------------------------------
Trigger Add 1 to DoubleCombat1
WhenToTest PostBattle

Condition IsGeneral
and Trait DoubleCombat1 = 0

Affects DoubleCombat1 1 Chance 100


;------------------------------------------
Trigger Remove DoubleCombat1 aEoT
WhenToTest CharacterTurnEnd

Condition IsGeneral
and Trait DoubleCombat1 = 1

Affects AntiDoubleCombat1 1 Chance 100


;------------------------------------------
Trigger CharacterSelected remove trait
WhenToTest CharacterSelected

Condition CharacterIsLocal
and IsGeneral
and Trait DoubleCombat1 = 1

Affects AntiDoubleCombat1 1 Chance 100

Then add:

and Trait DoubleCombat1 = 0 as a condition for every battlefield trait.

Notes/Comments/Problems:

This will stop the double traits for all battlemap battles (for AI and player), assuming that this type of battle is all that they have taken part in (i.e. no autocalc, or prebattle withdrawals).
This will allow as many autocalcs as the player likes - as soon as you select your general to attack anyone else, the DoubleCombat1 trait is removed.
There is still a problem for AI generals after a player-initiated autocalc, and multiple AI autocalcs involving the same AI general in one turn. For the 2nd, and all subsequence battles that turn, that AI general will receive no traits.
Perhaps more annoyingly, if an AI General retreats from the initial attack, he will be given the DoubleCombat1 trait. Whilst the player's is expunged by the character select trigger, the AI's remains, meaning he will not get any traits if the player follows up and attacks on the same turn (I do this often). If only PreBattle worked!
Similarly, it is possible that this could affect the player's general if he is attacked more than once during the AI's turns, and choses to withdraw or autocalc.
…


What we need, assuming PreBattle is not implemented, is a condition that is always automatically triggered in between battles (even during AI turns), and can remove the DoubleCombait1 trait for all generals, irrespective of faction. I would even settle for a player activated one...

At the moment, the Code tags don't seem to be working correctly. Hopefully they will be fixed soon. In the meantime, you can quote the post to get the proper formatting.

[Zrave]

What is that about Condition CharacterIsLocal? Can't we set CharacterSelected in a way that all generals you select lose the marker trait?

[therother]

What is that about Condition CharacterIsLocal? Can't we set CharacterSelected in a way that all generals you select lose the marker trait?I just nicked it from a CA use of the trigger (to trigger advice in export_descr_advice.txt). It is meant to check if the character selected is from the player's faction. Removing it doesn't seem to do anything, as you can’t 'select' characters of another faction, so I guess it's a bit redundant. Though I may be missing something.

[Zrave]

There is still a problem for AI generals after a player-initiated autocalc, and multiple AI autocalcs involving the same AI general in one turn. For the 2nd, and all subsequence battles that turn, that AI general will receive no traits.

Actually, only the even numbered autocalc battles will give no traits, so its not terrible, only bad :)



Perhaps more annoyingly, if an AI General retreats from the initial attack, he will be given the DoubleCombat1 trait. Whilst the player's is expunged by the character select trigger, the AI's remains, meaning he will not get any traits if the player follows up and attacks on the same turn (I do this often). If only PreBattle worked!

Yeah I had thought that it would not get applied on retreats, but upon further reflection, I guess it would apply. That being said, if the second battle is manual controlled instead of autocalc, everything will work as intended, even if you lose the marker trait by selecting yourself and the AI doesn't.



Similarly, it is possible that this could affect the player's general if he is attacked more than once during the AI's turns.!

As long as the battles are manually controlled, the fix will work. This is because regardless of whether the marker is active or not, either the first or the second pass will cause the triggers to go off.

[therother]

Hmm, perhaps my formulation is faulty. In the scheme I outline above, once a general enters a battle on the campaign map, or the battlemap, with DoubleCombat1 = 1, that general will receive no battlemap traits, as it will always be 1 throughout the file, and will end the battle as 1 also.

[Zrave]

Ah, sorry for not analyzing your code in detail, I recognized elements of my fix and assumed that it was such.

The difference is that my second trigger always goes off, and my first trigger gives 2 points.

What this means is that if you already have the marker, my second trigger returns you to a neutral state, allowing the triggers during the "bugged" pass to work. If you do not have a marker, then you will gain one and the "bugged" pass will not work.

[therother]

Ah, you are using a two-trigger system, like I tried last night. I don't know how I missed that.

To be honest, I'm still tending towards the manual "withdrawal" trigger, as that has no effect on the AI unless it, in one turn, it withdraws from battle x times (x being user definable, 2 in the case outlined above). Maybe it is unwieldy, bit it works like a charm.

[player1]

ALERT!
Scarrface fix is not working well!

It seems that GeneralHPLostRatioinBattle is working as itended when doing autocalc battle (checking % of health lost).

Only in manual battle it checks % of health remaining.

So, the fix for Scarrface has fixed the trait for manual battle, but broke it for autocalc.


P.S.
As sideffect, there would be more brave and scarred AI generals.

Have an idea about possibile compromise:


Trigger battle1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle > 0.3
and GeneralHPLostRatioinBattle < 0.7

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15


So that you get checked for trait in cases when general remains with 30-70% health, regardless is it autocalc or manual battle?

Not perfect, since it doesn't check those that are very badly injured (less then 30% heath).

[player1]

Is it somehow possibile, by useing some already bygged triggers like GeneralHPLostRatioinBattle or GeneralFoughtInCombat, to detect is combat, in fact, autocalc or manual?

[player1]

What are default general hit points anyway?

[Camp Freddie]

I've been told that Generals have +5 HP. So that's 7 HP, since the bodyguard unit has 2 already.


Is it somehow possibile, by useing some already bugged triggers like GeneralHPLostRatioinBattle or GeneralFoughtInCombat, to detect is combat, in fact, autocalc or manual?

Damn! I thought that would work for GeneralHPLostRatioinBattle but the best it can give is:

GeneralHPLostRatioinBattle "less than"0.95 is true when you autocalc (and didn't die) or when your battlemap general loses HP.

For battlemap: GeneralHPLostRatioinBattle > 0.05 is true when you battlemap or when your autocalc general loses any HP.

I can't think of a way to further distinguish between battlemap and autocalc.

[Jambo]

player 1, are you the guy from the civ forums that made the patch suggestion mod? Anyway, I think the General by default has 6 hitpoints. Edit: actually campfreddie might be right.

As well as the battlescarred, your fixes will also have to be applied to berserker trigger and the shieldbearer and heroic saviour ancillaries.

[player1]

player 1, are you the guy from the civ forums that made the patch suggestion mod?

yes

[therother]

Okay, using the rules (in this order) that I think Zrave is suggesting above:

If (bug, Fix) = (1,2), then (bug, Fix) reset to (0,0)
Parse battlemap triggers - no trait if Bug = 1
If Bug = 1 then Fix = 2
If Bug = 0, then Bug = 1)

And (1,2) is the maximum level for (Bug, Fix)...

If so, then these are the outcomes I expect from a few senarios:

AI battles or player likes A/C
2^Battletype|Start (Bug,Fix)|Resetter|End (Bug,Fix)|Triggered
4^Withdraw/AC|=(0,0)|=(0,0)|=(1,0)|yes
4^Withdraw/AC|=(1,0)|=(1,0)|=(1,2)|no -- error
4^Withdraw/AC|=(2,1)|=(0,0)|=(1,0)|yes

Player fights all
2^Battletype|Start (Bug,Fix)|Resetter|End (Bug,Fix)|Triggered
4^Battlemap read 1|=(0,0)|=(0,0)|=(1,0)|yes
4^Battlemap read 2|=(1,0)|=(1,0)|=(1,2)|no
4^Battlemap read 1|=(1,2)|=(0,0)|=(1,0)|yes
4^Battlemap read 2|=(1,0)|=(1,0)|=(1,2)|no

Player fights two battles, 2nd AI retreats, player follows up
2^Battletype|Start (Bug,Fix)|Resetter|End (Bug,Fix)|Triggered
4^Battlemap read 1|=(0,0)|=(0,0)|=(1,0)|yes
4^Battlemap read 2|=(1,0)|=(1,0)|=(1,2)|no
4^Withdraw/AC|=(1,2)|=(0,0)|=(1,0)|yes
4^Battlemap read 1|=(1,0)|=(1,0)|=(1,2)|no
4^Battlemap read 2|=(1,2)|=(0,0)|=(1,0)|yes

Player fights two battles, 1st AI retreats, player follows up, fights 2nd A/C
2^Battletype|Start (Bug,Fix)|Resetter|End (Bug,Fix)|Triggered
4^Withdraw/AC|=(0,0)|=(0,0)|=(1,0)|yes
4^Battlemap read 1|=(1,0)|=(1,0)|=(1,2)|no
4^Battlemap read 2|=(1,2)|=(0,0)|=(1,0)|yes
4^Withdraw/AC|=(1,0)|=(1,0)|=(1,2)|no -- error


If this is accurate, then I'm much happier. Although it is still penalising the AI, as the AI will normally fight far more A/Cs than the player. My preference, given the current situation with the AI, would be to penalise the player in situations such as this.

[player1]

Consdering that scarred is buggy for autocalc, maybe something like this could be a quick-patch

;------------------------------------------
Trigger battle1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.7
and GeneralHPLostRatioinBattle > 0

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

;------------------------------------------


Added GeneralHPLostRatioinBattle > 0 prevents getting Scarred in autocalc battles in which general didn't got injured at all. Same condition for manual cointrolled battles is not problem considering that general would be dead, for =0 anyway.

[player1]

Actually, when I think about it GeneralHPLostRatioinBattle > 0.15 is probably the best option.

For autocalc that means generals which lost more then 1hp.

7hp*0.15=1.05
9hp*0.15=1.35
11hp*0.15=1.65
13hp*0.15=1.95

That should leave enough room for autocalc to award scarred not to often.

For manual battles that just means that general which have 1hp left won't get checked for scarred trait (no big deal).

[Zrave]

I ran a test of the scarred bug player1 has just described and he's right on the money. So much for the theory that the double trigger bug was due to a "battle" pass and a "strat" pass, the autocalc engine uses its own ruleset.

My test was as such:

trait1 -> GeneralHPLostRatioinBattle > 0

trait2 -> GeneralHPLostRatioinBattle < 1

A tactical battle without general engaging gave me two points of trait1 and no trait2. the same battle with autocalc gave me no trait1 and one point of trait2. This means there was no engagement, because for only trait2 to be awarded the ratio had to be exactly 0, which by the tactical ruleset would mean dead.

As for fixing it, how about this:

;------------------------------------------
Trigger scarred1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.3
and GeneralNumKillsInBattle > 6

Affects Battlescarred 1 Chance 100

;------------------------------------------
Trigger scarred2
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle > 0.7
and GeneralNumKillsInBattle > 6

Affects Battlescarred 1 Chance 100

[player1]

;------------------------------------------
Trigger scarred1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.3
and GeneralNumKillsInBattle > 6

Affects Battlescarred 1 Chance 100

;------------------------------------------
Trigger scarred2
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle > 0.7
and GeneralNumKillsInBattle > 6

Affects Battlescarred 1 Chance 100

100% chance?
No thanks

Personnaly, I think that my variant
0.15 < GeneralHPLostRatioinBattle < 0.7
is just closer to the rules.
Barely changes things for manual, while making autocalc don't give weird results.

[Zrave]

the 100 chance is a typo left over from my testing triggers, again a victim of no edit button and not willing to double post. Of course it would be reduced to 30% as usual.

The triggers work like this:

In battle mode, trigger 1 will go off like we would want it to in a normal scenario. Trigger 2 will likely never go off unless the general can get X kills, in the proposed case 6, without losing at least 30% of his health - I viewed this scenario as unlikely, but the numbers may need adjustment.

In autocalc mode, the reverse is true. Trigger 2 will go off like we would want it to, and trigger 1 will likely never go off.

Another important thing is that the two triggers will never go off simultaneously, so you can't "double" up.

My proposition has two faults:

1) The unlikely case your scenario can rack up a high number of kills without losing much HP, he'll get battlescarred, and if we can adjust that number to satisfaction I'm willing to live with the ocasional fluke.

2) If your general gets severely hurt but never reaches the desired number of kills, he won't get scarred even though we would want him to.

That being so, I think that it is a viable alternative to your proposition, to be compared and contrasted for a consensus solution.

[player1]

Well, the problem is see, is that when playing manual, general can get a lots of kills (especialy if flanking or routing enemies), without almost getting any loses (and I'm talking things like 50+ kills).

Then, there would be a good chance to get battlescarred with second trigger, and that's bad.

On the other hand, such thing don't happen often in autocalc, so you can't really increase generalnumkills and make it ok.


Why I like my modif, is that it is almost 100% same as original should work, when doing manual battle (with exeption if 1hp is left because of >0.15).

Of course, it's a bit different, when making autocalc, but when you look at it, you don't really know what happend in autocalc battle.

[Zrave]

Yes, you bring a valid point with respect to routing enemies, which I'll consider in more detail. I think I have a better fix in the works.

There is another reason why I prefer my value - you actually have to be heavily wounded for it to work. I don't think we can say at this point what CA intended for the ratio value to be, because of the slew of bugs in its implementation. These are:

1) originally had a 30 instead of 0.3

2) with standard files their settings always give trait in manual

3) romans getting battlescarred twice shows they didn't analyse this area in much detail

4) autocalc/manual interpret the value differently

All this being said, I think what really matters is common sense. If someone is supposed to be tough to kill, then I would suspect that should be modelled by near-death values.

[Zrave]

I tested my new idea for the fix and it seems to work properly. I still need to figure out the best values and see if it needs any more conditions.

;------------------------------------------
Trigger scarred1
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle < 0.3
and PercentageBodyguardKilled > 50

Affects Battlescarred 1 Chance 30

;------------------------------------------
Trigger scarred2
WhenToTest PostBattle

Condition GeneralHPLostRatioinBattle > 0.7
and PercentageBodyguardKilled > 50

Affects Battlescarred 1 Chance 30

[player1]

Well, as I said, now it won'n fire for autocalc as often as it should, since getting 50 kills is a lot for that.

Also, it won't fire in case of manual battle with careless general (which killed a little and almost died in process).


While I find idea interesing, number of kills is too undependable method to aprox. how much is general injured.

[therother]

If GeneralHPLostRatioinBattle is bugged, perhaps we should just do without it?

So how about something like this:



;------------------------------------------
Trigger scarred1
- WhenToTest PostBattle
-
- Condition IsGeneral
- and PercentageBodyguardKilled > 50
- and GeneralNumKillsInBattle > 6
-
- Affects BattleScarred 1 Chance 30 This would mean that general's unit has been in tough combat, as he's lost over half his unit, and has engaged the enemy personally, as he's killed more than 6 men. The thresholds, of course, could be tweaked.

[player1]

Personnally, I'm not fan of complete trigger rewrite when doing bugfixing. I would rather leave it to some good MOD.

For that reason I proposed soultuion that keeps problem almost 100% fixed for most often uses (manual battle), while not giving too big deviation in autocalc.


Of course, if anyone ever finds solution for double combat traits, it would easily solve scarred problems too.

[Zrave]

player1, my second fix uses a different condition - it represents what percentage of the general's unit has died. I think it is a decent approximation of how much damage the general himself has sustained, but is not bugged like HPLostRatio is.

I understand your concern for trying to keep changes small, and I ordinarily would subscribe to that. However, since I am working on this for the CVP (a mod) I want to get the best approximation of what I interpret the concept to be, hopefully maximizing fun/gameplay in the process. For the purposes of keeping changes small, I think yours is the best and perhaps only solution.

I liked therother's suggestion of doing away with HPLostRatio entirely, since its hard to implement something so fickle. I think the combination of both conditions will rarely produce an odd result, but I wonder if number of kills is even necessary?

Does the general have better defensive stats than a regular man in his unit? If not, it should be possible to calculate at what percentage he should have been severely wounded.

[Pode]

I believe generals have the same stats but more hit points, although I'd be hard pressed to support that claim.

[player1]

As far as I understand generals have +5hp compared to the bodyguard unit.

So 7hp default, 15hp if scarface, 1hp if very, very ill.

[player1]

If GeneralHPLostRatioinBattle is bugged, perhaps we should just do without it?

So how about something like this:



;------------------------------------------
Trigger scarred1
- WhenToTest PostBattle
-
- Condition IsGeneral
- and PercentageBodyguardKilled > 50
- and GeneralNumKillsInBattle > 6
-
- Affects BattleScarred 1 Chance 30 This would mean that general's unit has been in tough combat, as he's lost over half his unit, and has engaged the enemy personally, as he's killed more than 6 men. The thresholds, of course, could be tweaked.

Interesting...
I never knew that there is PercentageBodyguardKilled condition in the game.

[player1]

Now, when I think about it, PercentageBodyguardKilled could be a very useful trigger for patial solution.

Would something like this work:

;------------------------------------------
Trigger battle1
WhenToTest PostBattle

Condition (GeneralHPLostRatioinBattle < 0.7
or GeneralHPLostRatioinBattle > 0.3)
and PercentageBodyguardKilled > 0.3
and not CultureType roman

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

;------------------------------------------

[player1]

PercentageBodyguardKilled is used as some sort of checker to distinguish false generalhpcount form the real one.

[player1]

Actually, let's just keep it simple:

Replace GeneralHPLostRatioinBattle with PercentageBodyguardKilled
And get:


;------------------------------------------
Trigger battle1
WhenToTest PostBattle

Condition PercentageBodyguardKilled > 0.3

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

;------------------------------------------

Simple and effective aprox.
And is not buggy.

Same to be done to shieldbreared and heroic saviour.

[Zrave]

player1, that is exactly what I suggested over my last few posts, even down to eventually settling for only %BodyguardKilled :P

The input it takes is an actual percentage though (instead of a ratio), and I settled for 50 since the troops have a less hitpoints than the general.

[player1]

Well, is really PercentageBodyguardKilled counting how many bodyguards die?

I ask this beacuse I tried using it instead of Generalhp for heroic savior (triggers when more then 80% bodyguard is killed).

But, I got HS when fighting some rebels with general unit only, which only had light casualties (manual battle).

[player1]

Nevermind, I just realized thta it needs to be 80% and not 0.8

[Zrave]

CVP 1.2 was just released with fixes for all the bugs discussed here.

[player1]

Ok, I made complied list of fixes for character traits and retinue members.

1) Buggy GeneralHPLostRatioinBattle condition replaced with PercentageBodyguardKilled, as best aproximation. This fixes Scarface issue and fixes to retinue members that used same condition
2) Double checked Scarface trait for Romans fixed (battle1 trigger should be limited to non Romans)
3) Coward trait fixed, so it actually happens when general avoids fighting, leaving dirty job to his troops (chnaged "= 0" to "> 0" in PercentageEnemyKilled condition, buggy GeneralFoughtInCombat condition replaced with GeneralNumKillsInBattle = 0)
4) Patched the hole in IndecisiveAttacker line of triggers, since they never got triggered when withdrawing with odds higher then 1.5, but lower then 3 in your favor (second trigger battle odds changed from "> 3 to "> 1.5")
5) Double awarded traits in manual battle bug fixed (thanks to Zrave for idea!)
This is only partial fix, since in cases when same general fights two autocalced battles in same turn, it won't get any traits in second battle.


It can be found in these two threads:
http://www.twcenter.net/forums/index.php?act=Attach&type=post&id=1812000192
http://www.twcenter.net/forums/index.php?act=Attach&type=post&id=1812000194

[sunsmountain]

Apart from all the mods and 'fixes' that usually give you balance preferences of their makers as well, this is the first post that actually helps people understand what traits went wrong and how.

CA needs a spelling checker! Small little mistakes have persisted since version 1.0, and the bug-fixer by Player1, Borsook and Camp Freddie fixes a lot of these typos.

With credit to your name i have added Farmer and Trader to their list, gregab25. Your suggested fix of Scarred/Hero/Brave doesn't work. GeneralHPLostRatioinBattle is beyond repair. Don't use it.

Cheers Player1.
~:cheers: