ls612's Traits

Just a note to clarify... any entries not included in the option edits set will default to the original core set. Those WILL still be included unless the NotOnGameOption tag is set on that entry to the option using the alternative set. I believe currently this may apply to Barbaric in ls612's set.
 
Just going through it:
I see ALOT of :mad: and i mean ALOT?? (Also see screenie??) No :gold: from the git go? Just asking questions is all :confused:

EDIT: OK Oral tradition took care of the :mad: in city?

I didn't change as far as I know the :mad: from City Size in these traits. :confused:
 
What I want to do is have virtually no :mad: and :yuck: on the lvl 1 traits (prehistoric & probably ancient) when developing leaders gets finished. Instead have slightly different penalties that aren't as crippling in the early stages of the game. Whereas later in the game, :mad: isn't so bad and can be introduced then - at say lvl 2 of the trait and/or 3. Having different benefits/penalties that can reflect the different eras (in terms of balance) is one of the main beneftis of developing leaders imo. Thats why I dislike the idea of having the elements within each trait simply get worse/better - I think they should change to reflect the fact that in different eras certain things have more of an impact.
 
Both your traits and the normal traits lack their pedia entries at the moment since no one bothered to move the Civilopedia tag entries from NewConceptInfos to TraitInfos after I made the traits work like other pedia screens.
The trait entries in NewConceptInfos can be deleted afterwards.
 
Both your traits and the normal traits lack their pedia entries at the moment since no one bothered to move the Civilopedia tag entries from NewConceptInfos to TraitInfos after I made the traits work like other pedia screens.
The trait entries in NewConceptInfos can be deleted afterwards.

Thunderbrd said that there were known issues with Option edits and the pedia, could that be it? If so that should be looked into before release, if not I'll start looking for tags to transfer.
 
Thunderbrd said that there were known issues with Option edits and the pedia, could that be it? If so that should be looked into before release, if not I'll start looking for tags to transfer.
No, it was part of my pedia changes/fixes last month to remove that old workaround that had the trait pedia info as separate NewConceptInfos entries instead of supplying it directly in the trait infos like with other things.
The NewConceptInfos trait entries are ignored now so the info needs to be moved to the traits where it belongs.
 
No, it was part of my pedia changes/fixes last month to remove that old workaround that had the trait pedia info as separate NewConceptInfos entries instead of supplying it directly in the trait infos like with other things.
The NewConceptInfos trait entries are ignored now so the info needs to be moved to the traits where it belongs.

Wait, I'm confused. In the traits I have this

Code:
		<TraitInfo>
			<Type>TRAIT_PHILOSOPHICAL</Type>
			<ReplacementID>TRAIT_LS612_PHILOSOPHICAL</ReplacementID>
			<Description>TXT_KEY_TRAIT_PHILOSOPHICAL</Description>

for the traits, and as far as I know the TXT tag there is valid because I copy-pasted it from the core traits. Is there some other TXT tag that needs to be added somewhere, or are you simply asking for me to delete the old NewConcepts page?
 
Wait, I'm confused. In the traits I have this

Code:
		<TraitInfo>
			<Type>TRAIT_PHILOSOPHICAL</Type>
			<ReplacementID>TRAIT_LS612_PHILOSOPHICAL</ReplacementID>
			<Description>TXT_KEY_TRAIT_PHILOSOPHICAL</Description>

for the traits, and as far as I know the TXT tag there is valid because I copy-pasted it from the core traits. Is there some other TXT tag that needs to be added somewhere, or are you simply asking for me to delete the old NewConcepts page?
That is the description, not the pedia text.
All info classes have the Civilopedia tag for that (and only for traits the Civilopedia tag on a special NewConcepts page was used instead).
 
Both your traits and the normal traits lack their pedia entries at the moment since no one bothered to move the Civilopedia tag entries from NewConceptInfos to TraitInfos after I made the traits work like other pedia screens.
The trait entries in NewConceptInfos can be deleted afterwards.

Ah... was not aware this was necessary.

However, something posted above brings up an interesting question...

It appears that the option edit primary indicator tag: <ReplacementID> needs to be set in the original trait entry. Then I suppose there's a tag for the option upon which the edit takes place. This brings up a question: What do we do when we have a second option edit that operates under a different option? Can we list multiple ReplacementIDs?
 
Ah... was not aware this was necessary.

However, something posted above brings up an interesting question...

It appears that the option edit primary indicator tag: <ReplacementID> needs to be set in the original trait entry. Then I suppose there's a tag for the option upon which the edit takes place. This brings up a question: What do we do when we have a second option edit that operates under a different option? Can we list multiple ReplacementIDs?
What? No, ReplacementID should only be set on info entries that are actual replacements, not on the original entry. It identifies this specific replacement for modular and multi pass read purposes.
There can be any number of replacements of the same type if they have different ReplacementID. The one that is actually active at a specific time is determined by the ReplacementCondition. If more than one ReplacementCondition evaluates to true at the same time, then the first one wins.
 
So, then, the actual original label should not be present here right?
Code:
		<TraitInfo>
			<Type>TRAIT_PHILOSOPHICAL</Type>
			<ReplacementID>TRAIT_LS612_PHILOSOPHICAL</ReplacementID>
			<Description>TXT_KEY_TRAIT_PHILOSOPHICAL</Description>
From what you just said, TRAIT_PHILOSOPHICAL and TRAIT_LS612_PHILOSOPHICAL are both in the wrong sections and should swap places. I just wanted to make this clear.
 
Why is it that when you get sufficient culture for a new trait level, the 'good' part allows you to either add a new good trait, OR remove an existing 'bad' one; but the 'bad' part only lets you add a new 'bad' one (why not give it the option to remove a 'good' one so it's symmetric)?
 
Why is it that when you get sufficient culture for a new trait level, the 'good' part allows you to either add a new good trait, OR remove an existing 'bad' one; but the 'bad' part only lets you add a new 'bad' one (why not give it the option to remove a 'good' one so it's symmetric)?

Now that sounds actually better. But won't that require some coding?
 
Now that sounds actually better. But won't that require some coding?

Yes, but presumably VERY, VERY similar to the code that is already there that allows you to remove a bad trait instead of adding a good one, so shouldn't b hard. No idea where this code is mind you - I assume it's in the Python somewhere?
 
Yes... could easily be done. I had considered doing so actually. Wasn't sure if anyone would feel this was 'the way to go'.

BTW: There is no python in use in the Developing Leader systems. If you wish to review the code, Koshling, you'll find it interesting I'm sure. Maybe you'll see some things to point out there too. Who knows. But its hub is pretty much CvPlayer::doPromoteLeader() All roads lead to or from the system there.

I can put making that change 'on the list'. Would take a little adaptation for the AI too but there's some 'on the list' stuff for that already.
 
Why is it that when you get sufficient culture for a new trait level, the 'good' part allows you to either add a new good trait, OR remove an existing 'bad' one; but the 'bad' part only lets you add a new 'bad' one (why not give it the option to remove a 'good' one so it's symmetric)?

I second this idea. But not until after the freeze. ;)
 
So, then, the actual original label should not be present here right?

From what you just said, TRAIT_PHILOSOPHICAL and TRAIT_LS612_PHILOSOPHICAL are both in the wrong sections and should swap places. I just wanted to make this clear.
No, that is not what I said. The code is correct. With Type you specify the normal ID that the replacement will have as well (so in a way you specify what you want to replace here). ReplacementID on the other hand is a special ID for the replacement to recognize it amongst several replacements of the same type.
 
Back
Top Bottom