archive by month
Skip to content

the big BOSS bug with zerg

UAlbertaBot includes BOSS, the Build Order Search System, which accepts goals like “I want 12 zerglings and the speed upgrade” and calculates how to achieve them as quickly as possible, including creating the spawning pool and extractor if necessary, adding supply, building the ideal number of workers, and the exact spending sequence for everything. It does make approximations, but the build orders it produces should be close to optimal for the goal you give. UAlbertaBot by default uses BOSS to oversee its production as soon as it gets out of its opening build order.

Unfortunately BOSS also has limitations and bugs. If you give it a complex goal, it can’t run in real time (though you can still use it to create opening builds offline). And for zerg, BOSS has the bug that it will sometimes throw in an extra building that is not implied by your goal, usually an extractor, hydralisk den, or lair. I only wanted zerglings, why are you giving me a hydra den?

Blog reader Micky Holdorf looked into that bug and found the cause. Thanks for the report!

BOSS wants to search efficiently, so given your goal, it calculates the prerequisites so that it doesn’t waste time searching actions that don’t contribute to the goal. It calls this the goalMax, the most of each thing that you might want in order to achieve the goal. For terran and protoss, BOSS recursively calculates all the prerequisites and carefully counts each. Here is the code for zerg, from DFBB_BuildOrderSmartSearch::setPrerequisiteGoalMax():

    else if (getRace() == Races::Zerg)
    {
        _goal.setGoalMax(ActionTypes::GetActionType("Zerg_Spawning_Pool"), 1);
        _goal.setGoalMax(ActionTypes::GetActionType("Zerg_Extractor"), 1);
        _goal.setGoalMax(ActionTypes::GetActionType("Zerg_Lair"), 1);
        _goal.setGoalMax(ActionTypes::GetActionType("Zerg_Spire"), 1);
        _goal.setGoalMax(ActionTypes::GetActionType("Zerg_Hydralisk_Den"), 1);
    }

That’s not a calculation, that’s a stand-in! This part of the code was never written in the first place. I wonder if there was a bug in the recursive calculation for zerg, and Dave Churchill put in a stub until it could be dealt with?

Anyway, the correct fix is to write that code. One workaround is to delete the setGoalMax calls for zerg and always pass in goals that include their own prerequisites; you have to remember that you might need a spawning pool, or notice that you’ve lost yours and explicitly put it in. Micky Holdorf found another workaround with the same effect, which tells BOSS not to worry about prerequisites at all. In DFBB_BuildOrderStackSearch::generateLegalActions() change the line

            if (!goal.getGoal(actionType) && !goal.getGoalMax(actionType))

to this, which tells it that only goals and not prerequisites are legal actions:

            if (!goal.getGoal(actionType))

I don’t have any plans to write a fix for Steamhammer. If somebody sends me one I’ll certainly consider it! But Steamhammer is moving away from BOSS, because BOSS answers the opening question “how do I get this stuff as fast as possible?” and not the middlegame question “how do I spend my resources efficiently?”

Trackbacks

No Trackbacks

Comments

AIL on :

I think I just remembered, why I didn't use BOSS in my bot. ^^

MicroDK on :

:D
If the issues with zerg are fixed, it can be a powerfull tool.

Jay Scott on :

Agreed. I like to delete code that won’t be used, but I’m keeping BOSS in Steamhammer. I may use it as part of automatically developing new openings. And I think BOSS should be adequate for middlegame production planning, even though that’s not its design purpose, if you use it carefully.

AIL on :

I just found another really, really important bug involving building buildings in UAB...

Ever wondered why several workers try to build the same building?
Why constructors go back and forth and seem undecisive?

Despite there being a building-manager that should make sure everything is managed?

Because the friggin' list of buildings in Queue gets deleted and requeued all the time, not considering if it has been there before because there is no before!

void BuildingManager::cancelJob(BWAPI::UnitType type)
is abused and called incorrectly all the time. Simply removing its code lead to tremendous improvements right away. Improvements such as: Not having 5 Ultralisk-Caverns built at once cause the building-queue: BuildingManager::Instance().buildingsQueued() now actually contains items until they are actually being constructed!

Jay Scott on :

UAlbertaBot doesn’t originally have cancelJob() or anything that looks similar. I think you must have added it yourself. And yet I also have 2 unsolved bugs related to the BuildingManager, and they match your description: 2 drones trying to build a hatchery in the same place, and drones moving to the construction location then changing their minds and building elsewhere.

AIL on :

Really, I have added that? :o
Now THIS is embarrassing!

krasi0 on :

Or perhaps it was the bot itself that added it? Self-improving AI has arrived?!

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Form options

Submitted comments will be subject to moderation before being displayed.