ls612's Traits

[ls612]

No, that is the source of the problem here.
<iMilitaryProductionModifier/> is equivalent to
<iMilitaryProductionModifier></iMilitaryProductionModifier>
which is not a valid entry for an integer and will cause a semi-random value to be read like you see.

OK. I thought that it worked the same as it works for nested tags where <tag/> is valid. I'm pretty sure though I've seen that syntax elsewhere, so all modders might want to be on the lookout for it.

 

[AIAndy]

OK. I thought that it worked the same as it works for nested tags where <tag/> is valid. I'm pretty sure though I've seen that syntax elsewhere, so all modders might want to be on the lookout for it.

That is because the reading code for those tags explicitely looks for children. So it finds the tag, queries for children and then tries to do something with each child but since there are none it just goes on.
And yes, this is a trap that people need to look out for. My recommendation is not to put in any tags that you don't actually use.

 

[Thunderbrd]

That is because the reading code for those tags explicitely looks for children. So it finds the tag, queries for children and then tries to do something with each child but since there are none it just goes on.
And yes, this is a trap that people need to look out for. My recommendation is not to put in any tags that you don't actually use.

The amount of effort it would take to overhaul all existing xml this way makes me shudder. This happens all over the place and that surprises me then, that these random numbers aren't coming in every place that's happening in the xml we already have. Last I looked, a review of just about any infos file will show hundreds of examples of this 'mistake'. I'm not doubting the truth in what you're saying here, as I've seen it work to take out an unused tag to fix that up. I'm just wondering how it doesn't happen in all these (possibly thousands of) cases we already have!

The issue is that many copyNonDefaults implementations use the getter methods to retrieve the value that they copy. That happens during game load when there is no meaningful game object yet.
When I moved the option array construction to when the actual game is started or a savegame is loaded, that kind of acccess during game startup caused crashes. Nowadays there is a check in there that always returns false for any game option which in your case happens to make it return the right value for copying the raw value.

Instead of adding a raw getter like Koshling did in the other case I think simply using the variable directly in the copyNonDefaults is a good solution.

I'm weakly following you here. I believe I've noticed the difference in the two forms your talking about when programming a copyNonDefaults entry. Are you saying that any class that is applied to the option array method must have all its copyNonDefaults entries updated in this way or it's going to cause trouble?

 

[AIAndy]

The amount of effort it would take to overhaul all existing xml this way makes me shudder. This happens all over the place and that surprises me then, that these random numbers aren't coming in every place that's happening in the xml we already have. Last I looked, a review of just about any infos file will show hundreds of examples of this 'mistake'. I'm not doubting the truth in what you're saying here, as I've seen it work to take out an unused tag to fix that up. I'm just wondering how it doesn't happen in all these (possibly thousands of) cases we already have!

The usual case of that is with tags that are not value tags but have children and then it does not hurt much (it might allocate expensive arrays in some cases though).

I'm weakly following you here. I believe I've noticed the difference in the two forms your talking about when programming a copyNonDefaults entry. Are you saying that any class that is applied to the option array method must have all its copyNonDefaults entries updated in this way or it's going to cause trouble?

My option replacement/edit method does not care one way or the other but anything that is put into the usual getter functions has to be aware that copyNonDefaults might be using them (so you should check whenever you add something to the getXXX methods).

 

[Thunderbrd]

My option replacement/edit method does not care one way or the other but anything that is put into the usual getter functions has to be aware that copyNonDefaults might be using them (so you should check whenever you add something to the getXXX methods).

Ah... I get it. That's a very helpful note for the Archetype project too. Thank you for clarifying.

 

[GiuseppeIII]

What are the differences between focused traits and the regular traits. I'm sure it's not that these traits are just more diverse balanced and have more new features than the regular set of traits as the in game description says or these would be the default set of traits. So what I'm really asking for is a pro and cons for using these traits over the existsting one

 

[ls612]

What are the differences between focused traits and the regular traits. I'm sure it's not that these traits are just more diverse balanced and have more new features than the regular set of traits as the in game description says or these would be the default set of traits. So what I'm really asking for is a pro and cons for using these traits over the existsting one

My traits (the Focused ones) have fewer extraneous benefits on each trait, and the core benefits have been diversified. It is basically my balance pass on traits, in addition to what the description says.

 

[DRJ]

I remember when trying focused traits together with no starting traits and developing traits game options I experienced a bug that made the pick a trait menu list look like 3 times the lists of the traits added up underneath

like

industiral
scientific
"protective" looked different than the others
(...)
philosophical
industiral
scientific
"protective" looked different than the others
(...)
philosophical
industiral
scientific
"protective" looked different than the others
...
philosophical

Is this solved?

 

