ls612's Traits

Ah, ok. So that won't then cause problems for the modular override mechanism if this is placed behind an MLF loading? I thought <Type> was pretty much the primary ID key of the entry and if you had another of the same <Type> in a module, (along with the force override tag in use) its definitions would then override the original if the module was active according to the MLF control. So what then would happen if the same type of setup as this was also then tagged with the Force override bool? Would that make both the original overridden normally then overridden redundantly when the option is in effect?
 
Thunderbrd said:
Ah, ok. So that won't then cause problems for the modular override mechanism if this is placed behind an MLF loading? I thought <Type> was pretty much the primary ID key of the entry and if you had another of the same <Type> in a module, (along with the force override tag in use) its definitions would then override the original if the module was active according to the MLF control. So what then would happen if the same type of setup as this was also then tagged with the Force override bool? Would that make both the original overridden normally then overridden redundantly when the option is in effect?
Click to expand...
Any modular interaction including force override will only interact with a replacement of the same type and ReplacementID. So Type is the primary ID key while ReplacementID is the secondary one (which is only set for replacements).
 
So, if I'm understanding correctly, once ReplacementID is established, it cannot override the original <Type> without doing so according to the guidelines on that ID then, right?

Ah... wait, I get what you mean by secondary ID. It becomes a whole new identity - like a last name further defines a person. Gotcha. So one could feasibly modularly alter an entry that uses a ReplacementID but would have to do so by correctly calling BOTH and then overriding that... ok. Complex stuff to express but I'm following you now.

Sorry... for all the db work I've done I've never worked with a secondary ID. Fascinating stuff. I love it when I come to understand something that seems complex until understood then it seems horrifyingly simple and I look back and wonder how I didn't get it in the first place. Then I think about how I would try to explain it to someone who doesn't understand it yet and realize how tough it'd be to pick up on the idea. lol
 
Have you changed the hover text in the custom game menu? I think it was totally inappropriate of you to 'describe' this trait option as 'more balanced' - 'more diverse' - 'many more features'. Last I checked it was still described like this.
How about when the new traits are done i'll put the hover text as -
Pick this option is you have more than half a brain and want to have a full game experience, however pick the 'focused traits' option if your the kind of person who values an ash-tray on a motorbike.
Not very nice is it?
 
I am not sure what the difference is between focused traits and non-focused traits.
 
There is the normal default traits and there are traits called 'focused traits' which are the same as default ones generally but have been changed/tweaked by Is612.
 
Sgtslick said:
There is the normal default traits and there are traits called 'focused traits' which are the same as default ones generally but have been changed/tweaked by Is612.
Click to expand...

Some are similar some have had significant reworks. In general they are more diverse.
 
Ah... one thing I wanted to mention here. The last time I looked, you have not created replacements for the Developing Leader trait versions. So if Developing Leaders is on and your option is on, its the default traits that are coming through, not yours. The difference is really only (or really only should be at this point) that the Developing Leader versions would have a 1 after the name and a 1 or -1 in the LinePriority tag (1 for positive -1 for negative traits). It gives us the ability to have a completely different structure for Developing leader base traits as you, yourself suggested.
 
Thunderbrd said:
Ah... one thing I wanted to mention here. The last time I looked, you have not created replacements for the Developing Leader trait versions. So if Developing Leaders is on and your option is on, its the default traits that are coming through, not yours. The difference is really only (or really only should be at this point) that the Developing Leader versions would have a 1 after the name and a 1 or -1 in the LinePriority tag (1 for positive -1 for negative traits). It gives us the ability to have a completely different structure for Developing leader base traits as you, yourself suggested.
Click to expand...

This might be why I haven't noticed the difference. I have been playing with developing leaders.
 
Thunderbrd said:
Ah... one thing I wanted to mention here. The last time I looked, you have not created replacements for the Developing Leader trait versions. So if Developing Leaders is on and your option is on, its the default traits that are coming through, not yours. The difference is really only (or really only should be at this point) that the Developing Leader versions would have a 1 after the name and a 1 or -1 in the LinePriority tag (1 for positive -1 for negative traits). It gives us the ability to have a completely different structure for Developing leader base traits as you, yourself suggested.
Click to expand...

Would just changing all of the existing ones to use LinePriority of 1 work for now?
 
Sorta. Just copy them all into a duplicate set and add the 1 after the name and the 1 or -1 to the line priority. You don't have to change anything else about the second set (yet).
 
The <Type> tag needs to add a 1 at the end of the name also. Thus, TRAIT_AGGRESSIVE is the basic, non-developing leaderhead version while TRAIT_AGGRESSIVE1 is the first selectable trait on the Aggressive promotionline with a line priority of 1 and is thus the Aggressive trait for the Developing Leaderheads side. (the filter is based on the line priority being 0 (only applies to non-Developing Leader games) or other than 0 (applies to only developing leaderhead games) but you still need to differentiate the Types for the sake of having two distinctly differing entries.)
 
Thunderbrd said:
The <Type> tag needs to add a 1 at the end of the name also. Thus, TRAIT_AGGRESSIVE is the basic, non-developing leaderhead version while TRAIT_AGGRESSIVE1 is the first selectable trait on the Aggressive promotionline with a line priority of 1 and is thus the Aggressive trait for the Developing Leaderheads side. (the filter is based on the line priority being 0 (only applies to non-Developing Leader games) or other than 0 (applies to only developing leaderhead games) but you still need to differentiate the Types for the sake of having two distinctly differing entries.)
Click to expand...

OK, thanks. The compatibility issue should be fixed now on the SVN.
 
The Focused Traits does seem to work with Developing Leaders now. However I have the Organized Trait, which says max 5 turns anarchy. I just switched civics and have 10 turns of anarchy.

Screenshot and save attached?
 
SilentConfusion said:
The Focused Traits does seem to work with Developing Leaders now. However I have the Organized Trait, which says max 5 turns anarchy. I just switched civics and have 10 turns of anarchy.

Screenshot and save attached?
Click to expand...

1. That should go in the Bugs/Crashes thread.

2. That is Thunderbrd's tag, so he'll need to look at it.
 
ls612 said:
1. That should go in the Bugs/Crashes thread.

2. That is Thunderbrd's tag, so he'll need to look at it.
Click to expand...

Will do.
 
You must log in or register to reply here.

Similar threads

K
[BTS] Prince Shadow Game: Cyrus of Persia
2 3
Replies
41
Views
2K
jorissimo
jorissimo
U
[BTS] How to edit Leader Traits?
Replies
4
Views
993
Upuauta
U
H
Randomizing leaders traits
Replies
9
Views
708
Humungus
H
D
Future Civ Changing Mechanic Suggestion
Replies
0
Views
377
desk
D
Nizef
TSG 269 Announcement
Replies
18
Views
1K
Megalou
Megalou
Back
Top Bottom