[MOD] Colonization: 2071

[Nightinggale]

wow that was fast I should've known it might be the number of buildings..

It's not like it's the first time I looked into that particular file. It is like the breeding ground for python problems
It wasn't that hard to track down. It complained about line 1185 and something about reading a too high index. That array is set around line 430 using data, which is set around line 150 (or whatever it was). Those are the only places those arrays are mentioned in the first 1200 lines meaning they were fairly fast to search for.

the current 2071 has about the same number of yields and specialbuildings as RaR, so hopefully performance and screen space won't be too bad once everything's working. But I definitely shouldn't add any more yields (that's another reason having combat effects not be inextricably linked to yields will be good).

I suspect we will end up with better performance than RaR. The last non 2071 commit was caching allowed professions. Considering how long the AI spend on browsing though professions all the time I say this should make a difference. If I keep improving whenever I spot something we will end up with nice performance.

As for having combat features linked to yields I say it wouldn't really hurt performance. It really depends on implementation and I had an idea where it wouldn't be bad.

Sure that would be possible to do; with a batch macro in photoshop it would be fast to make alternate color versions of each button. OTOH the number of free promotions will likely be very small compared to the regular ones and will already look recognizably different, so the regular ones wouldn't need any changing. E.g for M:C, units have at most one Armor type which could use the existing Armor icon for that yield, and have at most 1-2 Weapon or Shield effects which can use buttons that also look obviously distinct from the blue experience promotion badges.

If it's easy to do, then I say that's the best solution. There is no need to hide such data from the GUI. Also adding the bools to ProfessionInfo is likely the easiest solution to code.

Now I wonder about performance regarding adding that many promotions. It would likely be a good idea to see how promotions are handled in the code before making a final decision on how to deal with this.

 

[orlanth]

Actually, it'll only be necessary to add a very few promotions (one for each of the Armor types, and one for each of Shield, Bash and Parry). The icons for these small number of equipment promos can be made noticeably different from standard promotions, which retain their standard blue-and gold buttons. The existing promotions won't need to be duplicated & won't need anything done to them. IIRC this is about how equipment is handled in the many modmods of FfH and seems to work fairly well.

There is actually already an example of this in M:C's Hound Companion and Can Build Home, which are free promotions with a gold-on-magenta color. If the few free promotions from equipments also use that color scheme, it'll be obvious which are from experience and which aren't. (From a game standpoint it makes sense to be able to see equipment promotions as well; they're an aspect of the unit's power/abilities that are about as important as the experience-based promotions).

BTW I was meaning to ask about the AI yield groups, if Check_YieldGroup_AI_Raw_Material has the AI sell yields unless they're needed,
do you think it might be best for 2071 to just put the majority of the yields into this group? Once techs start getting implemented, I'd planned to have a lot of the advanced techs consume processed good types for research, so in some sense the majority of the yields would have the potential to be useful.

 

[Nightinggale]

Actually, it'll only be necessary to add a very few promotions (one for each of the Armor types, and one for each of Shield, Bash and Parry). The icons for these small number of equipment promos can be made noticeably different from standard promotions, which retain their standard blue-and gold buttons. The existing promotions won't need to be duplicated & won't need anything done to them. IIRC this is about how equipment is handled in the many modmods of FfH and seems to work fairly well.

My concern for performance is that we loop promotions, which obviously has proportional execution time with the number of promotions. However we also increate complexity of the promotions (more bools to check) meaning the time spend on each promotion increases. Specially because of the latter we should consider what to use promotions for. The AI shouldn't need to consider them greatly. If it has to, then we should consider caching or something. Actually it might not be a bad idea to cache combined attack bonus from all promotions instead of recalculating each time. This could be really interesting if the AI includes promotions when figuring out military power (I hope it does). There is a function to gain/remove promotions meaning we have a single location to recalculate such a cache.

There is actually already an example of this in M:C's Hound Companion and Can Build Home, which are free promotions with a gold-on-magenta color. If the few free promotions from equipments also use that color scheme, it'll be obvious which are from experience and which aren't. (From a game standpoint it makes sense to be able to see equipment promotions as well; they're an aspect of the unit's power/abilities that are about as important as the experience-based promotions).

Maybe one color for xp promotions, another for equipment and a third for unit ability.
Build home needs an improvement. Often I encounter "can build home" and I'm left wondering which building it will provide. That's basically a Pedia issue.

