With this goal, you are able to instruct your bot to create and upgrade buildings in your city. Build is a target, it is used to tell the bot the final quantity of buildings and levels you want in the city. For example, if you had 8 cottages in the city and wanted 9 then you would tell the bot to build 9 cottages rather than 1 more cottage. Assuming you wanted them each at level 10, you could write this as:

•  build c:10:9

Alternatively, if you had 9 cottages and wanted only 8 you would tell the bot you wanted 8 cottages rather than tell it to demolish just 1 more. Setting a building level of 0 will tell the bot to demolish the building since you want it at level "0". This would be written as:

• build c:0:8

If a building upgrade requires a prerequisite building to be completed, the bot will automatically build and upgrade the prerequisite building with priority; e.g., to upgrade a cottage to level 9, you need townhall level 8 first. The bot would upgrade the townhall to level 8 before completing a cottage build to level 9. Research goals that require a building to be completed will also be built with priority; e.g., to research machinery to level 1, the bot will build and upgrade your academy to level 9 with priority. Make sure your research goals are sensibly ordered so that you get the basics built before trying to start on level 1-9 academy!

When a prerequisite is not pending, and multiple buildings are in the same (next) goal line, then the bot will work on the fastest ones first. For example, if you had:

• build b:4:15,b:9:2

...then you've instructed the bot to build a total of 15 barracks at level 4, and a total of two barracks at level 9. The bot would get all barracks to level 4 first since working on those would be faster than upgrading two of them to level 5. It should be noted that since these goals are a target, the previous goal line would not tell the bot to build a total of 17 barracks. It's still a total of 15 barracks... building 15 barracks at level 4 is still considered "completed" even if you upgrade two of those higher to level 9.

By default the bot sets config building:1 internally if you have any build goal lines present. If you wish to disable all construction for a city temporarily, instead of adding a // or # to each build line, you can simply add config building:0 to goals.

In the 1st example above, the bot will build and upgrade a total of fifteen barracks to level 9, space permitting. In the 2nd example above, the bot will build and upgrade fifteen barracks to level 9, eight cottages to level 9, and forty sawmills to level 9, space permitting. When you've given the bot a goal to build more things than it has room for, for example fifteen barracks to level 9 when there's only fourteen slots to build barracks in, then it will build the ones it's able to and go on to the next line below it. If at any time later a slot gets cleared, it will backtrack to the previous line and build that missing barrack. When a building cannot have multiple of it's type and there's no slot available to build it, then the bot stops with the message of "Needs space: xxx" in the building tab. The same happens if the bot needs space to build a prerequisite for the building on the current goal line. For example if you tell the bot to build a stable, then it will need a farm at level 5. If it has no farm or room for a farm, it will say "Needs space: farm" and stop there until you fix the problem.

As with the troop goals, the bot performs multiple build lines in sequential order. As explained above, when building something that allows multiple of that building type (e.g. barracks/resource buildings/warehouses/cottages) it will skip to the next line(s) and continue until a slot is freed up to build on. Using this method, you can arrange goals to optimize the conversion of a npc10 in a few simple lines, e.g.:

• build b:9:15
  build c:0:9
  build st:0:0
  build fo:0:0
  build ws:0:0
  build s:9:40
  build f:0:0
  build q:0:0
  build i:0:0

With the above goals, the bot will demolish all but 9 cottages, demolish the stable/forge/workshop, and replace each slot one by one as it opens with a level 9 barrack until it has a total of 15 barracks at level 9. Once the inside of the city is complete it would move on to the resource fields. The bot would demolish all the farms, the quarry, and the iron mine, and replace them one by one as each slot opens with a level 9 sawmill until it had a total of 40 sawmills at level 9.

The bot will demolish and upgrade the lowest level of a certain building first to complete its goals. For example: if you have eight level 9 barracks, one level 8 barrack, two level 7 barracks, and one level 1 barrack and you tell the bot to build b:9:12, then the bot will first upgrade the level 1 barrack to match the two at level 7, then it will upgrade all three of those level 7 barracks to level 8, then it will upgrade all four of the level 8 barracks to level 9.

The bot will not demolish or downgrade any buildings to meet goals unless the building level or quantity is set to 0. For example: if you have a total of 16 barracks, fourteen at level 9 and two at level 10, and you set build b:9:15 for a goal, the bot will not demolish or downgrade any barracks. If you changed it instead to b:9:16 for a goal, it will not downgrade the two level 10 barracks to level 9 just because the goal says 9. If you changed the goal instead to b:0:15, THEN the bot would demolish one of the level 9 barracks and leave the two at level 10 plus thirteen more of the level 9s alone.

Using a quantity of 0 on a building will downgrade all buildings of that type until none are equal to the specified level. For example build inn:2:0 tells the bot you want 0 inns level 2 or higher. So it will demolish the inn one level at a time until it's not level 2 or higher (e.g. it will downgrade your inn to level 1). This works with multiple buildings too: build i:5:0 would downgrade all iron mines until none of them were level 5 or higher (e.g. it will downgrade all iron mines to level 4 or lower if they're already below that). If you wanted none of that type of building level, then use 0 for both quantity and level: build i:0:0 would demolish all iron mines completely.

