Regarding pellik's #3: Yes it's probably very safe to say that Conditions only affect the lines following the Condition statement. However, I would guess code like you've suggested isn't going to happen. The structure of the txt file seems very rigid, and we already know (from the fact that it accepts modification) that the game must parse it for use. Anyone that's used a parser before knows how unforgiving they typically are, so as far as code like this is concerned...

Trigger MyTrigger
WhenToTest CharacterTurnEnd

Affects BattleChivalry 1 Chance 100

Condition Trait BattleDread >=1

Affects BattleChivalry -1 Chance 100
Affects BattleDread 1 Chance 100

...I would surmise that since it never shows up in an Affects-Condition-MoreAffects format in the traits file, the parser probably doesn't handle that case. Nevertheless I'll see about setting one up like that to find out what happens. Something like a huge diplo skill boost for a new diplomat upon creation should work well, as it's easy to churn out a new diplo and see if he has 9 or 10 skill instead of his normal amount. Of course I might not get that far, as an unparseable traits file could make me CTD.

As an additional note, I think it's very unlikely we can use logic like IF, loops, etc in this file. Again I would cite the fact that the game code has to parse the txt file into some useable format, and allowing loops in the file would have made that parser ridiculously more complicated than it has to be. It's probably the exact reason that antitraits are handled entirely outside of the traits file: it's far more easy to associate traits with a word and define that association in actual code somewhere else, than it is to associate them using logic in the traits file and then have to parse that logic into code. It's just unfortunate for us that we can't actually mod the antitraits code, as I'm sure it would be a matter of only a few lines to make it do exactly what we think it should.

A few other ideas to toss out:

1. @Kobal: I have been thinking, and possibly have something on that 2) problem you mentioned. Without the Antitrait tags in the file, the game should allow opposite traits to exist with points in each... so you won't even need to mess with an unused trait to keep track. You do this:

Trigger trig1
Condition Drink = 3
Affects Sober 12 60%

Trigger trig2
Condition Drink = 3
and Sober = 12
Affects Trait Drink -3 100%
Affects Sober -3 100%

The important thing is that the trigger right before trig2 is the only way they'd get to be at 3 and 12 respectively (because the rest of my code inherently makes sure they can't be positive at the same time), so trig 2 can only run if trig1 hit success.

2. Another concept would be to use trig1 as is and ignore trig2 altogether, instead opting to simulate anti-trait code with additional triggers. This makes even MORE triggers though... but I'm not convinced it would cause any real slowdown (the computer can pretty much FLY through a few extra conditionals, especially since they'd be false most of the time), and would be easy to crank out in the file via automation. It also has the huge benefit of requiring no changes to any triggers already in the file, and only the removal of the Antitrait tag from all trait definitions. To explain better, if we're talking about marriage code here, you'd append to the file some triggers that check:

when marriage
if trait1 > 0
and antitrait1 > 0
then trait1 -1 100%
antitrait1 -1 100%

You'd copy that like 25 times for each trait/antitrait pair that could come into conflict during marriage. This is essentially a far less eloquent implementation of a while loop. I don't think anything actually gives a trait 25 points ever... so you could just cap the copies at whatever the biggest trait jump is that's in the file, and the code would balance it until at least one of the traits is zero again. This can be done for each WhenToTest time, over all traits.

The real beauty of it is in our ability to generate the code through a simple routine, though. We can parse the Vanilla traits file to find trait definitions and their associated antitraits, as well as all WhenToTest condition names (unless there's an All feature I don't remember seeing). This should be easy due to how rigid and formulaic the traits file is. Then you generate like 25 triggers for each antitrait family, for each checktime. Append them all to the file, and you should have achieved intuitive anti-trait functionality, without the broken anti-trait code.

The only thing left to consider would be how to implement situations where multiple traits are listed as antitraits for another.