AntiTraits : now what the heck is happening here ?

[Kobal2fr]

Buggy as hell, or I don't get how things should work ?

My understanding was that when a character had a given trait, and gained one point in it's anti-trait, then said trait gets -1, anti-trait 0, and that's it.

But I'm beginning to believe that when you gain 1 point in an anti-trait, the trait simply disappears altogether ! Which would explain why Assassins failing their missions go from "Experienced Assassin" to "Simpleton".

Case in point : start a campaign as Scotland. The prince has 2 StrategyDread, 2 BattleDread. I use him to capture York. Win, choose Occupy City, which gives 1 StrategyChivalry : all StrategyDread vanishes, instead of being reduced to 1.

So, are antitraits really meant to be "remove all levels of opposing traits when you gain this" ?
Because if that's the case... maaaan does there need to be a LOT more triggers and fixes to the traits files :/

And if they aren't, CA needs to be told FAST.

How were they used in RTW, does anyone know ?

[alpaca]

Yes I suspect that, too.
In RTW they worked differently (1 point in AntiTrait resulted in -1 in the Trait), but maybe they changed that behaviour deliberately in MTW2, because you can use negative affects values to make traits go lower.
However, I don't think that is the case and it is indeed a bug.

[Bob the Insane]

In Vices & Virtues FIXES v1.0 -

See:

https://forums.totalwar.org/vb/showthread.php?t=75661

and:

https://forums.totalwar.org/vb/local....php?catid=135


The author stats:

"Assasssins / Princesses / Diplomats losing all Good- traits instead of one point on unsuccessful mission: Now working as intended, failed missions now only reduce trait by one point."

Could this be related?

[Jace11]

Was it not working ok in 1.0? I seem to remember my assassins kept missing but didn't lose all their skills..

[Foz]

LOL! You're always a step ahead of me, Kobal. I was thinking yesterday that I would come on today and start up a thread about antitraits since I wasn't sure how exactly they were working or were supposed to be working. I show up, and voila, you already have one up. Good stuff.

As for the potential bug where agents commonly lose massive amounts of skill by failing, I'm fairly certain the antitraits code is at fault as you've suggested. We can presumably see all the pertinent triggers in the traits file for various agents failing missions. None of them give more than 1 point to any of the bad traits, nor do I see any particular failure situation that should result in 3 or more triggers (they could gang up to produce the effect we're all noticing - I use 3, because I know I've witnessed an agent lose at least that much skill from 1 failure before)... yet I too have noticed whole trait lines just vanish. So what is going on? If nothing we can see in the traits file can cause it to happen, it must be something we can't see, and antitraits code is about the only thing we can't see that would be A. associated with traits in any way and B. also designed to affect them. So in the presence of a very likely theory and the absence of any other reasonable explanation, I think we should operate under this assumption until we have reason not to.

Next topic: is the effect of antitraits as intended? I say no. It creates a ridiculous back-and-forth effect in traits, as a powerful line can just immediately vanish, and the character starts down the opposite road. The fact that RTW used them as the 3 of us intuitively think it should be is another indicator that it hasn't ended up doing what they intended. Why would the devs intentionally change a mechanic that is liked well enough and functions properly? I would also suggest that we ought to change it, even if it is as intended - a majority of people seem to not like the harsh punishment for agent failures, and agree that it is suspicious and unbalanced at best. I'm open to hear views though, if anyone isn't as sure that we should find a workaround.

So... if we are to make it work as we think it was intended, then what must be done? My idea is to avoid the antitrait mechanic by just giving -1 point to the appropriate trait in any situation where its opposite would normally receive an antitrait point. As far as I can see, the workaround goes like this:

- Remove all antitrait references from the trait entries. This is because we will have to set them up without using the antitrait mechanic to avoid the problematic code that we can't get at. Note that this is the last thing to do, so you don't lose track of what traits are opposites!

- Duplicate each trigger that contains an antitrait (not the word, but a trait that has one or more opposite) so you end up with a pair of triggers per antitrait it can give a point (or more) to: i.e. 3 possible antitraits makes 2(3) = 6 triggers necessary. This is because we will use "Affects OppositeTrait -1 Chance n" to work around the antitrait code. Since you want to still allow bad traits to happen, the extra triggers will be necessary to determine when a trait already has point(s) and should be decremented instead of the opposite trait being incremented.

- Setup the triggers for each event in pairs (one is for the antitrait being > 0, the other for not > 0), and change the Affects lines accordingly.

