| 1 |
[b]Widget: Global Build Command[/b]
|
1 |
[b]Widget: Global Build Command[/b]
|
| 2 |
[img]http://s7.postimg.org/wlcemw4yj/GBC.jpg[/img]
|
2 |
[img]http://s7.postimg.org/wlcemw4yj/GBC.jpg[/img]
|
| 3 |
[b]Download:[/b] https://www.dropbox.com/s/hegj8fz9hlw8a38/GBC.7z?dl=0
|
3 |
[b]Download:[/b] https://www.dropbox.com/s/hegj8fz9hlw8a38/GBC.7z?dl=0
|
| 4 |
\n
|
4 |
\n
|
| 5 |
This is a fork and a near total rewrite of the old "Central Build AI" widget. For those not familiar, it provides a global, persistent build queue and automatically divides jobs amongst your workers. This is meant both as a guide to using it and as a place for questions, comments, bug reports, etc.
|
5 |
This is a fork and a near total rewrite of the old "Central Build AI" widget. For those not familiar, it provides a global, persistent build queue and automatically divides jobs amongst your workers. This is meant both as a guide to using it and as a place for questions, comments, bug reports, etc.
|
| 6 |
\n
|
6 |
\n
|
| 7 |
\n
|
7 |
\n
|
| 8 |
[b]Installation[/b]
|
8 |
[b]Installation[/b]
|
| 9 |
To install, unpack the archive into Your_ZK_Data_Folder(ie Documents/MyGames/Spring)/LuaUI/Widgets and enable local widgets under F10->Settings->Misc->Local Widget Config.
|
9 |
To install, unpack the archive into Your_ZK_Data_Folder(ie Documents/MyGames/Spring)/LuaUI/Widgets and enable local widgets under F10->Settings->Misc->Local Widget Config.
|
| 10 |
\n
|
10 |
\n
|
| 11 |
The widget can be found in F11->Units->Global Build Command
|
11 |
The widget can be found in F11->Units->Global Build Command
|
| 12 |
Configuration is in F10->Game->Global Build Command
|
12 |
Configuration is in F10->Game->Global Build Command
|
| 13 |
\n
|
13 |
\n
|
| 14 |
You will also need to disable the default Lasso Terraform GUI widget and enable the GBC version for proper terraform compatibility. The extra installation steps may eventually be skipped if/when it gets integrated into ZK. However being an impatient sod I decided to release it early.
|
14 |
You will also need to disable the default Lasso Terraform GUI widget and enable the GBC version for proper terraform compatibility. The extra installation steps may eventually be skipped if/when it gets integrated into ZK. However being an impatient sod I decided to release it early.
|
| 15 |
\n
|
15 |
\n
|
| 16 |
\n
|
16 |
\n
|
| 17 |
[b]Usage and Features[/b]
|
17 |
[b]Usage and Features[/b]
|
| 18 |
To use it I recommend enabling autogroup (which is enabled by default) and going into F10->Settings->Interface->Autogroup and enabling all of its options (which are [b]not[/b] enabled by default). Autogroup doesn't work very well unless you configure it, so that's something you will probably want to do. Then add every constructor type to autogroup 0 by selecting one of each and hitting [i]alt+0[/i]. Note that you can use another control group if you want, in the configuration. Also note that every level your commanders have count as separate units, so you need to add any coms at every level where you want them to be a constructor (as opposed to a combat unit).
|
18 |
To use it I recommend enabling autogroup (which is enabled by default) and going into F10->Settings->Interface->Autogroup and enabling all of its options (which are [b]not[/b] enabled by default). Autogroup doesn't work very well unless you configure it, so that's something you will probably want to do. Then add every constructor type to autogroup 0 by selecting one of each and hitting [i]alt+0[/i]. Note that you can use another control group if you want, in the configuration. Also note that every level your commanders have count as separate units, so you need to add any coms at every level where you want them to be a constructor (as opposed to a combat unit).
|
| 19 |
\n
|
19 |
\n
|
| 20 |
Once your constructors are autogrouped, you can then start giving them jobs as usual. Therein lies the true purpose of this widget: freedom. You can select any worker anywhere, queue up any building anywhere, in any order, and not have to worry about the details of how that gets carried out. Workers just magically find the closest jobs and get to work, without wasting too much time mobbing on cheap stuff, and without having to use any complicated micromanagement tricks (or sacrifice flexibility/efficiency) to keep your workers busy and well distributed.
|
20 |
Once your constructors are autogrouped, you can then start giving them jobs as usual. Therein lies the true purpose of this widget: freedom. You can select any worker anywhere, queue up any building anywhere, in any order, and not have to worry about the details of how that gets carried out. Workers just magically find the closest jobs and get to work, without wasting too much time mobbing on cheap stuff, and without having to use any complicated micromanagement tricks (or sacrifice flexibility/efficiency) to keep your workers busy and well distributed.
|
| 21 |
\n
|
21 |
\n
|
| 22 |
It can also handle repair, reclaim and resurrect jobs, and area forms of those jobs. Just queue it up and forget about it, no fuss. If that's still too much work, there are options for auto-repair and auto-reclaim-res, and although it won't auto-reclaim map features it does clean up everything else quite nicely. It can also handle all of terraform properly, including the new raise-and-build commands (with a minor exception). Every type of worker including Athenas (and basically everything they can do) are supported, and pathing is also properly accounted for so that workers will only be assigned to jobs that they can actually reach and perform.
|
22 |
It can also handle repair, reclaim and resurrect jobs, and area forms of those jobs. Just queue it up and forget about it, no fuss. If that's still too much work, there are options for auto-repair and auto-reclaim-res, and although it won't auto-reclaim map features it does clean up everything else quite nicely. It can also handle all of terraform properly, including the new raise-and-build commands (with a minor exception). Every type of worker including Athenas (and basically everything they can do) are supported, and pathing is also properly accounted for so that workers will only be assigned to jobs that they can actually reach and perform.
|
| 23 |
\n
|
23 |
\n
|
| 24 |
When queueing things with shift held, jobs are added to the queue if they are not already on it, and cancelled if they are (in general, not with area commands though). Placing a new building on top of existing queued (but not yet started) buildings will cancel any that overlap. Doing anything without shift is a direct order, and will always replace whatever conflicts with it. The widget never cancels direct orders so the unit given the order will always carry it out immediately, as expected. If you queue up move orders or similar they're added to the unit's individual queue and carried out as usual as soon as they finish whatever they're currently doing. Direct orders for build/build-related jobs [i]are[/i] still added to the queue so that other workers can see them and assist if appropriate.
|
24 |
When queueing things with shift held, jobs are added to the queue if they are not already on it, and cancelled if they are (in general, not with area commands though). Placing a new building on top of existing queued (but not yet started) buildings will cancel any that overlap. Doing anything without shift is a direct order, and will always replace whatever conflicts with it. The widget never cancels direct orders so the unit given the order will always carry it out immediately, as expected. If you queue up move orders or similar they're added to the unit's individual queue and carried out as usual as soon as they finish whatever they're currently doing. Direct orders for build/build-related jobs [i]are[/i] still added to the queue so that other workers can see them and assist if appropriate.
|
| 25 |
\n
|
25 |
\n
|
| 26 |
There is also an area-job-remove tool, which can be invoked by hitting [i]control-x[/i]. This is very useful for ditching a hopeless expansion or otherwise keeping your builders out of trouble. Note that you are solely responsible for keeping your workers alive. This widget only attempts to carry out your intentions as faithfully as possible, and does not do anything explicit to prevent your workers from dying or suiciding themselves. This is necessary in order to prevent jobs from being cancelled on the front lines for no reason, and also allows you to build right over your opponent should you decide to. Jobs are never cancelled unless you cancel them yourself, or if they're completely finished or otherwise impossible to carry out, even if the incomplete builing and/or original worker die. Also note that auto-reclaim/res and auto-repair constantly add jobs to the queue and can override area-job-removal. You may still have to manually run your workers away (or distract them with build jobs) in some situations if those options are enabled.
|
26 |
There is also an area-job-remove tool, which can be invoked by hitting [i]control-x[/i]. This is very useful for ditching a hopeless expansion or otherwise keeping your builders out of trouble. Note that you are solely responsible for keeping your workers alive. This widget only attempts to carry out your intentions as faithfully as possible, and does not do anything explicit to prevent your workers from dying or suiciding themselves. This is necessary in order to prevent jobs from being cancelled on the front lines for no reason, and also allows you to build right over your opponent should you decide to. Jobs are never cancelled unless you cancel them yourself, or if they're completely finished or otherwise impossible to carry out, even if the incomplete builing and/or original worker die. Also note that auto-reclaim/res and auto-repair constantly add jobs to the queue and can override area-job-removal. You may still have to manually run your workers away (or distract them with build jobs) in some situations if those options are enabled.
|
| 27 |
\n
|
27 |
\n
|
| 28 |
\n
|
28 |
\n
|
| 29 |
[b]Cost Models and Assignment Behavior[/b]
|
29 |
[b]Cost Models and Assignment Behavior[/b]
|
| 30 |
GBC has two different cost models for assigning workers to jobs. The default is the 'intelligent' cost model, which tries to optimize build order to improve worker and expansion safety, and to ensure that mexes are capped quickly when expanding. The intelligent model prioritizes small defenses highly, and allows up to 2 workers to build each small defense in order to get them built as early as possible when expanding. It uses a reduced priority for small energy in order to boost the effective priority of mexes, so that they tend to be built immediately after small defenses. Expensive (> 300 metal) buildings are initially given a low priority, but once started their priority immediately increases and allows for unlimited additional workers from nearby until the job is complete. This ensures that resources are spent on more important things such as small defenses before larger projects are started, and reserves as much build power as possible to complete them quickly. Cheap (< 300 metal) build jobs aside from those mentioned are all cost=distance for the first worker, and all (non-defense) cheap jobs have a very low priority for assisting. This is to allow for rapid parallel construction, and to minimize walking time for individual workers.
|
30 |
GBC has two different cost models for assigning workers to jobs. The default is the 'intelligent' cost model, which tries to optimize build order to improve worker and expansion safety, and to ensure that mexes are capped quickly when expanding. The intelligent model prioritizes small defenses highly, and allows up to 2 workers to build each small defense in order to get them built as early as possible when expanding. It uses a reduced priority for small energy in order to boost the effective priority of mexes, so that they tend to be built immediately after small defenses. Expensive (> 300 metal) buildings are initially given a low priority, but once started their priority immediately increases and allows for unlimited additional workers from nearby until the job is complete. This ensures that resources are spent on more important things such as small defenses before larger projects are started, and reserves as much build power as possible to complete them quickly. Cheap (< 300 metal) build jobs aside from those mentioned are all cost=distance for the first worker, and all (non-defense) cheap jobs have a very low priority for assisting. This is to allow for rapid parallel construction, and to minimize walking time for individual workers.
|
| 31 |
\n
|
31 |
\n
|
| 32 |
If the intelligent model is disabled in options, GBC defaults to the 'flat' cost model instead. The flat model attempts to stick more closely to cost=distance, so that you can consistently control the build order just by moving workers next to the job you want them to start. Like the intelligent model the flat model allows for up to 2 workers per small defense, unlimited assist on expensive jobs and minimal assist on cheap build jobs. However, small defenses are not given a higher initial priority, small energy is not given a priority penalty, and expensive jobs do not have an initial priority barrier to being started.
|
32 |
If the intelligent model is disabled in options, GBC defaults to the 'flat' cost model instead. The flat model attempts to stick more closely to cost=distance, so that you can consistently control the build order just by moving workers next to the job you want them to start. Like the intelligent model the flat model allows for up to 2 workers per small defense, unlimited assist on expensive jobs and minimal assist on cheap build jobs. However, small defenses are not given a higher initial priority, small energy is not given a priority penalty, and expensive jobs do not have an initial priority barrier to being started.
|
| 33 |
\n
|
33 |
\n
|
| 34 |
Both models prioritize repair, reclaim and resurrect basically the same way. Resurrect is given the highest possible priority due to its exclusive nature, and since not much else is more cost effective or useful than res. Repair and reclaim on the other hand are given a fairly low priority, since getting new things built is generally more important. Repair and reclaim both allow for two workers per job before the cost increases. For reclaim this prevents workers from trampling over trees that other workers are trying to reclaim, and helps to keep workers from wandering in front of combat units in search of unclaimed wrecks. For repair it simply makes sense to allow for more workers per unit, but keep in mind that workers easily get distracted by reclaim. This also helps keep workers from following combat units to their deaths.
|
34 |
Both models prioritize repair, reclaim and resurrect basically the same way. Resurrect is given the highest possible priority due to its exclusive nature, and since not much else is more cost effective or useful than res. Repair and reclaim on the other hand are given a fairly low priority, since getting new things built is generally more important. Repair and reclaim both allow for two workers per job before the cost increases. For reclaim this prevents workers from trampling over trees that other workers are trying to reclaim, and helps to keep workers from wandering in front of combat units in search of unclaimed wrecks. For repair it simply makes sense to allow for more workers per unit, but keep in mind that workers easily get distracted by reclaim. This also helps keep workers from following combat units to their deaths.
|
| 35 |
\n
|
35 |
\n
|
| 36 |
Note that it does not add anything that you queue up before the game starts to the global queue. All of that is passed as direct orders to your commander, and will not be interfered with. You can use this to your advantage to specify the order of your earliest buildings, where build-order can make a large difference. I typically queue up my fac and the first 3 mexes and solars before the game starts, then add expansions, radar and defences to the global queue to be picked up after that. You can, of course, arrange it however you like.
|
36 |
Note that it does not add anything that you queue up before the game starts to the global queue. All of that is passed as direct orders to your commander, and will not be interfered with. You can use this to your advantage to specify the order of your earliest buildings, where build-order can make a large difference. I typically queue up my fac and the first 3 mexes and solars before the game starts, then add expansions, radar and defences to the global queue to be picked up after that. You can, of course, arrange it however you like.
|
| 37 |
\n
|
37 |
\n
|
| 38 |
This widget is very good at building lots of things very quickly, if you have enough workers and resources. It can build lines and grids of things much more efficiently than the default, it can allow you to cap mexes all over the map more efficiently than the default area mex (which it does capture properly), and to build more stuff than you normally could with per-worker queues. You can build solars and defences along with your mexes Lauri style, reclaim spam Drone style, and lots of other things that you would never imagine being able to do with normal-human APMs. Of course if you already have superhuman APMs the amount of time it can free up can allow for even more superhuman feats; more unit micro, more time to make decisions, more big units/superweapons, etc. Testing has shown that it can easily manage 100+ workers on CCR or even reclaim all 9001 trees on quicksilver without significant lag, errors or inefficiency so you'll be hard pressed to find something that it can't handle. I intend it to be reliable enough for tournament usage, both in terms of stability and intelligent/non-frustrating behavior, and should you find that it provides anything short of that I openly welcome feedback.
|
38 |
This widget is very good at building lots of things very quickly, if you have enough workers and resources. It can build lines and grids of things much more efficiently than the default, it can allow you to cap mexes all over the map more efficiently than the default area mex (which it does capture properly), and to build more stuff than you normally could with per-worker queues. You can build solars and defences along with your mexes Lauri style, reclaim spam Drone style, and lots of other things that you would never imagine being able to do with normal-human APMs. Of course if you already have superhuman APMs the amount of time it can free up can allow for even more superhuman feats; more unit micro, more time to make decisions, more big units/superweapons, etc. Testing has shown that it can easily manage 100+ workers on CCR or even reclaim all 9001 trees on quicksilver without significant lag, errors or inefficiency so you'll be hard pressed to find something that it can't handle. I intend it to be reliable enough for tournament usage, both in terms of stability and intelligent/non-frustrating behavior, and should you find that it provides anything short of that I openly welcome feedback.
|
| 39 |
\n
|
39 |
\n
|
| 40 |
\n
|
40 |
\n
|
| 41 |
[b]Known Issues/Incompatabilities[/b]:
|
41 |
[b]Known Issues/Incompatabilities[/b]:
|
| 42 |
\n
|
42 |
\n
|
| 43 |
This widget is not without its limitations, although there are not many that I am aware of.
|
43 |
This widget is not without its limitations, although there are not many that I am aware of.
|
| 44 |
\n
|
44 |
\n
|
| 45 |
-If you place a raise-and-build command too close to another terraform it may cause the raise-and-build's building to get placed early and get buried by its own TF.
|
45 |
-If you place a raise-and-build command too close to another terraform it may cause the raise-and-build's building to get placed early and get buried by its own TF.
|
| 46 |
\n
|
46 |
\n
|
| 47 |
-The mouse cursor only sort-of changes when the area-job-removal tool is active. This is an engine issue and has been reported upstream. One day it should just magically work.
|
47 |
-The mouse cursor only sort-of changes when the area-job-removal tool is active. This is an engine issue and has been reported upstream. One day it should just magically work.
|
| 48 |
\n
|
48 |
\n
|
| 49 |
-The auto-jump widget sometimes gets freakers stuck on top of buildings, and then fails to unstick them. Sometimes this also happens to recoms, but more rarely.
|
49 |
-The auto-jump widget sometimes gets freakers stuck on top of buildings, and then fails to unstick them. Sometimes this also happens to recoms, but more rarely.
|
| 50 |
\n
|
50 |
\n
|
| 51 |
-Technically it interferes with building-starter (hold q and build), however it reimplements the same functionality internally. You may want to disable building-starter if using GBC.
|
51 |
-Technically it interferes with building-starter (hold q and build), however it reimplements the same functionality internally. You may want to disable building-starter if using GBC.
|
| 52 |
\n
|
52 |
\n
|
| 53 |
-Specific-unit-reclaimer does not work properly with GBC, but is also reimplemented internally.
|
53 |
-Specific-unit-reclaimer does not work properly with GBC, but is also reimplemented internally.
|
| 54 |
\n
|
54 |
\n
|
| 55 |
-Does not work with the auto-repair-reclaim-assist widget or the auto-repair widget. Those widgets may interfere with GBC's proper functioning by preventing workers from going idle, and GBC replaces them when used.
|
55 |
-Does not work with the auto-repair-reclaim-assist widget or the auto-repair widget. Those widgets may interfere with GBC's proper functioning by preventing workers from going idle, and GBC replaces them when used.
|
| 56 |
\n
|
56 |
\n
|
| 57 |
-This widget does not do anything with nanotowers, DO use smart-nanos!
|
57 |
-This widget does not do anything with nanotowers, DO use smart-nanos!
|
| 58 |
\n
|
58 |
\n
|
| 59 |
[b]Differences from Central-Build AI (its predecessor)[/b]
|
59 |
[b]Differences from Central-Build AI (its predecessor)[/b]
|
| 60 |
-CBAI doesn't support repair, reclaim, resurrect, or terraform.
|
60 |
-CBAI doesn't support repair, reclaim, resurrect, or terraform.
|
| 61 |
-GBC spreads workers out more; CBAI will assign as many as 3 workers to a single solar (or worse, windgen) even if there are other nearby jobs.
|
61 |
-GBC spreads workers out more; CBAI will assign as many as 3 workers to a single solar (or worse, windgen) even if there are other nearby jobs.
|
| 62 |
-GBC may have more consistent assignment behavior than CBA; units rarely if ever 'go in circles' between conflicting jobs.
|
62 |
-GBC may have more consistent assignment behavior than CBA; units rarely if ever 'go in circles' between conflicting jobs.
|
| 63 |
-CBA prefers to assign athenas to help other workers, while GBC only assigns them to jobs that they can do themselves (and prefers resurrect).
|
63 |
-CBA prefers to assign athenas to help other workers, while GBC only assigns them to jobs that they can do themselves (and prefers resurrect).
|
| 64 |
-CBA does not move workers when they're obstructing each other's jobs, while GBC does.
|
64 |
-CBA does not move workers when they're obstructing each other's jobs, while GBC does.
|
| 65 |
-CBA removes 'dangerous jobs' automatically, while GBC avoids this as a matter of policy; GBC does not make or interfere with strategic decisions.
|
65 |
-CBA removes 'dangerous jobs' automatically, while GBC avoids this as a matter of policy; GBC does not make or interfere with strategic decisions.
|
| 66 |
-CBA does not have an area job remove tool (although it may eventually include this).
|
66 |
-CBA does not have an area job remove tool (although it may eventually include this).
|
| 67 |
-GBC includes numerous bugfixes and compatibility fixes that have, at least not yet, been backported to CBA.
|
67 |
-GBC includes numerous bugfixes and compatibility fixes that have, at least not yet, been backported to CBA.
|
Global Build Command