Anti-Trait+NoGoingBackLevel mechanic confirmed broken in Medieval 2 Kingdoms

[KEA]

My IR mod too, some even with effects - but these kind of traits usually don't have antraits.

[Gigantus]

No, they usually don't. Although a combined inheritance\family name script might throw up some interesting situations. Personally, I simply don't use anti traits - I rather write two triggers then take a gamble whether I remembered the basics correctly.

if trait a > 0
then remove points from trait a

if trait a < 1
then add points to trait b

[KEA]

It really becomes a problem when trying to code some kind of random character designation. For example, I use a lot of "Random Characters", that is characters I don't know more of than the name (sometimes not even that) and have them being assigned random traits on game start. Here Antraits would be handy when doing stuff like the humours:

;------------------------------------------
Trait PhlegmHumour
    Characters family
    AntiTraits BloodHumour, BlackBileHumour, YellowBileHumour

    Level Calm
        Description Calm_desc
        EffectsDescription Calm_effects_desc
        Threshold  1
        Effect Authority 1

    Level Composed
        Description Composed_desc
        EffectsDescription Composed_effects_desc
        Threshold  2
        Effect Authority 2

    Level Phlegmatic
        Description Phlegmatic_desc
        EffectsDescription Phlegmatic_effects_desc
        Threshold  3
        Effect Authority -1

Here you could fire off a trigger like that:

;------------------------------------------
Trigger CharacterTurnStart_Humours
    WhenToTest CharacterTurnStart
    Condition Trait RandomCharacter = 1
          and Trait BloodHumour = 0
          and Trait BlackBileHumour= 0
          and Trait YellowBileHumour = 0
          and Trait PhlegmHumour = 0

    Affects BloodHumour  1  Chance  50
    Affects BlackBileHumour 1  Chance  50
    Affects YellowBileHumour  1  Chance  50
    Affects PhlegmHumour  1  Chance  50

the result would be that this character only has one of these traits (or none at all). But he might have gained the effects of two of them by the Antrait feature. A possible solution would be to give the first level no effect and add the second level with the effects after the first one was acquired

;------------------------------------------
Trigger CharacterTurnStart_BloodHumour 
    WhenToTest CharacterTurnStart
    Condition Trait RandomCharacter = 1
           and Trait BloodHumour = 1

    Affects BloodHumour  1  Chance  100

Another situation where I run into it would be things like talents. You could have a trait MilitaryTalent with its antitrait NoMilitaryTalent, and fire both with Chance 50 on game start. Here again you might acquire the effects for both. In this case my solution would be to merge them:

;----------------------------------------------------------------------------------------------------------
Trait   MilitaryTalent
    Characters  family


    Level   MilitaryTalent1  ;;; Military interest, average
        Description MilitaryTalent1_desc
        EffectsDescription  MilitaryTalent1_effects_desc
        Threshold 1        

    Level   MilitaryTalent2 ;;; Military Talent, good
        Description MilitaryTalent2_desc
        EffectsDescription  MilitaryTalent2_effects_desc
        Threshold 2
        
        Effect  Command 1
        Effect  Violence    2

    Level   MilitaryTalent3  ;;; Military Incompetence, bad
        Description MilitaryTalent3_desc
        EffectsDescription  MilitaryTalent3_effects_desc
        Threshold 3
        
        Effect  Command -1
        Effect  Violence    -2



;------------------------------------------
Trigger CharacterTurnStart_MilitaryTalent
    WhenToTest CharacterTurnStart

    Condition Trait RandomCharacter = 1
          and Trait MilitaryTalent = 0

    Affects MilitaryTalent  1  Chance  100
    Affects MilitaryTalent  1  Chance  50
    Affects MilitaryTalent  1  Chance  25
;------------------------------------------

[Gigantus]

I was thinking of using multi level traits with bad at the top (level 1) and good at the bottom (level 8) - the entry level would be level 4 (if not trait level >4 and <4 then give level4). all other triggers will add or subtract from there.

[KEA]

