Current and Future Developments

[Nightinggale]

If you want I can add the todo list to source forge and we can work to knock out that list from there.

I think we should add more or less all tasks to SF, even though we talk about, but will not start now. We will forget half of them if we don't.

 

[Nightinggale]

I think I finally figured out precisely how we should end up with civics and how to enter the different types

We have 4 XML files, one for each of civics, inventions, traits and FFs. More can easily be added if needed.

Each file has it's own schema. This allows for unique setup. For instance inventions have to enter a location in the tech tree while the others can't give that value. After the file specific setup, all the files have the same elements. Each of the shared elements have a fitting name and contain multiple settings. For instance CivicGroupAllow contains all the AllowsImprovements, AllowsUnitClasses and so on. Future additions should be added to the appropriate group and that way be accessible to all files.

On load, all files are loaded as civics and they enter the same vector. All settings are loaded for all, including the file specific ones. The options not present will then be given default values to make them inactive. The default location in the tech tree is outside the window, meaning it will not be drawn. This give the XML modder the impression that the tech tree location is only present for inventions while inside the DLL it's present for all.

CvGlobals will keep track of where in the civic vector each type is, which allows looping from GC.getFirstInvention() to GC.getLastInvention() and skip looking at non-inventions if that is what we want. Naturally we can loop the entire vector if needed, which is what the cache generating code will do. It will not care if a unit is unlocked by a trait or an invention, which is the whole point of this merge.

That's it. It looks so simple when it's written like this, but it sure took some code reading and some thinking to end up with this.

 

[Kailric]

Flot arbejde, Night, vil det være fantastisk!

 

[Nightinggale]

I found the civic tag RequiredUnitType. It tells which UnitClass which can research the invention in question. I don't like it. If we use it, it should be an array, not just a single UnitClass. However the main problem is that say we set improved farming to be researchable only by expert farmers. All existing researchers will be kicked out and we have to apply farmers. Next invention is improved mining and only miners can research. Once again all researchers are kicked out and we have to replace them with miners. I fear heavy usage of this tag will quickly become annoying.

For now I will just let it stay as it is, but it would actually be on my wishlist to remove it. How do you feel about it?

 

[Kailric]

Since it is already in the game and working we should leave it. It adds an extra option for Tech research. If a UnitClass is listed, like Expert Farmer, all you need is One Expert Farmer, doing research, and not "only" that class. Any other Unit can still help the Expert Farmer do his Research, you just don't gain any points if there is no Expert Farmer. Making it an Array would just add more options for this, but I wouldn't say it is a necessity.

 

[orlanth]

I think it can in some cases be a cool option, in that IIRC you can have some techs where you need to have at least one of that Unitclass in order to lead the research (as Kail said I think you can have other units researching in other cities as long as at least one has the Unitclass specified, is that accurate with what's in the DLL?)
In 2071 I used this so that some Alien Autopsy requires you to have captured an Alien Hybrid unit for use in the research , and for some of the top tier techs you need to have someone from the appropriate specialist unitclass lead the research (e.g. to make top Biotech breakthroughs you can need a Brilliant Biochemist, who are suitably rare and precious to get given future dystopia-Earth's abysmal education system )

This also could keep you from easily making one research powerhouse city and leaving "Brilliant Inventor" researchers on autopilot; with careful modding the player could need to do some planning to make sure you have appropriate Yield inputs and specialists available for what you want.

 

[Nightinggale]

Point well taken. We really need proper documentation telling what each tag is supposed to do. Not only are they hard to sort when it isn't clear what they do, it will also be hard for the XML modders.

Another important purpose with documentation is to tell what it is supposed to do. Right now I can have a hard time spotting bugs because I don't know if the current behaviour is intentional or not.

is that accurate with what's in the DLL?

Good question. I saw one place in the DLL where it was used (there might be more) and didn't look into it in detail as it was rather complex. Going through the civic tags, I spot multiple places where the code could be improved (particularly regarding performance) and I add TODO on all of them. MSVC knows this keyword and can list all of them, making it ideal to get an overview of all of them. I decided not to code stuff like that right now as I have one task I will try to focus on.

 

[Nightinggale]

This is my new brainstorming state

I woke up this morning and had an idea for data storage. In fact I didn't get the idea, it was just in my head while I woke up. Also it wasn't just an idea, but more like an implementation template. I wrote it down on SF to remember it for later use.
https://sourceforge.net/p/colonizationmodcollection/tickets/11/

Code designing is easy. You just dream up some code

 

[Nightinggale]

I just noticed that inventions are called techs in BTS XML. I started calling them inventions because I like that word better. However trying to stay somewhat in sync with BTS naming scheme is not bad either. What do you think we should do?

 

[Kailric]

The term Inventions fits better with the M:C theme, but from a xml point of view we can call them Techs.

 

[Lib.Spi't]

Yeah I would make inventions cosmetic, and techs the technical term, 1 it is shorter (which is always better if you are going to be using it 100s-1000s of times) and two it keeps a sense of uniformity with bts, which I think is good for cross platform collaborations, that way which ever version your modding experience comes from, you will more or less be speaking the same language.

 

[Nightinggale]

I just realized something. While traits are player based and can be converted to civics, Founding Fathers are team based. We can't mix player and team based effects in civics.

The only solution I can think of is to make FF provide a free civic to all team members. That civic will then be an "effect civic", which is otherwise hidden and unreachable.

Another thing: why is researched civics stored in an int array? It looks like they can only contain either 0 or 1 meaning we can convert it to a BoolArray and reduce memory usage by 96%. The question is if there is some sort of idea in using int rather than bools.

 

[Kailric]

Old Kailric don't remeber why he made Young Kailric create an int, so convert all you like. I was wondering that myself the other day.

 

[Nightinggale]

I looked into Founding Fathers. I don't think it will make sense to merge those with civics after all. They do provide a free civic, meaning that functionality is preserved. The only FF feature that civics are currently missing is the ability to reveal all plots with a certain improvement (used for goody hut improvement), which I will not consider important enough to do a bunch of recoding.

I wonder about the last FF though. "He" is called REAL_TRADE_TRADING_POSTS and he provides <FreeCivic>21</FreeCivic>. That looks wrong on so many levels

Traits on the other hand would be awesome to merge with civics. Some of the tags are identical to some civic tags (easily merged ), but most of them are different totally unlike civic tags. Tags seem more focused on units, with bonus combat strength, movement, free promotions, modified yield requirements and all that. Civics are more focused on unlocking units and stuff, production and unit growth. Merging those concepts could be rather interesting

 

[Lib.Spi't]

More xml options is always good

 

[Kailric]

I looked into Founding Fathers. I don't think it will make sense to merge those with civics after all. They do provide a free civic, meaning that functionality is preserved. The only FF feature that civics are currently missing is the ability to reveal all plots with a certain improvement (used for goody hut improvement), which I will not consider important enough to do a bunch of recoding.

I'd agree

I wonder about the last FF though. "He" is called REAL_TRADE_TRADING_POSTS and he provides <FreeCivic>21</FreeCivic>. That looks wrong on so many levels

Poncho!! You found Poncho, I've been looking all over for you Poncho, now where is that fish... Actually, I have no idea what that FF is about, unless he is required for Trade Points somehow since they work on FF points.

 

[Nightinggale]

I greatly improved the debug code for finding GameFont IDs.

Now the debug button automatically shows up in Domestic Advisor if there is a debug DLL present (no more XML editing for activation).

It shows columns in this order: ID, small GameFont, large GameFont. This is followed by icon, name and type of what the DLL detects is using this ID when using getChar. The columns are icon, name and type.

If the latter 3 are all blank, then the game can't access the ID and it is unused. If it prints something in at least one of the columns, then it is in use.

The number of rows is from the start until the last used ID + 64. This should adapt nicely to changing XML and GameFont files without the need to change any hardcoded numbers. The only way to get it to fail is to leave a gap between used chars, which is larger than 64.

Page 2 is ASCII characters. Might only be useful in translations or if the font starts to act up.


I added this to TradeScreens branch. Next step is to fix the GameFont offset issues present in that branch (and some others).

 

[Nightinggale]

I documented how we handle GameFont (only TradeScreens branch is up to date)

The question is: can people understand this page?
https://sourceforge.net/p/colonizationmodcollection/wiki/GameFont iChar setup/

 

[Lib.Spi't]

There are some grammar issues or missing words (I think?), that make some sentences more difficult to follow.

Example:
Manual assigning

The XML files for the types, which get icons from GameFont all have a (?) called iChar. Simply write which GameFont ID you want the yield/unit/whatever to use and it will use it.


I don't know if it can support pictures, but I think that would help clarify some of the descriptive sentences about the layout of IDs/icons, etc.

I can sort of follow it, it would possibly be easier if I was going through the files/screens and looking at them while reading your descriptions, but somethings are a bit difficult to understand what you are referencing.

Such as:
The Gamefont.tga file
or maybe an xml layout
or maybe an 'imaginary' layout that the computer uses.

I am also thick and sleepy, so... I am one of the lowest common denominators for the purposes of gauging understanding.

 

[Kailric]

I am also thick and sleepy, so... I am one of the lowest common denominators for the purposes of gauging understanding.

And thus are the very exemplary person we need to comment on this, as if you can understand it, anyone can