So if the original trigger could give BadAdministrator and BadTaxman, each pair of new triggers now corresponds to one of the two traits' anti-traits: The first pair will check for GoodAdministrator > 0, while the second checks for GoodTaxman > 0. If either one is true, we'll subtract from the Good trait instead of adding to the Bad one (which would cause the anti-trait code we're working around). So a trigger like this:

Trigger trigger1
When ToTest CharacterTurnEnd

Condition Original_Conditions

Affects BadAdministrator 1 Chance 3
Affects BadTaxman 1 Chance 3

Becomes something like this:

Trigger trigger1
WhenToTest CharacterTurnEnd

Condition Original_Conditions
and not GoodAdministrator > 0

Affects BadAdministrator 1 Chance 3

Trigger trigger2
WhenToTest CharacterTurnEnd

Condition Original_Conditions
and GoodAdministrator > 0

Affects GoodAdministrator -1 Chance 3

Trigger trigger3
WhenToTest CharacterTurnEnd

Condition Original_Conditions
and not GoodTaxman > 0

Affects BadTaxman 1 Chance 3

Trigger trigger4
WhenToTest CharacterTurnEnd

Condition Original_Conditions
and GoodTaxman > 0
Affects GoodTaxman -1 Chance 3

If I'm wrong on any of this, just let me know.

Also as a side note... each trigger with n different possible anti-trait effects now will require 2n separate triggers. IIRC some triggers have as many as 5 traits, so this might be a lot of additions...

[Shahed]

Something I wanted to add.

No going back levels are not working either. It happens that you've reached the no going back level for a trait, but if you pop an anti-trait it can completely remove your trait line, even though your character is supposed to have passed the threshold for possible loss of this trait.

[pellik]

The traits have been bothering me a good deal as well.
I've made myself a small trait editing program (of sorts), and I don't see why I can't extend it to fix the traits as you've mentioned. (Actually I've been doing just that since before I read this post, but thats beside the point.)

Unfortunately I am away from home for the holiday and I don't have access to the game for another few days. This means that I can't test either the fixes I think should work nor test the ideas I think might work. If any of you other guys fooling around with the traits file want to test a few things for me then I can probably get a mod traits up on Sunday evening.

Before I do something so klunky as duplicating half the triggers I want to find out a few things that might make this far more elequent:

1) Can we use the docudemon commands in the traits file? An IF in the traits would not only make this fix clean, it will open doors for other modders.

2) Can we use conditions in the trait definition instead of the trigger definition? This will also keep the file more human parsable then duplicating triggers. Although the usefullness of a condition is somewhat limited without some sort of an else.

3) Does condition placement effect only lines after the condition?
For example:
Trigger MyTrigger
WhenToTest CharacterTurnEnd

Affects BattleChivalry 1 Chance 100

Condition Trait BattleDread >=1

Affects BattleChivalry -1 Chance 100
Affects BattleDread 1 Chance 100

Much thanks if someone could let me know.

Sorry if this doesn't make sense. I am very tired.

[Kobal2fr]

@Bob : yeah, that's what ticked me off on the antitraits not working actually. I checked what he did to make the assassins go -1 instead of all the way down, and sure enough, he's duplicated all assassin/diplo/spy mission triggers to check if trait>0 then trait -1 if trait=0 then antitrait 1.

Which is exactly what the_foz suggests, and what I'd been thinking as well. The problems are :

1) that's a truckload of triggers to duplicate/quadruple/sextuple, with min AND max conditions if nogoinback doesn't work either. We'd basically double/treble the size of the file, and more triggers mean more checks mean more time spent checking. Also means more work to change otherwise simple paramaters.

2) there are some triggers that are just plain too relying on antitrait code to fix easily. I'm thinking of the marriage ones here, with a slew of "if Drink =2 Then Sober 8 60%" "if Drink = 3 then Sober 12 60%" etc... which rely on the antitrait system not only to reduce a given trait, but actively give the relevant antitrait.

And something like :

Condition Drink = 3

Affects Drink -3 60%
Affects Sober 4 60%


Doesn't work, because you could get one or the other :/

The only thing to do here would be to duplicate once more, have these triggers give an unused trait like GoodGunpowderGeneral 60% (trait which can't be used/made to work for lack of the relevant trooptype variable). Then make another trigger right under it with same condition that also checks wether GoodGunpowderGeneral exists, and if so then Drink -3 100% Sober 4 100% GoodGunpowderGeneral -1 100%.

But like I said, that's a LOT of triggers to rework, meaning also a LOT more chances to bork stuff up. Plus the lazyness in me cries out : "Let CA fix their mess first ! Tell'em it dun't work properly ! Less work for us both, K. Have a pretzel instead." :)

@pellik :
1) perhaps, but ifs and whiles and loops tend to hog a lot of proc time when let loose, dont' they ? if so we'd have to ask ourselves if it wouldn't bring a lesser comp than ours to its knees, or unduly lenghten the between-turns time since triggers also affect the AI

