Main Page
Downloads
Preview
Preview
Features
CTP For Macintosh
Strategies
Callings
Modification
Forums
Chat
Links
Back to ACS Index

Apolyton CS: Call To Power
CTP MODIFICATION: AIPLOADER.FLI COMMENTS

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/000298.html

AIPLOADER.FLI COMMENTS

OUTPUT primary_loaded is only in aiploader.fli

primary_loaded is to make sure that the AIPs are loaded in the correct order. This is to ensure that survival_mode.aip and citywall.aip are only loaded after the personality aips have first been loaded. Personality AIPs are always loaded on the first turn (turn 0). Otherwise, not relevant.

INPUT count is xref to inputs.fli

I have no idea what count is - but it gives you reddog, low, med and high count. reddog_count is used for sally.aip and nosally.aip. If count is reddog, sally.aip - if count is (not reddog), nosally.aip. What does sally/nosally do?

sally has a higher sally_priority, which in default.aip is set to 0, where in sally.aip it is 459k and in nosally.aip it is 300k.

Ah! I just checked the other personality.aips ... other than the default.aip, the rest have no sally_priority entry in them. In other words, sally.aip and nosally.aip are the codes used to determine if the AI sallies. So what does sally mean ... do I come out from a town and beat you up?

I guess we'll have to go back to reddog to see what reddog means.

reddog counts are 3,7,10,19 with low counts 0-10, med count 5-15, high count 10-20, farm count 10.

reddog appears nowhere else but in inputs.fli and aiploader.fli, so once again, there is no guess as to what reddog means unless you understand what the INPUT count means. Maybe we should now take a look at what farm, low, med and high count do?

farm_count is xref to set_inst_priority.fli (the installation and PW build type fli) but gives the same result whether it is farm_count or not farm_count. So not relevant.

low_count has no ref outside inputs.fli
med_count and high_count appears in aiploader.fli and seems to refer to if high_count (15-20) and not med_count and not at war, then occasionally increase minimum defenders by loading pull_units_into_city.aip. If the count is 0-15, then the AI uses defend_normal.aip.

Which begs the question - what do pull_units_into_city.aip and defend_normal.aip do?

pull_units increases the number of city defenders to 5. defend_normal sets this to 1.

In addition, for low counts (0-5), the distance_from_unit_priority_modifier (lowdist.aip) is set to -5, and for the later counts (6-20), the distance_from_unit_priority_modifier (highdist.aip) is set to -500.

The distance_from_unit_priority_modifier also appears in gather.aip (-500), fallback.aip (-250) and takecity.aip (-500). My guess here is that distance_from_unit_priority_modifier refers to how far away the units are allowed to roam from their cities, since gather, fallback and takecity are the aips used when the AI conducts the phases of war.

So ... what conclusions can we make?

If count is 0-2, city defenders = 1 and the sally priority is 300k. unit_distance_modifier -5 (low)
If count is 3, city defenders = 1 and the sally_priority is 459k. unit_distance_modifier -5 (low)
If count is 4-5, city defenders = 1 and the sally priority is 300k. unit_distance_modifier -5 (low)
If count is 6, city defenders = 1 and the sally priority is 300k. unit_distance_modifier -500 (high)
If count is 7, city defenders = 1 and the sally_priority is 459k. unit_distance_modifier -500 (high)
If count is 8-9, city defenders = 1 and the sally_priority is 300k. unit_distance_modifier -500 (high)
If count is 10, city defenders = 1 and the sally_priority is 459k. unit_distance_modifier -500 (high)
If count is 11-14, city defenders = 1 and the sally_priority is 300k. unit_distance_modifier -500 (high)
If count is 15-18, city defenders = 5 and the sally_priority is 300k. unit_distance_modifier -500 (high)
If count is 19, city defenders = 5 and the sally_priority is 459k. unit_distance_modifier -500 (high)
If count is 20, city defenders = 5 and the sally_priority is 300k. unit_distance_modifier -500 (high)

As I see it, there isn't any underlying logic to how sally_priority works. For that matter, we don't even know what sally_priority does. But it seems when the count is 15-20, the AI will increase minimum defenders. Does the count level relate to a perceived threat value? Once again, we don't know.

It also doesn't make sense to have 4 separate reddog counts. If it was a perceived threat value, then reddog should always be high, but it appears to the same effect at 3, 7, 10 and 19.

So perhaps the count refers to the passage of game time? At certain times become more belligerent and increase defenders? Or perhaps the count resets itself to 0 after 20, and then it goes through the entire cycle of alternation between sallying and no sallying again? This would make sense, because then there would be 4 sallies every 20 counts.