BTW I was meaning to ask about the AI yield groups, if Check_YieldGroup_AI_Raw_Material has the AI sell yields unless they're needed,
do you think it might be best for 2071 to just put the majority of the yields into this group? Once techs start getting implemented, I'd planned to have a lot of the advanced techs consume processed good types for research, so in some sense the majority of the yields would have the potential to be useful.

There are two almost identical groups. YieldGroup_AI_Sell_To_Europe and YieldGroup_AI_Raw_Material. Yields sold to Europe are sold to Europe unconditionally. Raw materials checks cities to see if they are need and gets transported to where they are needed. If they aren't needed they use the code for YieldGroup_AI_Sell_To_Europe. From a technical point of view we can say all are YieldGroup_AI_Raw_Material, but for performance reasons we tell the AI that certain yields will never have a domestic usage.

I have been wondering about those two groups as well. With a domestic market, it would seem that all becomes raw materials. We could also merge them and then make the AI cache which are in which group. It would make sense to not check for need for yield A until you invent units/builds, which creates a demand for it. There are some options and I really haven't figured out what we will end up with. Inspection of performance gain from skipping the check for domestic need and perhaps make the check faster or run the check once every turn and cache the result for the rest of the turn. We have quite a few options.

Speaking of demand for yields. I think we have a bad piece of code regarding uninvented yields. Basically they are discarded at the start of every turn. However I had one game with 2071 where the aliens though I was a nice guy and they gave me 89 uranium. I was like and started researching my gift. After all I only needed to use half of it to gain the needed invention. That would be the logic response to a gift like that. Throwing it all away seems like a design flaw. Instead it should hardcode production to be 0 or something.

 

[orlanth]

Speaking of demand for yields. I think we have a bad piece of code regarding uninvented yields. Basically they are discarded at the start of every turn. However I had one game with 2071 where the aliens though I was a nice guy and they gave me 89 uranium. I was like and started researching my gift. After all I only needed to use half of it to gain the needed invention. That would be the logic response to a gift like that. Throwing it all away seems like a design flaw. Instead it should hardcode production to be 0 or something.

That's a good point.. But it's not necessarily an intrinsic flaw in the existing M:C DLL, rather something that I think could actually be made very interesting by careful mod design. It's already possible to have the profession for producing yield X require a tech, so having another tech that invents the yield itself would seem a pointless feature.. unless you create a compelling reason to want to buy or acquire some of that yield before you're able to produce it yourself. This could be done by making sure discovery of the yield itself comes with the earliest techs, allowing you to purchase, capture or acquire a small amount as a research sample, which can in turn be used to research production of that yield or discovery of other related yields.

I've started a new template sheet in the design doc to begin to plan out the techtree production lines that will gradually unlock trading, production, and processing of each of the related "groups" of three yields shown in the Raw Yields tab of the doc. It's in early stages yet and might be a little hard to communicate, but hopefully can be read using the key at the lower right. Basically each group consists of 3 raw yields in ascending order of value and difficulty to discover (eg Actinides->Isotopes->Rare Earths in the Geologist group; named RA, RB, and RC in the template). Everyone starts out able to buy/sell the RA yield in each group, and also start with access to a variety of other techs depending on their civ. Advancement from there is incremental, requiring some strategic thought and tradeoffs at each step. To discover how to produce Actinides (yield RA) yourself, you can first acquire a small amount of Actinides (through gifts, war, hunting, or trade with Aliens or Earth) then analyze them in your Research Lab to discover the tech for Actinides Extraction. As you progress, you can also use Actinides to unlock access to the next yield in the group (Isotopes, yield RB) and then unlock their production. Isotopes can in turn be used to discover Fusion Cores, (PA, the processed version of Actinides) and so on; creating a stepwise march of progress with interesting decisions at each stage. It's still at early stages and I'd be interested to hear your input; I'm hoping that handling the techtree design in an algorithmic manner will enable a balanced, interesting and consistent overall design (while also setting the stage for techtree generation via Perl!) Anyway, the upshot is that unlocking tradability of yields can be made an interesting early part of the techtree. However the mod design process must avoid requiring a yield to discover access to itself; and it would also help if Aliens/natives only gifted yields you have discovered access to.

 

[Kailric]

