Contents
Troop
| Usage: | troop troops_to_queue |
|---|---|
| Example: |
troop p:1,sw:1,cav:1 |
| Switch: |
/increment: |
| Example: |
troop /increment:0.1 /queuetime:.5 b:5k,t:5k |
This directive is how you tell the bot what troops to queue for you. The bot reads each line from left to right, top to bottom. The bot will not move on to the 2nd troop line until the 1st line is completed, and if at any point in time a previous line becomes invalid (eg, you get attacked and lose all your pikes) the bot will drop back to the 1st incomplete line to finish that one first.
Using the above examples, the bot will first build 1 pike, 1 sword, and 1 cavalry in that order. Once complete the bot will then build 100k archers, 5k ballista/trans, 15k warriors, 5k workers/pikes/swords/scouts, 1k cav/phracts, and 5 rams/pults. Once that's completed the bot will then build 50k warriors, 15k pikes/swords, 50k scouts, and 200k archers. Once that's completed the bot will then build 250k archers, 100k scouts, 10k cav, and 5k phracts. Finally, the bot will start building 400k archers, 200k scouts, 10k ballista/trans.
If the bot is currently working on building the 4th line of troop goals, and you get attacked and you lose all your cavalry and pike, with the above settings, the bot will stop queuing the 4th line and instead build 1 pike/cav again from the 1st line, then go to the 2nd line and build the 5k pike and 1k cav, then go to the 3rd line and build the 15k pike, then resume where it left off on the 4th line.
The bot also allows switches to individual troop goal lines that will override the default and configured troop settings. If no switches are specified, the bot will use the configured goals for all troops, or the default settings if both are lacking.
During an attack, the bot will read and build the 1st line of troop goals with emergency priority. A reserved barrack, if you have one, will be used to (re)build the troops specified in the 1st line (hopefully you put layers in there) with the best available attack hero.. rather than simply queue the troops behind other builds after waiting for the traininghero to arrive.
Troopqueuetime
| Usage: | config troopqueuetime:[hours] |
|---|---|
| Example: |
config troopqueuetime:2 |
This goal allows you to tell the bot how many hours per individual troop (each slot in each barrack) queue you want. It is recommended to adjust this number as your traininghero's attack attribute grows or number of barracks changes, so that the bot can utilize your population and time more efficiently. If this is not set, the bot defaults to 15 minute queue times.
Troopsusereserved
| Usage: | config troopsusereserved:[switch] |
|---|---|
| Example: |
config troopsusereserved:1 |
By default, the bot will attempt keep 1 day worth of food in each city, or the number of days specified in config extrafood. The bot will not queue troops if doing so would bring it under this amount of days. You can override this behavior and allow it to continue to queue new troops by enabling this goal.
Enabling this without knowing what you're doing could cause the bot to send your city into refuge!
Troopsusepopmax
| Usage: | config troopsusepopmax:[amount] |
|---|---|
| Example: |
config troopsusepopmax:1 |
By default, the bot will only use your idle population to queue new troops. You can allow it to use your entire population, by dropping production temporarily, by setting this to '1'. The bot can also use a percentage of your total population by using a number lower than '1', eg: config troopsusepopmax:0.5.
Troopincrement
| Usage: | config troopincrement:[amount] |
|---|---|
| Example: |
config troopincrement:.01 |
By default, Y.A.E.B. will queue troops in the order you specify from left to right, on each sequential 'troop' line. By setting this goal, you can tell the bot to instead queue a percentage or specific amount of each troop on the line. For example, if your goals contained:
troop w:100000,s:100000,p:100000,sw:100000,c:100000,t:3500,b:3200,a:300000
The bot will first train 100k warriors, then 100k scouts, and so on without troopincrement set.
If given the line above and using config troopincrement:0.01 then the bot will instead queue 1000 warriors (1%) and then queue 1000 scouts (1%), continuing down the line until it runs out of resources, population, open barracks, or troops to queue, and then restarting at the beginning of the line to rinse and repeat until the entire line goal has been met.
For the percentage challenged, the bot will also accept whole numbers as the actual amount to queue, eg: config troopincrement:500. In this case the bot will queue 500 warriors then 500 scouts then 500 pike, continuing down the line, and then restarting at the beginning of the line to rinse and repeat until the entire line goal has been met.
Note that the bot does work left to right in the current troop line with both percentage and whole number increments. If the traininghero stops queue'ing due to moving, lack of resources, lack of population, etc. then it will restart back at the start of that line to queue the whole number or percentage specified again. This means that you may finish the first several troop types on a line before it ever gets to start on the next several of that same line if the bot uses up all it's available resources/population before all the barracks are filled.
If config troopincrement:1 is set, the bot will enter ratio-based troop building. What this means is the bot will produce different types of troops simultaneously while trying to maintain the troop ratio as specified in the troop goal. The bot will maintain a balance in total percentage completed of the entire goal, for every troop. Meaning all troops must be at an equal percentage of total completion, or it will focus on the troop(s) that are below that average percentage.
Example 1: Suppose you have 50k warriors and 50k archers, and the bot works on the following goal:
# note the goal specifies that you want to have 2.5 times more warriors than archers troop w:2.5m,a:1m
The bot will first build warriors until you have 125k of then (i.e. 2.5 times more than the number of archers). Once you have 125k warriors (already available + queued), the bot will start producing both warriors and archers while trying to maintain the ratio between warriors and archers at 2.5:1. By the time you have 200k archers, you will also have 500k warriors. At 400k archers you will have 1m warriors, and so on.
Example 2: Suppose you had multiple lines like that:
troop a:100000,s:100000,c:2000 troop a:200000,s:200000,c:4000 troop a:300000,s:200000,c:6000 troop a:400000,s:300000,c:8000 troop a:500000,s:400000,c:10000
With ratio-based production mode enabled you can replace the above with just one line:
troop a:500000,s:400000,c:10000
If you lose some troops, the bot will automatically rebuild the ones you lost first due to them falling below the the total % completed in ratio to the rest of the troops completed, then continue with building all listed types of troops.
Troopidlequeuetime
| Usage: | config troopidlequeuetime:[minutes] |
|---|---|
| Example: |
config troopidlequeuetime:5 |
When a traininghero is configured, but not currently present, and there are idle barracks available, the bot can now use the best available hero to queue troops in small batches. This goal will set the amount of time per batch, in minutes, for the idle queue.
The default value is currently 0 (disabled) for non ratio-based mode. In ratio-based mode (when troopincrement:1) the default idle queue time is 1 minute.
The bot will look at best available hero vs. traininghero for each troop type to decide whether to use idle production or regular. For example, if traininghero is 360 attack and best idle hero in town is 300 attack, both have 1 second warriors. If warriors need to be built, it will do the full amount with the available hero rather than building small amounts or waiting on the traininghero to arrive.
Troopidlequeuetime:xx is how many minutes can be queued in the barracks in relation to what the traininghero would take. Example: config troopidlequeuetime:1. This means it will queue a batch size that will not take 1 minute longer than the traininghero would take to queue the same thing. This can mean larger queues for better heroes.
Troopdelbadque
| Usage: | config troopdelbadque:[switch] |
|---|---|
| Example: |
config troopdelbadque:1 |
By default, the bot will always use your traininghero to queue troops. If you do not have one set, the bot will attempt to use the highest attack hero available in the city. Sometimes you may queue manually, or lag may cause the bot to queue with the wrong hero. In this case, the bot recognizes the queue as 'bad' because it is not an optimal time to completion. With this enabled, the bot will sometimes cancel these bad queues so that it can replace them with good ones using the right hero. Do not enable this if you have instant troops hidden in the barracks behind deliberately slow builds that you plan to cancel when the instant troops are needed.
Reservedbarrack
| Usage: | config reservedbarrack:[switch] |
|---|---|
| Example: |
config reservedbarrack:1 |
By enabling this, the bot will reserve 1 barrack in the city free of queues to use to build instant troops and to build the first of your 'troop' goal lines when under attack.
Keeptroops
| Usage: | keeptroops city_name troops quantity |
|---|---|
| Example: |
keeptroops OtherCity w:100k,s:400k,p:100k,sw:200k,a:400k 10k |
This goal will tell the bot to automatically send troops to another city when it reaches more than the amount you specify. In the example above, when ThisCity has more than 100k warriors, or 400k scouts, or 100k pikes, or 200k swords, or 400k archers then the bot will send extras to OtherCity in increments of at least 10k. When combined with troop goals set higher than these amounts, the bot would continually queue troops to be sent to another city. This can be useful to stock or restock a war city or continually rebuild troops for a npc10 farming city.
This goal is being phased out in lieu of the newer and more powerful sendtroops command.
Sendtroops
| Usage: | sendtroops coords trooptype local_min remote_min quantity |
|---|---|
| Example: |
sendtroops OtherCity|AnotherCity archer 300k 200k 10k |
This goal will tell the bot to automatically send troops from this city to another one when it reaches an amount over what you specify and if the other city has an amount under what you specify. This goal can be useful to constantly restock another city that farms npc10s, or have several building/feeder cities that build troops for a war city to accumulate.
A city can have as many sendtroop goal lines as desired, with each one containing a different troop type and/or city to send troops to. The city to send to parameter can be written as coordinates (111,222) or the city name if same account (OtherCity) or to encompass any city (any) or as multiple city names or coordinates seperated by the | symbol (City1|City2|City3 or 111,222|111,223|111,224).
As with the sendresources and requestresources directives, sendtroops and requesttroops are also able to use -1 as a parameter. The -2 parameter can be used for the remote quantity to force the bot to behave more like the older keeptroop goal (sending quantities of at least the amount specified, but more than it if possible).
In the 1st example above, if ThisCity has more than 300k archers, and either OtherCity or AnotherCity has below 200k archers, then ThisCity will send OtherCity or AnotherCity archers in increments of 10k. Note that ThisCity would need to have 310k archers to begin with before sending 10k away, to avoid putting itself below the 300k minimum.
In the 2nd example above, if ThisCity has more than 300k archers, then it will send in increments of 10k to 111,222... regardless of how many archers 111,222 has, as long as ThisCity doesn't fall below 300k.
In the 3rd example above, if ThisCity has more than 300k archers, and OtherCity has below 200k archers, then ThisCity will send OtherCity as many archers as needed to bring OtherCity up to 200k, while keeping ThisCity above 300k.
In the 4th example above, if OtherCity has below 200k archers, then ThisCity will send it archers in 10k increments until it gets above 200k, regardless of how many archers ThisCity has.
In the 5th example above, if ThisCity has more than 300k archers, then it will send all archers over that to 111,222, regardless of how many 111,222 has and how many it sends at a time, as long as the minimum send is at least 10k archers.
Requesttroops
| Usage: | requesttroops coord type local_min remote_min remote_request |
|---|---|
| Example: |
requesttroops OtherCity archer 200k 300k 10k |
This goal will tell the bot to automatically request troops from another city to this one when it reaches an amount under what you specify and if the other city has an amount over what you specify. This goal can be useful to constantly restock a warcity or city that farms npc10s from remote feeder/builder cities.
A city can have as many requesttroop goal lines as desired, with each one containing a different troop type and/or city to request help from. The city to request from parameter can be written as coordinates (111,222) or the city name if same account (OtherCity) or to encompass any city (any) or as multiple city names or coordinates seperated by the | symbol (City1|City2|City3 or 111,222|111,223|111,224).
As with the sendresources and requestresources directives, requesttroops and sendtroops are also able to use -1 as a parameter. The -2 parameter can be used for the remote quantity to force the bot to behave more like the older keeptroop goal.
In the 1st example above, if ThisCity falls below 200k archers, and OtherCity has more than 300k archers, then ThisCity will request OtherCity send archers to it in 10k increments. Note that OtherCity would need 310k archers before 10k would be sent away, to prevent it falling below 300k itself.
In the 2nd example above, if ThisCity falls below 200k archers, then request 10k archers from 111,222, regardless of how many archers 111,222 has. With this line, the bot will keep requesting archers, 10k at a time, until ThisCity has at least 200k or 111,222 runs out of archers.
In the 3rd example above, if ThisCity falls below 200k archers, and any other city has more than 300k archers, then it will request as many archers at once as it takes to achieve 200k archers in ThisCity, without putting the other city below 300k.
In the 4th example above, the bot will request 10k archers at a time be sent from OtherCity to ThisCity, regardless of how many archers are in ThisCity and as long as OtherCity doesn't fall below 300k archers.