And towards the end of that count, you would increase defenders - "occasionally increasing defenders" as the comments in aiploader.fli seems to indicate.

So you would have 3 sallies, 1 buildup and then 1 more sally before the cycle begins anew. It also looks like the AI will keep its units close for part of the game, and then lets them roam for the rest.

This also fits in with farm_count, because in set_inst_priority.fli, it also aims to get the AI to build farms on count 10, although this function was ultimately not implemented.

We don't know at this stage if 20 counts means 20 game turns, but if I am describing the function of INPUT count correctly, then this is likely.

OUTPUT warmany_test, warfew_test, scifew_test, scimany_test are only found in aiploader.fli. It determines what personality type the AI falls under, with many and few referring to whether it settles densely (cities close together) or loosely (cities further apart).

OUTPUT few_cities_test refers to the range 1-9 cities. Few cities is also referenced further down against a tri too_few_cities_test, but nowhere in the AI files does it call this tri function, so it can be safely ignored. only in aiploader.fli

OUTPUT fewplus_cities refers to the range 1-13 cities. It would seem that there is a degree of overlap between the two, but nowhere in the AI files does it make a further distinction. I guess this output is simply returned to the dll, which then interprets it the way it is supposed to. I guess the AI would then build more settlers, I suppose. only in aiploader.fli

OUTPUT early_aip - this seems to refer to the output state of whether the AI has been found by other civs early in the game. If not at war, with only 1-5 cities and the map size isn't small, the AI will then load mass_settle.aip if King, Emperor or Deity and mass_settle_sandbag.aip if Chieftain, Warlord or Prince.

In other words, the AI will then take steps to quickly defend itself early in the game in order to prevent itself being rushed by a neighbouring civ.

If not found early, it will load the AIP corresponding to its personality type. *In addition, it loads improvement_build_normal.aip, which prioritises structures. So I guess one immediate difference is that if found early, the AI will concentrate on units.

I am going to confine myself to just examining the FLIs for now, so I won't look in-depth into what mass_settle and sandbag do, and how they compare to the normal opening sequences for the personalities. This I will KIV and look into at the appropriate juncture.


TWO interesting lines then follow - and it has everything to do with human capitol distance. Note that the AI ONLY reacts this way to the HUMAN, and not other AI civs.

If the human capitol is 1-15 tiles away OR the AI has a ratio of over 4 units per human city, it will then load citywall.aip. Meaning that, even if the human capital is far far away, once it has too many units, it will also load citywall.aip.

Citywall.aip, while I haven't delved too deeply into it seems to focus on population growth (granary, aqueduct etc) and defense improvements (walls, bio-warfare filters, sdi etc).

NOTE: In this instance, citywall.aip is only ever loaded if an additional condition is met - it must be within opening_gambit_time = ancient_time, which is xref in both diplomacy_begin.fli and inputs.fli and refers to turns 0-80.

So, in other words, if it is within the first 80 game turns, and the human capitol is 1-15 tiles away or if the AI has a 4:1 unit:human city ratio (however far the human capitol is), it will load citywall.aip. *Now I don't know if the AI actually has to 'find' the human capitol or does it already know where the human capitol is at the start of the game. My hope is that it doesn't, and that the AI knows how to shield itself from knowledge it certainly possesses.

However, citywall.aip is also loaded in other circumstances, war in particular. So the above use of citywall.aip is not exclusive.

The second interesting instance is during turns 16-34, in which case it will ALSO load survival_mode.aip in addition to citywall.aip.

What does survival_mode.aip do? Again, I won't look at aip files in depth at this stage, but my guess is that it does whatever is necessary during these middle turns, when a human could conceivably try to overrun its capital to take whatever precautions are necessary in order to safeguard its existence.

Unlike citywall.aip, survival_mode.aip is only ever loaded under these circumstances. Turns 16-34, HUMAN capitol distance 0-15, or AI has 4:1 unit:human city ratio.


NAVAL.AIP is loaded whenever the present continent the AI is on is more than 2/3rds settled, by the AI and the AI's friends. In which case, it switches over to a more sea-based build order.

SUPERNAVAL.AIP kicks in when over 90% of the continent has been settled, by the AI or by its friends, in which case it kicks into heavy naval mode.

OUTPUT settle_bonus_island I assume tells the AI to settle offshore islands, as it only kicks in when over 65% of the continent has been settled, by the AI or by its friends.

It is only referenced in aiploader.fli.

