[an error occurred while processing this directive]
[an error occurred while processing this directive]

The following was posted on our CTP-Creation forum by Tucson Luke Loh(a.k.a. Celestial Dawn) on June 12 1999
Original post http://ctp.apolyton.ctp2.info/forums/Forum11/HTML/000299.html

INPUT my_current_savings
xref set_budget.fli

Means exactly that. The AI's current savings.

If savings are more than 10,000, the AI will rushbuy anything (its default setting is only to rushbuy buildings).

INPUT desired_farm_pw, desired road_pw, desired mine_pw
xref set_inst_priority.fli

Game engine tells the FLI how much PW it wants for farms, roads and mines.

set_inst_priority.fli uses the zero_desired_XXX_pw to work out very zero_pop_science and very zero_pop_gold but I can't figure out what those mean. My best guess is that zero_pop_science and zero_pop_gold refer to whether you have Scientists or Merchants, but why you'd want zero of those when your PW is sufficient, I cannot understand. Maybe an idea will come later ...

INPUT current_military_readiness
xref diplomacy_begin.fli

This Input is duplicated, entry for entry in diplomacy_begin.fli.

peace_footing and ready_footing, while defined, are not used anywhere in the AI files.

War_footing is defined as a current_military_readiness between 1.5 and 2.5. My feeling is that the game engine returns a 0 for Peace, 1 for Ready, and 2 for War, which would explain the choice of range.

I will leave the effect of war_footing to a later analysis of the diplomacy files. Perhaps it may also not be my place to do this, since MrBaggins may understand it better.

INPUT unit_to_city_best_human_ratio
xref aiploader.fli

Returns the ratio of AI units:no of human cities.

Only a 4:1 ratio is used in the AI files - used in aiploader.fli to help determine if it should load citywall.aip and survival_mode.aip.

INPUT unit_to_city_ratio
xref set_military_readiness.fli

Returns ratio of AI units:no of its own cities.

If the AI's ratio of units:cities is less than 3.1, and it isn't in the first 150 turns, it will load unit_focus.aip i.e. build more units.

INPUT i_agreed_to_stop_polluting
xref aiploader.fli

Returns a boolean value (yes = 1, no = 0) depending on whether or not it has agreed to an eco-pact.

The aiploader.fli uses this value to determine if it should build pollution improvements.

INPUT i_can_build_wormhole_probe

Returns 1 or 0 depending on whether or not it can build the Wormhole Probe. I have a feeling that the AI uses this INPUT to determine whether it should shoot for the Alien Life project as well. Some work will have to be done to determine if the AI can cope with delayed ALP, or Bloodlust. It should be able to, unless the AI is stupid enough to try building the same X-lab components in multiple cities. I know Civ2 AI did this, but so far there is no evidence that CTP does. In any case, this bears investigation.

xref set_govern.fli

Used to determine which governments are more attractive when headed for the Alien Life Project. Interesting - how does the AI deal with Bloodlust? or a delayed project? Again, some investigation will need to be done.

xref set_pw.fli

If it can build the wormhole probe/ALP, it will set PW to 0, in order to speed completion. I wonder if the AI is intelligent enough to try Infrastructure or Capitalisation? Will have to look at the AIP files.

xref set_resource_desire.fli

If it can chase the ALP, it will set factory grunts to max and scientists to minimum. Makes sense. Just that ... what if the world is bloodlust? Or the X-lab is five times more expensive to build? Make a mental note to check if the AI actually builds multiple X-labs at the same time (normally no sane person would do this, but I know the AI in Civ2 did - hopefully this is one part of Civ2 the AI programmers chose NOT to follow). If it only builds one, then this shouldn't be a problem.

xref set_wgf.fli

Again, if the ALP is possible - it will allow a maximum (but not set it to) of 12.5 rations and prioritise production, gold and growth, in that order.

INPUT can_space_settle, can_sea_settle

Returns 1/0 whether it is possible to settle space/sea.

xref aiploader.fli

Used only to determine whether on low difficulty levels (Chieftain, Warlord and Prince) it should build more cities or not. The AI will not build many more cities than the human unless it can expand into sea and space.

