archive by month
Skip to content

MicroTransports improvement and the addon bug

Simplifying MicroTransports.cpp reduced its length by about 150 lines of code. That was rather a lot of extra code for the small job of moving around the edge of the map—and the waypoint method that I’m sticking with is hardly the simplest way. The savings in memory use (it takes less than half as much) and runtime (ditto) are greater—not big enough to make an overall difference, but reducing overhead is always good. Most importantly, the code is much clearer, so the future improvements needed for drop will be easier. The detailed behavior is slightly different, not much. There is still a bug in choosing which direction to go around the map, but I’ll solve it.

In vaguely related news, dropping sometimes triggers Steamhammer’s addon bug. The bug is that when building a terran addon, such as the control tower for a starport, sometimes the addon is ordered but never built, wrecking the build order. BWAPI says that the addon will build, but when the order is issued, it doesn’t. In practice, it happens when the control tower comes up in the queue at about the same time that the starport finishes. My latest theory is that there is a latency period after the starport finishes before the control tower can start, and BWAPI doesn’t recognize it.

The last time I worked on this bug, I struggled a long time and finally gave up. I ended up inserting filler items into the openings to delay addons so that they are unlikely to be ordered early and trigger the bug. Of course that makes play worse, but it was a workaround. The bug came up again because queue reordering cleverly realized, “Hey, this addon can be moved up, let’s build it now!” and triggered the bug in half of games.

For now, I told queue reordering not to pull an addon to the front. 2 hacky workarounds for the same bug are too many. This time I’m determined to get to the bottom of it. So... any hints?

Trackbacks

No Trackbacks

Comments

Stanislaw Halik on :

> So... any hints?

Check building's or worker's action a few ticks later. It should be what you ordered. Only after the action's verified, proceed any further with build order stuff.

Jay Scott on :

Monitoring goals is a highly general technique and I’ve always thought it was a good idea. Yet Steamhammer does virtually none of it....

Anon on :

Perhaps set (specifically for addons) that you want to retry X times (with Y frames of interval between those)? Or maybe you could remove the addon from queue in case of failure, so it will eventually be queued again later (hopefully not much later). Either way, you'd have to check if the addon is in progress after ordering it...

Jay Scott on :

Something like that, perhaps. As things stand, the addon does get queued again later—much, much later. :-/

Stanislaw Halik on :

This is a very simple technique when used for build order. I remember writing a bot for taking over IRC rooms. It had to queue up existing actions and repeat only if they took too long, or couldn't be done. The relevant logic in Perl took maybe 150 lines.

It's interesting how many simple things bots get wrong. They don't find holes in turret defenses, or are unwilling to get through a static base defense repeating the approach indefinitely. It's sad watching all good play get ruined due to the bot getting "stuck" in a bad state.

Also, are you using SparCraft or have you rolled up your own estimator?

Jay Scott on :

Steamhammer uses FAP by N00byEdge to predict combat outcome.

Jay Scott on :

Bypassing defenses is only an easy skill if you have judgment. It requires weighing alternatives at different distances into the future. So far, most bots that can do it use reactive methods (Iron, Tscmoo) which work but not with good efficiency. Overkill uses a planning method to find a path for its mutalisks around static defenses (watch their angular flight paths), and it often picks a dangerous path and takes damage from enemy mobile forces. Try telling a roboticist, “picking up an object is an easy skill.”

Stanislaw Halik on :

WRT turret evasion, why not do any of the following?

a) Plot a path with many nodes, coming to a full stop if necessary to draw a precise path.
b) Give a safety margin.
c) Scout around the cliff.

I can imagine that performing well for most/all common game skills is a herculean task. Priorities...

Jay Scott on :

For most bots, including Steamhammer, even a simple method for trying to bypass or work their way around static defenses would probably be a win. The old Berkeley Overmind had a method which wasn’t too complex and kept the risk low. I haven’t noticed other bots that follow the plan: Draw the convex hull of the enemy anti-air units (static defense and mobile units), and work around the outside looking for weak points. You can pick off free stuff, or hit the corners of the convex hull and try to wear it down.

Jay Scott on :

Part of the idea is that by considering only the convex hull of enemy defenses, instead of the detailed danger zones created by the current enemy formation, you reduce the risk of being outmaneuvered and trapped. “Look, a gap where I can dart in. Oh no, my escape is cut off!”

Jay Scott on :

Solved the direction-around-the-map bug. There was a confusion between signed and unsigned integers in the modular arithmetic used to close the waypoints into a loop. Kind of subtle.

Joseph Huang on :

Disable latency compensation. Then track pending resources yourself so you don't double spend. Profit.

Marian on :

I use custom UnitManager and custom orders that keep track and fix potential shortcommings of bwapi.
For this problem:
custom order: OrderBuildAddon
-> assign to starport
-> reserve gas/minerals
-> order executed each frame and checks itself for completion and failures(basically state machine)

Ankmairdor on :

I did a simple test of having CCBot order a selected starport to build a control tower on the first frame that it completed construction. CCBot leaves latcom enabled, although I don't know if makes a difference that it uses bwapi 4.2. There were no problems during the test and there were no obvious delays in openBW, which suggests that the problem may result from either a code conflict in your bot or an obstacle in game. I don't know Steamhammer well enough to rule out the first, but I would place my bet on either a unit blocking the build site or somehow a lack of resources.

Jay Scott on :

Hmm. I’m sure it’s not an obstacle. I think I should dissect this frame by frame.

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.