Research: Fixing the trait bugs

[therother]

Please post possible fixes for the bugs in the triggers for various traits. For background info on some bugs already identified, please see these threads:

Traits that are bugged in 1.2 with fixes. Part 1: Scarred, Farmer, Trader (https://forums.totalwar.org/vb/showthread.php?t=43903)
Would 1.2 be better with traits removed altogether? (https://forums.totalwar.org/vb/showthread.php?t=44006)
HA, Scarface fixes for download (http://www.twcenter.net/forums/index.php?showtopic=21549)
Double Combat Traits? (http://www.twcenter.net/forums/index.php?showtopic=21798)
Bear in mind that this is a research thread - please post only fixes that you have tested yourself, or comments directly related to the feasibility of the suggested fixes. Please provide as much information as possible on: the proposed bug you are fixing, how you believe the trigger should work, what you have done to fix it, what parts of the file require editing, and so on. Also note that this is for bugs only, i.e. traits that do not work as CA intended, rather than traits you think could do with improving.

Anything not adhering to these criteria will be removed from this thread.

Eventually, the intention is to come to a consensus for solutions to the bugs, and to release a patch to implement them.

[Kraxis]

I can only urge people to look through the export_descr_character_traits file. There are a lot of small oddities, such as the progression of traits give the wrong bonus. I found one where the bonus dropped in the middle of a 5 step bonus only to jump up to the correct value in the next. Obviously nr 3 was wrong.
Sadly I fixed this on the run and can't remember which this was, but I think Drillmaster is wrong (should be -1 to morale rather than +1). But beware, not all traits progress liniarly, some have a penalty for going too far. So open the text file associated with it (descriptions of the traits).

I have found a small bug with risky battle
This is how it should look.

Trigger V0110_Standard_Risky_Battle_Attacker_Clear_Victory_VnV_Trigger
WhenToTest PostBattle

Condition WasAttacker
and IsGeneral
and WonBattle
and BattleSuccess = clear
and I_ConflictType Normal
and BattleOdds < 0.5
and BattleOdds > 0.16

Affects GoodRiskyAttacker 1 Chance 100

But it looks like this


Trigger V0110_Standard_Risky_Battle_Attacker_Clear_Victory_VnV_Trigger
WhenToTest PostBattle

Condition WasAttacker
and IsGeneral
and WonBattle
and BattleSuccess = crushing
and I_ConflictType Normal
and BattleOdds < 0.5
and BattleOdds > 0.16

Affects GoodRiskyAttacker 1 Chance 100

That is the case for all four Clear_Victory risky battles. That means if you win a clear victory you won'y get any bonus, while if you win a crushing victory you gain in the unmodded game 3 points towards GoodCommander.

Thus change all the crushing to clear, but remember to only do it to the clear battle, not the crushing or else it will only be reversed.

[Pode]

I *believe* the consensus from the other thread was that the vanilla governing10 and governing11 triggers (the ones that control good farmer and good trader tests when a building is finished) were working as designed (WAD), but the thresholds for these traits needed adjustments. Based on the amount of traits generated over 50 years for a governor remaining in place building a town from scratch, I recommended thresholds of 3, 18, and 36 for the levels of good farmer.

One point I'm still unclear on from that discussion, is whether the < = operator is functioning properly. We know this board doesn't like it, but does it work right in game?

[Bob the Insane]

I *believe* the consensus from the other thread was that the vanilla governing10 and governing11 triggers (the ones that control good farmer and good trader tests when a building is finished) were working as designed (WAD), but the thresholds for these traits needed adjustments. Based on the amount of traits generated over 50 years for a governor remaining in place building a town from scratch, I recommended thresholds of 3, 18, and 36 for the levels of good farmer.

Well I guess that was what you posted... ~D

Actually I do not mind that the GoodFarmer traits are really for those who possess farming temples (possibly why the default thresholds are so high).

I think the real problem here are the triggers which cause BadFarmer and BadTrader points to be generated. In the default files you can get BadFarmer and/or BadTrader points simple by building anything that is not a farm or trade building, even if you have already maxed out on farm and/or trade buildings. I believe resolving this would resolve the problems with the GoodFarmer and GoodTrader traits...

[Bob the Insane]

For the Scarface thing... Does this mean we are using:

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

Condition GeneralHPLostRatioinBattle < 0.7
and not CultureType roman

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

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

Condition GeneralHPLostRatioinBattle < 0.7
and Trait Berserker >= 1

Affects Berserker 1 Chance 30

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

Condition GeneralHPLostRatioinBattle < 0.7
and CultureType roman

Affects BattleScarred 1 Chance 30
Affects RomanHero 1 Chance 15

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

instead of the default:

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

Condition GeneralHPLostRatioinBattle > 0.3

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

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

Condition GeneralHPLostRatioinBattle > 0.3
and Trait Berserker >= 1

Affects Berserker 1 Chance 30

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

Condition GeneralHPLostRatioinBattle > 0.3
and CultureType roman

Affects BattleScarred 1 Chance 30
Affects RomanHero 1 Chance 15

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

[therother]

For the Scarface thing... Does this mean we are using: [...]If it is widely regarded as the best solution, I'll put this in as our first settled fix. Do you know who devised the solution?

[Pode]

delete the battlescarred effect from the battle1r trigger. Otherwise a roman general tests for scarring once under battle1 and again under battle1r. There's enough double traits from playing out battles, we don't need more. :)

And you're right, Bob, that was only what I posted. I thought it was the general consensus, and by claiming it as such I thought I could draw out the last of the undecideds :)

[Bob the Insane]

Do you know who devised the solution?

Yikes, who originally thought this one up?? I guess you would have to pour through the forums here and at TWCenter to see who posted it first... Or you could say the resolution developed by the consensus in the RTW community...



delete the battlescarred effect from the battle1r trigger. Otherwise a roman general tests for scarring once under battle1 and again under battle1r. There's enough double traits from playing out battles, we don't need more. :)

Much neater that way...


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

Condition GeneralHPLostRatioinBattle < 0.7

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

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

Condition GeneralHPLostRatioinBattle < 0.7
and Trait Berserker >= 1

Affects Berserker 1 Chance 30

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

Condition GeneralHPLostRatioinBattle < 0.7
and CultureType roman

Affects RomanHero 1 Chance 15

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

[player1]

delete the battlescarred effect from the battle1r trigger. Otherwise a roman general tests for scarring once under battle1 and again under battle1r. There's enough double traits from playing out battles, we don't need more. :)

That's really not needed.
There is already "and not CultureType roman" around first battlescarred check.

Why edit files more then necessary?

[Bob the Insane]

That's really not needed.
There is already "and not CultureType roman" around first battlescarred check.

Why edit files more then necessary?

By default the "and not CultureType roman" is not there, I added it above to try and fix the issue (not orginially my idea I must point out)... Pode was just pointing out that removing the line in Trigger battle1R was more elegant than adding extra lines of code to achieve the same effect...

[Sinner]

I thought it might be helpful to include a few notes on how the triggers work given some of the apparent confusion.

I'll use the probably now familiar GoodFarmer trigger as my example...

Trigger governing5
WhenToTest GovernorBuildingCompleted

Condition SettlementBuildingFinished >= farms

Affects GoodFarmer 1 Chance 100

First we have the trigger's identity, governing5, which is nothing more than a convenient label to make it easier for people to locate a specific trigger. I could rename this trigger as get_badfarmer and it would have no effect on its functionality, equally I could change its name to governing1, duplicating that of another trigger, and it will have no effect - both triggers will still function correctly.

Next is the event when the trigger is tested, GovernorBuildingCompleted. Many events can be determined from the examples already available in the traits file, while others can be found in the Events, Conditions, & Commands thread (https://forums.totalwar.org/vb/showthread.php?t=43121). It's important to note that only CA can edit existing events or create new events, so we can only work with what is available, no amount of modding will get around this.

In the case of the GovernorBuildingCompleted event, it occurs when a building is completed in a settlement that has a governor.

Next we have the condition, SettlementBuildingFinished. Despite how many of them appear conditions are not mathematical equations. Conditions are functions that return a true or false answer given one or more parameters. Some of these parameters are variables that are automatically passed to the function, and are otherwise hidden, while others have to be specifically declared in the trigger and are thus visible and amendable.

In the case of this trigger, the condition function SettlementBuildingFinished is intended to test a building that has just been completed. It is passed a variable parameter that contains the identify of the completed building, plus two declared parameters - >= and farms - that the function tests that building against. This trigger will return true if the completed building is Land Clearance or any other higher-level farm.

All conditions for a trigger in effect have to return an answer of true for the trigger to cause any results. I say 'in effect' because we have the possibility of 'not' switches, such as and not SettlementBuildingFinished >= farms, which would mean you'd get GoodFarmer for completing anything other than a farm. The 'not' switch simply reverses the true/false answer from the function, so you'd need the function to return false for that condition if the trigger is to cause any results. Confused? You will be! ~:)

A trigger can have multiple conditions... for example if we only want Julii characters to gain GoodFarmer when they complete a farm, we'd add and FactionType romans_julii under the Condition SettlementBuildingFinished >= farms line. In the case of multiple conditions, all conditions must return true, after any 'not' switches if appropriate, for the trigger to cause any results.

Finally we have the results caused, Affects GoodFarmer 1 Chance 100 if all conditions are met. In this case the governor's GoodFarmer trait has a 100% chance of gaining 1 point. Obviously if the chance is less than 100% then it's possible that random chance will result in no points gained even if all the conditions have been met. If the points gained are enough to equal or exceed the threshold of a trait level then the character will gain the appropriate effects.

As a note up to 10 traits can be effected by any one trigger, but the trigger can be duplicated and different traits effected if more than 10 are required for the same trigger event and conditions.

[player1]

By the way, has anyone investigated what Camp Freddie has done in regards to Coward trait.

I refer to changes done in his RTWv12_bugfixes patch.

In line:

Condition not GeneralFoughtInCombat
and PercentageEnemyKilled = 0

Affects Coward 1 Chance 10

Add not before "PercentageEnemyKilled"

[player1]

Also, he made some changes to shieldbearer and heroic saviour ancillaries, since they also use GeneralHPLostRatioinBattle (and were maybe bugged).

[Bob the Insane]

Also, he made some changes to shieldbearer and heroic saviour ancillaries, since they also use GeneralHPLostRatioinBattle (and were maybe bugged).

These are definately still broke as they are still expressing a percentage...

i.e. GeneralHPLostRatioinBattle >= 80

[player1]

These are definately still broke as they are still expressing a percentage...

i.e. GeneralHPLostRatioinBattle >= 80

I guess that one should be:
GeneralHPLostRatioinBattle < = 0.2
(or seriously wounded general)

[player1]

Ok, I just realised that fix for Coward trait, done in Camp Freddie bugfix patch is not working.

It appears that GeneralFoughtInCombat condition is buggy.

So I tried instead of:



Trigger battle4
WhenToTest PostBattle

Condition not GeneralFoughtInCombat
and PercentageEnemyKilled = 0

Affects Coward 1 Chance 10


this:



Trigger battle4
WhenToTest PostBattle

Condition GeneralNumKillsInBattle = 0
and PercentageEnemyKilled > 0

Affects Coward 1 Chance 10


"GeneralNumKillsInBattle = 0" is the closest thing to "not GeneralFoughtInCombat" that works.

Also there is a > instead of = for "PercentageEnemyKilled", which is close to original fix done by Camp Freddie (to prevent getting the trait when enemy runs away, giving you no chance to fight it).


I tested this with "Affects Coward 8 Chance 100", when general properly got highest coward trait anytime when not fighting battle.

Only in case when enemy lost zero units trigger didn't started (tested by retreating at start of the battle).

[Kraxis]

Have I understood it correctly that Coward with the old fix is impossible?

[player1]

Since GeneralFoughtInCombat will always be true, you won't get Coward with such trigger.

P.S.
Althouhg there is another trigger about general routing that can give Coward.


And of course, my fixed version of this trigger.

[player1]

If anybody is interested I made fixed version of coward and scarred trait at Scarface thread at twcenter:

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

[therother]

Have I understood it correctly that Coward with the old fix is impossible?As I understand it, it will be impossible with Camp Freddie's fix if you fight all battles on the battlemap, as the condition GeneralFoughtInCombat is always true. However, it should be possible to get it from an autocalc battle.


If anybody is interested I made fixed version of coward and scarred trait at Scarface thread at twcenterAny chance you could compile the changes made into one post?

[player1]

Ok, I'll try.
It's pretty much slightly modified version of Camp Freddie fixes to export_descr_character_traits.txt

these are modified battle1 triggers:

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

Condition GeneralHPLostRatioinBattle < 0.7

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15

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

Condition GeneralHPLostRatioinBattle < 0.7
and Trait Berserker >= 1

Affects Berserker 1 Chance 30

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

Condition GeneralHPLostRatioinBattle < 0.7
and CultureType roman

; Affects BattleScarred 1 Chance 30
Affects RomanHero 1 Chance 15

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

and modified battle4 trigger:

;------------------------------------------
Trigger battle4
WhenToTest PostBattle

Condition GeneralNumKillsInBattle = 0
and PercentageEnemyKilled > 0

Affects Coward 1 Chance 10

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

[player1]

quote the message if you wanna see correct formating

[Bob the Insane]

For the coward thing I am using:


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

Removed due to being stupid... ~D

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

If I follow this correct this is triggered if the general was on the battlefield but was withdrawn (GeneralFoughtInCombat returns false) and none of the enemy was killed...

From what I can see you should only get the coward trait when you go to the battlemap, if you withdraw from the strategic map a lot you should get IndecisiveAttacker instead. Is this what people see?

[player1]

You need to realise that after some testing I'm confident to say that GeneralFoughtInCombat is always true in battle.

But, if you do autocalc, it would be only true if general didn't actually fighted.
So GeneralFoughtInCombat is bugged. Use some other trigger instead.

Also, what you use (with added not), will trigger coward when doing autocalc and some enemies get killed, but not by general.

Better replace it with GeneralNumKillsInBattle = 0, so it works for both autocalc and manual battle.

[Bob the Insane]

player1 - I understand where you are coming from and I understand the problems you have pointed out... (I have removed the code I suuggested to avoid confusng people)...

But, one thing I noted with the example you provide, it will not trigger coward for simply withdrawing from the battlefield immediately (on the battlemap). Where GeneralNumKillsInBattle = 0 and PercentageEnemyKilled = 0 (I presume)... Was this intentional?

[player1]

The problem is that if you leave that, then you could get coward trait when enemy withraws right from start (and not just you).

[Pode]

Try adding a not WonBattle condition

[Camp Freddie]

But, one thing I noted with the example you provide, it will not trigger coward for simply withdrawing from the battlefield immediately (on the battlemap). Where GeneralNumKillsInBattle = 0 and PercentageEnemyKilled = 0 (I presume)... Was this intentional?

Player1's fixes to my attempt at solving the coward bug seem to be the best option. Generalfoughtincombat seems to be totally buggered. This could be affecting the Heroic Saviour ancilliary too, which should be changed to GeneralNumKillsInBattle > 0.

To answer your question, it will not trigger if you withdraw, BUT that isn't what the coward trait is about.
There's another trait (indecisive attacker) and 3 triggers which cover withdrawing before combat (100% chance when you are the attacker, 50% chance when odds are 0.8-1.5 and a 50% chance for a 2-step increase when odds >3). It has huge thresholds though (8, 16, 32) and has goodcommander and goodattacker as antitraits, so it's hardly ever seen.
Strangely, if odds are 1.5-3 and you aren't attacking, it's safe to withdraw - another trait glitch!
Therefore, in Trigger V0200, the > 3 should be reduced to > 1.5. If you want coward traits to be added, then put "coward 1 chance 50" in Trigger V0200, which would now fire when odds >1.5 and you withdraw. You could put "coward 1 chance 10" in Trigger V0190 as well, if you want to really persecute generals who avoid battle when they have a good chance of winning!
The only problem is that I don't know how often the AI general withdraws. If he withdraws a lot (he did in MTW) then he could be heavily penalised by coward traits. That might even be the reason why "indecisive attacker" has such high thresholds.

[player1]

Well, it's interesting to point that when using autocalc, if having enough troops, generals rarely fight, which already increases chances of gaining this coward trait for AI.

So no need to add more futher.
Fixed Coward trigger does even more then enough.

[player1]

By the way, Heroic Savior works fine, since one of the conditions is already generalnumberofkills.

[player1]

ALERT!
Scarrface fix is not working well!

It seems that GeneralHPLostRatioinBattle is working as intended 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.

[Simetrical]

Oh, God. Another difference between autocalc and battle map. This one will be even harder to sort out, since at least doubling the check gives us something we can work with. At least here we might be able to get away with not using the condition, though, I suppose.

-Simetrical

[Camp Freddie]

Uuurgh...

Oh well, I'm kinda happy that this will make it harder to kill the enemy generals.
Also, since the autocalc doesn't give double traits, the AI shouldn't get the full scarface until it's fought an average of 14 battles (4 threshold / 0.3 chance).
And if you've modded the game with double comabt trait thresholds, it would be an average of 27 battles before the AI gets scarfaced.

How did you test it? I'm guessing you used the "less than" 0.7 fix, raised the chance to 100 (and deleted the roman-only scarred chance), then autocalced a few battles, and you got "been in the wars" after every battle - right?

[player1]

How did you test it? I'm guessing you used the "less than" 0.7 fix, raised the chance to 100 (and deleted the roman-only scarred chance), then autocalced a few battles, and you got "been in the wars" after every battle - right?

Something like that.
Later I tried =1 and =0, just to be sure .

[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.

[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).

[player1]

Well, considering that generalhplost condition is buggy, maybe the best way to fix battle1 trigger would be using PercentageBodyguardKilled counter. It would aprox. give similar conditions, and is not buggy:



Trigger battle1
WhenToTest PostBattle

Condition PercentageBodyguardKilled > 30

Affects BattleScarred 1 Chance 30
Affects Brave 1 Chance 15


Note that PercentageBodyguardKilled uses % instead of probablities.

[Camp Freddie]

If that trigger is non-buggy then it seems like the best option to me.
With all the problems in traits, I reckon it's best to keep the triggers as simple as possible.

Regarding the bravery and romanhero traits, it even makes more sense to use bodyguard death rather than general wounding. You gerneral is valiantly fighting on, while men around him are dying!

It'll works well for heroic saviour and shieldbearer too.

[Red Harvest]

I've been watching this (spectating.) Have any of the major participants come to a conclusion? Mainly I was hoping for something that won't unnecessarily handicap the AI, by granting the human so many stars so easily. Other than wiping out most of the combat traits altogether...I'm not really hearing a solution.

[player1]

True, only solution for Scarred & Co. traits was made, while doubling is still a big problem.

There is just no trigger which would make difference between autocalc and manual battle, so there is no way to compensate for a bug.

[Jambo]

zrave's solution is possibly the best so far. It effectively removes the doubling aspect, with the only drawback of it being that a general performing more than 1 autocalc in any given turn will receive no battle traits on each even numbered battle (i.e. nos. 2, 4, 6, etc).

So in effect it's a minor hurt on the AI, but from what I've seen the AI doesn't tend to perform >1 autocalc per turn with a general that often.

[player1]

It's just bad that thread is really chaotic for reading.

It would be nice if someone could repost some of the "band-aid" solutions 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

[player1]

Anybody noticed that admirals can gain Haruspex and Soothsayer as their retinue members (triggers when defeated in battle)?

Do they get any benefit from this (bonus to morale)?

If not, then adding simple IsGeneral condition in their triggers would fix this weird behavior.

[Jambo]

For ships, morale is the major factor that decides how long the fleet stays in combat before retreating. If ships have a high morale then they will stay and fight longer thus either suffering or inflicting more casualties as a result.

To fix the lack of lethality of the naval battles in 1.1, CA increased the morale values of all ships in 1.2.

[Kraxis]

For ships, morale is the major factor that decides how long the fleet stays in combat before retreating. If ships have a high morale then they will stay and fight longer thus either suffering or inflicting more casualties as a result.

To fix the lack of lethality of the naval battles in 1.1, CA increased the morale values of all ships in 1.2.
Ahh... I too wondered about that Haruspex guy. Makes sense now, but now I wonder why they only seem to get him when defeated, for I have only gotten him like that, and player1 indicates the same.

[player1]

Well, his trigger says that you can only get him if defeated in battle (5% chance).

Soothsayer is pretty similar, +2moral, also only after lost battle (2%).

[Kraxis]

That is the point. Usually we get ancilliaries when we win, but for some reason admirals get their better ancilliaries when they lose. I would like to know why that is, for I can't find any acceptable reasons.

[player1]

Let's see other winning ancilliaries:
1) turncoats (no point in naval battle when you sink everything)
2) famous warrior (it's a warrior, not sailor)
3) floozy (negative security effect have no point for admirals)
4) galloper (no point for sea battle)
5) heroic saviour (bodyguard related, no point)
6) military tribune (no tribunues in navy)
7) runner (no point for navy)
8) scout (neither)
9) shiledbearer (bodyguard related)
10) swordbeared (bodyguard related)
11) veteran centurion (it's a centurion)
12) veteran warrior (not a sailor)

