New Trait

komisch1

Chieftain
Joined
Aug 3, 2008
Messages
37
Im trieing to do a Helvetia/Switzerland Civilization Mod and thought i could add "Direct Democracy" as a Trait, which enables Converting Production into Happiness, the same way as Production -> Wealth/Science. Would be like 10/15/20 ? Production into 1 Happiness.

Is that even possible to do that in xml?

What ive done so far (separated CI5Traits.xml)
<GameData>
<Traits>
<Row>
<Type>TRAIT_DIRECT_DEMOCRACY</Type>
<Description>TXT_KEY_TRAIT_DIRECT_DEMOCRACY</Description>
<ShortDescription>TXT_KEY_TRAIT_DIRECT_DEMOCRACY_SHORT</ShortDescription>
</Row>
</Traits>
AND NOW?



</GameData>

Sorry im an absolute noob in modding so...

THX a lot in previous
 
you can't do that in XML only, it will also require some LUA coding.
 
wow..would be a whole new language to learn for me...way above my abilities xD
guess i need to find a more simple trait...exept someone can do it for me if it isnt too much....
 
guess i need to find a more simple trait...

Rule #1 of XML modding: if it's not explicitly allowed within the existing tables, you can't do it. It doesn't matter how easy you think it should be, or how close to an existing one it seems (like your proposed trait); if it's not already there AND functional, it's just not possible.

This is especially limiting for Traits and Projects, most of whose variables are hard-coded flags instead of adjustable values. You can sometimes mix and match a few bits and pieces to get something distinct (especially the ones involving custom promotions), but a lot of the trait entries are absolute on/off values. Some are in between; you can adjust how much Culture the Aztecs get from each kill or how many Culture the French get each turn, but you can't make a trait that triggers in the same ways but gives gold or research instead of culture.

Rule #2 of XML modding is that just because there IS a table entry doesn't mean it actually works. A lot of the variables in the existing XML tables are remnants from Civ4 (and therefore completely nonfunctional) or were part of early Civ5 designs and were never really removed (like the Religious flag for buildings).

So even if you DO find something that seems to be what you want, you can't be sure it'll actually do anything unless something in the existing game is already using that particular variable/table/schema.
 
oh ok...this clarifies a lot for me...and will make my trait even more simple xD
thx for the advice
 
These two rules of XML modding are very important. Many people think the XML tags are directly telling the game what to do. This isn't true. They are just database entries, and the C++ code in the DLL (the source code of the DLL hasn't been released yet, but the DLL itself exists) reads them and gives them actual game effects. So if something is not programmed in C++, it won't work as an XML tag (you can sometimes give them some effects using LUA, but it has limited capabilities). It applies also to some existing XML tags, which are leftovers from Civ4, or early Civ5 concepts - if the code that interprets them doesn't exist, it won't work.
 
It applies also to some existing XML tags, which are leftovers from Civ4, or early Civ5 concepts - if the code that interprets them doesn't exist, it won't work.

The bright side of this problem is that if you decide to fix the problem yourself and program some Lua code to mimic those old Civ4 functions, there's a ready-made variable to use for them already in the tables. For instance, my mod adds working nuke interception through Lua; while I could have created new table entries to control the probabilities, it was just easier to use the existing <NukeInterception> tags to store the probabilities for each project. Besides just being easy to use, it means that if the devs were to ever actually add nuke interception in an expansion or DLC, I'd be able to remove my own logic with minimal impact.

But yes, reasonably speaking those nonfunctional stubs are just traps for first-time modders to fall into. You see a function/stub that sounds promising, only to have it do nothing. Some tables are worse than others for this; the promotion table, for instance, has a bunch of variables associated with ignoring terrain movement costs, some of which work and some of which don't. It's very aggravating.
 
ok went through the CIV5Traits.xml from the game and tried to match the follwing tarit together, but i didnt really figured out how to use those diffrent trait schemas. sure its wrong but could this be working?

<GameData>
<Traits>
<Row>
<Type>TRAIT_THE_RECIPE_OF_WEALTH</Type>
<Description>TXT_KEY_TRAIT_THE_RECIPE_OF_WEALTH</Description>
<ShortDescription>TXT_KEY_TRAIT_THE_RECIPE_OF_WEALTH_SHORT</ShortDescription>
</Row>
</Traits>
<Trait_NoHillsImprovementMaintenance>
<Row>
<TraitType>TRAIT_THE_RECIPE_OF_WEALTH</TraitType>
<NoHillsImprovementMaintenance>true</NoHillsImprovementMaintenance>
</Row>
</Trait_NoHillsImprovementMaintenance>
<Trait_TradeRouteChange>
<Row>
<TraitType>TRAIT_THE_RECIPE_OF_WEALTH</TraitType>
<TradeRouteChange>3</TradeRouteChange>
</Row>
</Trait_TradeRouteChange>


</GameData>
 
Back
Top Bottom