I have made the experience that the neutral level would be best placed at the first position and the good on the next (or the bad, depending on what you wish to be more dominant).

[Melooo182]

This explains some of the weird things i've observed in SS
lot of work to do :/

[myarta]

No, they usually don't. Although a combined inheritance\family name script might throw up some interesting situations. Personally, I simply don't use anti traits - I rather write two triggers then take a gamble whether I remembered the basics correctly.

if trait a > 0
then remove points from trait a

if trait a < 1
then add points to trait b

There's a slight gotcha to this approach, that you can get hit with a double-whammy. If a=1, and you pass your remove point check in the first trigger, now you are eligible for a < 1 (because a=0) in the second check. If you pass that roll, you've just advanced two ticks in one event. For example, in this event from EB2 that caused me to notice this issue and be referred to this thread for the AntiTrait bug:

;------------------------------------------
Trigger pillage_bad_disciplinarian_disciplined
  WhenToTest SackSettlement


  Condition Trait Disciplinarian > 1


  Affects Disciplinarian -1  Chance  20


;------------------------------------------
Trigger pillage_bad_disciplinarian_undisciplined
  WhenToTest SackSettlement


  Condition Trait Disciplinarian < 1


  Affects BadDisciplinarian  1  Chance  20

Here, you have a 4% chance to go all the way from +1 on the A trait to +1 on the B trait (1/5 * 1/5 = 1/25)

Proof:

Spoiler Alert, click show to read: 

For simplicity, assume the Chance is 100% and the change is 1 point at a time, and the thresholds are 1 point

Case 1: a=0, b=0
Trigger 1: a > 0 becomes 0 > 0 which is FALSE
Result: Nothing changed
Trigger 2: a < 1 becomes 0 < 1 which is TRUE
Result: Points added to B
Interpretation: If the event in question is designed to grow B and reduce A, this is correct. No problems with this case.
END RESULT: a=0, b=1

Case 2: a=0, b=1
Trigger 1: a > 0, 0 > 0 FALSE
Result: Nothing changed
Trigger 2: a < 1, 0 < 1 TRUE
Result: Points added to B
Interpretation: This trigger set continues to function correctly, growing B when it already has a starting value the same as if both sides were 0 as in case 1
END RESULT: a=0, b=2

Case 3: a=1, b=0
Trigger 1: a > 0 becomes 1>0 which is TRUE
Result: Points subtracted from A (a=0, b=0 at this stage)
Trigger 2: a < 1 becomes 0 < 1 (no longer 1 < 1 due to the change we just made!), which is TRUE
Result: Points added to B
Interpretation: This is the double whammy. The change wrought by the first trigger makes you qualify for the second trigger, resulting in a total shift of two levels for just one event
END RESULT: a=0, b=1

Case 4: a=3, b=0
Trigger 1: 3 > 0 TRUE
Result: a=2, b=0
Trigger 2: 2 < 1 FALSE
Result: a=2, b=0
Interpretation: The double whammy only happens when shifting from the last level of A down to zero then starting up one level into B. It doesn't cause a problem when you're dropping levels in A but not getting below the second trigger's check.
END RESULT: a=2, b=0

It seems that the proper general formula for avoiding this issue is to assess whether you are raising A or B and adjust the trigger order accordingly:


For events that would raise A and lower B, your two-trigger pair would be as follows:

1. trait b < 1, then
add points to A

2. trait b > 0, then
subtract points from B

Proof:

Spoiler Alert, click show to read: 

Case 1: a=0, b=0
Trigger 1: 0 < 1 TRUE
Result: Points added to A
Trigger 2: 0 > 0 FALSE
Result: Nothing changed
Interpretation: With no trait set, the A trait correctly begins to grow without messing with B.

Case 2: a=0, b=1
Trigger 1: 1 < 1 FALSE
Result: Nothing changed
Trigger 2: 1 > 0 TRUE
Result: Points subtracted from B
Interpretation: You have to clear out the B trait before you can start growing in A. This trigger combination correctly cleans up the B value without also growing A, which is ineligible on this iteration
Note: If instead of b=1 we tried b=4 as a sample case, the results are the same. B gets a chance to reduce this tick without also improperly ticking up A.

