Current and Future Developments

[Kailric]

Trying to remember all that needs adjusting and added that we have recently talked about in the latest testing, if you remember something let me know...

-New Luxury Food units right from the start
-Adjust Local Market prices to make them more viable
-Adjust Limited Resources so they are not depleted to soon
-Linked Limited Resources, such as Luxury Food/Hides so they deplete at the same time
-Interest producing Buildings are overpowered, need to be made unique

 

[Lib.Spi't]

fix the castle trade bonus to fealty instead of crosses

that is the only one i can think of

 

[Kailric]

fix the castle trade bonus to fealty instead of crosses

that is the only one i can think of

Oh yeah, I never finished that. There was one other thing I didn't finish as well, will have to go back a read your posts.... didn't find it. Anyway, I'm sure I'll remember when I start coding again, trying to finish up school at the moment.


Also, Vassal Gifts per city, not player

 

[Lib.Spi't]

Ah yes! Forgot that one.

I have been trying to think if there was anything else as well.. but I think those were all the 'tweaky' concepts we discussed.

 

[Kailric]

Ok, I've started a playtesting session fixing a few things. I am starting a new list of things to finish before next release. Below is just my initial list, there will be plenty more.

-Make the Native Teach Class more diverse. In my current game there are three Shepard trainers in a cluster.
-Finish AI Trader
-Finish Auto Prospector
-Add Prospector Profession
-Finish King's Forest improvement
-A City command to turn off AI Traders
-Initial Luxury Unit art
-Adjust Local Market prices to make them more viable
-Look into adding Yield/Unit requirements for certain Techs
-Add more functionality to Minor Civs, such as improving territory and contructions

 

[Nightinggale]

I propose not completing the consumption multiplier (it will take too long to do). Instead we just hide the setting from the GUI for the time being.

I'm half way to finishing the center plot selection (I decided to ignore professions for now). I might as well finish it.

I want to make a list of TXT_ string names used in the DLL, EXE and python and put those into XML files named something with DLL or whatever. That way other mods knows which strings to keep and which to discard. That would likely be a good idea to do before other mods really split out from M:C.

 

[Kailric]

I propose not completing the consumption multiplier (it will take too long to do). Instead we just hide the setting from the GUI for the time being.

I'm half way to finishing the center plot selection (I decided to ignore professions for now). I might as well finish it.

I want to make a list of TXT_ string names used in the DLL, EXE and python and put those into XML files named something with DLL or whatever. That way other mods knows which strings to keep and which to discard. That would likely be a good idea to do before other mods really split out from M:C.

Well, I have a pretty long list that needs to be done so it will take sometime to finish it all. School has started again also, so that will take up much of my extra time. So, you can always make a new branch for things you may want to start and if I happen to get done with my part we can either merge and finish or hold off.

 

[Nightinggale]

For those who haven't noticed, there is a thread (general colo modding) about radical changes. It's a brainstorming thread and there are plenty of bad ideas, but also some good ones.
http://forums.civfanatics.com/showthread.php?t=484859

I particularly like posts #31 and #34 (I wrote both )

I decided to copy them here as it isn't unlikely that they will be coded eventually.

If we add productionMultiplier (an int) to profession, whatever the profession produces will be multiplied by that int. This mean 2 yield A + 2 yield B + 2 yield C -> 6 yield D (if production multiplier is 3).

If productionMultiplier is negative, -productionMultiplier will be multiplied to input. That will allow 3 yield A -> 1 yield B (productionMultiplier = -3).

This could become quite interesting and it really unlocks a lot of options using XML only. I don't even think coding this will be that difficult and I will likely take a closer look in the near future. I still think it's plain silly to have productionMultiplier set to -1000 though.

Good point. The civic system in M:C is quite powerful and modder friendly because if a feature is available to civics, XML modders can use it for civ style civics, inventions or both. Also having a massive amount of civics is not really a performance issue because most or all values are cached. This mean they are only fully looped when you gain or lose one.

If I am to spend time coding something for traits, I will likely move all trait features to civics, make a new civic subtype for traits (if needed) and then make leaderheads store which civics they have. That would really increase the XML modding freedom adding a new trait to a civ would be the same as adding a new invention from a goody hut.

Now that I think about it, I kind of like this idea. It will allow traits with mixed trait and civic abilities. We could make a trait, which gives military bonus, reduced XP requirements and at the same time we use current civic abilities to give civilian penalties, such as -10 units on the docks in "Europe". As there can never be less than 1, it mean that leader cares little for civilian units and will never have multiple units on the dock to pick from. Alternatively he could have extra units on the dock.

It makes me wonder if founding fathers should also be placeholders to getting a civic. They would still be unique as it would be the only way to gain the civic in question. However all the effect code would be shared meaning endless setup options.

 

[Kailric]

Yeah, the Civic xml controlling everything is brilliant, I wanted that from the start but allowed Civics to have Traits to simplify things for me. Currently, the CivicTypes (Medieval Techs, Trade Techs, Civics etc.) are defined as a Civic itself. I started to create a new CivicType xml, where we defined the different Civic types called GlobalCivicEffectInfos.xml. Here we could place all the different Civic types instead of having to create a Civic just for that. So, if you was going to do this perhaps this would be good to add to, unless you can think of a better idea.

 

[orlanth]

Yes, the way CivicInfos.xml ended up having entries for totally different kinds of entities (Tech Categories, Techs, and Civics) is a bit disjointed (even more so due to working together with CivicOptionInfos.xml) and seems like it could be cleaned up by making sure each type of entity goes in its own file. It would be awesome if Tech Categories could actually have a game function like in the original Inventor modcomp, for example if a leader could have a Pious trait giving a slight bonus to research for techs in the Religious tech category.

Alternately, might it be even more straightforward to let everything have the same XML Schema (ie each file have the same set of tags available), and let there be separate files for Civics, Techs, Traits, and Censures, which are all based on the same or similar Schema so have the same tags and features available? This could accelerate modding by letting you define all characteristics of something when you create it, and not need to reference a Trait-like tag in a separate file.

It seems like we could settle on either this kind of approach where a common set of tags is present in each XML file, or an overhaul like in NG's message above where there is one central XML handling almost all types of modifiers/effects (could even separate this out as ModifierInfos.XML), and different game entities such as Civics, Techs, Traits, Fathers and Censures can simply reference this single file. I guess this second direction would seem to keep things the most flexible but what do you guys think?

 

[Kailric]

It would be awesome if Tech Categories could actually have a game function like in the original Inventor modcomp, for example if a leader could have a Pious trait giving a slight bonus to research for techs in the Religious tech category.

Well, on this part I think it would be a great idea and also to have an XML just to create Tech Categories in. I plan to re-look at Techs, evaluate the ones we have, think of new ones, think of Categories, add in Yield Requirements and such.

I think Gold is easier to come by in M:C at the moment so it may be a good idea to make at least a default of YIELD_GOLD requirement for Techs, then some Techs require some another fitting Yield.

 

[Nightinggale]

Yes, the way CivicInfos.xml ended up having entries for totally different kinds of entities (Tech Categories, Techs, and Civics) is a bit disjointed (even more so due to working together with CivicOptionInfos.xml) and seems like it could be cleaned up by making sure each type of entity goes in its own file. It would be awesome if Tech Categories could actually have a game function like in the original Inventor modcomp, for example if a leader could have a Pious trait giving a slight bonus to research for techs in the Religious tech category.

That's a bit different from what I'm aiming for, but sure, we should have a civic option to get faster research in certain categories.

However I think a bonus is a bad idea. I would much rather reduce the requirements for the techs. Here is why:

• no bonus
  5 idea/turn --- 100 required = 20 turns
• production bonus (+10%)
  5+10%=5.5, which is rounded to 5 (int)
  5 idea/turn --- 100 required = 20 turns
• demand lowered (-10%)
  100 - 10% = 90
  5 idea/turn --- 90 required = 18 turns

Alternately, might it be even more straightforward to let everything have the same XML Schema (ie each file have the same set of tags available), and let there be separate files for Civics, Techs, Traits, and Censures, which are all based on the same or similar Schema so have the same tags and features available? This could accelerate modding by letting you define all characteristics of something when you create it, and not need to reference a Trait-like tag in a separate file.

Multiple files sounds like a good idea and I think I have an (untested) idea for implementation.

LoadGlobalClassInfo([COLOR="Blue"]GC.getCivicInfo()[/COLOR], "[COLOR="Red"]CIV4CivicInfos[/COLOR]", "GameInfo", "[COLOR="red"]Civ4CivicInfos[/COLOR]/CivicInfos/CivicInfo", &CvDLLUtilityIFaceBase::createCivicInfoCacheObject);
LoadGlobalClassInfo([COLOR="blue"]GC.getCivicInfo()[/COLOR], "[COLOR="red"]Civ4InventionInfos[/COLOR]", "GameInfo", "[COLOR="red"]Civ4InventionInfos[/COLOR]/CivicInfos/CivicInfo", &CvDLLUtilityIFaceBase::createCivicInfoCacheObject);

The part of interest for the schema file is written in red. We have two different XML containers, each holding one CivicInfos. The schema code for CivicInfos is written just once meaning the part of the schema file, which we usually mod is shared.

The part of interest for the DLL is written in blue. It tells which vector the result is written to. The XML reading code appends to the vectors, not overwrite (except if there are nameclashes, which should be avoided at all cost!!!). This mean the second time we read an XML file into the array, the new data is added after the data from the first file.

In short the DLL ends up with just a single vector to loop and the XML modders ends up with one file-one task. I can't think of a reason to have an upper limit to how many files we can read into the same vector. The game will not care if a tech is written in file A or C, but human readability cares.

The only sideefffect I can think of in this is that it will break my nameclash detection code. However I have a plan for a new detection system with much nicer code, which should be able to handle this. However it has been low priority for months because it will not actually add anything to the game until now.

 

[orlanth]

Yes that tech discount idea seems even better actually . In fact especially for techs that can have Yield requirements consumed in research (like the original Inventor modcomp and almost all in 2071!), getting a cost discount would be the only way to go since it could decrease how much you invest in the research, rather than just finishing a bit faster.

About the nameclash detection system, I have no idea because I have not excavated enough Progenitor Artifacts to complete the research needed to reach your guys' level of expertise However I trust that as always you will end up implementing something vastly less crappy than Firaxis. I would guess with the system you propose, it might become unnecessary to make seperate XML entries to define every Tech Category (each tech entry in TechInfos could have a <TechCategory> tag and on startup the game could detect what categories existed based on that.

Another cool thing possible with Tech Categories is that you could let research in each category boost a different type of FatherPoints if you like. Ie completing research in Religious category could contribute to progress for gaining Religion FFs, etc.

 

[Nightinggale]

A funny thing happened when I read through the code to put everything into civics. I came across CvCity::updateBuildingConsumptionCache().

According to the comments I wrote it, but I can't remember that I did. It looks ok and it does in fact cache how many yields the buildings will consume each turn if they are full of "free colonists". I made a one line chance (ok, I split it into two for readability) to feeder service and now it will use this cache * consumption multiplier if that number is higher than the current threshold. I then re-enabled the consumption multiplier spinbutton in import/export and ran some tests. It appears to work just fine and now it's committed. It also appears to update correctly, though one could argue that a complete recalculation every time a building or civic is added/removed might be a bit overkill.

We should go treasure hunting in the source code. Who knows what else I added without remembering it

 

[Kailric]

We should go treasure hunting in the source code. Who knows what else I added without remembering it

That's where you and I differ, what you add and don't remember even adding it, it actually works

 

[Nightinggale]

I have run into a practical problem with merging traits into civics. My original concept with just copy pasting the code into the end of civics will work, but if I do that and then do the same with FF, then we will have a mess nobody can figure out. The main problem is that currently more or less everything is in random order inside each of those and as the size increase, the problem gets worse.

The only solution I can think of is to start with the mandatory data (type and all that). After that there should be no variables on their own. Instead there are containers, each with a specific theme. Say we call the first unlock. It will then contain arrays telling which yield, profession, unit, whatever it unlocks. If the civic unlocks nothing, then we can simply write </unlock>. Everything should be able to be skipped in XML, meaning even if you place something in unlock, you only have to actually enter what you change. You don't have to enter that the profession array is empty just to unlock a unit.
I think that will be the most XML modder friendly approach.

The problem is that it would mean all variables have to be sorted. Some or obvious, but others takes some research to figure out. For instance, what would be the appropriate category for iModdersCode1

I think I will make an unsorted category for stuff like that and then we can at a later date empty it one by one. If the variable is skipped anyway for most(all?) civics anyway, then it will not really be that much work to move it later.

Once CvCivicInfos have been sorted, it will be ready to take variables from traits and FF one by one as they are sorted too in the process. This is going to take a while

 

[Kailric]

oFor such a game changing aspect, with all those options, it would be a good idea. I regretted making all my additions to CivicInfos with 0 as Minimum appearance, cause every time I want to add one of the new attributes I can't remember where it is suppose to go. So, perhaps that should be changed too, not sure though as when you add FF and Traits that is going t be a ton of options for each entry.

 

[Nightinggale]

I regretted making all my additions to CivicInfos with 0 as Minimum appearance, cause every time I want to add one of the new attributes I can't remember where it is suppose to go.

Same here. I started writing a script to fill in default data to get around that issue. It's a lot of work though and I would much rather do it based on the schema if I could figure out a way to get the default value.

The only real solution I can think of is to scan CvCivicInfos in c++ and insert the values written in there. It would be a lot of work though. However if I do, I could make one, which makes default lines vanish as well.

Looking at recommended XML programs:
http://modiki.civfanatics.com/index.php/Civ4_Useful_Programs#XML_Programs
XML editor: never looks in the schema and if a variable isn't present, it will not be shown. Otherwise ok.

XML marker: could be ok for navigating files if all lines are present. However I don't know what happens when the 30 day trial runs out. Perhaps I should have installed it in 2030


I think the best option for people using notepad++ is to group everything, and allow empty groups. Each group is then sorted alphabetically.

Another idea (which goes for all XML files) is to write some sort of wiki generating perl code. It uses the schema as input and outputs a txt file, which can then be copy pasted into the wiki and it will look nice there. If we can get it to read comments and place those in the wiki as descriptions for each variable, then we would actually have a decent system, which will bring proper comments to both wiki and schema at the same time. I started doing something like this at one point, but it can be way better.

 

[Nightinggale]

I started cleaning up branches. The idea was that every time a feature was done, it should merge back into develop. Also every time we make a feature branch, it should branch off develop. As it turns out, this has not happened and we really need a cleanup.

I have set develop to the same revision as AI_Trader, which makes it the head of development again.

I want to merge prospecting_setting into develop and be done with that part before it gets too much out of sync with what else goes on (read: conflicting codechanges).

Kailric can continue to use AI_Trader. That will allow his savegames to be unaffected by me merging in savegame breaking code in develop.

The branches I plan on deleting as they are already included in develop.

• prospecting_setting (after merge)
• LimitedResources
• Trade_Relations
• Trade_GameFont
• Trade_Relations
• delayed_response_generic
• LimitedYields

I'm not sure about the Russian branches, Fullrene (factions) or delayed_response. They contain unmerged changes, which would need a closer inspection to tell what to do with. Btw it would appear that we lost our Russian translator. He haven't done anything in haft a year. However that isn't the same as we should just forget about his work and delete it.

Are there any objections?

 

[Kailric]

Sound like a plan. On my phone at the moment so can't reply much more.