2) big no-no. You don't mix actual code in the definition of a variable :) I mean, I'm not sure it's not possible, I'm not home so I can't check, but I'm certain it's Bad programming form

3) hmm good question. I don't think it's possible, triggers being very simple "when if do" syntax from what I can see, in fact it seems adding more than 3 Affects to the same trigger is not advised (hence the 20 or 30 birth triggers instead of just a big one). But it's a good idea nevertheless, I'll test that ASAP when I get home on tuesday

[pellik]

Kobal2fr:

At #1 again:
I'm disinclined to believe that the traits file is responsible for much of the overall workload between turns. But I guess the test could be to remove all triggers and play the game without traits. (Just removing triggers so the initial campaign doesn't need to be edited). I'll give this a shot on Tuesday night or Wednesday.

Also it seems that most of the triggers in the game only come up at specific times. Upon a marrage and such. Another load limiting factor.

Finally consider that an if statement fix would circumvent needing the AntiTrait conditions, and the AntiTrait loop wouldn't run in place of an if we control running. Replacing one loop with another is probably going to be a lot faster then running twice as many trigger checks.

Not that any of this matters since we don't know if we can use control loops in the traits file anyhow.

Regarding foz's method of doubling up the triggers:
The script I've been writing for statistical analysis of the traits I can modify to auto-generate a new file with fixed triggers. I just dont want to do this until I've given up on being able to use the other potential solutions I mentioned in my previous post.


One last thing @Kobal:
Do you have a more indepth changelog for your traits fixes? I havn't diffed it to the vanilla yet, but since you're deleting blocks I'm not sure how useful it would be. Maybe you could release version updates as diff files (patch.diff) as well so modded files can stay somewhat compatible?

[Foz]

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.

[Sarastro]

In Vices & Virtues FIXES v1.0 -

See:

https://forums.totalwar.org/vb/showthread.php?t=75661

and:

https://forums.totalwar.org/vb/local....php?catid=135


The author stats:

"Assasssins / Princesses / Diplomats losing all Good- traits instead of one point on unsuccessful mission: Now working as intended, failed missions now only reduce trait by one point."

Could this be related?

Hey folks, found this problem when I first started modding M2 traits (I authored the Vices & Virtues FIXES mod, different username on this forum :) ), and managed to hotfix it, but there does seem to be a hardcode problem.

Just like to say hi to Kobal quickly, and thank you for your mod, you found a lot of stuff that I missed out first time round, was most helpful being able to see someone else's mod along the same lines, so thanks!

I think, but haven't tested thoroughly, that a part of the anti-trait hardcode is broken. In RTW, anti-traits had two functions. One, having X trait would disallow any of its anti-traits. Two, 1 point in that trait would = -1 point in the anti-traits. This meant that the RTW triggers operated a scale between trait & anti-trait like thus:

EXAMPLE

BadCommander 4 3 2 1 NEUTRAL 0 NEUTRAL 1 2 3 4 5 6 GoodCommander

So the triggers which give 1 point in BadCommander for losing a battle would simply take 1 point off GoodCommander if that character had points in GoodCommander. NoGoingBackLevels would simply mean that once the character was advanced enough in a trait, he wouldn't lose it past that level.

In Medieval 2, it seems that code is broken. So if you gain 1 point in BadCommander, that trait will appear, and since GoodCommander is the anti-trait, it will dissapear. The new trait overrides the old anti-trait. The result was that if there isn't a NoGoingBackLevel, then as soon as you gain 1 point in the Bad- trait, you will lose all points in any GoodTrait. If there is a NoGoingBackLevel, as soon as you gain 1 point in the Bad- trait, you will go straight to the NoGoingBackLevel of the Good- trait.

This is a little annoying. However, -1 Trait as a trigger value still works, so my fix (example for diplomats) is this:

;------------------------------------------
Trigger agents27
WhenToTest DiplomacyMission

Condition MissionSucceeded

Affects GoodDiplomat 1 Chance 100

;------------------------------------------
Trigger agents28
WhenToTest DiplomacyMission

Condition not MissionSucceeded

Affects GoodDiplomat -1 Chance 50

;------------------------------------------
Trigger agents28_baddiplomat
WhenToTest DiplomacyMission

