UAlbertaBot fixes #4 and #5
#4 where are you? where are you?
CombatCommander::getMainAttackLocation()
figures out where the “main attack” squad should aim to attack. It thinks the enemy main base is the top possibility. Here enemyBaseLocation
is the location of the enemy main base (the comment is a little off), null if the enemy base location is not known.
// First choice: Attack an enemy region if we can see units inside it if (enemyBaseLocation) { BWAPI::Position enemyBasePosition = enemyBaseLocation->getPosition(); // get all known enemy units in the area BWAPI::Unitset enemyUnitsInArea; MapGrid::Instance().GetUnits(enemyUnitsInArea, enemyBasePosition, 800, false, true); bool onlyOverlords = true; for (auto & unit : enemyUnitsInArea) { if (unit->getType() != BWAPI::UnitTypes::Zerg_Overlord) { onlyOverlords = false; } } if (!BWAPI::Broodwar->isExplored(BWAPI::TilePosition(enemyBasePosition)) || !enemyUnitsInArea.empty()) { if (!onlyOverlords) { return enemyBaseLocation->getPosition(); } } }
The isExplored()
check is supposed to account for the case where the location of the enemy base has been inferred although the base has not been seen. (UAlbertaBot infers the location of the enemy base when it has seen all but 1 starting location and they’re all bare.) But the check is not correct, because of how onlyOverlords
and isExplored()
are combined.
The effect is that, if the enemy base location has been inferred, the first combat units do not go toward it but believe that the enemy base is empty. If no other enemy buildings have been seen, the squad ends up exploring the map trying to find the enemy whose location is already known. This happened in one game of Steamhammer 0.2 versus PeregrineBot, and it was the main reason that PeregrineBot won. I’ve seen it in other games too.
The exploration check can be made correct by separating it from the onlyOverlords check.
if (enemyBaseLocation) { BWAPI::Position enemyBasePosition = enemyBaseLocation->getPosition(); // If the enemy base hasn't been seen yet, go there. if (!BWAPI::Broodwar->isExplored(BWAPI::TilePosition(enemyBasePosition))) { return enemyBasePosition; } // get all known enemy units in the area BWAPI::Unitset enemyUnitsInArea; MapGrid::Instance().GetUnits(enemyUnitsInArea, enemyBasePosition, 800, false, true); for (auto & unit : enemyUnitsInArea) { if (unit->getType() != BWAPI::UnitTypes::Zerg_Overlord) { // Enemy base is not empty: It's not only overlords in the enemy base area. return enemyBasePosition; } } }
#5 there is always a building rush
Here is how UAlbertaBot checks whether it is getting proxied.
bool CombatCommander::beingBuildingRushed() { int concernRadius = 1200; BWAPI::Position ourBasePosition = BWAPI::Position(BWAPI::Broodwar->self()->getStartLocation()); // check to see if the enemy has zerglings as the only attackers in our base for (auto & unit : BWAPI::Broodwar->enemy()->getUnits()) { if (unit->getType().isBuilding()) { return true; } } return false; }
Well, there is an incorrect comment, but that’s not a bug. The routine omits one little condition.
if (unit->getType().isBuilding() && unit->getDistance(myBasePosition) < 1200)
UAlbertaBot thinks it is being proxied whenever it knows the location of any enemy building anywhere on the map. The bug causes workers to be pulled for emergency defense more often than originally intended. See CombatCommander::findClosestDefender
. Here’s the rather confusing line you may want to rewrite to change when workers are pulled for defense:
if (!Config::Micro::WorkersDefendRush || (unit->getType().isWorker() && !zerglingRush && !beingBuildingRushed()))
Comments
AIL on :
Steamhammer for example sometimes just ignores my natural because it wants to attack my main, even if the main is defended and the natural is not, causing its lings to hop back and forth instead of shredding the expansion.
What I have done is to look for the closest enemy building from the center of my bases first and possible starting-locations with a lower priority.
Jay Scott on :
AIL on :
I thought I had fixed the issue but am now unsure I ever had and whether it's a new issue or the old one still.
Ironbot is really good at triggering the crash.
Besides the crash there's a massive slipup it has against Ironbot. Ironbot likes to build turrets around my base and for some reason the Mutas keep attacking them all the time instead of avoiding them. It looks like, once again an issue with SparCraft.
Sparcraft also does not take Vulture-kiting into account, which is just super-effective against my Zerglings.
Jay Scott on :
krasi0 on :
Jay Scott on :
Ail on :
One thing where my Bot has problems in ZvZ is Muta-Timings like the one Zzzkbot uses, when I play more eco-heavy. While my Bot can get the spire just as early, the way it works right now is to not save up for the mutas and only build them one after the other, which is kinda bad if the opponent gets 6 at once. But I could let him save std::min(gas, larvaecount*100) minerals once the spire is under construction.