The point is to get rid of the hardcoded types in the DLL as it messes up with 2071. However I noticed something else. UnitCombatInfo lacks it's own type in C++ and is instead of type CvInfoBase. This mean it actually has Civilopedia meaning the hardcoded text in C++ Pedia code could just read CvInfoBase from XML.

However I wonder about another thing. We could give it a type and move the file into XML\Units and use the schema file there. That way we can add bools and other data to the combat types themselves.

Either way something has to be 'hard coded" right? If you add new booleans then each new boolean will need to be coded and checked for in both mods. Just saying either way both mods will need to check for every option here. Adding them to the CvUnit schema maybe useful and allow for more modability.

 

[Nightinggale]

That's a good point.. But it's not necessarily an intrinsic flaw in the existing M:C DLL, rather something that I think could actually be made very interesting by careful mod design. It's already possible to have the profession for producing yield X require a tech, so having another tech that invents the yield itself would seem a pointless feature.. unless you create a compelling reason to want to buy or acquire some of that yield before you're able to produce it yourself. This could be done by making sure discovery of the yield itself comes with the earliest techs, allowing you to purchase, capture or acquire a small amount as a research sample, which can in turn be used to research production of that yield or discovery of other related yields.

I had a new idea on this. Inventing a yield is the same as discover the existence of that yield. Say country A invents a way to produce clay pots. Country B will then have the knowledge that clay pots exist even though they can't produce them themselves.

Following this logic the allowed yields cache should be redesigned into being actual data storage instead of a cache (simple change). By default all yields are undiscovered. Once a yield is discovered, it can't be undiscovered again meaning it's a bool, which only goes one way. This bool is saved. The question is then what should be needed to enable a yield. Obviously inventing something, which enables it or no civic gives access to it (available from the start).
However how about at the start of all turns, you gain access to yields known to all civs you have contact with, possibly with at least +3 relationship or something like that.
Following the uranium gift incident, the natives would then tell what uranium is, which gives the player enough interest to store it. However it can't be produced until the player investigates it further and gain the needed tech himself.

(while also setting the stage for techtree generation via Perl!)

If it can be generated by perl to make an XML, then perl can generate code for graphviz as well. That might be helpful to get an overview in the design phase. I wouldn't rule out that it could be helpful later as well.

Either way something has to be 'hard coded" right? If you add new booleans then each new boolean will need to be coded and checked for in both mods. Just saying either way both mods will need to check for every option here. Adding them to the CvUnit schema maybe useful and allow for more modability.

Hardcoding a bool in the DLL is ok when the bool is set in XML. The hardcoding I want to get rid of is the hardcoded number of armors and stuff like that. Basically the DLL should apply feature X to whatever has the bool set in XML rather than whatever has the Type Y in XML.

 

[orlanth]

In the 2071 framework it's not just being aware that something exists, but having the technology to acquire and store it and be able to use it effectively for researching other things. (eg beginning to actually store, use, and analyze Alien Specimens and Isotopes would need development of containment technologies, mass spectrophotometes or what have you). But it could be worth having some "knowledge diffusion" adjustment for techs in general as a balancing mechanism - ie get a slight discount in research costs for each other player you have friendly contact with that knows that tech). Also, a really good tag to add to traitinfos is one that gives a percent discount to costs of techs from a certain Category (the tech categories in civicinfos are otherwise unused.)

 

[Nightinggale]

I realized the game must have a schema for UnitCombatInfo somewhere and I started searching for it. The game loads vanilla and then it is overwritten by the MOD meaning if it isn't in the mod, it might be in vanilla, which is the case here. Now all BasicInfo has a schema.

I added Civilopedia to UnitCombatInfo with minOccurs="0". I then copied the hardcoded strings from the pedia part of the DLL to this new field. The DLL code is then recoded to loop though all UnitCombatInfos and print the string for those where the profession has the type as combat gear and the Civilopedia isn't empty. Not only did this entirely remove the hard references to 3 armor types from the DLL, it also fixed the bug that only some of them actually appeared in the pedia. Now they all appear. The pedia still appears buggy because of stuff like infantry lacks leather armor, but that is because they lack the gear type. I didn't go though the gear setup in XML.

Now we can also easily add more settings to UnitCombatInfo. However I didn't make a new class for it meaning it is still stuck with BaseInfo variables in the DLL, which is just a few strings and such. If we add a bool, then we should make a new class to store that bool, read it from XML etc. It might not be that tricky, but it's not just copy paste of existing code either. Civilopedia is a string in BaseInfo, which is one of the reasons why I picked that name.

