Loading...
  OR  Zero-K Name:    Password:   

Global Build Command

43 posts, 2197 views
Post comment
Filter:    Player:  
Page of 3 (43 records)
sort


USrankaeonios
3 years ago
(edited 3 years ago)

Widget: Global Build Command

Download: https://www.dropbox.com/s/hegj8fz9hlw8a38/GBC.7z?dl=0

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.


Installation
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.

The widget can be found in F11->Units->Global Build Command
Configuration is in F10->Game->Global Build Command

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.


Usage and Features
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 not 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 alt+0. 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).

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.

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.

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 are still added to the queue so that other workers can see them and assist if appropriate.

There is also an area-job-remove tool, which can be invoked by hitting control-x. 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.


Cost Models and Assignment Behavior
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.

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.

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.

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.

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.


Known Issues/Incompatabilities:

This widget is not without its limitations, although there are not many that I am aware of.

-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.

-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.

-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.

-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.

-Specific-unit-reclaimer does not work properly with GBC, but is also reimplemented internally.

-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.

-This widget does not do anything with nanotowers, DO use smart-nanos!

Differences from Central-Build AI (its predecessor)
-CBAI doesn't support repair, reclaim, resurrect, or terraform.
-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.
-GBC may have more consistent assignment behavior than CBA; units rarely if ever 'go in circles' between conflicting jobs.
-CBA prefers to assign athenas to help other workers, while GBC only assigns them to jobs that they can do themselves (and prefers resurrect).
-CBA does not move workers when they're obstructing each other's jobs, while GBC does.
-CBA removes 'dangerous jobs' automatically, while GBC avoids this as a matter of policy; GBC does not make or interfere with strategic decisions.
-CBA does not have an area job remove tool (although it may eventually include this).
-GBC includes numerous bugfixes and compatibility fixes that have, at least not yet, been backported to CBA.
+12 / -0



AUrankAdminGoogleFrog
3 years ago
Would you be able to write the entire worker handling and economy parts of an AI?
+2 / -0


USrankaeonios
3 years ago
AUrankAdminGoogleFrog Probably. :P It'd require some coordination to ensure that the responsibilities of each part of the AI were well separated, but overall it wouldn't require much modification from this.

Actually deciding what to build and where would be better handled by a strategy module though, IMO. Building e-grids apparently requires something else, which I don't know much about but I could probably figure it out one way or the other.

+0 / -0



AUrankAdminGoogleFrog
3 years ago
I haven't work on the new AI in a while but it does have modules. You could try to imagine where an economy and structure placement module would fit in. Perhaps I should think up a module diagram so I know what else needs to be written and can finish it off.

https://github.com/ZeroK-RTS/Zero-K/tree/master/LuaRules/Gadgets/CAI
+0 / -0


GBrank[Fx]Drone
3 years ago
wheres the tl;dr?
+0 / -0


USrankaeonios
3 years ago
tl;dr:

1) Install/Enable the widget
2) Configure autogroup and add your cons/coms to autogroup 0
3) Enable the 'always show' option in the widget so that you can see what it's doing

If it isn't doing what you want it to, check the options to see if you can find what you're looking for. If that isn't working for you, then you can ask about it here.


+3 / -0



RUrankAdminikinz
3 years ago
(edited 3 years ago)

I tried fighting some bots with it and about 15 minutes in it crashed with
quote:
[cawidgets.lua] Error: Error in GameFrame(): [string "LuaUI/Widgets/unit_global_build_command.lua"]:2103: attempt to perform arithmetic on local 'x1' (a nil value)
[cawidgets.lua] Error: Removed widget: Global Build Command

http://zero-k.info/Battles/Detail/349569
+0 / -0


USrankaeonios
3 years ago
(edited 3 years ago)

RUrankAdminikinz
Hmm, well basically that indicates that it was trying to get the location of a worker that was already dead. I've had problems with that before, which I thought I solved already, but apparently lag/async calls from spring can cause it to miss units that die in the same frame that jobs are assigned. I added extra guards to prevent that from causing it to crash and updated the download link.

I appreciate the informative report. :P

EDIT: I recall now dealing with a similar problem, where I realized that GameFrame was being called before other functions such as UnitDestroyed. That explains the crash, and I reported the issue upstream since the way it currently works is dumb and forced me to write a bunch of unnecessary validity checks. It should be fixed now anyway.
+0 / -0

ROrankJoeDoe
3 years ago
This is good until it stops working randomly. I can reset it with /luaui reload. But its very annoying.
+0 / -0



AUrankAdminGoogleFrog
3 years ago
So that sounds like I shouldn't merge the PR yet. You could try posting your infolog to see if USrankaeonios fixes it.
+0 / -0


FIrankVermind
3 years ago
This is pretty amazing.
You still need to control your commander and his build queue is different from other constructors.
+1 / -0



CHrankAdminDeinFreund
3 years ago
Wow, this sounds interesting!
Thanks for documenting it so nicely, CSI can surely make use of that cost function(if you dont mind).
+0 / -0

ROrankJoeDoe
3 years ago
This can be used to spam blueprints all over the map VERY fast. Blocks everything with just a few air cons. Someone should add a limit or something. :D
+0 / -0


PLrankAdminSprung
3 years ago
Blueprints as in 1% nanoframes? That's not the GBC, hold Q when queueing a building to do that.
+1 / -0



CHrankAdminDeinFreund
3 years ago
Sadly it seems to always crash after some time when I try using it. When it's about sth as important as constructions, the wubget has to be reliable. :(

I could try to reproduce and supply infolog if that helps.
+0 / -0

ROrankJoeDoe
3 years ago
I have not been able to reproduce the crashes either. I suspect a crash due to multiple reclaim commands and a dead worker crash.


+0 / -0


USrankaeonios
3 years ago
I've been aware of the crash issues for some time. Some evil things happened so I haven't been able to do anything productive in recent history, but I'll probably get around to fixing that soon. Unfortunately I haven't been able to track down the precise cause of the crashes (even with infolog data) and it's also difficult to reproduce.

Also, to anyone who wants to use any part of this in your AI or whatever, feel free. I didn't write all those comments for nothing!
+0 / -0


USrankaeonios
3 years ago
Updated the first post with a new version.

-Fixed an issue that could cause screwy behavior when giving build commands as direct orders.

-Implemented a proper fix for the issue where it would try to assign work to dead units.

-Implemented a fix for the issue where units were sometimes listed as having an assigned job, but the job didn't exist on the queue. I still don't know exactly why that happened, but it should no longer cause GBC to crash.

If you do find it crashing, infologs please!
+0 / -0




EErankAdminAnarchid
3 years ago
WB USrankaeonios :)
+1 / -0


USrankaeonios
2 years ago
I fixed some random things, including:

-A bug where resurrect jobs might get removed from the queue twice, causing a crash.
-A bug where convert to res did not respect the user's settings in options.
-A bug where cranes were not being handled properly by constructor separator, causing them to get stuck in 'drec' mode.

On an unrelated note, someone recently modified cmd_mex_placement and broke compatibility of area mex with GBC and CBAI, which I'll have to fix before releasing a new version. Apparently someone might convert control-w into a full template-build system instead of just area mex, which is cool but it means I'll probably have to edit it for compatability again when it's finished.
+0 / -0
Page of 3 (43 records)