OUTPUT troops_only_aip always returns zero, since there are no other IF functions that reference it. It may mean something to the AI, but at present it isn't implemented. According to the comments, the AI will build more troops if it has too few. But this may have been superseded by unit_focus.aip.

BASIC WAR RULES

This section determines what AIPs will be loaded depending on the length of the longest_war being fought. In other words, it doesn't matter if the AI has only been at war with a particular civ this turn, it bases its decision on the length of the *longest running war it has fought*. Please note that this is not the same as the number of turns it has been at war with one civ or another, but simply the longest war it is presently involved in.

start_war (turns 0-4) - getarmy.aip, citywall.aip, build_no_settlers
phase1_war (turns 0-5) - getarmy.aip, citywall.aip, build_no_settlers, gather.aip
phase2_war (turns 5-25) - getarmy.aip, citywall.aip, build_no_settlers, takecity.aip
phase3_war (turns 35-55) - getarmy.aip, citywall.aip, build_no_settlers, fallback.aip
phase4_war (turns 55-75) - citywall.aip, build_no_settlers, takecity.aip
phase5_war (turns 75-95) - getarmy.aip, citywall.aip, fallback.aip

There is a mention of endless_war in Inputs.fli, where the comment says it will go back to standard tactics. It isn't implemented anywhere however. But I think that this is pretty much dealt with in diplomacy, in phase5, it is very likely to accept a peace treaty.

As you can see, it attacks in cycles. Is this wise? I don't know - if fallback.aip is merely a regroup rather than an outright retreat, then I think the above routines work fine. More later when work is done on the AIPs.

Note also the gap between turns 26-34, I'd assume what happens then is that phase2_war continues, it simply doesn't refresh the aips.

CHECK FOR TOO MANY CITIES PENALTY

There are four outputs here, found only in aiploader.fli.

many_cities_test_happ, many_cities_test_diff, many_cities_test_total, few_cities_test

What the AI does is it checks against INPUT city_delta in inputs.fli which returns (Government city limit - AI number of cities).

If it is over its city limit, it will load NO_SETTLE.AIP, which basically tells the AI to please stop making new cities.
If it is more than 3 over its city limit, it will ALSO load SIEGE_OFF.AIP, which basically tells the AI to stop conquering cities.

On CHIEFTAIN, WARLORD OR PRINCE difficulty, the AI will handicap itself and not build many more cities than the human. It will also load NO_SETTLE.AIP if it is ahead of the human.

Under any other circumstances, the AI will load YES_SETTLE.AIP which tells it to evaluate up to 30 places to settle, and to settle 5 of them.

EXPLORE A LOT EARLY

Three outputs here, all referenced only in aiploader.fli - one_explore_aip, two_explore_aip and normal_explore_aip. These will load the relevant aips respectively.

If no of cities =1, use 1 explorer, set explore priority to 500k.
If no of cities =2-3, use 2 explorers, set explore priority to 500k.

Actually, I am beginning to think that it isn't 2 explorers, but that the figure is more of a ratio. It is more like 2 explorers PER city in this instance. For example if the number is 0.25, it will mean you want 1 explorer for every four cities. A number of 2 will mean that you want 2 explorers per city. This is a maximum figure, and isn't necessarily how many the AI builds - it prioritises what it should build based on the priority figures, but once it reaches its max limit, it won't build any more regardless of the priority.

This is my guess on how the AIPs work, but more on that later when I look at AIPs.

Actually, I'm not sure if this is a logical way of looking at things, because the AI only loads normal_explore.aip (0.25 explorers per city, explore priority 393k) once the game moves out of opening_game_strategy. Whether or not it is opening_game_strategy or not depends entirely on SET_FOOD_OR_PROD.FLI.

So this basically means that the explorer limit per city is set at 2 until the AI moves out of the opening_game_strategy phase. What it does in the opening_game_strategy phase is that until it gets 10 cities or more (hey, that makes sense) it will stick with 2 explorers per city. Hmmm, you know this might all make sense because I've always noticed that early in the game, the AI has phalanxes, and warriors and god-knows-what-else roaming around. Once I managed to lock the AI up into one corner, and he had those roaming parties trying to walk through my lands for like forever. I don't know if it's really 2 explorers per city though, I'll take a look at the AIP files in closer detail later. But its logical when you compare it to normal_explore.aip, which gives a figure of 0.25, meaning 1 explorer to 4 cities, and this kicks in once the AI has 10 cities. Well, more on this later.

DON'T BUILD MORE UNITS IF I AM TOO STRONG

If I am twice or more than twice as strong as the nearest human, OR >2x as strong as any other civ (AI civs included), and the turn count (not_ancient_time) is 95 or more, I will stop building units.

