Current and Future Developments

[Nightinggale]

I managed to get the first group working in CivicInfo. It's doesn't look like much and there is no change ingame (luckily). However the start is always the hardest.

I encountered a severe problem. Whenever I changed just a tiny bit, there were an XML file full of data, which needed a new layout. Most of my work so far have been to make a script to deal with that problem. Now we can say "put variable X in group Y" and it will do so. Such requests will have to come in order meaning the script only works if it starts over every time. Not perfect, but good enough considering it will just have to do until everything have been converted to the new format.

The rest of civic organizing seems like simple bookkeeping now. Make groups, name them well and add variables to those. No real coding and no designing.

I have been thinking on a final design. I want multiple XML files for civics. They all end up in the same vector and are all based on the same schema, but even if that is the case, they will not be treated identically. The XML reading code is to be aware of which file it reads from and it can set certain data accordingly. For instance it should automatically disable tech tree display for everything not written in the invention file.

Not only will this ensure that techs will not be placed in traits by accident (and still work ingame), it will also ensure that no group is stored in multiple pieces. This can be exploited to loop just inventions when drawing the tech tree and similar.

Feel free to look into civic_rewrite and provide feedback if you like. However do not commit changes to CivicInfos.xml or you will screw my newly designed script

 

[Kailric]

However do not commit changes to CivicInfos.xml or you will screw my newly designed script

This totally messes with my just now posted plans. I don't think I actually have to add anything to the schema of Civics, but did need to makes some changes to test things. I can always revert the file back to its current state before pulling your changes though. Most of the work I need to do is just finishing my required Yield for Civics (Decrees) in the dll.

 

[Nightinggale]

This totally messes with my just now posted plans. I don't think I actually have to add anything to the schema of Civics, but did need to makes some changes to test things. I can always revert the file back to its current state before pulling your changes though. Most of the work I need to do is just finishing my required Yield for Civics (Decrees) in the dll.

You are presumably working in AI_Trader, which gives a higher degree of freedom. It will still clash when we merge though.

I think I will change develop to be aware of the split in the cpp files. That way we will not have huge problems if you develop civic code like that based on develop. However develop just ruined savegame compatibility (unlike AI_Trader)

 

[Kailric]

I am updating my todo list...

-Add Gold to Civic Upkeeps
-Finish AI Traders
-Foreign Trade Post upgrades
-adjust Vassals listed in Trade Routes
-Finish AI connecting cities with roads
-Add Kings Forest
-Generic code for TradeScreens(one Python file)
-Add new Trade Screens
-Vassal needs more gold
-Adjust AIs Production AI
-AI needs better gold spending functions
-Dignitaries give Tax collection bonuses
-Test Economy
-Diversify Native Teach classes
-Adjust AIs desire for Luxury Food
-Make note that Fealty renamed to Administration
-Strongholds autokill feature adjusted
-Animal dens and Bonuses spawn Animals

 

[Nightinggale]

I have reduced my goal to just finish merging traits and FF into civics. Since I'm cleaning up the code at the same time and not just blindly copy paste into a mess, it will take longer than originally planned.

Also we have to remember to make a release candidate branch and make people play that one for a few weeks to look for bugs.

 

[Kailric]

That is going to be an awesome improvement to the XML. It will be so much easier with so many options to go wild with. I really want to get the economy part where it is fun, challenging, interesting, and manageable before any more releases so I'm working on all aspects of that.

 

[Nightinggale]

While looking through the DLL code for civics and their effects, I have uncovered some places where the code loops the civics even though CvPlayer has the answer cached. Naturally I will fix stuff like that as I go along.

I have uncovered something else. AllowsBuildTypesTerrain. It's a civic setting, which allows you to enable building improvements on certain terrain, like it can unlock building in desert or swamp. I don't like it as it is an all or nothing setting. Imagine being allowed to build hunting camps and mines on grassland, but you need a certain civic to unlock mining in tundra. With this setting, you can't hunt in tundra before you are allowed to mine there as well. That's not ideal. Also the current implementation of this concept is even a bit flawed. Nothing major, but it should be looked into if we keep it.

I'm thinking of changing it into needing the XML settings:

• ImprovementType
• Terrain
• iChange

That will allow unlocking one improvement, but not the other. Naturally as it is a list, it can repeat those 3 fields over and over for the same civic and that way unlock multiple improvements on the same terrain or multiple terrains for a single improvement.

I can do something similar for routes as well. That will allow inventing a fast route for grassland while it takes a later invention to unlock it for swamps as well.

Now the big question is if this is something, which will be used. I can make a clean stable and fast (cached) implementation of this, but if we are not going to use it anyway, I might as well just disable the current code and move on. The current code is not used in XML, meaning we will not see a gameplay change of just disabling this feature.

What do you say? Is this something, which should be coded?

 

[Lib.Spi't]

It could certainly have implementations in WHM.

Railroad over hills or mountains.

Pioneering new continent terrains etc.

 

[Nightinggale]

Railroad over hills or mountains.

You are making this complicated

Hills and peaks are PlotTypes, not terrain. You do make a good point though as enabling based on PlotTypes could be interesting too.

Having PlotType, Terrain and Route in the same setting will surely unlock lots of potential XML setups, but it would also be a 3D cache in the DLL and even a 2D cache is stretching the limits. We could have a route vs PlotType, but that's about it. It can't be merged with terrain as well in one setting.

It would check both settings through meaning it would check railroad on hills and railroad on desert and both have to be true to be allowed to build. It will however not allow allowing railroads in grassland hills and level desert, but not hilly desert. That will be too much coding, too much XML setup and too much CPU time spend on a too little gain in gameplay.

I'm not sure if it would make sense to allow improvements on each PlotType. We have the PlotTypes land, hills and peak. At most it could be a check if an improvement could be build on peaks, meaning unlocking mining will allow mines in hills and a later civic will unlock peaks too.

 

[Lib.Spi't]

I think those checks would be sufficient.

Something like dynamite would allow hill or peak constructing.

Another thing like water logistics (I don't know..) would unlock desert.

if you can unlock that based on improvement type, so one for mines, one for farms, etc.

I think that would be plenty.

I think that falls within the simpler version of your thoughts... right?

 

[Nightinggale]

I think that falls within the simpler version of your thoughts... right?

My thoughts would be to have the tables:

• Improvement vs terrain
• Route vs terrain
• Route vs PlotType

All 3 would be tested individually and can succeed or fail independently from each other. Naturally all route checks succeed without checking if it isn't a route being build and the same for improvement.

Now I just need an idea for an actual DLL implementation. I can't remember any 2D arrays being read from XML meaning I will have to design some XML reading code for that purpose. The rest shouldn't be that hard to implement.

 

[Lib.Spi't]

So we would lose improvement vs plottype?

Is there a reason for that? i.e. to do that is where the complexity spirals out of control?

If we can do it for route, can we not do it for improvements as well?

 

[Nightinggale]

So we would lose improvement vs plottype?

Is there a reason for that?

Lazy programmer, who doesn't think it's important enough to code

I don't really see the need as improvements are generally coded to only apply to one PlotType anyway. Writing code for it as well as calculating the cache and check cache at runtime all takes time and my guess is that it's not worth the time.

Btw I decided to postpone this. It is essentially a new feature and I will do it after I have cleaned up civics and merged it with traits and FF.

 

[Lib.Spi't]

no problem, I guess one 'fix' would just be to make something like mountain improvements that get unlocked, rather than standard improvements bieng unlocked on new terrain.

The civic upgrade work is definately more worthwhile.

 

[Nightinggale]

Actually maybe it would be a good idea to make an improvement vs PlotType setup if the others are made anyway. The reason is that it would give XML modders more freedom, but also it would be flexible and will not need to be updated if we add more PlotTypes. Right now I can't think of more, but I'm sure that col2071 can come up with a few, which could be interesting.

It could also be interesting to see if it would make sense not to hardcode PlotTypes in the DLL. We could hardcode the current ones for performance and then add the ability to add more in XML.... but not right now.

 

[orlanth]

I'd agree Improvement vs PlotType unlocks could be nice to have, but not by any means a must-have feature if at all difficult. As you know ImprovementInfos.xml already has <bHillsMakeValid> and <bRequiresFlatlands> to handle modding of where an Improvement is possible to construct, so it's a matter of whether you want to add options for constructability to be unlockable via Civics/Techs etc. There might need to be a Peak plottype tag for ImprovementInfos if you want to add Peak improvements.

Are Water tiles (Coast/Ocean/Lake) also their own Plottype, or is this handled separate from Plottypes by having them be the Water Domain? If 2071 eventually becomes able to have Coast/Ocean tiles on some aquatic planets, in addition to Low Orbit ("Coast" replacement) and Deep Space ("Ocean" replacement) tiles surrounding planets as in the current version, I'm not sure whether this raises coding issues to think about. I don't think this would require custom DLL changes for Improvements, since you could mod Improvements specific to oceans or space terraintypes and mod units that could construct them. UnitInfos does have <bLandYieldChanges> and <bWaterYieldChanges> which I guess refers to land and water Domains rather than plottypes.

 

[Nightinggale]

Water plots both have their own domain and PlotType. Domains are hardcoded at the moment, but at some point I would like to add a space domain. That way all the stuff, which are coded for water (waves and stuff) applies to planet oceans and not stars. Making a map surrounded by space domain is task for the map generator, which can be as simple as use the current code, loop all plots and change water into space.

However I will focus on civics and all the other stuff will have to wait. I have too many half finished tasks to start new ones in the very near future.

EDIT: my 2000th post

 

[Kailric]

Water plots both have their own domain and PlotType. Domains are hardcoded at the moment, but at some point I would like to add a space domain. That way all the stuff, which are coded for water (waves and stuff) applies to planet oceans and not stars. Making a map surrounded by space domain is task for the map generator, which can be as simple as use the current code, loop all plots and change water into space.

I am glad you guys are getting this figured out. Way back in the day someone suggested the feature of Improvements and Terrains so I did a half-hearted effort to add that but never really finished it up. It would be a neat feature to have for larger mods though.

Yeah, there are so many cool things we could do with 2071. I've been itching to be able to go wild with programming exotic features like Spells and such for a Fantasy mod but a Tech savy mod like 2071 would be a good playground as well, so perhaps I'll be able to invest some time into it when M:C is caught up.

However I will focus on civics and all the other stuff will have to wait. I have too many half finished tasks to start new ones in the very near future.

You are not the only one.

EDIT: my 2000th post

Gratzs And one to grow on!!

 

[Nightinggale]

Way back in the day someone suggested the feature of Improvements and Terrains so I did a half-hearted effort to add that but never really finished it up.

I wouldn't say it would be half assed. It's more like it's rather complex to get right. That's one reason why I'm not starting on it right now. Thinking about it made me realize I couldn't do it in a single day as there are a bunch of issues once you look into it.

I still want to do it eventually though. However due to time constraints (I want next release ASAP) I will finish what must be done before next release and then look at Kailric's remaining todo list and decide what to do at that time.

EDIT: now I'm done cleaning up the allow arrays. It turns out that it's a really good thing this part of the code is cleaned up. The code mainly consist of addons, added to make something else work and it has become a jigsaw of inconsistent naming, behavior and placement in the code. This lack of overview have resulted in a few minor bugs, but the new layout fixed those more or less without noticing them.

 

[Kailric]

I still want to do it eventually though. However due to time constraints (I want next release ASAP) I will finish what must be done before next release and then look at Kailric's remaining todo list and decide what to do at that time.

Yeah, I need all the help I can get. The next version needs to have a nice polish to it. If you want I can add the todo list to source forge and we can work to knock out that list from there.