Anyway, none of them has any point to appear in navies.

[therother]

So in effect it's a minor hurt on the AI, but from what I've seen the AI doesn't tend to perform >1 autocalc per turn with a general that often.The biggest problem isn't two autocalcs per turn, as that is that is not that common. The problem is a retreat, then an autocalc. So if a superior force attacks an inferior one, the latter commonly retreats. That counts as a battle, and the triggers are read. The AI follows up the retreat (as it now does) for the 2nd battle that turn, and neither general will receive any traits for that battle. I think this situation is far more common, and so this solution still adversely affects the AI. I still looking into something that may provide a complete solution, but it's still fiddly.

[player1]

My testing showed, that prebattle withdrawals don't give bugged trait to generals, and thus don't affect next autocalc.

That's probably since postbattle trigger isn't triggered with prebattle withdrawals, only prebattlewithdrawal trigger.

So it affects less AI then you think.


EDIT:
Of course you still have bug if AI defeats the army and then tires to mop up everything that retreated. But, anyway such battles are rarelly challenging, so AI really won't miss too much from the traits.

EDIT2:
Testing with done with files I already put to download, but with bugged and fixed traits not being hidden (in that case you need to add some lines in export_VnVs.txt so game won't crash). And then lots of testing with autocalcs.

EDIT3:
I love edit function. If we only had it in Colosseum.

[therother]

Ah, I see where I went wrong - they changed a lot more in the file than I thought. Assuming you are right about prebattlewithdrawals (can't test as I'm not at my RTW computer), that would explain why the traits didn't show up as I was expecting during my testing.

On the edit function - you should be able to edit anywhere on the board, including the Colosseum, now that you are a Member.

[player1]

BUG-FIXER, an unofficial patch for Rome: Total War released:
https://forums.totalwar.org/vb/showthread.php?p=716695

[player1]

Ok, by looking some old indexed threads, I just realised that Good/Bad Conspirator trait is a bit buggy.

Newly created spies sometimes get it. Good.
After some missions spies could get it. Good.

But, it seems that after sabotage missions assassins should get it too.

Look these lines:


;------------------------------------------
Trigger agents13
WhenToTest SabotageMission

Condition not MissionSucceeded

Affects BadConspirator 1 Chance 100

;------------------------------------------
Trigger agents14
WhenToTest SabotageMission

Condition MissionSucceeded

Affects GoodConspirator 1 Chance 100

;------------------------------------------
Trigger agents15
WhenToTest SabotageMission

Condition MissionSucceeded

Affects GoodConspirator 2 Chance 50

;------------------------------------------
Trigger agents16
WhenToTest SabotageMission

Condition MissionSucceeded

Affects GoodConspirator 3 Chance 25

And there is a bug, since Conspirator trait is reserved for spies only, making it impossible to gain by sabotage.


So:


;------------------------------------------
Trait GoodConspirator
Characters spy
AntiTraits BadConspirator

should be changed to:


;------------------------------------------
Trait GoodConspirator
Characters all
AntiTraits BadConspirator

Same should be done to BadConspirator trait too.


I changed it to all, since I don't think it would work if I add two types of agents in Character line. Should not be a problem since no other type gets checked for Conspirator.


Also, if you look closely agents14-16 triggers you'll see that you would get unrealistic amount of experience for every mission, since all 3 traits get checked (2.75 poitns per mission, on average). Not to mention that threashold tops at 8. If we compare how all other agent traits work, it's obvious that only agents14 trigger should be used while others should be deleted or outcommented.


What do others think?

[Jambo]

good find player 1, I always wondered why successful sabotage did nothing!

[player1]

Ok, after some investigation I'm pretty sure that adding Conspirator to assassins is unbalanced.
There is already more then enough synergy without it to get uber-assassins, and extra possible 1-3 to Subterfuge adds a lot.

Now, my theory is that sabotage was originally planned to be spy mission, but was later move to assassins.

So, instead of GoodConspirator, successful sabotage should give GoodAssassin, since that's the trait which governs assassins experience. Also, that way, there will be no dangerous synergy that could make assassins overpowered.

I suggest only changing triggers agents13 and agents14, since having agents15 and agents16 would make sabotage better in exp gain then assassination.


In short, replace:


;------------------------------------------
Trigger agents13
WhenToTest SabotageMission

Condition not MissionSucceeded

Affects BadConspirator 1 Chance 100

;------------------------------------------
Trigger agents14
WhenToTest SabotageMission

Condition MissionSucceeded

Affects GoodConspirator 1 Chance 100


with this:


;------------------------------------------
Trigger agents13
WhenToTest SabotageMission

Condition not MissionSucceeded

Affects BadAssassin 1 Chance 100

;------------------------------------------
Trigger agents14
WhenToTest SabotageMission

Condition MissionSucceeded

Affects GoodAssassin 1 Chance 100


What do others think?

[Jambo]

Have you noticed that even when diplomats fail missions they seem to gain experience? Similarly, spies and assassins never seem to lose their skills when they miss targets or get caught in a city.

[player1]

Actually, I've seen something opposite.

I've seen some agents losse all their experience (good trait goes back to 0) when fail the mission. But I think it's only realted to thse units that you get at the start of the campaign. Others, later build, don't have such weird handycap.

Maybe these two things are related in some way.

[Calmarac]

good find player 1, I always wondered why successful sabotage did nothing!
That`s peculiar. I`ve definately seen Assassins gain experience from performing successful sabotage missions, fairly regularly, even when the chance is 100%. I see the little box dropping down the side of the screen immediately after a sabotage attempt, and gain an `eye` in the process. I always use CVP however, so this may be relevant.

[player1]

Well, you answered it yourself.

CVP is trait change mod, after all.

[therother]

What's the current status of these assassin issues? Do we think they are bugs or just CA eccentricities?

[player1]

If you ask me, it's a mixed blessing.

While it's weird to not get experience for Sabotage, if you introduce Conspirator trait to Assassins, you effectively get +3 synergy bonus to subtefuge to assassins making them a bit overpowred.

On the other hand, if you switch Conspirator with bonus to GoodAssassin trait, you could get loss of flavor (Murderer that didn't killed anyone).


That's probably why I kept status quo with bug-fixer.


EDIT:
Maybe CA did at first wanted assassins to get XP from sabotage, but later balanced assassins with no XP for sabotage in mind?

[sunsmountain]

Both spies and assassins can easily get their master level (5) after 16 successfull missions. Add in the talent (+1/2/3) and the retinues (+2/3/4) makes 10 on average (i believe the assassin and spy rolls are solely dependant on subterfuge, and it doesn't seem to rise above 10).

This effectively makes GoodConspirator redundant.
One way out of this is change threshold for GoodAssassin from
1/2/4/8/16 to
2/4/8/16/32, and disable triggers agents15 and agents16.
Change threshold for GoodConspirator from
2/4/8 to
4/8/16.

This way you can still get 5 levels in subterfuge after 16 missions as an assassin, but now they're distributed evenly between murder & sabotage. Plus your assassin can 'grow' to level 8 over time (which spies can already do).

Spies still need highly successfull spying missions to get GoodConspirator (probably a little harder to get but redundant anyway).

[player1]

Newly founded bug (first noticed at twcenter):

Numidian governors can never get priests as their retunue mebers, since only triggers for their pantheon of gods are reserved to carthaginians only.


Example:


Trigger trigger_priest_of_Baal
WhenToTest CharacterTurnEnd
Condition EndedInSettlement
and RemainingMPPercentage = 100
and SettlementBuildingExists >= temple_of_justice_temple
and FactionType carthage
and IsGeneral

AcquireAncillary priest_of_Baal chance 15

This is the only trigger for Baal priest and is carthaginian only.



P.S.
Changing "FactionType carthage" to "FactionType (carthage or numidia)" does the trick. Will be seen in new version of bug-fixer soon.


EDIT:
Wow, when did [CODE] tags started working properly?

[Dead Moroz]

Changing "FactionType carthage" to "FactionType (carthage or numidia)" does the trick. Will be seen in new version of bug-fixer soon.
Maybe "FactionType carthage, numidia" ?

[player1]

Actually, the best would be creating aditional trigger with numidia instead of carthage as FactionType.

[Dead Moroz]

Actually, the best would be creating aditional trigger with numidia instead of carthage as FactionType.
Why? These's lots of triggers for multiple factions. I think it's no need for creating special Numidian one... But maybe I missed something?

[tai4ji2x]

dead moroz: what are the other multi-faction triggers, btw? what's the wording format/syntax?

[player1]

Why? These's lots of triggers for multiple factions. I think it's no need for creating special Numidian one... But maybe I missed something?

Actually, if you look for other factions with shared temples, you'll see not only that they have seperate triggers, but they have separete retinue memebers too (just with same image and name, so they look same).


I advised separate trigger instaed of original "(carthage or numidia)", since when i tested it, it woked fine in campaign, but gave me some weird error in custom battle, when I tried to modify spartan texture (weird???). Something like unrecognised factiontype.

[Dead Moroz]

dead moroz: what are the other multi-faction triggers, btw? what's the wording format/syntax?
See the first in export_descr_ancillaries.txt:


Ancillary actor
Image effete_man_ancillary.tga
ExcludedAncillaries comedian, playwright
ExcludeCultures barbarian, carthaginian, eastern, egyptian, roman
Description actor_desc
EffectsDescription actor_effects_desc
Effect Influence 1

It doesn't set exactly factions, just culture types, but I'm sure it works with factions too. I used this syntax for adding new trait to multiple agent types and it worked.

[Dead Moroz]

Actually, if you look for other factions with shared temples, you'll see not only that they have seperate triggers, but they have separete retinue memebers too (just with same image and name, so they look same).


I advised separate trigger instaed of original "(carthage or numidia)", since when i tested it, it woked fine in campaign, but gave me some weird error in custom battle, when I tried to modify spartan texture (weird???). Something like unrecognised factiontype.
Dunno about textures, but multiple targets must work for traits, ancilliares and buildings.

Actually I guess that string should be:


and TargetFactionCultureType carthaginian

[tai4ji2x]

dead moroz: the syntax for the "factiontype" condition seems to be as player1 indicates: parentheses with the word "or".

[player1]

Repost from bug-fixer thread:


Some things I'll really like input of other players.

I've considered fixing values of some traits that seem like typos.


First there is and Energetic trait. A real mess.
At first level it has movment bonus of 2 (ok), which gets increased to 4 at 2nd level and drops back to 2 at 3rd level (!!!) Also at 4rd level it loses one point of management (drop from 3 to 2). Nothing in flavor text indicated any negatives about improving this trait. Also it will be common occurance since Energetic can be increased with some temples.

I guess that fourth level is supposed to give +4management. But how movement bonus is supposed to incrase I have no idea. I'm only sure it was never ment to be higher then +4 at any point.


Then there is a Berserk trait. Really easy to gain with germans if using proper temples. But nothing is descpritions explains sudden high drop in moral. Is it supposed to be +4bonus, not -4 penalty?


Then goes IanR trait. Very rare, but gives -10 personal secutiry per level. Somehow I think it is supposed to be -1 per level, since -10/-20/-30 is way to huge value (call it instant assassination).


RomanHero and Brave are interesting since they both get drop in moral at last level (from 4 to 2). Very weird considering that they have high praises in their descriptions. Maybe bonus is supposed to be 5. Also, it's weird that Brave gets bonus in popular standing since it is non-roman trait. It's interesting to point another minor thing, and that is that no non-roman or barbarian general can gain "The Great" title. Only last level of RomanHero, as well as Warlord give "The Great" title. Somehow I think that last level of Brave, should give "the great" title since brave trait is non-roman replacment of romanhero.

And there is a Feck trait that gives bonuses/penalties to popular/senate standing, but can be gained by non-romans too.


Any oppinions about these?

[magnum]

Definately believe that IanR trait should be -1 / -2 / -3 instead of the -10 / -20 / -30. Personal Security not only affects the ease that you can be assassinated, but also the size of your personal bodyguard. Each point is worth 2 bodyguards. This means at the second and third level of IanR you can actually end up with a negative number of bodyguards. Somehow I don't think thats what CA meant.

[player1]

I doubt that you can get negative bodyguards. It's just that that bodyguard unit would probably not get reinforced ever.

[player1]

Does anybody remember the old bug, when gaining anti-trait would reset trait value to zero, regardless how good trait was?

Well, I found out the solution.

The thing is that traits that have "no going back level" aren't affected.
So soulution is to add "virtual" no going back level to all traits. Since we really don't want to have all traits with real no gonig back levels, no going back level should be one level higher then highest level of the trait (impossible to reach). So, for example, if GoodCommander has 5 levels, its no going back level should be made 6.