[Thunderbrd]

It should be resolved now thanks to AIAndy's handiwork there yes.

 

[strategyonly]

Was going to "try" your traits out but i get this in the 1st Options, all kinds of, well you tell me, this is all one OPTION??? (attachments are all on ONE option pop-up, for the 1st time??)

Whats going on??

I remember when trying focused traits together with no starting traits and developing traits game options I experienced a bug that made the pick a trait menu list look like 3 times the lists of the traits added up underneath

Is this solved?

Obviously not.

EDIT: Negative traits are the same 2 sets listed in 1 option . . .

 

[Thunderbrd]

hmm...

1, the Protective trait seems to be missing its graphic reference.

2, AIAndy... something is not working correctly regarding the replacement method it would appear. The graphics SO just posted show that both trait sets are being considered available for selection. Don't know if this is just the way I've got my optionlist programmed that should differ now to keep the new method into account properly, but I thought it wouldn't have to as those additional options would not be considered active enough to be referred to by other sections of the code. I've seen a bug like this in the short traits labels seen at gamestart on the leaders too but haven't gone to attempt addressing it yet. Is this an oversight in the code or an oversight in the way ls612 has implemented the option edits?

 

[AIAndy]

hmm...

1, the Protective trait seems to be missing its graphic reference.

2, AIAndy... something is not working correctly regarding the replacement method it would appear. The graphics SO just posted show that both trait sets are being considered available for selection. Don't know if this is just the way I've got my optionlist programmed that should differ now to keep the new method into account properly, but I thought it wouldn't have to as those additional options would not be considered active enough to be referred to by other sections of the code. I've seen a bug like this in the short traits labels seen at gamestart on the leaders too but haven't gone to attempt addressing it yet. Is this an oversight in the code or an oversight in the way ls612 has implemented the option edits?

The replacements are hidden from normal access so only one can be visible to most code. And if they would not be read as replacements, they would instead be read modularly above the normal ones as they share the type ID.
So no, can't get both sets at once.

 

[Thunderbrd]

The replacements are hidden from normal access so only one can be visible to most code. And if they would not be read as replacements, they would instead be read modularly above the normal ones as they share the type ID.
So no, can't get both sets at once.

Well... you say we can't. But we are. Or is what SO posted a display of some other sort of mistake made somewhere? I guess the question I'm asking is what do you think is going wrong here?

 

[AIAndy]

Well... you say we can't. But we are. Or is what SO posted a display of some other sort of mistake made somewhere? I guess the question I'm asking is what do you think is going wrong here?

Meh, both you and ls612 are like "we have no understanding of the replacement system, there is a bug with too many traits, must be it".
What about you think about which two sets of traits are always visible to the code in both trait option settings. Base traits and developing leader traits ring a bell? Then maybe you also remember in which XML tag you hid the selection between those two and which magic value represents the base trait and then check ls612's traits for that tag and find what other value in the base traits there?

 

[strategyonly]

Meh, both you and ls612 are like "we have no understanding of the replacement system, there is a bug with too many traits, must be it".
What about you think about which two sets of traits are always visible to the code in both trait option settings. Base traits and developing leader traits ring a bell? Then maybe you also remember in which XML tag you hid the selection between those two and which magic value represents the base trait and then check ls612's traits for that tag and find what other value in the base traits there?

Looks like anything marked "replacement"

 

[Sgtslick]

Is612 has them as:
<Type>TRAIT_BARBARIC</Type>
<iLinePriority>-1</iLinePriority>

<Type>TRAIT_BARBARIC1</Type>
<iLinePriority>1</iLinePriority>

They should be:
<Type>TRAIT_BARBARIC</Type>
<iLinePriority>0</iLinePriority>

<Type>TRAIT_BARBARIC1</Type>
<iLinePriority>-1</iLinePriority>

Shouldn't they?

Even the positive ones:
<Type>TRAIT_PHILOSOPHICAL</Type>
<iLinePriority>-1</iLinePriority>
<Type>TRAIT_PHILOSOPHICAL1</Type>
<iLinePriority>1</iLinePriority>
Should be:
<Type>TRAIT_PHILOSOPHICAL</Type>
<iLinePriority>0</iLinePriority>

<Type>TRAIT_PHILOSOPHICAL1</Type>
<iLinePriority>1</iLinePriority>

His base traits should be <iLinePriority>0</iLinePriority> not <iLinePriority>-1</iLinePriority> for both positive & negative and the negatives go 0, -1, -2, -3, positives go 0, 1, 2, 3.

 

[ls612]