Condition not MissionSucceeded
and AgentType = diplomat
and Trait GoodDiplomat < 1

Affects BadDiplomat 1 Chance 50

Tested that thoroughly with various agents, and it works going up and down the scale, so effectively it should work like RTW again. However, it does required a lot more triggers and thinking when writing new traits.

As for broken NoGoingBackLevels, I haven't noticed that myself, but it could well be related to the above.

I don't know exactly what is going on in the code, but at a guess I would say it is either: the latest gained trait over-rides existing traits more than it should, or the code for anti-traits has been changed so that they no longer = -1 point in corresponding traits.

Hope that is some use.

PS The longer I work on the traits, the more it looks to me like whoever did them for M2 was a) not the same person who developed it for RTW, b) doesn't quite understand how they work, c) had to rush the job. The good news is that there are now many more conditions which seem to work within the traits & strat functions, so there seems to be a lot of opportunity for modding.

[Foz]

I agree with everything you've said, Sarastro. I had surmised the exact same thing about the antitrait hardcode, since nothing in the trait file could be causing the issue. As for your solution, it works for agents, but can't be applied directly to other situations. The primary reason is that the agent-affecting traits never gain more than 1 point at once for their success or failures. This allows the simple +1/-1 trigger pairs that you implemented, which admittedly IS the easiest way to fix the agents. However, as Kobal pointed out in the coming-of-age triggers, the marriage triggers, and others, sometimes traits like sobriety have a chance of gaining huge amounts of points, like 8 or more. There's no easy way to setup a similar trigger pair to fix that, as the points are typically split across removing antitrait and adding trait. So 8 points of sobriety at 60% chance doesn't equal -3 pts drink at 60% and 5 pts of sobriety at 60%, because there's no way to make sure the 2nd triggers if and only if the first does, short of actually testing to see, which makes yet another trigger and is messy to boot. See #1 from my last post for how this would work, though I don't recommend trying to do this to the file.

I would also point out that the code you displayed is not quite right yet: you've allowed an agent with 0 GoodDiplomat pts to still have 1 removed half the time, and then have a chance to gain a BadDiplomat point as well. This means a failed mission could cause a 2-point swing in any diplo with 1 or less GoodDiplomat points, since both triggers will go off - and he could also get a negative GoodDiplomat stat, which is something undefined in game terms as far as I know. The fix is to make the triggers mutually exclusive by testing the first trigger as well. You check for GoodDiplomat > 0 (or >= 1 if you prefer), which then prevents GoodDiplomat from becoming negative ever, and keeps the Affects line from firing if there aren't points to lose in GoodDiplomat.


Update: As per my #2 from last post, I'm in the middle of working out a program to sift through the file, pull out all the traits and their corresponding list of antitraits, find all the WhenToTest conditions, and generate comprehensive antitrait-like triggers for all WhenToTest times. It shouldn't be too difficult to get it wrapped up - hopefully inside of a few days. It will probably be several thousand more triggers though. I anticipate it will make the traits txt file very much bigger than it currently is, but don't anticipate a lot of extra overhead in-game, though it's hard to tell exactly how much time is currently spent trigger-checking. I know this is a source of much concern, so I'll keep everyone posted on the results, whenever I get to that point.

[Sarastro]

I would also point out that the code you displayed is not quite right yet: you've allowed an agent with 0 GoodDiplomat pts to still have 1 removed half the time, and then have a chance to gain a BadDiplomat point as well. This means a failed mission could cause a 2-point swing in any diplo with 1 or less GoodDiplomat points, since both triggers will go off - and he could also get a negative GoodDiplomat stat, which is something undefined in game terms as far as I know. The fix is to make the triggers mutually exclusive by testing the first trigger as well. You check for GoodDiplomat > 0 (or >= 1 if you prefer), which then prevents GoodDiplomat from becoming negative ever, and keeps the Affects line from firing if there aren't points to lose in GoodDiplomat.

Yep, the failed / successful mission which should switch the trait from Good- 1 or Bad- 1 to neutral will instead immediately go to the opposite trait. I actually tried the way you suggested above, and several similar triggers which were meant to be safeguards to ensure that the standard mission failed / suceeded script didn't fall foul of the anti-trait bug, and the character correctly returned to neutral. For some reason, however, it didn't work, and the agent didn't start picking up points again on the next successful / failed mission. Since I was a little pressed for time, I simply went for the hotfix of skipping the neutral level, which doesn't make a huge difference to the game imo. Also, it is stable and works, which is a big plus

You are right about the -1 thing though, I'll stick in

Condition not Trait BadDiplomat >= 1