I'm thinking about removing <Combat> and replace it with the geartype. That way a unit can truly have multiple types. If we do that, then we should have a minimum of one gear type. I haven't examined the code to see how hard this would be to implement.

In the 2071 framework it's not just being aware that something exists, but having the technology to acquire and store it and be able to use it effectively for researching other things. (eg beginning to actually store, use, and analyze Alien Specimens and Isotopes would need development of containment technologies, mass spectrophotometes or what have you).

Good point. We shouldn't change anything in this regard. However we should remember that the game is perfectly ok with having 225 civics to enable a specific yield and that it's enabled if a civ has any one of those.

But it could be worth having some "knowledge diffusion" adjustment for techs in general as a balancing mechanism - ie get a slight discount in research costs for each other player you have friendly contact with that knows that tech).

Makes me think of Imperialism II. If another country knows an invention, then you get added percentage to the money you allocate to research that invention as well as a base bonus. That would be like +2 science and +25%. This stacks for each other country having this invention, though it doesn't stack linear. You don't get twice the bonus for two countries having the invention.

A result of this is that if you are really short on money and can't give anything to your scientists to research, then you can select only inventions invented to other countries and allocate no money for research. The base bonus will still give you those inventions within 10-20 turns where you might get it in as little as 3 turns if you invested in it.

Another result of this is that it's much harder to do what you could in Civ 1 where you could attack chariots with tanks. The civ(s) lacking behind would get a research bonus, which mean they have an easier to to somewhat keep up with you.

Needless to say if the tech tree is very unlinear, then it mean that there could be strategy in selecting certain techs. Say you specialize in one branch for a while and then start researching in other branches you get a bonus because other civs have invented those in the meantime (hopefully). Sure others will gain a bonus from your research, but it could be so specialized that they have a hard time exploiting that.

Also, a really good tag to add to traitinfos is one that gives a percent discount to costs of techs from a certain Category (the tech categories in civicinfos are otherwise unused.)

You make it sound like we have to use it and we don't have to. However we could make a series of interesting choices. Say for instance we add a lab giving +25% bonus in one category. We could do that for several categories, but only one can exist in a city at any one time and replacing one should be impossible or hard to do, such as you disable it and it will not go away for another 10 rounds before you can start building a new one. This will open up more strategy in inventions.

 

[raystuttgart]

By the way:

Did you guys ever consider to not use the Civics for implementing Techs ?
(If I recall correctly, that is how it is done in M:C.)

I never really liked mixing those 2 concepts.
(And never saw any advantage other than saving a bit of time for implementing.)

Why not do it like it is done in Civ4:BtS ?
(There is a separate CIV4TechInfos.xml.)

It would be a lot cleaner and probably also easier to maintain and enhance.
(I personally prefer implementations that are clean and tidy.)

Also, the Civics might be used for similar concepts as in Civ4:BtS some time in the future.
(Could be interesting in a SciFi-Mod like this one ... )

 

[Nightinggale]

Did you guys ever consider to not use the Civics for implementing Techs ?
(If I recall correctly, that is how it is done in M:C.)

To be honest I don't like it either, but at least it's working. One good thing is that civics and inventions have the same features meaning you can make stuff like this profession is available when using this civic or you have this invention or we could allow production of a certain unit as long as a certain civic is active. Civics could also ban professions and units if we like.

The current cache for allowed professions, units etc looks at both civics and inventions meaning civics is already implemented to do the same as inventions. Enabling changeable civics shouldn't be hard to do considering we have the ability to turn civics off as well as on. We might have some performance issues, but then again that's not really an issue considering how rare a change of civics is supposed to be.

Why not do it like it is done in Civ4:BtS ?
(There is a separate CIV4TechInfos.xml.)

That would mean implementing a brand new class. Getting this up and running might take some work for replacing something, which is already working.

After all I see little reason to change this implementation.

 

[raystuttgart]

To be honest I don't like it either, but at least it's working.
...
After all I see little reason to change this implementation.

Well, it is your mod and your choice how to implement things.

 

[Nightinggale]

I examined the effect of combat gears and I don't think we should change anything. After all it is somewhat clear.

Here is the effect of each:

• UNITARMOR_PLATE: half damage except blunt.
• UNITTACTIC_PARRY: gives one parry point
• UNITARMOR_SHIELD: gives one parry point
• UNITWEAPON_BLUNT: gives double damage to plate mail instead of half

All the names are fairly generic. Also now that I moved the Pedia strings to XML they became modable.

Each unit gets the amount of it's own parry points - opponent's parry points, though no less than 0. A unit trades in a parry point instead of taking damage meaning it is kind of like a first strike, though not 100% the same. There is a graphical difference as well (if I read the code correctly. Not 100% sure).

I say the worst part about this is the documentation. It appears to be non-existing.

Next is changing profession combat type into gear type. I figure the easiest way to do this is change how XML is loaded. It loads combat and stores it, then it loads gear types, then it enables the gear type set by combat. This way we don't have to modify XML at all to gain this feature. We can then make promotions have bonus against enemies with certain gear types. I have to look though everywhere the combat type is used to ensure that I will not screw up something by this change. Luckily we can make this gear type change without removing combat type if we want/need to.

Well, it is your mod and your choice how to implement things.

Currently Kailric is busy with other stuff and haven't committed anything in a month, which mean any change to the DLL falls back to me alone. This mean changing inventions is out of the question as the current implementation works and isn't preventing us from getting the ingame features we want. There are other more important tasks.

Also it doesn't help here that I also started spending time hunting for desyncs in RaR

 

[Nightinggale]

It turns out that UnitCombatInfo has several uses. The dominating check is to see if Profession has Combat set to NONE instead of a UnitCombatType. This actually results in some bugs because types like NONECOMBAT_PEDLER are viewed as combat units as it isn't NONE. Looks like there is some cleaning to do as XML and possibly DLL needs to be modified to make non-combat units really non-combat.

I propose a plan B:

• Profession tag Combat stays as it is.
• Profession automatically gets Combat as gear type unless it's NONE.
• Promotion UnitCombatMods works on gear types instead of Combat.
• Promotion UnitCombats works on gear types instead of Combat.

This way we can make those two work on all gear types while we keep all the code unrelated to this untouched. We can then have a swordsman on a horse gaining promotions for both UNITCOMBAT_MOUNTED and UNITCOMBAT_MELEE. Likewise promotions can give bonus against either of those will give bonus against this guy.

I think it would be best to only use the best bonus as having bonus against armor, horse and weapon accumulating could end up becoming quite a lot. On the other hand maybe that would be interesting, but then we shouldn't make promotions, which adds damage to a whole lot of types. Perhaps only the best bonus is used for each promotion meaning promotion A against UNITCOMBAT_MOUNTED and promotion B against UNITCOMBAT_MELEE could stack, but promotion C against both UNITCOMBAT_MOUNTED and UNITCOMBAT_MELEE would only use the best one.

 

[orlanth]

Hmm I'd still much rather have them as Promotions to keep things more standardized and flexible.. If they're bound through Professions rather than Promotions it won't be feasible to grant these effects to anything else like specific types of ships, vehicles, barbarians, or beasts, and won't be possible to have a Tech or FF provide them. And if UnitCombatMods refer only to gear, it'd also become impossible to grant bonuses against any non-gear groups of units like UNITCOMBAT_PROGENITOR or UNITCOMBAT_BEAST, etc. There are also UnitCombatMods in CIV4UnitInfos that would have the same problem. I think the most moddable way would be to let it check Promotions for the same effects. That way if you wanted to assign a block, parry, or damage reduction via Profession you can still easily do that with the existing tags; but assigning them in other ways also becomes possible and the ways UnitCombatMods can be used become a lot less limited. (BTW I also discovered Promotions have the <bGraphicalOnly> tag available, so you can easily set that to 1 if you don't want them displayed.)

Makes me think of Imperialism II

I loved Imperialism II You can tell they really thought carefully about the design. There is a lot of content to get unlocked and lots of interesting decisions and trade-offs to be made at each step, yet somehow it never gets bogged down in micromanagement.

 

[Androrc the Orc]

I loved Imperialism II You can tell they really thought carefully about the design. There is a lot of content to get unlocked and lots of interesting decisions and trade-offs to be made at each step, yet somehow it never gets bogged down in micromanagement.

Same here

And speaking of which, there is a team working on an Imperialism remake:
http://remake.twelvepm.de/forum/index.php?sid=86e043e3f99d447d99467d035f09b137