Meh, both you and ls612 are like "we have no understanding of the replacement system, there is a bug with too many traits, must be it".
What about you think about which two sets of traits are always visible to the code in both trait option settings. Base traits and developing leader traits ring a bell? Then maybe you also remember in which XML tag you hid the selection between those two and which magic value represents the base trait and then check ls612's traits for that tag and find what other value in the base traits there?

Ah, I need to put an option restriction on the Developing Leaderheads trait to only be availabe with Developing Leaderheads then, and make the normal ones only with my option but NOT developing Leaderheads, correct?

 

[AIAndy]

Is612 has them as:
<Type>TRAIT_BARBARIC</Type>
<iLinePriority>-1</iLinePriority>

<Type>TRAIT_BARBARIC1</Type>
<iLinePriority>1</iLinePriority>

They should be:
<Type>TRAIT_BARBARIC</Type>
<iLinePriority>0</iLinePriority>

<Type>TRAIT_BARBARIC1</Type>
<iLinePriority>-1</iLinePriority>

Shouldn't they?

Even the positive ones:
<Type>TRAIT_PHILOSOPHICAL</Type>
<iLinePriority>-1</iLinePriority>
<Type>TRAIT_PHILOSOPHICAL1</Type>
<iLinePriority>1</iLinePriority>
Should be:
<Type>TRAIT_PHILOSOPHICAL</Type>
<iLinePriority>0</iLinePriority>

<Type>TRAIT_PHILOSOPHICAL1</Type>
<iLinePriority>1</iLinePriority>

His base traits should be <iLinePriority>0</iLinePriority> not <iLinePriority>-1</iLinePriority> for both positive & negative and the negatives go 0, -1, -2, -3, positives go 0, 1, 2, 3.

Bingo. Only line priority 0 is interpreted as base trait and will cause it to be ignored in the selection dialog.

 

[Thunderbrd]

Meh, both you and ls612 are like "we have no understanding of the replacement system, there is a bug with too many traits, must be it".
What about you think about which two sets of traits are always visible to the code in both trait option settings. Base traits and developing leader traits ring a bell? Then maybe you also remember in which XML tag you hid the selection between those two and which magic value represents the base trait and then check ls612's traits for that tag and find what other value in the base traits there?

Don't get me wrong... I wasn't trying to be accusing of your system but simply asking for theories. You provided one and I believe its correct. Thank you I'm surprised I hadn't considered that right away myself.

I'd not taken time to look at ls612's traits but if I had I would've quickly spotted the following, which I had not considered wasn't understood enough to have been avoided.

BTW: earlier on the forum I was saying I thought I had a bug in my crime accumulation but I did not realize how penalizing the Nomadic trait was on crime... understanding that now I do believe there was no bug. Just me being blind to my own modifiers. Sorry for the erroneous bug claim there too.

Is612 has them as:
<Type>TRAIT_BARBARIC</Type>
<iLinePriority>-1</iLinePriority>

<Type>TRAIT_BARBARIC1</Type>
<iLinePriority>1</iLinePriority>

They should be:
<Type>TRAIT_BARBARIC</Type>
<iLinePriority>0</iLinePriority>

<Type>TRAIT_BARBARIC1</Type>
<iLinePriority>-1</iLinePriority>

Shouldn't they?

Even the positive ones:
<Type>TRAIT_PHILOSOPHICAL</Type>
<iLinePriority>-1</iLinePriority>
<Type>TRAIT_PHILOSOPHICAL1</Type>
<iLinePriority>1</iLinePriority>
Should be:
<Type>TRAIT_PHILOSOPHICAL</Type>
<iLinePriority>0</iLinePriority>

<Type>TRAIT_PHILOSOPHICAL1</Type>
<iLinePriority>1</iLinePriority>

His base traits should be <iLinePriority>0</iLinePriority> not <iLinePriority>-1</iLinePriority> for both positive & negative and the negatives go 0, -1, -2, -3, positives go 0, 1, 2, 3.

Absolutely correct. Thank you SGTSlick!

Ah, I need to put an option restriction on the Developing Leaderheads trait to only be availabe with Developing Leaderheads then, and make the normal ones only with my option but NOT developing Leaderheads, correct?

You need to have a set of option edits for each of the sets of the core. iLinePriority 0 traits are the non-developing Leader traits. iLinePriority negative values are the negative traits in a developing leader game (and they count down for further tiers, thus a negative trait lvl 1 is -1, lvl 2 is -2 etc...) And iLinePriority positive values are the positive traits in a developing leaders game.

If you make an option set like you have, you must accurately replace the 0s, -1s and beyond for more tiers and 1 and ups for more tiers. You obviously have the replacement part down otherwise.

 

[ls612]

The traits should be fixed now on the SVN, I changed the linepriorities and more clearly delineated what the option edit replacement conditions are in the XML, so hopefully it should work now.