Archive for November, 2011

Startcraft + BWAPI + pybw

Posted in Uncategorized with tags , , on November 30, 2011 by voline

This post is meant to provide a quick way to get up and running with pybw and BWAPI 3.7, instead of spending a lot of time scouring the net for the prereqs.


  1. StarCraft Broodwars and patch — this must be installed and patched to at least 1.16.1.
  2. VisualStudio 2008 express — You only need to install the C++ portion.  Note, however, that VS 2010 currently _will not_ work. (not needed if none of the downloads are source that needs to be compiled).
  3. Python 2.6 — pybw should compile against any 2.6.  Python 2.7 may work, but is untested (the project build will need to be modified to include 2.7 instead of 2.6 headers).
  4. — The Chaoslauncher can be a little harder to find since the website hosting the project went down.
  5. BWAPI — If you wish you may compile this from source, but the binaries should work just as well
  6. pybw — Checkout the source. Upstream currently only supports BWAPI up to version 3.2 Beta.  Or download precompiled binaries.
  7. vcredist_x86.exe — This may need to be installed.


Install Starcraft with 1.16.1 patch.  Then follow steps 1 – 4 (note the section is misnamed, “Build Instructions”) for setting up BWAPI to be injected into Starcraft using the Chaoslauncher.  If compiling pybw from source, follow the instructions from the README file.  Otherwise, you may need to install vcredist_x86.exe and then you should be able to run pybwClient.exe from the binary distribution to start the example AI.  Keep in mind that an AI can not start once you’re in a game.  Starcraft should be started with the Chaoslauncher with BWAPI checked.  It will be obvious that the AI is connected at game start because there will be text on the screen indicating the revision of BWAPI being used at game start (not to mention that the workers should automatically start gathering minerals).


Windows hibernate… where did my bios options go?

Posted in Uncategorized on November 29, 2011 by voline

So a couple months ago I acquired a new laptop installed with Windows 7.  Of course, one of the first things I did was install linux on it.  But I did this by shrinking the win7 install to make space for linux.  I figured that it might come in handy one day to run windows, and promptly left the win7 to gather dust.

Well I’ve recently been spending a lot of time back in windows playing with the BWAPI (the subject of a forth coming post).  Because I’ve been doing non-trivial things in windows, I want to hibernate the machine instead of just shutting it down.  To my consternation, I noticed that, after hibernating from windows and then restarting, the bios disabled access to the bios menu and bios boot menu and booted directly to the windows device.  Since I boot my linux from a usb but the windows install is on a harddisk, this is problematic.  Effectively hibernating to windows forces me to resume back to windows.  However, when I shutdown windows and boot back up, the bios menus are re-enabled.

After doing some googling around, i found others with the same problem, but no solution.  Now, I’ve been spending a lot of time learning about my Phoenix UEFI firmware and know that the boot menu can be modified from a UEFI booted machine by modifying the UEFI variables.  So, I could see how a UEFI booted OS could at hibernation change these variables to only boot the device which was being hibernated to and disabling all other firmware access.  The funny thing was that the OEM windows install booted from the MBR and not an EFI bootloader application.  Thus windows was not running under UEFI (actually it is running under UEFI, but in a BIOS compatibility mode) and accordingly could not modify the UEFI variables.

So I started thinking “how is the firmware being modified such that the firmware knows to disabled firmware access and boot directly to the windows hibernated device?”  The first thought I had, was that somehow this information is being stored in ACPI, which I knew only a little about.  After downloading the ACPI spec and reading about the various sleep states, I realized that the hibernate state, S4, does not fully turn off power to the machine.  Yes, the computer looks completely off, no lights or sounds, and even a firmware loading screen is presented on “power on”, but it is sucking tiny bit of energy (see ACPI spec v5 16.1.4).  Somewhere, maybe in some modified ACPI tables but I’m not sure, windows hibernate tells the firmware to just boot directly to the device window hibernated to.

Armed with this knowledge, I decided to see if cutting all power to the machine would change anything.  I hibernated windows, then disconnected AC power and the battery.  When turning the laptop back on the result was the same, no boot options.  Coincidentally, I had been reading my laptop’s service manual about how to replace core components and I remembered that the manual said to ensure that there was no residual power in the system before disassembling.  The manual said to ensure this by removing battery and power and then pushing power button waiting for a second and pushing the power button again, repeating several times.  That did the trick, the firmware booted back up and allowed me to select which device I wanted to boot from and get into the firmware setup menu.  It also has no effect (as far as I can tell) on the resumed windows, which resumes without issue.

Strangely, hibernating from linux (using the tux-on-ice kernel) does not exhibit this behavior.  I can think of two possible reasons for this.  One, linux or tux-on-ice specifically do not actually go to S4 on hibernate, but actually go to S5 (logical off).  Or two, it has to do with the fact that I’m hibernating from a running OS that was booted from a removable device.  Without further testing, I suspect the former more likely.  Anyone else have any ideas?