beginturn.fli is a template that is unused by the game.
The settings for the various personalities are:
Barbarian settle_dense, science_slow, diplomacybarbarians //Barbarian
Cleric settle_dense, science_fast, diplomacypeacebackstab //Religious
SciFew settle_loose, science_fast, diplomacypeaceloyal //Agreeable
SciMany settle_dense, science_fast, diplomacypeaceloyal //Peaceful
Slaver settle_dense, science_fast, diplomacywarbackstab //Slaver
WarFew settle_loose, science_slow, diplomacywarloyal //Aggressive
WarMany settle_dense, science_slow, diplomacywarbackstab //Militant
Note that both science_fast and science_slow are identical, Activision decided to set them all to a fast science rate, but differentiated them according to their research goals - i.e. do you research war branches rather than development brances of the tech tree. I think this approach is just fine.
But that's just a little note to tell you that as far as the FLIs are concerned, the only difference between the personalities is how densely (cities close together) or loosely (cities don't overlap beyond four tilse) they settle. And their diplomacy.
END OF COMMENTS.
Explaining outputs is going to be tougher than Inputs. Still, let's give it a try.
OUTPUT rushbuy_max_utility [ -100000, 10000.0 ] = 150.0
Determines whether or not AI will rushbuy anything. Default is it only rushbuys buildings. (at least this is what the comment says - I think maybe what might be the case is that the value is presently set such that only improvements are worth buying).
If savings are greater than 10,000, then the AI will rushbuy units (and I assume wonders) as well. What I haven't figured out is what the numbers actually mean, the default is 150, a positive number, while the rushbuy-anything modifier sets the number to -100,000. Maybe it's possible that negative ranges allow the AI to rushbuy both buildings and units, middle ranges allow the AI to rushbuy only buildings and large positive numbers do not allow the AI to rushbuy anything at all?
I honestly think that the explanation is less convoluted than that, and would prefer to believe that rushbuy_max_utility is exactly that - a set parameter beyond which it becomes 'worth it' to rush buy an improvement or a unit. For example, it doesn't make sense for the AI to rush buy improvements on Turn 0 of production, rather it would wait until it reaches a certain cash value, and then rush buy it. Might it be possible then that rushbuy_max_utility represents such a value?
What would that number represent then? Production points remaining? No ... because then there would be no distinguishing between wonders, units and improvements. It has to be a gold derivative, since the only distinguishing feature between the three is the amount it costs for you to rush buy. Wonders are the most expensive (5x-6x), followed by units (3x-4x) and then improvements (1x-2x).
Ah, I give up - if I give more thought to this, I'm going to get a headache. Maybe someone else who reads this might be able to figure out how the negative numbers work in this. Either that or I'm headed off a tangent, and that it really does represent a range of figures.
Determines whether the AI will load no_settle.aip.
Determines whether the AI will load unit_focus.aip.
OUTPUT likely_food_multiplier[0.0, 5.0] = 5.0
// This is the multiplier that tells the ai how much
// food it will probably have after it changes the wgf.
That's what the comment says. I have no clue ok? Just out of curiousity, how do you get more or less food from changing the wgf? If I reduce rations by one notch, don't I save 2.5 food per citizen? Or does this refer to a larger combination of factors, for example increasing the number of specialists as well (probably)? Ah well, you geniuses figure this one out.
Tells the AI what the minimum workday should be set to in wgf.
OUTPUT food_max and food_min.
Tells the AI what is the range of values (food_min < rations setting < food_max) within which it can set its rations.
Uh, best you see for yourself, it changes the permissible range depending on a number of factors.
Seems to have been superseded by OUTPUT mass_settle_aip and OUTPUT mass_settle_sandbag_aip, both found in output_aipnames.fli.
Superseded as well by the other aips.
OUTPUT min_food_factor[0.0, 3.0] = 1.5
Determines how much excess food over base to aim for - in other words, how much food to leave for growth.
The comment says something about 10% excess food but don't think that is correct. In a real game, players hardly, if ever aim for 10% excess food, because that would mean that your cities would hardly grow. I think 1.5 stands for 50% excess food. Could be wrong, but I doubt the AI would stick to such a low growth %.
Only no_growth_min_food_factor is called (the rest are unused), and here it is used in conjunction with a money crisis - when wage and gold costs are prohibitive - it increases the number of Merchants, while cutting back on food and science.
From what I understand of the comment, I assume this forces the AI to use the expected wgf. From what I understand from the follow-up tri statement, using expectations is the default AI behaviour. The right thing to do.
Unused, and probably best left alone.
Tells the AI what proportion of PW it should set aside for road building.
Until the AI has 10 cities or more, it will not build any roads. Once it has 10 cities, it will start building a few roads.
Hmmmm, with distance unhappiness increased it may be a good idea to set this to a lower city number ... meaning maybe get it to start building roads once it has 5 cities or more. For the first 5 cities, distance_unhappiness isn't much of a problem, but beyond that ... certainly something you will have to look into.
OK, the next few sections deal with WGF and I confess that I don't understand them completely, but here's a try:
OUTPUT wgf_production[0.0, 20.0]= 7.5
tri work_forgetit_wgf_production(wgf_production, 6.0, 0.5)
tri work_little_wgf_production(wgf_production, 8.0, 0.5)
tri work_ave_wgf_production(wgf_production, 10.0, 0.5)
tri work_hard_wgf_production(wgf_production, 24.0, 0.5) // from 12
output wgf_food[0.0, 45.0]= 0.2
tri feed_lots_wgf_food(wgf_food, 0.5, 0.5)
tri feed_well_wgf_food(wgf_food, 4.0, 0.5)
tri feed_ave_wgf_food(wgf_food, 5.0, 0.5)
tri feed_nothing_wgf_food(wgf_food, 25.0, 0.5)
// increased feed nothing to 25 to keep food as low as possible
output wgf_gold[0.0,20.0]= 3.0
tri care_not_wgf_gold(wgf_gold, 0.1 , 0.1)
tri pay_lots_wgf_gold(wgf_gold, 4.0, 0.1)
tri pay_ave_wgf_gold(wgf_gold, 8.0, 0.1)
tri pay_little_wgf_gold(wgf_gold, 10.0, 0.1)
tri pay_nothing_wgf_gold(wgf_gold, 25.0, 0.1)
Note that the comment says that these numbers are weighting numbers. Meaning the AI uses these numbers internally to weight how much it wants production vs food vs gold.
For all three it seems that the less you care about any of the three, the lower the weighting number should be. Meaning, if you want to maximise your workday while keeping your wages low and your rations down, you will assign high values to to production and low values to gold and food. Since you are prioritising production (high weighting value for production) and not gold and food (low weighting values), you will pay more wages and set higher rations as a result.
Likewise, if you are a miser and want to save money, you will put a high priority value on gold and thus pay them nothing. Similarly with food, if you want to maximise growth.
From the default values it looks like production is the most important, followed by gold and then food. This is generally the right way to go about things, so long as the production is focused on growth improvements and not unnecessary numbers of units, which the AI seems overly fond of doing, at least in my games.
So nothing here probably needs to be changed, but you should take a look and make sure that the growth buildings are prioritised in the AIPs.
OUTPUT set_wgf[0.0, 9.0] = 5.0
tri growth_prod_gold_deficit_set_wgf(set_wgf, 1.0, 0.5)
tri prod_growth_gold_deficit_set_wgf(set_wgf, 2.0, 0.5)
tri growth_prod_gold_set_wgf(set_wgf, 3.0, 0.5)
tri prod_growth_gold_set_wgf(set_wgf, 4.0, 0.5)
tri prod_gold_growth_set_wgf(set_wgf, 5.0, 0.5)
tri growth_gold_prod_set_wgf(set_wgf, 6.0, 0.5)
tri gold_prod_growth_set_wgf(set_wgf, 7.0, 0.5)
tri gold_growth_prod_set_wgf(set_wgf, 8.0, 0.5)
This are probably all the defined states within the AI dll that tells it how to prioritise its wgf. growth_prod_gold for example means growth first, then production, then gold.
xref set_food_or_prod.fli, set_wgf.fli
set_food_or_prod.fli basically tells you which of the above strategies you should pursue and set_wgf.fli tells you how to implement them. You should probably take a careful look at both these files later to see whether you can tweak the AI to emphasise the growth curve more, if it isn't already doing it already. From a cursory glance, the AI does focus on growth at the start of the game, but you might want to see where it decides to level off. In most of my games I find that even though I am behind on the powergraph, I happen to have the largest 3 (or often, largest 5!) cities in the world. I've always wondered what was up with the AI - in Civ2, the AI had this tendency to grow big, fat cities, with huge production capabilities. The same should apply to CTP too, unless there are good reasons for not doing so. Maybe there are, and that is why you should first take a careful look at both files before doing anything stupid.
Hmmm, this brings me back to my question in Inputs.fli to what those extra 10% increases translate to when you talk about wages. Now ... it may just be possible, though this is but a guess, that budget_income_wages refers to how much % of your budget should be dedicated to wages.
Then the % stuff in inputs.fli makes sense because it would just indicate how much more of the budget one needs to devote to wages in order to keep the populace happy. It would also lend a stronger case to the Inputs returning percentages, rather than absolute values, which I previously noted would have no useful function. Hmmm, I think that this just might be it. Am I a genius now for figuring this out or was I simply being dense when I was looking at inputs.fli? Probably the latter.
The individual tri statements are used in the most obvious fli, the budget fli. It's funny but now that I look at the file, I wonder if I got the explanation of the budget right - it doesn't explain why the programmers would want to pay double or triple the wages just to keep the populace content. Mayhaps they want to increase workday as well? But I've looked elsewhere and I can't seem to find any other place where they tie these increased wages to increased workday or decreased rations. In any case, I wouldn't pay that much extra wages - it would stagnate my science! Maybe you should do a little testing in this department and see what happens if you bring the wages down to just slightly above what it is necessary to keep the population content.
Either that or you're misunderstanding how this whole thing works. But that's what experimenting is for I suppose.
Cool, I was right in my guess over at inputs.fli. 2 corresponds to war readiness, 1 to ready and 0 to Stand Down.
You'll want to look at this file again later to ascertain when the AI feels it is necessary to let down its guard. I guess it all depends on which school of thought you belong to - is it better to have lots of units but at half readiness level or to have less units, but at full readiness? I personally prefer the latter approach, but I'll have to give some thought into this, particularly if the AI enjoys building lots of units. Either a) you make the AI go for parity rather than overwhelming strength (which is pathetic because they are always beaten by your city walls anyway - kind of wasted strength if you ask me) or b) make them stick to at_war readiness more. I think it might be best to do both ... it would mean that the AI stops building those huge stacks that do absolute jack against your city walls. You might also want to see whether you can get the AI to build more city walls as well (actually it already seems to do this quite well - taking AI held cities is such a b*tch - whatever would you do without a siege engine?). Oh, maybe get them to build more siege engines too, if they are going to insist on building lots of stuff. Hmmm, might it be possible to make the AI put its units to better use - meaning a better mix of units? Interesting idea - might be possible if you can somehow decipher the AIPs.
OUTPUT production, food, science, happiness, defense, offense
No clue as to their function, may have been superseded since they don't seem to be used anywhere.
OUTPUT pop_gold, pop_production_max, pop_production_min, pop_food_max, pop_food_min, pop_science, pop_happiness
How the AI prioritises its specialists and its workers. Unfortunately, I have been unable to divine its inner workings. It says in the comments that 100 is 1x in principle. Well ... I'm still lost. Perhaps someone else can work the numbers out.
Maybe, (hmm actually quite possibly), it doesn't just refer to the specialists, but rather how the population is placed on tiles. That would explain the min/max pops for production and food. In fact, I just took a look at set_resource_desire.fli and that seems to confirm my suspicions. I'll leave it at that for now, later I'll take a look at set_resource_desire.fli, decipher what it means and then maybe come back here.
Hmmm, haven't I done this before? So many entries, I can't remember now. But it refers to the first 80 turns.
//the system will turn population into entertainers to satisfy min_happiness and max_crime
Cool stuff Now you know how they work out when to move their entertainers around. They will never let happiness drop below 50 or crime go above 15, which without a Courthouse and a Crime_coefficient of 1 is usually 70 happiness. Makes good sense. I wonder if the AI knows how to build Courthouses and Theaters ... check the AIPs later.
Sets the amount of PW that goes into the Terraform pool. At least this is my best guess, since I have found outputs for farms/nets, mines, roads, but no terraform. The comment also seems to say this, although it isn't entirely clear.
Calculates the ratio of each cities' growth against the nation's slowest growing city. It does this by comparing the ratio of the number of turns to next population to the number of turns to next population of the slowest city in the nation.
Low ratios mean accelerated growth, and high ratios mean slow growth.
The descriptors for the tri are a bit misleading. max_production_city_growth_ratio means that you want to maximise growth.
OUTPUT city_growth_min_percent[0.0, 1.0] = 0.15
Sets the percentage of cities the AI is using to maximise growth, in order to prevent odd city growth distributions. Good stuff.
I think this has been superseded by the individual exploration AIPs.
OUTPUT settler_packing[0.0, 10.0] = 4 //target average distance between cities
As the comment says, it sets the average distance between cities.
It all depends on whether the AI personality settles densely or loosely - refer to the individual beginturns for the personalities.
For settle_loose personalities (SciFew, SciMany), it will build its first 2 cities within 3-4 tiles of each other, after which it will build them an average of 4 tiles apart.
For settle_dense personalities (the rest), it will build its first 2 cities within 3 tiles, after which it will build them an average of 3-4 tiles apart.
This is just a general gist of the set_settler_density.fli, more information on how settler_packing affects it when I look at it later.
MODULATE THE NET UTILITY FUNCTIONS
Ok, I have no clue, so I'm going to skip this section. All of them seem to be set to 1, but it would be nice to know what all these "uscales" do. There is another gov_uscale further down, after the govts.
// science is calculated as what is left AFTER deducting wages
// savings goes directly into savings
// science and savings are summed and normalized
output budget_income_science[0.0, 1.0]=1.0
output budget_income_savings[0.0, 1.0]=0.0
This section is interesting. I wonder ... if I change what look like boolean values, I might be able to get Science to be calculated before wages? And I don't know what will happen if I set savings to 1. Or does this simply refer to budgeting and won't affect the game engine? Probably, but still - must try!
// new buildings are build only if we can pay for them with maintainance
// this is taken from total net income ( wages + science + savings)
output budget_income_new_blg[0.0, 1.0]=0.5
Ok, I think this one can be left alone. My guess is that unless wages + science + savings are above 0.5, it won't build a new building. I could be wrong, because it doesn't make any sense to include wages in this - don't wages have to be paid anyway? You could have a situation where wages make up 0.4, and science and savings 0.05 each. Would you still want to build that improvement? Hmmmm. I wonder if you could get a discernible effect by playing with this number? The thing is, you don't control the AI - you won't know what is being built. Oh, maybe if you dumped a Spy next door. To KIV.
Basically sets the priority in which you wish to research that particular government - xref from set_govern.fli.
OUTPUT inst_prod, inst_food
My guess is a weighting for how much to prioritise food improvements over production improvements.
Used in set_inst_priority.fli
OUTPUT make_farm, make_mine
I have a feeling that these have been superseded by inst_food and inst_prod. Only_farms is an if condition in set_inst_priority.fli, but it isn't called anywhere, so the if function never clicks in. In addition, both the defaults for these outputs are 0.
OUTPUT base_gold_reserve_multiple, special_action_gold_reserve_multiple
Sets the default gold reserve for the AI as well as the special action gold reserve. Used mostly in set_budget.fli, and is dependent on personality.
// how much randomly over and under should it set
// the computed force matching ratios
output min_force_matching_percent[0.0, 1.0] = 0.8
output max_force_matching_percent[1.0, 2.0] = 1.2
Sets the range 0.8 < x < 1.2 in which the AI will set force matching ratios.
I do wonder, when does the AI decide to match forces instead of just building until its told to stop? (see aiploader.fli where if its too strong it decides to stop). I certainly have not seen any other instances of force_matching in the AI files. Mayhaps directly in the dll?
Or does force_matching refer to how many it will throw into a stack in order to prevent you from busting it? Doesn't sound right, but still a possibility. In any case, it doesn't look to me that there are any instances of force matching in the AI files since there are no AI calls for equal_strength from the Input deltas. Perhaps they could be written in - in which case it would also be necessary to write a new AIP for the new 'force matching' behaviour.
OUTPUT enough_pw, too_much_renaissance_pw, too_much_modern_pw, too_much_genetic_pw
Tells the AI that it has enough PW for the time being.
END OF COMMENTS