to be safe, but I think that is in effect what it assumes anyway, as I haven't seen anything that would indicate a buildup of negative GoodDiplomat trait points which would have to be worked off to gain GoodDiplomat 1 from the next successful mission. In fact, I'm not sure the game even recognises a trait with negative points, they only seem to work when the trait has points above zero.

Always looking for improvements though, so if you have a working code to get the neutral level working, I'd like to know the solution!

[Kobal2fr]

I just thought of something, and I really, really need to find my old Rome CD's so I can check how things were when they worked : couldn't traits and antitraits coexist in a character ?
I know only the superior one was displayed, minus any levels in the antitrait but -

Say you had a Stoic 4 general (can't remember wether this has a NoGoingBackLevel, and I'm stranded with a 52k connection so let's assume not for the sake of the example). He stops in town, picks up the dreaded Drink. Then moves out. Now, does the general has Stoic 3 or (like I'm fearing right now) Stoic 4 Drink 1 ? Because if it's the latter, then Drink's of course self-updating, so overtime the general would become Stoic 4 Drink 5 = Drink 1.
With the duplicate triggers, that won't be possible because both traits will never appear together, and the self-updating bad traits will never make a good one slowly drop down... Not that it's a huge problem of course, but it would be one more thing lost in an easy-for-CA-to-fix hardcode issue...

@pellik : forgot you last time, I'm sorry.
No, I don't have diff files, I'm afraid I'm not what you'd call a disciplined coder. The readme file is pretty much all I've got to remind myself of what I changed as I plowed through the file without a plan. When I saw a bug, I cross checked then made a change if necessary, then wrote it in the readme - no method, no order, no hierarchy, no nothing. I tried to be as verbose as possible, and to always give the trigger names so that the changes can be found and reverted easily, but... well, you've seen the result :}
I'll try to make .diff files from now on though.

[Foz]

Yep, the failed / successful mission which should switch the trait from Good- 1 or Bad- 1 to neutral will instead immediately go to the opposite trait. I actually tried the way you suggested above, and several similar triggers which were meant to be safeguards to ensure that the standard mission failed / suceeded script didn't fall foul of the anti-trait bug, and the character correctly returned to neutral. For some reason, however, it didn't work, and the agent didn't start picking up points again on the next successful / failed mission. Since I was a little pressed for time, I simply went for the hotfix of skipping the neutral level, which doesn't make a huge difference to the game imo. Also, it is stable and works, which is a big plus

You know it's funny you mention that. I fixed the agent success/failure triggers in the manner I described, and it seemed a little quirky, but I couldn't place exactly how. I haven't even been playing with the new code long enough to say if I have the problem you described for sure... but I aim to find out. If so, then maybe it's an odd quirk of the antitrait code that doesn't allow things to get back to neutral again correctly. Since the agent fix should already bypass it, I recommend removing the Antitrait lines from the Trait defs for all the Good/Bad agent traits, and seeing if it solves the problem.

You are right about the -1 thing though, I'll stick in

Condition not Trait BadDiplomat >= 1

to be safe, but I think that is in effect what it assumes anyway, as I haven't seen anything that would indicate a buildup of negative GoodDiplomat trait points which would have to be worked off to gain GoodDiplomat 1 from the next successful mission. In fact, I'm not sure the game even recognises a trait with negative points, they only seem to work when the trait has points above zero.

Can anyone verify/deny this for me? If the game zeros negative traits or otherwise ignores a -1 to an already 0 trait, it would save me a TON of triggers for all the cases where a trait has multiple antitraits. I could just -1 all the antitraits without worrying about making any negative...

@Kobal: I hope you're wrong about the traits actually coexisting, because there's absolutely no way we can accomplish that from modding the trait file. Well we could make them coexist by ONLY removing the antitrait lines from the file... but it'll make your character actually get both traits, lol. They typically have opposite effects so this might actually make the characters get reasonably correct stats since the good and bad would cancel... but it would make reading a character sheet nearly impossible, and certainly it would be way too hard to figure out what net effects your governor is actually going to have on a settlement. Not to mention just how weird it would be to see people around with completely opposite traits at the same time...

[Sarastro]

Can anyone verify/deny this for me? If the game zeros negative traits or otherwise ignores a -1 to an already 0 trait, it would save me a TON of triggers for all the cases where a trait has multiple antitraits. I could just -1 all the antitraits without worrying about making any negative...

You should be able to test that from MedShell with give_trait?