As of the 3096 public release, you are able to use conditions in goals. Conditions are checks to see if certain buildings or research targets are met first, and if so then to perform some building task. For example, if I wanted to demolish my last quarry and my workshop after I had upgraded walls to level 10, then I could write it as:

• build ?w:10?q:0:0,ws:0:0

Looks confusing, but I promise it's not. The stuff inside the ??s is the condition. So we're checking above "if the walls are at least level 10 then demolish all the quarries and the workshop".

We can even go one step further and tell the bot to upgrade the walls to level 10 if they're not yet like so:

• build ?w:10?q:0:0,ws:0:0 w:10

The above says if walls are at least level 10 then demolish all quarries and the workshop. It also says to build the walls to level 10 (just in case they're not).

You're able to mix in research conditions as well in the build goals, like so:

• build ?met:10,w:10?q:0:0,ws:0:0

The above says if metal casting is at least level 10 and walls are at least level 10 then demolish all quarries and the workshop.

Now, just to throw in a bit of confusion for you... the ?condition?goal can be written in reverse too as goal?condition?. The following both mean the same thing:

• build ?w:10?q:0:0,ws:0:0
  build q:0:0,ws:0:0?w:10?

There is a neat trick you can use with these building conditions that may help you when writing your goals. You can use a 0 in the quantity spot for a building to tell the condition to trigger if you have no buildings of that level or higher.. for example:

• build ?i:4:0?s:9:40

The above says if I have no iron mines at level 4 or higher, then build 40 sawmills to level 9.

If you would like even more precise control over building order along with research order, check out the Plan goal.

Comfort Goal

Enable the comfort goal and the bot will automagically perform comforting on your city as required. This goal along with config gate:[time], config hiding:[time], config npc:[level] all working together can make your cities virtually impossible to capture. With comforting activated the bot will raise loyalty, reduce grievance, adjust tax rates to prevent riots, and perform miscellaneous comforting actions as specified in comfortpolicy. Comfort can be used by itself or along with comfortpolicy. If you want to use comfortpolicy, this goal is required.

Comfort Script

Performs one of the comfort commands in the city that it is run from.

This policy adds additional comforting and levying functions on top of the normal praying/disaster relief that it will do for grievance and loyalty maintenance. You do not need this policy if you only want your bot to maintain 100 loyalty/0 grievance. Config comfort:1 is enough for that. ComfortPolicy must be used with config comfort, but config comfort does not need comfortpolicy.

In the example above, the bot will perform population raising, if needed, every 15-20 minutes.

You may include any levying or comforting option in this, e.g., comfortpolicy 15 20 popraise wood pray, to have the bot perform population raising if needed every 15-20 minutes, and if not then levy wood every 15-20 minutes and follow with a prayer every 15-20 minutes whether it's needed or not.

Be careful of adding praying or disaster relief to comfortpolicy with a larger account. You will very quickly be tossing away 10 million food per cycle if you do.

This policy will tell the bot how far, in miles, it may go from your city to perform these actions in order. This number must be a whole number between 5 and 50.
Beginning with version 2695, the maximum limit in miles is 150, rather than 50.

Distancepolicy supports fractional numbers, ie - 10.5 miles.

In order the numbers signify the distance for: npc farming, then npc building, then medal or valley farming, then valley acquisition, then map scanning and view distance.

This goal tells the bot how many slots empty you want in your feasting hall in regards to automatic hero hiring. One space is reserved by the bot for the TrainingHero regardless of this goal.

As an example, if you set config feastinghallspace:4 the bot will stop hiring new heroes when there are 4 spaces plus 1 for the traininghero.

It is important to note the bot does not automatically hire heroes just because this goal is set. You must still use another goal, e.g. FastHero, if you want the bot to hire them.

This directive will tell the bot to build wall defenses for your city. Just like the troop goal, fortification is read line by line in sequential order. In the example above, the bot is told to build 1 trap, 1 abatis, and 1 AT, then build 10 traps, 10 abatis, and 10 ATs, then build 100 traps, 100 abatis, 100 ATs, and 10 trebs, then build 3000 traps, 3000 abatis, 15000 ATs, and 200 trebs.

If the bot is currently working on building the 4th line of fortification goals, and you get attacked and you lose part or all of your wall defenses, with the above settings, the bot will stop queuing the 4th line and instead complete the goal of 1 trap/abatis/AT again from the 1st line, then go to the 2nd line and build the 10 traps/abatis/ATs, then go to the 3rd line and build the 100 traps/abatis/ATs and 10 trebs, then resume where it left off on the 4th line.

During an attack on you, the bot will read and build 1 of each type of wall defense listed on the 1st line of fortification goals with emergency priority. By setting these queue goals wisely, you can make yourself quite hard to break.

You can disable wall building via goals with config fortification:0.

By default, the bot will attempt keep 1 day's worth of food in each city. The bot will not queue wall defenses if doing so would bring it under this amount of days. You can override this behavior and allow it to continue to queue new fortifications by enabling this goal.

When this goal is turned on, it will tell your bot that you do not want it to heal injured troops in the medic camp.

With this goal turned on, the bot will not keep a mayor appointed in the city. This will allow the politics hero to be sent out on farming runs.

Note - you should use config trainpol:1 instead of config nomayor:1 to allow the politics hero to farm npcs and still be appointed mayor when it is not on a npc run.

This policy will allow you to instruct the bot the priority with which it will try to perform its tasks such as npc farming, valley acquisition, etc.

By default all tasks have equal priority in the bot, so the bot would try to send out roughly the same number of each task. For example, after a few hours of running, the bot would have attempted to send out the same number of npc farmers as it would have medal farmers, if both tasks were equal in priority in your goals (or not specified at all). Troops, heroes, or farming targets could prevent it from actually sending equal amounts of course. Each time the bot sends out a mission of a certain type, it will accumulate a higher internal point value on that task. Tasks with the lowest points will be given priority to perform first, when possible.

You can specify one or more tasks to have higher priority than some or all others. For example, if you used in goals processingpolicy n:10 m:20 then medal farming would have a 2x higher priority than npc farming, and roughly double the number of medal farmers would be sent to the number of npc farmers. Once again, if you have heroes or troops limiting medal farmers or just don't have the valleys to farm, the bot may not be able to keep the ratio you desire.

The default priority for any task is 10 if not specified. You can however specify some lower than that. You are also able to use the * (asterisk) symbol to include any task not specified. For example, processingpolicy n:10 m:20 *:5 in your goals would mean to give 10 priority to npc farmers, 20 to medal farmers, and 5 to everything else. In that example, there would be roughly 4x more medal farmers sent out as anything else, 2x more npc farmers sent out as anything else, and 2x more medal farmers sent out than npc farmers.

You can turn off certain tasks using the ! symbol. For example, processingpolicy !b would disable npc building completely. You can even use the * to disable everything but what you specify. For example, processingpolicy m:10 n:20 a:30 !* would give medal farming a priority of 10, npc farming a priority of 20, valley acquisition a priority of 30, and disable everything else.

Disabling a task in processingpolicy can be written a few ways for your convenience. The following examples all mean the same thing - disable npc building:

•          processingpolicy !b
           processingpolicy b:0
           processingpolicy b:off
           processingpolicy b:false
           processingpolicy b:no

You can also specify times to turn on or off certain tasks. For example, if you wanted to disable npc farming between the hours of 1pm and 2pm, you could do processingpolicy /start:13:00 /end:1400 !n

Processingpolicy allows using = instead of : in all places as well for your convenience. The following examples both mean the same thing - disable npc farming between the hours of 1pm and 2pm:

•          processingpolicy /start:13:00 /end:14:00 !n
           processingpolicy /start=13:00 /end=14:00 !n

Using the = is not limited to just timed policies. You can use it freely in all processingpolicy goals, for example processingpolicy n=10 b=20 a=30 works too.

This policy will allow you to set the maximum number of each mission that can be done at the rally spot. This goal does not reserve rally spots for these tasks, nor does it increase the default limit on these tasks; it merely limits how many it can do at one time.

Rallypolicy counts both returning and marching missions in its total.

For npcfarming, you can limit not just by total missions, but also missions for each level of npc. In the example above, n:10:1 would limit to 1 npcfarming mission to level 10 npcs, while n:8 would limit ALL npcfarming missions (including level 10s) to 8 total. You could also write the level as a n:*:8 to account for any level, but it would be quicker to just write n:8.

This directive will tell the bot which reports you want it to keep.

In the above example, any report with a treasure acquired will be kept because the first number is set to "1". Any valley attack report will be kept if the archers lost in it are 500 or more. Any npc5 attack report will be kept if 1 or more ballistas are lost. Any npc10 report will be kept if the archers lost are lower than 3.8k or higher than 6k. All other reports will be read and deleted by the bot.

You can set these numbers to 0 in order to have it keep every report, i.e., reportstokeep 1 a:0 b:0 a:0 a:0.

With the recent changes to Evony's reports system, the usefulness of this goal is only when you are offline during a report.

This policy will tell the bot the range of tax you want set.

The first example above would maintain a minimum 20% and maximum 100% tax rate. If the bot detects that additional gold is necessary to prevent a revolt, it will increase the tax rate as necessary, up to "max_rate".

The second example above utilizes the optional war time tax rate. It would maintain a minimum 20% and maximum 100% tax rate during peacetime, and set 30% tax rate if it enters defense mode.

The default values are 0 (min) and 100 (max). A default of 0 (min) allows the bot to maintain maximum population. Players with established accounts will probably wish to use the defaults.

This goal allows you to tell the bot how many hours per individual wall queue you want. It is recommended to adjust this number as your mayor's politics attribute grows, so that the bot can utilize your time more efficiently. If this is not set, the bot defaults to 15-minute queue times.