They seem to be more or less advanced in their project; hopefully they will have a playable version up soon.

 

[Nightinggale]

Hmm I'd still much rather have them as Promotions to keep things more standardized and flexible.. If they're bound through Professions rather than Promotions it won't be feasible to grant these effects to anything else like specific types of ships, vehicles, barbarians, or beasts, and won't be possible to have a Tech or FF provide them.

Good point. We should move those features to promotions.

And if UnitCombatMods refer only to gear, it'd also become impossible to grant bonuses against any non-gear groups of units like UNITCOMBAT_PROGENITOR or UNITCOMBAT_BEAST, etc.

We can still do that. After all gear is just in the name and it would be the most correct to change the name, but I don't feel like changing that much just to change a name. On the other hand we can rename it if we like, but what should it be? CombatTypes? CombatFeatures?

(BTW I also discovered Promotions have the <bGraphicalOnly> tag available, so you can easily set that to 1 if you don't want them displayed.)

Good to know. I came up with the idea to have two icons for promotions, one for xp gained ones and one for free promotions. That way we can tell them apart and we can make the function to get the free promotion one return the already present one if free promotion icon is unset meaning it's ok to have just one icon. That shouldn't be too difficult to implement.


I'm currently more or less done with allowing professions to gain promotions from any of their gear types instead of just their combat type. Free promotions are unaffected by this change. I'm having a bit of a problem with changing profession and allowed promotions in this regard as just adding the code to handle this appears a bit too slow and I'm working on a new design, which will increase performance as well as decrease memory usage (just a little memory, but it's a bonus, not a goal).

I noticed that looping though all gear types will slower the more gear types we have (no surprise). While it isn't a major issue, I still say it's enough not to add types we don't need. In other words our goal to be to only add the types mentioned in promotions. UNITARMOR_LEATHER is used by 3 professions, but it adds no ingame features, meaning it's a waste to see if we gain a bonus against it as well as to see if it allows more promotions. Besides the XML overview gets messy if some has ingame effects and others has none at all.

EDIT:
Committed the change to make promotions allowed by gear type instead of combat setting in profession. Combat is automatically copied into gear type as well. While I had a little bit of an issue with this feature regarding changing profession and not make eat up the CPU I ended up with a new design which I believe is faster than vanilla in most cases and the more promotions the unit has, the faster it is compared to vanilla.

And speaking of which, there is a team working on an Imperialism remake:
http://remake.twelvepm.de/forum/index.php?sid=86e043e3f99d447d99467d035f09b137

They seem to be more or less advanced in their project; hopefully they will have a playable version up soon.

Bookmarked.

 

[Nightinggale]

I noticed I never finished the python fix to main interface. I did so now and now CvMainInferface.py is the same in both M:C and 2071 and 2071 has no python errors when starting the game. I also added the new buttons to the city screen, though they are pink squares as they lack sprites. However that isn't important right now as they work anyway. I still get a bunch of asserts and then a crash when ending the first turn.

 

[orlanth]

cool, I'll look forward to using that for lots of fancy deflector shields etc. It actually wouldn't even be necessary to make it gain promotions from combat types; since it's already possible to gain them from professions using <FreePromotions> or <AltFreePromotions> directly. (ie, in professioninfos you could decide to grant a Block or Deflect effect by granting those promotions, and you can also independently decide what UnitCombat group you want to assign.) That takes advantage of the existing freepromotions tags, and also opens the possibility of units which have an effect like Block, Deflect, or Armor Piercing, but don't necessarily always have to belong to a UnitCombat group based on equipment. (for instance a beam weapons Tech could provide your units bonuses at melting through Duralloy Armor, yet a horrific chitinous space beast which also has an armor deflection point could be unaffected by this technology)

I've started an outline on the design doc for planning and balancing the Yield types across Terrains.

The core of the design will be based around the standard Terrain types from vanilla (TUNDRA,MARSH,GRASS,PLAINS,DESERT,COAST,OCEAN) , where each standard terrain provides a yield from one of the 5 yield groups (Archaeology, Bioscience, Cultivation, Drilling, and Geology) in tab 1 of the design doc. Tundra and Desert can also provide some Base Metals and Silicates in compensation for providing less Nutrients.