Case 3: a=1, b=0
Trigger 1: 0 < 1 TRUE
Result: Points added to A
Trigger 2: 0 > 0 FALSE
Result: Nothing changed
Interpretation: Value is already positive to start, and correctly continues to grow without messing with its counter-trait
Note: Same as case 2, A could have started at 7 if you have that many levels and the result would still be correct

Case 4: a=1, b=1
Trigger 1: 1 < 1 FALSE
Result: Nothing changed
Trigger 2: 1 > 0 TRUE
Result: Points subtracted from B
Interpretation: This is an invalid starting state, since the point is to simulate anti-traits and you shouldn't have both at the same time. However, at least it will self-heal a bit and start erasing your anti-trait and get you back to an a=1,b=0 healthy state

And for events that would lower A and raise B, you need your two-trigger pair different, as follows (note how now 'a' is the condition that matters and, as before, the 'add points' trigger comes first, despite being for trait B:

1. trait a < 1, then
add points to B

2. trait a > 0, then
subtract points from A

Proof:

Spoiler Alert, click show to read: 

Case 1: a=0, b=0
Trigger 1: 0 < 1 TRUE
Result: Points added to B
Trigger 2: 0 > 0 FALSE
Result: Nothing changed
Interpretation: B correctly begins to grow in light of this negative event, while A remains unchanged

Case 2: a=0, b=1
Trigger 1: 0 < 1 TRUE
Result: Points added to B
Trigger 2: 0 > 0 FALSE
Result: Nothing changed
Interpretation: B continues to worsen in light of this event, without the non-present A trait being affected

Case 3: a=1, b=0
Trigger 1: 1 < 1 FALSE
Result: Nothing changed
Trigger 2: 1 > 0 TRUE
Result: Points subtracted from A
Interpretation: The A trait goes down to zero without double-whammying a tick up in B as well, as the original method would have caused

Case 4: a=1, b=1
Trigger 1: 1 < 1 FALSE
Result: Nothing changed
Trigger 2: 1 > 0 TRUE
Result: Points subtracted from A
Interpretation: Another invalid state like in the other pair of triggers, but it heals it back to the valid a=0, b=1

So then here is a fully fleshed out example for the case when your "A" trait is "Disciplinarian" and your "B" trait is "BadDisciplinarian", and the event of Occupying a Settlement (instead of Capture or Raze) grants better discipline and the event of sacking a settlement worsens discipline, both at 20%:

Spoiler Alert, click show to read: 

All that needed changing was the order of the SackSettlement triggers. Previously they were mirroring the order of the OccupySettlement triggers, but that allowed for the whammy. The general case is you have to make the trigger that affects the trait that is the condition for this pair the SECOND of the two or it will cause a double-fire in the cases where the first trigger brings it below 1.

;------------------------------------------
Trigger occupation_disciplinarian_disciplined
  WhenToTest OccupySettlement


  Condition Trait BadDisciplinarian < 1


  Affects Disciplinarian  1  Chance  20


;------------------------------------------
Trigger occupation_disciplinarian_undisciplined
  WhenToTest OccupySettlement


  Condition Trait BadDisciplinarian > 0


  Affects BadDisciplinarian -1  Chance  20

;------------------------------------------
Trigger pillage_bad_disciplinarian_undisciplined
  WhenToTest SackSettlement


  Condition Trait Disciplinarian < 1


  Affects BadDisciplinarian  1  Chance  20



;------------------------------------------
Trigger pillage_bad_disciplinarian_disciplined
  WhenToTest SackSettlement


  Condition Trait Disciplinarian > 1


  Affects Disciplinarian -1  Chance  20

tl;dr You have to make the trigger that Affects the trait that is the Condition for the pair of triggers the SECOND of the two or it will cause a double-fire in the cases where the first trigger brings it below 1, firing both triggers in a row.

[Gigantus]

The example actually makes sense: you go from a good disciplinarian to a bad one when you pillage a settlement. There is no 'neutral' disciplinarian trait - that can only be achieved by having a multiple level trait, eg

level1 = good
level2 = neutral\default - requires 'catch all' triggers, eg ComingOfAge, Adopted etc
level3 =bad

I am a big fan of that method Starting with neutral has it own trigger pitfalls.

[myarta]

Yes, but I'm not talking about a neutral trait. I'm saying that there is a corner case during which the correct behavior of going from Good to Bad when you pillage a settlement is accidentally doubled in magnitude.

Imagine starting with GoodDisciplinarian at 1. Then let's say you make that 20% roll. Now GoodDisciplinarian doesn't exist on your sheet, and neither does bad. But because you ran that check first, now your trigger that raises BadDisciplinarian also fires, so you get a SECOND 20% chance for the same single action.

If you have Good or Bad disciplinarian at any other value than Good=1 when you start, you properly only get a SINGLE 20% shot at a trait shift, but there's this case in which you get double, and the solution is as simple as adjusting the order of the triggers so you don't change the Condition trait before you've checked it both times. I may have been too verbose and confusing the first time through.

[Gigantus]

I think we both made an error:

A. the first trigger is 'more then level one' (two or more)
B. the second trigger is 'less then level one' (zero or less)

If you reduce A. by one then you still have more then zero, meaning only one of the triggers will fire at any given time.
Obvious question: is there a trigger that will reduce 'Disciplinarian' back to level 1 so that eventually a 'Bad Disciplinarian' trait can be given?
I would think the correct format for A. should have been 'equal or larger then 1' if there are no other triggers.

The double whammy only comes into play if the first trigger actually succeeds to reduce the level (20% chance). Then it's another 20% chance that the 'bad' trait gets given - all in all the 4% chance you mentioned for both to happen which in this case I think is acceptable, considering how often the same person pillages a settlement For higher, accumulative chances (trigger percentage\event frequency) this system is obviously not suitable.

[myarta]

I think we both made an error:

A. the first trigger is 'more then level one' (two or more)
B. the second trigger is 'less then level one' (zero or less)

If you reduce A. by one then you still have more then zero, meaning only one of the triggers will fire at any given time.
Obvious question: is there a trigger that will reduce 'Disciplinarian' back to level 1 so that eventually a 'Bad Disciplinarian' trait can be given?
I would think the correct format for A. should have been 'equal or larger then 1' if there are no other triggers.

The double whammy only comes into play if the first trigger actually succeeds to reduce the level (20% chance). Then it's another 20% chance that the 'bad' trait gets given - all in all the 4% chance you mentioned for both to happen which in this case I think is acceptable, considering how often the same person pillages a settlement For higher, accumulative chances (trigger percentage\event frequency) this system is obviously not suitable.

Oh yes, you're right. I missed that in assessing that paste. I think if you expand the last spoiler though, you'll see my suggested replacement Disciplinarian triggers. I think those will work perfectly without having to accept a chance at a double whammy at all. Which is useful for when people write 100% triggers using this formula. The reasoning for why was assessed in the proof spoilers of my two general cases.

EDIT: Here, just posted. Do you see any gotchas or mistakes in these? I don't, but I may be blind to them. And they solve the double whammy problem. I agree that it's not worth wasting Dev team time on EB to go rework all double whammies out of the code, especially since it's the right effect at least, but on this thread people may be using this knowledge to write new triggers and then it's no problem for them to put them in the correct order from the get-go.

;------------------------------------------
Trigger occupation_disciplinarian_disciplined
  WhenToTest OccupySettlement


  Condition Trait BadDisciplinarian < 1


  Affects Disciplinarian  1  Chance  20


;------------------------------------------
Trigger occupation_disciplinarian_undisciplined
  WhenToTest OccupySettlement


  Condition Trait BadDisciplinarian > 0


  Affects BadDisciplinarian -1  Chance  20


;------------------------------------------
Trigger pillage_bad_disciplinarian_undisciplined
  WhenToTest SackSettlement


  Condition Trait Disciplinarian < 1


  Affects BadDisciplinarian  1  Chance  20


;------------------------------------------
Trigger pillage_bad_disciplinarian_disciplined
  WhenToTest SackSettlement


  Condition Trait Disciplinarian > 1


  Affects Disciplinarian -1  Chance  20

[Gigantus]

The bottom set seems to have the gap again - if the trait = 1 then absolutely nothing happens when sacking, copy\paste error? Else it looks fine.

[myarta]

Ah, right. I was more tired than I realized when writing that.

I think I stated the general formula correctly then goofed around with EB example code:

For events that would raise A and lower B, your two-trigger pair would be as follows:


1. trait b < 1, then
add points to A


2. trait b > 0, then
subtract points from B


And for events that would lower A and raise B, you need your two-trigger pair different, as follows (note how now 'a' is the condition that matters and, as before, the 'add points' trigger comes first, despite being for trait B:


1. trait a < 1, then
add points to B


2. trait a > 0, then
subtract points from A

Should yield:

;------------------------------------------
Trigger occupation_disciplinarian_disciplined
  WhenToTest OccupySettlement

  Condition Trait BadDisciplinarian < 1

  Affects Disciplinarian  1  Chance  20

;------------------------------------------
Trigger occupation_disciplinarian_undisciplined
  WhenToTest OccupySettlement

  Condition Trait BadDisciplinarian > 0

  Affects BadDisciplinarian -1  Chance  20

;------------------------------------------
Trigger pillage_bad_disciplinarian_undisciplined
  WhenToTest SackSettlement

  Condition Trait Disciplinarian < 1

  Affects BadDisciplinarian  1  Chance  20

;------------------------------------------
Trigger pillage_bad_disciplinarian_disciplined
  WhenToTest SackSettlement

  Condition Trait Disciplinarian > 0

  Affects Disciplinarian -1  Chance  20

The only change being that last check needed to be 0 as you say.

[Gigantus]

I made that 'being tired' mistake myself - see the 'faction besieging itself' issue in EBII.

[b0Gia de Bodemloze]

Can we sticky this thread please?

[Jurand of Cracow]

No, it's not broken, it simply cannot be used in EDCT. Only use it in EDA.

Is it really true? In the Stainless Steel it's used in EDCT in some cases, for instance to signify that somebody has a provincial title, and I think it works well...

[KEA]

Is it really true? In the Stainless Steel it's used in EDCT in some cases, for instance to signify that somebody has a provincial title, and I think it works well...

I don't know the EDCT of SS, but it doesn't work. Maybe the same trigger is in EDA as well.

[alreadyded]

Has anyone ever released code of the anit-traits and nogoingback removed or replaced? I assume nogoingback can just be deleted right? Or will that mess things up?

[Jurand of Cracow]

Has anyone ever released code of the anit-traits and nogoingback removed or replaced? I assume nogoingback can just be deleted right? Or will that mess things up?

I don't mess with EBII, but in SSHIP if I want to have NGB effect, I put a "jump" in the thresholds of the levels. For instance, if I want the NBG3, the thresholds would be 1,2,3,14,15, and additional trigger for 4 points would be introduced, adding 10 points more. It's an effective no-going back. Sometimes it may be ackward, but you need to cope somehow).
Does anybody see a problem with such a solution?

I don't know the EDCT of SS, but it doesn't work. Maybe the same trigger is in EDA as well.

I think I was not clear enough. According to the context, the question was about "HasAncType" condition. I think it works well in EDCT as well.

---
Using the opportunity of this post, I would like to ask if the old AntiTrait bug (mentioned in the second part of this post) is still in the M2TW engine? If yes, then the result would indeed be to steer away from using AntiTraits...

[KEA]

I think I was not clear enough. According to the context, the question was about "HasAncType" condition. I think it works well in EDCT as well.

No, it doesn't. Just try it out.