archive by month
Skip to content

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?

Trackbacks

No Trackbacks

Comments

PurpleWaveJadien on :

Just did a quick check with PurpleWave. If I cancel an Assimilator, my unit tracker still sees it, and sees it correctly as a Vespene Geyser.

----------------------------------------------------------------------------

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 :

So it can definitely be made to work, good news. I’ll solve it. Maybe I did something else wrong when I tried getAllUnits()?

Joseph Huang on :

I think your check is for distance of 300 units might be too low of a value, it might need to be 350 or 400.

krasi0 on :

Talking about bugs in SH, do you plan to add support for high(er) latency frame values like 6 (LAN UDP). Currently, it appears that the BO processing gets haywire (pool @7 instead of @9), if I set up a LAN game against SH.
Truth be told, my bot is also negatively affected by higher network latency...

Jay Scott on :

Wow, it’s a long time since I thought about that. No plans are laid. I should start thinking about it and make some.

MicroDK on :

I guess that will be a problem for all UAB/SH related bots?

Ail on :

Btw. The same bug that effects the hive-research also effects the greater Spire.
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.

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.