Just select a diplomat, give_trait this GoodDiplomat 0, give_trait this BadDiplomat 0. Then give_trait this GoodDiplomat -3, then give_trait this GoodDiplomat 1, and see what happens. If he gets GoodDiplomat level 1, then it doesn't seem to take negative levels into account, if it takes GoodDiplomat 4 to get him to positive levels, then it does.

Would do it myself, but don't have an installed copy here atm.

[Kobal2fr]

Won't quite work that way - give_trait gives the absolute value input for the trait. You can type "give_trait this GoodDiplomat 1" for a week, your diplo will still have GoodDiplo 1 :)

What he can do is make up a test trigger along the lines of "WhenToTest EndOfTurn Condition AgentType = Diplomat Affects GoodDiplomat 1 100". Then fire the game, make a brand new diplo, give_trait him GoodDiplo -3 and NaturalDiplomat 0, and then hit end turn four times. If he's got Influence 1, then negative values are accounted for. If he's got 2+, then negatives equal zero.

[Foz]

Thanks for the help Sarastro and Kobal. I have ended up doing something very similar to what Kobal said: I setup one of the spyinit triggers to give -32 to GoodSpy with 100% chance, then on the next line gave 32 to GoodSpy with 100% chance. Fired up the game, loaded a save, queued a ton of spies, and they all came out Master Spy (that's the +5 tier of GoodSpy) instead of the neutral you'd expect if negatives counted. So yeah, the negatives don't do a thing past 0, which is really handy for me.

Update: I got my code for generating the extra triggers up and running tonight. It churned out some 17,000 new triggers, and that was just with 1 copy of each trait/antitrait pairing. I think that may be enough, as there are way more WhenToTest conditions than I originally thought, meaning the trigger for any given trait/antitrait pair should trigger multiple times per turn on each character anyway. You still might see a son turn of age and have oodles of drink and sobriety at the same time, but it should be balanced in a few turns as his triggers go off. Most everything else is completely seamless.

As expected, it didn't affect the game speed noticeably, even between turns, but of course your mileage may vary. I have to tweak it a little still, as I neglected to trip ALL antitraits -1 anytime that the trait and one of them are both positive. This results in trait points cancelling with only one of the antitraits... whichever happened to be listed first in the file. Obviously we can't have that! I also have yet to thoroughly test it to make sure it's really doing what I think it is. If that goes well, then I'll see about releasing it here.

@Kobal2fr: Are you okay with me using your modded file as a basis for further changes? I did so because it has already incorporated the easy bug fixes, but I can go back and make the fixes myself if it will bother you. Also, supposing that you like what I come up with, what would you think of incorporating the fix into your mod? I don't feel the need to have my own mod on account of one fix, and seeing that you already have a bug-blasting mod going, it seems like a good place for my work to be.

[pellik]

@foz: I already have a script that can do what you are trying to do. Its not well written but its more or less human understandable. If you want it let me know.

Speaking of which, I turned my script to generate the traits file already. Sorry Foz that I didn't get on here sooner to save you some work.


I will be able to test my script tomorrow evening. But until then I have an modified character traits file for anyone who wants to give it a try.

export_descr_character_traits.txt

My solution was to generate a series of eight triggers for each trait/antitrait pair. Each trigger checks to see if both the trait and the antitrait are > 0, and then adds -1 to each. So if you have Trait 4 and gain AntiTrait 1, the first trigger will set Trait 3 AntiTrait 0. There are eight of them incase you gain many points of an antitrait. They fire on turn end right now, so weird things may happen in character generation that wont get fixed until the next turn. I'll play with it more later to fix that, however.

Please let me know where the bugs are. I havn't test this at all yet and am unsure if it will even load.

Enjoy.

[pellik]

T
Update: I got my code for generating the extra triggers up and running tonight. It churned out some 17,000 new triggers, and that was just with 1 copy of each trait/antitrait pairing. I think that may be enough, as there are way more WhenToTest conditions than I originally thought, meaning the trigger for any given trait/antitrait pair should trigger multiple times per turn on each character anyway. You still might see a son turn of age and have oodles of drink and sobriety at the same time, but it should be balanced in a few turns as his triggers go off. Most everything else is completely seamless.

You posted this while I was in the process of posting mine. Crazy.
I should have held mine back for testing, but that will take a few days and I wanted feedback now!~. I added a lot fewer triggers for the same effect .

[Foz]

Not a problem Pellik, I've enjoyed doing it. Plus, you've brought out my competitive nature and gotten me to release mine too! But first...

I added a lot fewer triggers for the same effect .

...The same not-quite-right effect, lol! The way I understand it, a trait point should cancel 1 from all of its antitraits, where we implemented it such that each time any antitrait gets cancelled, it eats a point of trait.

Luckily, the fix is easy (at least was for me, how I was mining the file). You just have to trip a -1 for all antitraits any time you find that the trait and any of its antitraits is > 0. As mentioned previously the -1 can't take it below 0, so this ensures that if there are pts to be lost, they all are losing them. So a trait with 4 antitraits still gets its 4 different triggers, it's just that each one will slap a -1 on the trait and all its antitraits. If you wanna see it in action, I think the last one in my modded file had 4 or 5 antitraits.

Speaking of which, I got all my tweaking done on mine, and ran it (yes, it runs for me). It seems to do exactly what I thought it would. It's also generated with CA-copied formatting, so it's readable (though the 17k triggers kinda aren't). I did notice that sometimes erroneus Trait Increased messages trip for agents now, presumably when you gain 1 antitrait point temporarily (which pulls the stat -1), just before the new trigger fixes it back to 0, bumping the stat up again (by removing the minus to it).

More good news: I can mold my generated triggers to a great degree, so let's get some discussion going! Do people prefer Pellik's implementation where massive balancing is done at the end of the turn while using less added triggers, or is it preferable to do it all through the turn which would keep the character sheet more up-to-date typically? What's important, what isn't, and how should it be? If we get some sort of concensus, I'll just generate it to specifications

And oh yeah, can't forget the best part:

export_descr_character_traits.txt

[Sarastro]

Just before we get too carried away here. There is a litmus test trait about the -1 thing: Fertility

Fertility only works in + and - numbers

WifeIsFertile / WifeIsBarren (when working) each test Fertility of a Princess. If she has + Fertility, then she gets the fertile trait, if she has - Fertility she gets Barren.

I've seen WifeIsBarren appearing in my fixed traits file...that suggests that at least some - traits exist. It might be a good idea to work out a) if this is true, b) which traits it applies to, before starting a system which relies on negative numbers not existing.

Traits file is below, it's between 1.0 and 1.1 on my VnV Fixes mod, but it's pretty much all updated to 1.1 apart from some checking. Has all of Kobals fixes as well as many more (unless you've updated yours sir!).

http://www.savefile.com/files/370033

[Foz]

Apples and oranges, Sarastro. Fertility is not a Trait at all, but rather an Attribute. The following code illustrates this:

;------------------------------------------
Trigger family_generalmarries_barren_1
WhenToTest CharacterMarriesPrincess

Condition SpouseAttribute Fertility < 0

Affects WifeIsBarren 1 Chance 100

Attributes appear with the word "Attribute" preceding them in the Condition line, where a trait appears with "Trait" in front of it always. Similarly, Traits are changed with Affects, while Attributes get Effects used on them. I assume this is a tag for the parser, to indicate what kind of variable it is that we're talking about... which coincidentally would only be needed if the different types actually behaved differently.

To elaborate: When you notice your characters having WifeIsBarren, it's not that it's a - trait. It's a bad trait and impacts the character negatively, but it will have positive trait points: it's just that the trigger which generates it checks an Attribute that had a negative value. Similarly, Fertile/Infertile would never be negative since they are always given positive points (note the trigger above) no matter whether the woman's Fertility was positive, negative, or zero.

So I'm gonna keep rolling along with the "Traits can't be negative" thing since I've seen evidence of it from several traits, and none to the contrary. If anyone finds any that don't behave like that though, let me know of course. Until then, use my file!

Also since I just noticed it... no wonder I've never seen a man with WifeIsFertile: it's set only to apply to "admirals," where WifeIsBarren correctly affects "family." I guess only sailors could procreate like rabits back in those days.

[Sarastro]

...and that's why I don't have good ideas at 1:30 in the morning.

Any chance you could release the anti-trait generating program?

[Foz]

Hmm... I will consider doing so. It's a real mess right now though from a usability standpoint for anyone that didn't write it. All C++ code, no UI... so everything is in the hardcode, which you'd have to modify, compile and run, since I'm not dressing up a script intended for a single purpose with a happy interface and lots of fun features and settings. If you're into that, you're welcome to have the cpp file.

If you're not into that, which I'm guessing is most people, then there are other possibilities. I can refine it a little and post the resulting exe, which would then do the following:

1. Read in a traits file.
2. Find all the traits in the file, with their associated antitraits.
3. Generate a new traits file, with antitrait lines stripped out and new antitrait-simulating triggers appended.

This would allow you to generate triggers for any modded traits file, which I'm sure is neat for you modders out there, since removing or adding a single trait or antitrait would otherwise mean you'd have to hunt down all the associated triggers that had been generated and modify them appropriately by hand. Since I wrote a program to do it rather than attempt it by hand, you should be able to guess about how much fun that would be.

The other possibility is similar, but with some inputs. Like, I could have it give simple options like generating for all test times, only for start and end turn, only end turn... and then allow you to choose the number of copies per trigger.

So what it boils down to is, what do you (and anyone else that will use it) want it to do, and how?

[Sarastro]

My main feature would simply be a working generator which created all the extra triggers neccessary to fake the trait/anti-trait scale working correctly.

When the adjustments are done doesn't concern me too much, I'm quite happy with start turn, end turn, and on battle or mission resolution.

Inputs are always good though, my top options would be:

Ability to generate for a single set of trait/anti-trait triggers (ie GoodPrincess/BadPrincess), specified by trait name.

Automatic .bak creation on an operation (probably easiest and most secure way to work with a lot of operations & numerous triggers).

HOWEVER, it is probably worth waiting until the 1.2 patch until taking your time to make such a thing, as there's always a (slim) chance that if the mod community make enough noise, CA might fix what should be a pretty basic and important hardcode error.

[Kobal2fr]

Hey lads, sorry for the lack of reply, my comp did its meltdown trick... again, and I had to go out and buy stuff... Still need some more till it works perfectly again I'm afraid, in the meantime it's unstable as a schyzophrenic, and I'm a liiittle bit afraid of what the MB might do to my filesystems until I'm confident it's patched up, so no medieval for me for at least another few more days... Merry christmas ! :)

the_foz : sure sure, use'em all you want. Saves me the hassle of doing this for myself :)

[alpaca]

Hmm... I will consider doing so. It's a real mess right now though from a usability standpoint for anyone that didn't write it. All C++ code, no UI... so everything is in the hardcode, which you'd have to modify, compile and run, since I'm not dressing up a script intended for a single purpose with a happy interface and lots of fun features and settings. If you're into that, you're welcome to have the cpp file.

If you're not into that, which I'm guessing is most people, then there are other possibilities. I can refine it a little and post the resulting exe, which would then do the following:

1. Read in a traits file.
2. Find all the traits in the file, with their associated antitraits.
3. Generate a new traits file, with antitrait lines stripped out and new antitrait-simulating triggers appended.

This would allow you to generate triggers for any modded traits file, which I'm sure is neat for you modders out there, since removing or adding a single trait or antitrait would otherwise mean you'd have to hunt down all the associated triggers that had been generated and modify them appropriately by hand. Since I wrote a program to do it rather than attempt it by hand, you should be able to guess about how much fun that would be.

The other possibility is similar, but with some inputs. Like, I could have it give simple options like generating for all test times, only for start and end turn, only end turn... and then allow you to choose the number of copies per trigger.

So what it boils down to is, what do you (and anyone else that will use it) want it to do, and how?

Well that's a fairly good idea if it works properly ;)
How does it work actually, do you read in the triggers for the respective traits as objects and edit them?

By the way, I'*d propose using python for small scripts, it's very useful and you don't have to re-compile it (since it's run through an interpreter) every time :)
It's also easily usable in C programs so can be actually given a UI to go with it later if you feel like it (which you probably won't but who knows)

