User:Flixx/Configuration Specifications

The specifications are Work in Progress

All configurations can be implemented by aspects (inside the [ai] tag).

recruitment-instructions

Derived from trademarks forum-thread about his idea of this configuration.

I will repeat his idea here in a slightly modified form:

[ai]
  [aspect]
    id=recruitment
    [facet]
      [recruit]
        id=scout_first
        type=scout
        number=2
        turns=1,2
      [/recruit]
    [/facet]
  [/aspect]
[/ai]

Parameters inside [recruit]:

id: (string) Important if you need to access it later to modify it.
type="": (string) This key takes a comma separated list containing the unit-type, usage or level of the units that can be recruited. A value "random" means to recruit randomly all type of units. A empty string means that the AI will decide what to recruit (so "" means kind of all units).
number=-1: (integer) A number greater than 0 will tell the AI to recruit n units of each usage/unit-type for each turns specified below. -1 means as much as possible. 0 means do not recruit
turns="": (string) This key takes a comma separated list containing number specifying the turn. '-' can be used between two values to define a range. A empty String means all turns.
importance=1: (integer) The importance of a recruitment tells the AI to firstly recruit units with the highest importance. If gold is lacking or the castle is full, only the most important units will be recruited, the other will be dropped. This is useful when we want to do something like "recruit 3 scouts and if there is still money left recruit fighters".
leader_id="": (string) If the AI plays with multiple leaders who can recruit we may target only one of them. Empty sting means all leaders.
total=no: (boolean) Sometimes it could be useful to define how many units of one type should be on the map. When total is set to yes the AI will count the own units on the map and will then recruit the difference between number and the counted amount.

Notes:

If there is more then one unit specified for recruiting (with the same importance), the AI will decide what to recruit.
By default when recruitment is specified for a turn, the AI will not recruit any other unit. (So if we say recruit 1 scout in turn 1 then the ai will only recruit 1 scout and not more). To prevent this behavior one can do this:

[recruit]
   id=recruit_more_then_specified
   importance=0
[/recruit]

According to all the default values above (all types, as much as possible, all turns) the AI will now fall back when all other recruitment jobs are done.

To solve the Problem described by Coffee one could define along with [recruit] something like [count_trait_as]. There we could define that we count the trait "quick" as "scout". Then we could first recruit fighters with high importance. In a next step we recruit scouts and make use of the total flag. Discussion needed ;)

Other

recruitment-diversity

recruitment_diversity = 0.2 (double)

When this value is high, the AI will recruit more units which are currently rare on the map. (recruitment_diversity * 50 will be added to each score)

recruitment_more

recruitment_more = "Orcish Grunt" (string)

comma-separated string of unit-types ("Orcish Grunt") and/or usages ("fighter").

This is meant to let a scenario editor make a easy hack when he/she wants the AI to recruit more units of a specific type. (25 will be added to the unit-types score).

recruitment-more = "Orcish Grunt, Orcish Grunt"

is possible to add 50.

recruitment_level_pattern

recruitment_level_pattern = "0111223" (string)

unseparated list of numbers (levels)

This one is inspired by this idea in the forum. When a recruitment_level_pattern is given the AI will similar to recruitment_pattern only recruit units according to given level ratios. recruitment_level_pattern will internally expand to a recruitment-instruction (see above)

recruitment_save_money

recruitment_save_money = no (boolean)

When this flag is activated the AI will not always recruit when money is available. The AI will always keep track of the ratio our_total_unit_costs / enemy_total_unit_costs whereas the costs are the sum of the cost of all units on the map weighted by their HP. When this ratio is bigger then...

recruitment_save_money_begin = 1.0 (double)

...the AI will stop recruiting units until the ratio is less then...

recruitment_save_money_end = 0.7 (double)

This leads to wave-like recruiting. Also if the enemy hasn't recruited any units yet, the AI will only recruit a few units (with default begin/end usually one).

recruitment_spend_all_gold = 110 (int)

Only important when recruitment_save_money=yes. When the AI have earned this much gold, the AI will start spending all money to start a big offensive wave.

Old aspects

supported

recruitment_pattern="" (string)

recruitment_pattern will internally expand to a recruitment-instruction (see above)

villages_per_scout=4 (int)

The "recruitment" aspect can also be supported. Most likely [limit] will be integrated in the [facet] of the recruitment-instructions (see above).

not supported anymore

recruitment_ignore_bad_combat

Tweaking Configurations

The following configurations are intended to tweak some inner functions and weights. In order to use them one should have a idea of how the recruitment works.

Most likely I will implement those things:

recruitana-combat-weight = 1
recruitana-map-weight = 1
recruitana-counter-weight = 1
recruitana-counter-counter-weight = 1
recruitana-diversity-weight = 0

With this configurations one could adjust the weights of the scores coming from the analyse-algorithms. I want to normalize the default weight to 1 (or 0 if the analyse-algorithm is not activated by default). So one could double the impact of a algorithm by setting the weight to 2 or half the impact by setting the weight to 0.5.

This is a rather a vague guess about how some specific analysis-functions could be tweaked further. I will not specify them further yet.

recruitana-combat-range = 100
recruitana-map-village-range = 1
recruitana-counter-turns = 2

Notes

I will pay attention not to break the existing configurations 'recruitment', 'recruitment_pattern', 'recruitment_ignore_bad_combat' and 'villages_per_scout'.
Before all the analysis-algorithms run the units which are considered for recruitment (and get a entry in the score-map) will be filtered according to some configurations.
Some combinations of configurations will cause impossible instructions. For example if a recruitment_pattern and a level_pattern are given. So some configurations will overwrite others. I will the *what overwrites what* list define later.