If the above conditions are met, I will load BUILD_TROOPS_OFF.AIP, which sets the build_troops_priority to 19998000.0.

If not, I will keep on building troops, loading BUILD_TROOPS_ON.AIP, which sets the build_troops_priority to 20000000.0.

Uh, not a big difference ... 2000? Maybe it may look small here but within the AIP files it might make a difference, I don't know. More on this later.

DONT RUSH THE HUMAN ON EASY DIFF LEVELS

Three outputs here, again all found only in aiploader.fli - special_actions_off_test, cleric_on_test, slave_on_test.

Basically, on Chieftain, Warlord or Prince, the AI won't use special actions against ANYONE (not just the human) in the first 50 turns. It will load special_attacks_off.AIP. This means the AI will leave everyone alone with special attacks.

After 50 turns, it will load CLERIC_ON.AIP or SLAVER_ON.AIP depending on its personality. It will then start evaluating cities to convert, soothsay and enslave.

On higher difficulty levels, the slavers start appearing from the start. Hmmm, now I know why I'll never play on the lower difficulties. You get to enslave the AI, but the AI won't do it back to you. Not really fair

OUTPUT green_me_test is only found in aiploader.fli. I think what happens here is it tells the AI dll to start building pollution improvements once the appropriate diplomacy has been done. This leads me to wonder, does the AI only ever build pollution improvements after signing a pact or will it do so as a matter of course. Because if the former is true, this means that if you're at war with a highly polluting SOB, there is no way to get him to sign an ecopact, and that will mean the world goes into global warming. I wonder if the other AIs will do diplomacy amongst themselves ... and thus do ecopacts as well. Hmmmm, it will be interesting to see how the AI conducts diplomacy among its own civs.

OUTPUT unit_focus_test is only found in aiploader.fli. If not found early (by anyone), it won't worry too much about improvements and focus on units instead. Hmmm.

What it does is load unit_focus.aip which increases the build priority to 20002000, which is again a 2k difference. Looks like what I said earlier about the build_troops_on and off AIPs was true - 2k must be a significant figure in the AIP files. Will certainly look into those later.

I must make a mental note here now to check whether this increase in unit focus comes at the expense of city improvements. Note that since it is not referenced anywhere else, and under the present parameters, unit_focus.aip is in effect for the entire game.

Most interesting! I did a search for build_troops_priority and found that the only files (other than default.fli) that set this priority are build_troops_on/off, fallback, gather, takecity and unit_focus.aip. It's also interesting that the default value is 2,000,000 and that the only departures from this default are for build_troops_off which sets it 2k lower at 1,998,000 and unit_focus.aip which sets it to 2k higher at 2,002,000.

You'll probably need to look at the AIPs later to see if these troop build priorities do come at the expense of improvements. The thing to remember here is I know quite a number of players focus on improvements, and field a mobile strike force instead, with minimal city defenders. This is an effective style of play, at least against the AI. Mayhaps we could get the AI to either i) parrot this human technique, or ii) teach it to pick its targets better? TO KIV.

GET CITY WALLS

Citywall_science.aip is loaded if citywall.aip is loaded and its within turns 0-50. Basically what citywall_science.aip does is to tell the AI what to research in order to get citywalls quick. The reason it extends a little further than Stoneworking is that it may remain active for the first 50 turns of the game.

Hmmm, a thought - since this is loaded whenever citywall.aip is loaded, and extends to turn 50, will this mean that the Cleric personalities will take a bit longer to get up to steam? (Theocracy is right at the bottom of the research list). Better check when citywall.aip is loaded ...

Oh, ok I checked through my notes - the AI only ever loads citywall.aip during war, and early in the game (turns 0-80) if the human capitol is 1-15 tiles away. But I wonder if 80 turns is too long, perhaps I might decrease this to first 40, since Stoneworking is such an early advance, you want the Cleric types to start annoying you as soon as possible. One must remember that 80 turns means 0 AD (in the original timeline), and most players would have researched Stoneworking by then. Once they have Stoneworking, they should move on to whatever their normal research order is. I think 80 turns is too much, I'd prefer to see the Religious AI start moving towards Theocracy earlier, especially now that it is pushed further back down the tech tree.

END OF COMMENTS (you will want to maybe rewrite this all later, though it seems like an awful amount of work. Let's see how the other files go first).

Back to main Modification page



Apolyton Civilization Site Copyright © Robert Plomp and Jeroen Schweitzer
All trademarks and trade names are the properties of their respective owners.