[Foz]

Actually, I don't do a thing with the existing triggers except copy them verbatim to the output file, and copy all the WhenToTest conditions from them to a list to reference later. The real work all comes from the Trait definitions in the top part of the file.

Basically, I pull out the name of the trait and each of its antitraits from each trait definition in the file. I know how to find them because they're preceded by "Trait" and "Antitrait." While doing that, I echo the trait defs to the output file, but without any antitraits. Then after that's done, I pull all the WhenToTest stuff from the triggers while copying them to the file.

The new triggers are generated in the following manner:

-for each WhenToTest condition
--for each trait
---for each antitrait of that trait
----output the trigger for this trait/antitrait pair

The triggers are basically identical, so all the code has to do is stick in the correct trait and antitrait names in the correct places, and the trigger pops out. Oh yeah, I also run a counter to name each trigger incrementally.

So overall, it wasn't bad to get done... and I might be able to fit in a no going back level fix sometime too. I'll have to think on it and see if I can work it out somehow. It's not as simple as it initially seems.

[Afro Thunder]

What I find interesting is that this bug was also present in BI. It was fixed in the Bug Fixer Mod, made by Player1 I believe. I'm not meaning to bash CA or anything, but I just find it curious how this same bug is still present in Medieval II, long after a third-party mod fixed it in BI.