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

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

Add 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 Effects

Back 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 100

Finally, create a new trigger immediately after like so:

Trigger unprevent_hate_n_fear1
WhenToTest CharacterTurnEnd

Condition Trait Phnf1 > 0

Affects AntiPhnf1 1 Chance 100

So 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, 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...

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