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

Quote:

---

Originally Posted by Sinner

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:

Quote:

---

;------------------------------------------
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:

Quote:

---

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

{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):

Quote:

---

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:

Quote:

---

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

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

Quote:

---

Originally Posted by Simetrical

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.

Quote:

---

Originally Posted by 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

---

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

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:

Code:

---

;------------------------------------------
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:

Code:

---

;------------------------------------------
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").

Code:

---

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

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.

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.

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

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.

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:

Code:

---

;------------------------------------------
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:

Code:

---

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

{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:

Code:

---

;------------------------------------------
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").

Code:

---

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

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. :(

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.

Quote:

---

Originally Posted by Sinner

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.

Quote:

---

Originally Posted by Zrave

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.

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.

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.

Quote:

---

Originally Posted by 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.

---

Yeah, he mentions that in his 2nd post.

Quote:

---

Originally Posted by Sinner

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.

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.

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.

Quote:

---

Originally Posted by 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.

---

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.

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.

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

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

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.

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

Code:

---

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

    Condition CharacterIsLocal
          and IsGeneral
          and Trait DoubleCombat1 = 1

    Affects AntiDoubleCombat1  1  Chance  100

---

Okay, putting ideas together.

Do the steps in the first 2 code boxes in this post, just forget about the 2nd level.

At the end of the Character file, add this:

Code:

---

;------------------------------------------
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:

Code:

---

          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.

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

Quote:

---

Originally Posted by Zrave

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.

Quote:

---

Originally Posted by therother

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 :)

Quote:

---

Originally Posted by therother

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.

Quote:

---

Originally Posted by therother

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

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.

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.

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.

Quote:

---

Originally Posted by 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:

Code:

---

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

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

What are default general hit points anyway?

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

Quote:

---

Originally Posted by player1

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.

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.

Quote:

---

Originally Posted by Jambo

player 1, are you the guy from the civ forums that made the patch suggestion mod?

---

yes

Okay, using the rules (in this order) that I think Zrave is suggesting above:

1. If (bug, Fix) = (1,2), then (bug, Fix) reset to (0,0)
2. Parse battlemap triggers - no trait if Bug = 1
3. If Bug = 1 then Fix = 2
4. 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:


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.

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.

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

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

Quote:

---

Originally Posted by Zrave

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

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.

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.

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.

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

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.

If GeneralHPLostRatioinBattle is bugged, perhaps we should just do without it?

So how about something like this:

Code:

---

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

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.

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.

I believe generals have the same stats but more hit points, although I'd be hard pressed to support that claim.

As far as I understand generals have +5hp compared to the bodyguard unit.

So 7hp default, 15hp if scarface, 1hp if very, very ill.

Quote:

---

Originally Posted by therother

If GeneralHPLostRatioinBattle is bugged, perhaps we should just do without it?

So how about something like this:

Code:

---

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

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

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

PercentageBodyguardKilled is used as some sort of checker to distinguish false generalhpcount form the real one.

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.

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.

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

Nevermind, I just realized thta it needs to be 80% and not 0.8

CVP 1.2 was just released with fixes for all the bugs discussed here.

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...&id=1812000192
http://www.twcenter.net/forums/index...&id=1812000194

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: