New Civics Screen

[Nightinggale]

I think tech screen doesn't belong in the civic screen as what you are asking is mainly a graphical change. Still it wouldn't be bad to look into later.

 

[Kailric]

While the Civics/Techs system is undergoing renovation, one feature I would most love to see brought back from the original Inventor modcomp is that Techs can actually belong to several Categories (such as Military, Cultural, Religious, Industrial, Economic etc). There is still the tag <InventionCategory> in M:C, but it's not really used since everything has to have MEDIEVAL_TECH in this tag. If belonging to categories were brought back, this could be used to let leaders/techs/civics grant a discount to research in certain tech categories by a TraitInfos tag; and maybe could even allow easier viewing of the tree by using one tab per category like the Founding Fathers screen does. What do you think?

I'll put this on todo list after the Civics update. Having tabs for the categories would be cool, but not necessary atm so that would be a later addition as I am not a fast python coder.

 

[Nightinggale]

I'll put this on todo list after the Civics update. Having tabs for the categories would be cool, but not necessary atm so that would be a later addition as I am not a fast python coder.

Domestic advisor has a state machine controlled by buttons. Considering I wrote that one, I might be able to write a state machine for tech screen fairly fast using experience/code I gained with domestic advisor. I haven't looked at the tech screen code yet though.

 

[Kailric]

Domestic advisor has a state machine controlled by buttons. Considering I wrote that one, I might be able to write a state machine for tech screen fairly fast using experience/code I gained with domestic advisor. I haven't looked at the tech screen code yet though.

Let me know if you do, The Tech Screen code is pretty simple. The Tabs should worked like the Founding Father tabs. If I was doing it I would probably hihack the Founding Father code and add Techs to the tabs instead of FFs, but that's just me, I hijack stuff. Very little original code here

 

[Kailric]

The Civics Screen is getting close to its first release version, I guess you could say that. I have one huge task ahead and that is getting the AI to work the new Civics. I am looking over the code in Civ4 and it doesn't look all that complicated however I'll have to heavily edit the AI_civicValue() for M:C. Huge task looms ahead, but I shall over come

 

[Kailric]

The two new pushes to CivicScreen branch are:

1. First Addition of AI changing Civics. They are very primitive at the moment and I will need to add adjustments related to M:C as most of the Civ4 AI was not relevant.

2. Set CIVICOPTION_INVENTIONS to -1 in the DLL. Removed CIVICOPTION_INVENTIONS from the XML Civic Files. Techs, Censures and anything that is not a Civic should put a NONE for CivicOption Type.

Example:

<CivicOptionType>NONE</CivicOptionType>
<Type>MEDIEVAL_TECH_STIRRUP</Type>
<Description>Stirrup</Description>

Also with 2..
Removed Techs from displaying in the CvCongressAdvisor.py
Removed Civics from appearing in the CvRevolutionAdvisor.py
Added AI selected Civics to be viewable in the Foreign Advisor screen under "Active" tab, if you have contact with them.

Besides the AI I still need to have Button Art for each of the new Civics. I have filled in a bunch of the effects, but still there are somethings lacking. Plus Tech requirements need to be added.

I also moved the Civics closer to the beginning in the file CIV4CivicInfos.xml so that Civic code would not have to cycle through all the Techs to get to Civics. I will eventually move them to the very top but I still need the Tech Category MEDIEVAL_TECH to be the second Tech. Tech Categories need to be added as globals in the DLL so their placement does not matter.

 

[Nightinggale]

I also moved the Civics closer to the beginning in the file CIV4CivicInfos.xml so that Civic code would not have to cycle through all the Techs to get to Civics. I will eventually move them to the very top but I still need the Tech Category MEDIEVAL_TECH to be the second Tech. Tech Categories need to be added as globals in the DLL so their placement does not matter.

Add a variable to CvGlobals telling the index of the first civic, which isn't NONE type. When looping civics, get this index from GC rather than loop though irreverent techs each time. Yields use this with cargo and virtual yields. It's possible to just loop though one of the types if you want that. Currently I think all yield loops starts with 0, but the concept is there and the end is not always the same.

Alternatively they could be first and then the loop can break if the civic type is NONE. Having techs loop though civics is likely less of a performance issue than having civics looping techs, though I don't think either will be slow. It depends on when and how you loop.

 

[Kailric]

Add a variable to CvGlobals telling the index of the first civic, which isn't NONE type. When looping civics, get this index from GC rather than loop though irreverent techs each time. Yields use this with cargo and virtual yields. It's possible to just loop though one of the types if you want that. Currently I think all yield loops starts with 0, but the concept is there and the end is not always the same.

Alternatively they could be first and then the loop can break if the civic type is NONE. Having techs loop though civics is likely less of a performance issue than having civics looping techs, though I don't think either will be slow. It depends on when and how you loop.

Thanks for the info. Yeah, I wasn't sure about performance it just doesn't seem right having the Civics out in the middle of all those techs. Plus when I was debugging I was having to count all the way to 50+ times just to figure out what civic I was looking in the matrix. I'm sure you have a script for that, but I am script ignorant atm

 

[Trade Winds]

2. Set CIVICOPTION_INVENTIONS to -1 in the DLL. Removed CIVICOPTION_INVENTIONS from the XML Civic Files. Techs, Censures and anything that is not a Civic should put a NONE for CivicOption Type.

Example:

<CivicOptionType>NONE</CivicOptionType>
<Type>MEDIEVAL_TECH_STIRRUP</Type>
<Description>Stirrup</Description>

Pushed to CIV4CivicInfos.xml

 

[Lib.Spi't]

I don't think it will work for WH yet as we need, the updated .dll that includes all the civic work

 

[Kailric]

I don't think it will work for WH yet as we need, the updated .dll that includes all the civic work

This is true. All the work I am doing on Civic Effects I am pushing to the CivicScreen branch. This will eventually be merged with the other branches so that "push" will eventually be needed but at the moment it would cause errors.

 

[Lib.Spi't]

yep that was what I thought, at least it will be ready when the time comes, I just have to remember to be careful with my merging till then.

I am however very excited about the civics

 

[Nightinggale]

I just had a new idea for layout. GC should have an array of CivicOptionTypes. All values should be set to the number of civics by default. On XML load (or just after it), all civics are looped and it will do the following:

• assert if current CivicOptionType is lower than the previous one
• store current index if it is lower than the one stored in the array for the civic type in question

If we add one more number to the array and set it to the number of civics, then we can loop all civics of a specific option type by looping from array[CivicOptionType] to array[CivicOptionType + 1]. If we want to loop all non-tech civics, then we just loop from array[0] to num civics.

The assert ensures that the civics are ordered correctly in the XML for this approach to work.

This approach has just one flaw. If a CivicOptionType is defined in XML, but not used, then the array will not be set up correctly. Presumably we can fix that with an assert to detect if this happens.

 

[Nightinggale]

I finally managed to move growth unit into CvCivicInfo and everything looks fine right until I notice a comment. I get a nagging suspicion and test something else and sure enough clear speciality now clears units to serfs

The problem is that serfs are now the default growth unit on game start and native braves are now UNITCLASS_SERF instead of UNITCLASS_COLONIST. The problem is that clear speciality converts to a default growth unit, which is now UNITCLASS_SERF. Changing clear code into using the current growth unit (civic aware) would at least be an improvement as it will at least switch to UNITCLASS_COLONIST when you invent guilds.

The problem is that I would like to always clear to UNITCLASS_COLONIST even without guilds as serfs gain production penalties. That isn't possible with the new design as UNITCLASS_COLONIST no longer has a special meaning. Making a new hardcoded clear unit will not work either as natives no longer have a UNITCLASS_COLONIST.

The only solution I can think of is to add default clear unit to CivilizationInfo. Editing all civilizations is a lot of work though and I came up with an idea for that (even before I ran into this problem). I want to make a new XML with civilization classes. Each civilization will then gain a class.

On civ info load, the code will load the class info and then overwrite with whatever non-default the specific civ has. Say we have a civ with class CIVILIZATION_CLASS_NATIVE, it will use class info to set disallowed buildings and units for natives. We can then overwrite this for the civ in question if we want. Say we want the civ to have native buildings and units, except there is one native buildingClass, which should be a different building. The civ info will then not contain unit info and only one building info.

This way we can quickly set up rules for natives, kings and Europeans. However Christians and Muslims should likely be two classes even if they are in the same group (out of those 3) meaning we will presumably end up with a number of groups.

If we add civilization classes, then I will not mess with clear unit class right now as it will be much easier later.

What do we do now?
Should I make civilization classes and add a clear unit to it later or should we try to rethink how growth units work?

 

[Lib.Spi't]

That civilization class system sound interesting, especially if the classes are defined and modified in xml, that would give me the ability to do things like have continent specific natives and such.

I would also love to see the growth units moved to xml, the specialist ones, like squires being made with grain, etc. I want to have at least 3 specialist growth units in my game (luxury, rich and tinned food) plus the ability to change the base food unit as well (although that already happens right? like the serfs change to peasants). So something that allows you to define:

Yield Type
Yield Amount
Growth Unit Produced

Would be awesome...

 

[Nightinggale]

Right now the growth code is pretty hardcoded into having just two types. Adding a third means a lot of code duplication or a redesign. I have the serf->pesaant working locally and I'm finishing up on doing the same for luxury food (NO_UNIT->UNIT_PAGE). The great part of the new system is that you can have chains of upgrades, not just between two. For instance you can have Cottar->Serf->Peasant if that is what you like.

The rule for picking growth unit is actually quite simple. There is a default class and some civics enables more classes for growth units. The one you get will then be the unit with the highest ID, which belongs to one of those classes. This mean the order of CvUnitInfos matters as it will pick the last one in that list if there are multiple allowed by civics. In other words: the controllers in XML for growth units are:
-new default growth unit tag in civics
-order of units in XML
Everything else should be automatic.

 

[Kailric]

What do we do now?
Should I make civilization classes and add a clear unit to it later or should we try to rethink how growth units work?

Well, I would suggest we add a defaultClearSpecialtyUnit to Civilizations.xml as you say, and separate the two systems. Or, just add a GlobalDefineAlt for it just like the old DefaultPopUnit code.

We could do both, were it checks the Civilization first if someone wants to code in something different. As far as M:C goes all we need is a GlobalDefine set to UNITCLASS_COLONIST. Specialist are considered by definition none serfs, so yeah, converting them to gimp serfs is just not right. I don't see a use for having a Civic option to ever change this as the whole purpose is to simply clear the unit of it's specialty so that it can become a different specialist. Thinking about it, even an option in Civilizations.xml may never get used other than default.

While the CivilizationClass could come into handiness, I'll leave it up to you if you want to do that or not.

 

[Nightinggale]

I started writing why adding it to GlobalDefineAlt wouldn't work and while doing so I finally figured out how to do this

DefaultPopUnit goes back to being UNITCLASS_COLONIST. This will then be the clear speciality unit and will never change.

I will then add something new to GlobalDefineAlt, which is default growth unit. This will be set to UNITCLASS_SERF (I renamed that one btw).

Now when setting the cache, it starts by assigning the default value to UNITCLASS_SERF. If UNITCLASS_SERF for current civ results in NO_UNIT, it will use UNITCLASS_COLONIST as backup. The result will be serfs for civs with serfs and colonists for all other civs (mainly natives). After that init setup all civs should have a growth unit to start with and the civics will be looped to maybe update to a better one.

Just my luck that I already committed the change. I didn't push it and removing a non-pushed commit isn't that tricky. The tricky part is that I want to reuse half of it. I will likely have to make a local branch for that and do branch magic to easily preserve as many of the changes as possible.

This at first glance simple task have taken forever by now

 

[Kailric]

This at first glance simple task have taken forever by now

Well, like we say in Texas, sounds like you got it by the horns now!

 

[orlanth]

The tricky part is that I want to reuse half of it. I will likely have to make a local branch for that and do branch magic to easily preserve as many of the changes as possible

yeaaa Branch Magic! Lets turn that ordinary Scrape into a Buck crazed MAGIC Scrape

hmm I'm thinking of how to use this in 2071 (the growth unit feature, not the Buck Licking Gel.) If there are slots for a "regular" and "elite" growth unit, maybe I could have default growth unit start with Proletarians and later become Free Colonists with a civic or tech. Is it still possible to set a default Elite/Knight growth unitclass and yield based on a tech/civic? That will be good for type of having different types of Elites emerge based on the type of society you design. You could also choose some governmental civics that boost all Elites while penalizing Proletarians, or vice versa.