There is one problem I've noted when looking at the code. It uses both can_space_settle as the input for both the yes_can_space_settle and yes_can_sea_settle functions. Probably a typo. They certainly should be able to work separately, since the input can_sea_settle is defined, and both space colonies and sea colonies are available with separate advances. I've also seen the AI build sea cities even when it doesn't have the Space Colonies advance. Typo, looks like.

INPUT diff_level

Returns 0-5 for Chieftain through Deity. Note the bad spelling for emperor and deity - you will have to use the exact same bad spelling if you intend to call on those functions. Either that, or edit it to spell right.

Used in a wide variety of files to determine appropriate response for difficulty level.

OUTPUT chieftain_test and diety_test

diety_test (sic) is unused. chieftain test is used in aiploader.fli to determine appropriate response.

INPUT most_human_city_delta

Returns (AI's cities - number of cities owned by human with most cities)

xref aiploader.fli

Only more than 4,6,8 cities are used, for handicapping the AI on the lower difficulty levels.

INPUT highest_enemy_strength_ratio, highest_human_enemy_strength_ratio

Returns ratio of AI's strength:strongest (or next strongest) opponent's strength. I am unsure what parameters are used to calculate strength. Number of military units, I presume.

Ditto for highest_human_enemy_strength_ratio, except that it is compared to the strongest human.

xref aiploader.fli

Only 2x_to_4x_stronger is used for both human and other opponents, to determine if the AI should stop building troops and concentrate on other things.

INPUT total_enemy_strength_ratio

Returns ratio of AI's strength:sum of all opponents' strength.

Unused. Not surprising, since this INPUT is not very useful. The result varies according to the number of players in a game.

INPUT allies_vs_enemies_strength_ratio

Returns ratio of AI + allies strength:sum of all other opponent's strength. This is not my allies v your allies but rather my allies v everyone else.

Again, unused - for the same reasons as above.

INPUT most_human_adv_known_delta

Returns (No of advances known to most advanced human) - (No of advances known to AI). Note the order of the operand, if the AI is more advanced, it returns a negative number.

At least this is my guess ... it seems a little unintuitive, especially when you consider that most_human_city_delta returns a positive number. To be experimented with I guess. Something silly like opening the Map Editor and giving all advances to the human and then starting diplomacy. Then set the diplomacy such that if it will automatically love the human and do whatever the human demands. If the result doesn't match expectations, then reverse the order and retry.

Unused. This function might be useful though, especially if determining if an AI civ should be worshipful or spiteful of someone who is slightly or greatly more technologically advanced.

INPUT ratio_advance_cost_me_to_best_human

Hmmm, scratch what I said in the last section. This INPUT looks to be more useful - it returns the ratio of cost of AI's current research: cost of best human's current research. In other words, if the AI researching a Modern Age advance vs the human's Renaissance, the AI will consider itself much more advanced than the human.

Weird, this is unused too. Why isn't it being used in the AI diplomacy? I find this ... strange to say the least. Whoever decides to look into the AI Diplomacy files should certainly make use of this string.

INPUT ratio_advance_cost_me_to_best_other

Same as above, but ratio to best other, not human. Also unused ...

INPUT distance_to_nearest_human_capitol

Returns distance (in tiles is my guess) to nearest human capitol.

xref aiploader.fli

Used in aiploader.fli to help determine if AI should go for city walls or enter survival mode upon encountering a human early in the game.

INPUT public_works

Returns amount of available public works.

xref set_pw.fli

Used in set_pw.fli to determine if AI has too much available public works. It then scales it back accordingly.

INPUT count

Returns a count that resets itself to 0 after it reaches 20. This is my best guess. Refer to my comments for aiploader.fli for clarification.

xref aiploader.fli

Used to set somewhat 'random' behaviour of AI.

INPUT longest_war

Returns length of war fought with longest war opponent. This does not return how long the AI has continuously been at war, but rather the length of war with its longest opponent.

xref aiploader.fli

Used to determine war rules and tactics.

INPUT shortest_peace

Returns length of continuous peace.

xref diplomacy_begin.fli, diplomacy_incoming.fli, diplomacy_outgoing.fli

Determines AI response to requests and offers. This will be looked into in more depth if I ever do the diplomacy files.

INPUT lowest_unit_regard

Returns level of relations (0=hostile, 100=love) with most hostile opponent.

xref set_military_readiness.fli

Used to determine whether or not to increase military readiness.

INPUT total_military_incursions

I am not sure what this returns, though my guess is that it returns the total number of incursions made by all enemies.

Now the TRI statements here are problematical because few_incursions, many_incursions and no_incursions are also duplicated in the diplomacy files. Since these are calls from two separate functions, it may be that true returns here may have totally screwed with diplomacy at the other end.

Since it doesn't seem like total_military_incursions is used anywhere I'd recommend removing the tri statements here or at least renaming them, in order to avoid conflict with diplomacy. I wonder if there is a possibility that this might be screwing up the diplomacy AI? For all my cursory looks at diplomacy AI, it seems that it is a model of some complexity. In practice though, it falls short. Whether its because the model didn't go far enough or because of conflicting functions will have to bear investigation. Anyway, that will come later, after I look at the diplomacy files.

INPUT percent_cost_readiness

Returns percent cost of readiness.

Unused, probably superseded by the military_readiness input. In any case, if you ever plan to use these functions, you need to remember to change the readiness costs to reflect your readiness percent cost changes. If it remains unused, it can be left alone.

INPUT at_war_count

Returns number of opponents AI is fighting.

Duplicated in diplomacy_begin.fli and called by the various diplomacy files.

INPUT land_continents_full

Returns percentage of land occupied by the AI on the continent. Meaning even if the continent is full of enemy civs, it only returns the proportion of land occupied by that AI itself. In other words, it sees enemy civ land as 'empty land' that can be taken by conquest. Doctrine of terra nullius anyone?


INPUT land_continents_full_of_friends

Returns amount of land occupied by AI on the continent, including friends.

xref aiploader.fli

Determines whether the AI should start pursuing a naval strategy, since most of its continent is already occupied by itself or by friends.

INPUT percent_wages_needed_content

Returns the percent of wages required to make the population content. I am not quite sure what 10 percent or 20 percent corresponds to because wages is paid from 2 to 6.

xref set_budget.fli

Looking at the xref didn't help me unravel this mystery either. Perhaps someone with greater familiarity with the wgf can shed some light on this issue. I don't quite understand what the percentages stand for, especially when the wages seem to be doubled or tripled on the lower percentages. To revisit.

INPUT city_delta

Returns (Government city limit) - (No of cities owned by AI)

xref aiploader.fli

Used to determine whether the AI has too many cities for its government form and determines whether it will stop building settlers and stop trying to conquer cities.

INPUT num_cities

Returns number of cities owned by AI.

Used everywhere.

INPUT time

Returns the current turn.

Used everywhere.

Note to self: Remember to change this to a suitable value for your set_govern.fli since you wish the AI to leave Tyranny once it has 5 cities or more. At present, your AI changes are cosmetic, it still is following the old 1-5 rule.

Also, there are a number of timeline issues that you may have to consider, in particular if the science rate has been slowed down. You will have to make sure the AI gives priority to Science improvements or you may have to tamper with the time inputs here too, depending on what they tell the AI to do. If they mostly deal with the ancient age, then you can leave it untouched since there have been no drastic science changes in the ancient age. If they affect post-Ancient however, you may need to keep a lookout for any of these effects. Run a thorough check on this later.

OUTPUT opening_gambit_time

opening_gambit_time = ancient time = 0-80 turns.

xref aiploader.fli

Used to determine if the AI should pursue a citywall or survival_mode.aip.

xref set_military_readiness.fli

Sets war_readiness to maximum for first 80 turns, to protect from barbarian raids and to slow down? according to the comment. Slow what down? To prevent AI from getting too far ahead? Maybe the AI might need a boost and you might want to reduce opening_gambit_time to a smaller number of turns. Before making any changes, check the conditions under which the AI will switch to lower readiness levels. This may also no longer be a problem because you raised the readiness percentages ...

INPUT size_of_world

Returns the world size.

xref aiploader.fli

Helps determine whether the AI should panic if it is found early in the game, and whether it should load masssettle.aip or masssettle_sandbag.aip.

INPUT input wgf_prod_setting, input wgf_gold_setting, input wgf_food_setting

Returns -2 to +2 depending on the current wgf setting.

wgf_gold_setting and wgf_prod_setting are presently unused.

xref set_wgf.fli

The wgf_food_setting return is used to determine whether or not to increase rations and decrease wages during a money crisis.

INPUT income_expense_cleric
input income_expense_crime
input income_expense_maintenance
input income_expense_wages
input income_expense_science
input income_expense_savings

I am unsure at this stage whether these inputs return the actual values or do they return percentages of the original gold production. My guess is percentages because actual values will differ over time and ages.

So for example, if I started with 100 Gold, and I lost 4 gold to Crime, paid 36 gold in Maintenance and 30 gold in wages, then with a 50% science rate split the remaining 15 gold to Science and 15 gold to savings, the input would return 0.04, 0.36, 0.30, 0.15 and 0.15 respectively.

Conversion income is handled a little differently, since it is added to directly to savings and does not contribute towards the Science cycle. If conversion income gave 20 gold in the above example, I assume it would return 0.20. The question here is - savings ... will it then return 0.15 or 0.35?

Of course I could be wrong and the game might just return the actual figures - but the savings example in the file seems to say differently.

I wonder if it might be possible to script the AI so that it displays text messages while you are playing a game. In this way it would be possible to read the actual returns from the inputs while within the game, and would save us a lot of educated guesswork.

Presently unused.

INPUT gold_and_wage_percent_cost

My guess is this returns the percentage of gold going to maintenance and wages.

xref set inst_priority.fli

Ah, things begin to make sense now. You will remember at the start of this comment file I talked about not understanding how zero_desired_road_pw and all the rest worked. Now I understand the statement they were used as parameters in.

If the percentage of gold going to maintenance and wages is NOT dangerously high, and you don't need any farms, mines or roads, and you have enough PW in reserve, then don't build Scientists and don't build Merchants.

This makes sense because unless the proportion of maintenance and wages is very high, you have good savings and good gold being diverted into science, so you won't need Scientists or Merchants yet.

xref set_pw.fli

If you don't have enough PW, and your maintenance and wage costs are dangerously high, and you're not focusing on building units, set your PW level to very super high.

I don't know what 'very super high' translates to in terms of %, but it makes sense - you want the PW so that you can build more mines and get more gold.

xref set_resource_desire.fli

In a gold crisis, get a lot of Merchants/Bankers (identical), cut Scientists to a minimum, and slow city growth to a minimum.

xref set_science_speed.fli

If not in a gold crisis, increase the number of scientists required in a city to the desired level of science.

xref set_wgf.fli

Tells the money_crisis output that yes, we're in a moneey crisis.

INPUT save_expense_overtime

No clue, I can only guess that it refers to the amount of extra gold you would free if you stopped the overtime.


Hmm, it seems that there is a doubling (repeated lines) of inputs here. I wonder if they could be safely removed. I would think so - will test this later.

INPUT sci_ave_turns_to_advance

Returns average number of turns to next advance.

Presently unused, but I would love to see it linked to a script or text file that could display how the AI is coping at any given stage of the game. This would allow modmakers to fine-tune their difficulty levels, and help them work out a cohesive timeline too. It would also show up any glaring problems the AI might have with keeping up in science for example. You need to seriously think about how you can get the AI files to return a text value to you within the game ... it would be so useful ...

INPUT power_ratio

No clue.


INPUT total_pop_size

Returns the total population of the AI.

xref set_food_or_prod.fli

Used to tell the AI to concentrate on maximising growth during the very early stages of the game. You might want to look at this file in more detail later, since the right way to play the game is to maximise growth all the way until happiness becomes a problem, since more pop = more prod + gold + science. Right now the AI is only doing it at game start - this should extend all the way imho. To look into later at greater length.

INPUT num_players_in_game

Returns number of players in the game.

Presently unused, but if you ever plan to use it for anything, you might need to add strings all the way up to 32.


Back to main Modification page

[an error occurred while processing this directive]