To try to finally take advantage of the Infinite Terrain Pack and Androrc's space modcomp, there will be several variants of each of the standard terrain types, representing planets with different climates. Each of these variants will provide the same yields as its corresponding standard terrain, but with a slightly different raw yield chosen from the same yield group of its standard terrain. The Planets mapscript will be re-jiggered so that in generating each planet it assigns a unique Climate type, and replaces the vanilla terrains with their variants from that Climate set. It would be good to include a little local randomness with every planet, so on a largely Aquatic planet you still might find local patches of Salt Flats or Volcanic Soil.

I've put up some preliminary base yield values for each of the core terrains (though not totally sure yet how best to handle Grass and Ocean). It may also make sense to let each terrain provide two different raw yields rather than one, to ensure there's always a decent balance accessible. Since the 5 raw yield groups are already assigned, the fertile "Grass" terrain types could also provide a small amount of Biopolymers, or maybe the 3 Nutrients is enough. For Ocean (and analogous difficult-to-colonize terrains like Magma) maybe we could take advantage of the Tech system to have certain Techs boost their yield. That way only well-adapted Alien species starting with that tech (or Earthlings developing it later) would be able to take full advantage of those terrains.

Any other balancing thoughts, requests or suggestions from experienced Col players?

 

[Nightinggale]

I found the code which calculates combat strength. The design made it a bit tricky to find, but once I have found it, the code design actually looks ok.

Now I wonder about bonus against UnitCombatTypes. I had three concepts

1. Best possible bonus from each promotion
2. Bonus for the best UnitCombatType
3. Combined bonus for all UnitCombatTypes

I like the first best, but Firaxis cached promotion bonuses in a way, which is incompatible with that solution. Basically they made a single promotion, which is the sum of all promotions.

Now the question is if a unit should have +25% or +50% vs horseback archers when the unit has +25% vs mounted and +25% vs archers. It is purely a gameplay decision as both are equally easy to code.

Maybe I should code both at this point and then make setting in GlobalDefineALT.xml to select which option to use. That way I can code and leave possible disagreements for later.


Another thing I noticed is that the code currently attached to UnitCombatTypes should be moved here as the code for the chance of winning (right hold down on enemy popup) use this code to calculate the possible outcome. I also suspect the AI use this code to figure out if it should attack or not. It would be logical to fix this when I move the effects to promotions (whenever I do that).

Any other balancing thoughts, requests or suggestions from experienced Col players?

Presumably I have a lot of thoughts once the game is playable though too unbalanced to become enjoyable. Still I think that should be the goal to get it into that state right now rather than stalling on possibly minor details.

Maybe I should spend time investigating the crash on next turn event. Looks like we need to go through a debugger to figure out why the game crashes and I suspect it will not be done unless I do it myself.

EDIT: fixed. It crashed due to trade routes. I changed all of them into land routes as well as available from the start. I suspect the cause of this issue is related to the issue which allows forests on ocean plots. It still has some asserts, but no crashing ones and I propose not touching anymore until TerrainInfo is set.

 

[orlanth]

EDIT: fixed. It crashed due to trade routes. I changed all of them into land routes as well as available from the start. I suspect the cause of this issue is related to the issue which allows forests on ocean plots. It still has some asserts, but no crashing ones and I propose not touching anymore until TerrainInfo is set.

I can now load and play the M:C master branch mod itself without crashes, but I'm still getting the same assert/crash as before when using the 2071 branch files with the updated DLL and python. (I did make sure to compile a new DLL from the master branch sources, and copy the Assets/Python dir from the master branch to local 2071 folder before running). I also filled out TerrainInfos.xml to add the new 2071 terrain types, but I don't think this should have any game effects yet since the mapscript still only places the vanilla terrains.

I can tell your fixes are having an effect, since I now get to the normal map interface without the yield icon bar at the bottom, and the mouseover tooltip now says Trade Route Access when hovering over many of the map tiles. But after ending a turn I'm still getting the assert and crash below. On your machine are you able to run it using the 2071 branch as well as the master? I'm thinking it may have to do with some hardcoded content about the trade system that's in M:C XML but not in 2071.

Spoiler :

File: CvPlayer.cpp
Line: 1292
Expression: std::accumulate(aiWeights.begin(), aiWeights.end(), 0) > 0
Message:
Assert Failed

File: CvPlayer.cpp
Line: 2406
Expression: getStartingPlot() != NULL
Message: