the refinery bug and the extractor trick
BWAPI 4.1.2 has two bugs that (it seems to me) pinch zerg hard. One is the hive research bug that prevents a bot from doing lair research in a hive (and related bad stuff). This bug is why Steamhammer so rarely gets overlord speed; it wants a fast hive. Someday I’ll work around it as best I can, either making a second lair or spending on overlord speed first whether or not it is needed at the time.
But today I want to talk about the other bad bug, the extractor bug. In BWAPI 4.1.2, when a gas mining building of any race is destroyed or canceled, the geyser goes dark: It is treated as a unit which is out of your vision, and you can’t get information about it. geyser->exists() returns false, even when you are standing next to it and it’s in plain sight.
UAlbertaBot and Steamhammer are unable to take the dark geyser. That is why, when Steamhammer loses its gas, it never retakes it. The geyser is permanently lost to it.
I’ve never seen it done, but in principle the bug could be used offensively: Take your opponent’s gas but cancel your refinery building immediately. Do it again in the natural, if you like. Against a BWAPI 4.1.2 bot, the geyser goes dark permanently. Steamhammer would have little chance to recover. Rules don’t forbid it; after all, it is in a sense Steamhammer’s own fault that it can’t recover—nobody required it to use a buggy library.
I hit this bug back in Steamhammer 1.0 when I implemented the extractor trick: At 9/9 supply, start an extractor which uses up a drone and takes you to 8/9 supply; make a new drone, returning to 9/9; cancel the extractor, getting 10/9 supply. I wanted to try the old school 10 hatch opening which is strong against 2 gate zealot rushes. The extractor trick is a slightly fancy skill with a lot of potential failure cases, but I thought it through and implemented it with all the checks—then never used it in production or advertised the feature, because once the extractor was canceled it could never be taken again. That’s why I say that the bug is particularly harmful to zerg: The extractor trick is a basic zerg skill for getting an extra unit in certain openings, and for restoring the health of a drone in the field which has gotten into a scrape (which could count as the offensive exploitation of a bug, which I don’t want to do).
Is there a workaround? I hope that there is still a way to take the geyser after it goes dark. I tried a couple of quick fixes and did not find a workaround yet. The issue discussion says that getAllUnits() returns the real geyser, but it did not work for me. I will have to dig into the code to see what’s happening, and I’m a little reluctant to put in the effort without knowing whether it will help. So I ask: Does anybody know a workaround? Do other 4.1.2 bots cope successfully?
Comments
PurpleWaveJadien on :
----------------------------------------------------------------------------
My unit tracker is powered by getAllUnits(): https://github.com/dgant/PurpleWave/blob/master/src/ProxyBwapi/UnitTracking/ForeignUnitTracker.scala#L31
----------------------------------------------------------------------------
I do recall the lifecycle of geysers being funky. Something like, a Geyser morphs into an Extractor, but when the Extractor dies a new Geyser is created. If that's correct, then it makes sense why getStaticGeysers would miss it.
----------------------------------------------------------------------------
I also recall there being one bot which currently uses the Extractor trick. I believe it's either Overkill or Zia bot. Both are recently-ish updated so it's likely they're both on 4.1.2.
Jay Scott on :
Joseph Huang on :
Jay Scott on :
krasi0 on :
Truth be told, my bot is also negatively affected by higher network latency...
Jay Scott on :
MicroDK on :
Jay Scott on :
Ail on :
Have noticed it yesterday in a game where my Bot for some reason got into a late game vs. The Protoss Ai that made scouts and Corsair s. Was nice to see my Bot getting a muta/guardian/devourer air force... But it never got any upgrades for those, which definitely was wrong and so I concluded that it is because it simply couldn't find a unit to make them in. Really socks, that Bwapi has these kind of issues.