canBuildHere() doesn't return false for hatcheries/nexuses/cc's too close to minerals/gas

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Pick a TilePosition too close to a mineral/geyser
2. Check the output of canBuildHere

What is the expected output? What do you see instead?
It should return false if too close in proximity to a resource. It doesn't.

What version of the product are you using? On what operating system?
2.4

Original issue reported on code.google.com by chad.zan...@gmail.com on 11 Dec 2009 at 2:40

[GoogleCodeExporter]

Are you sure about this? I'm 99.99% sure canBuildHere does return false if the 
tile
position is too close to minerals or geysers, though it only uses accessible 
minerals
and geysers so I suppose it could return incorrect values near minerals that are
invisible and complete map information is disabled.

Original comment by lowerlo...@gmail.com on 11 Dec 2009 at 2:17

• Changed state: Questionable
• Added labels: Priority-Low

[GoogleCodeExporter]

I'll try to create a basic test-case for you later tonight.

What I was doing (don't have access to code ATM):

I wrote quick hack of a function to randomly grab build spots around the center 
of a 
base's region. It's essentially:

do {
  x,y = random offsets from bases' region's center
} while ( !Broodwar->canBuidHere(NULL, TilePosition(x,y), Zerg_Hatchery ));

It'd would now-and-then return a TilePosition immediately next to or too close 
to my 
extractor.  I might have written the description to hastily, as after reading 
your 
response and some BWAPI code I only noticed the error next to my completed 
extractor.

According to the source, it looks like it should check as you say:

http://www.google.com/codesearch/p?
hl=en#5xqY1YZBkWI/trunk/bwapi/BWAPI/Source/BWAPI/Engine.cpp&q=canBuildHere 
package:http://bwapi\.googlecode\.com&sa=N&cd=3&ct=rc&l=611

My guess (if I'm not doing something stupid) is that if ((*i)->canAccess() from 
getGeysers() is returning false if the geyser has an extractor built on it. 
This 
drops the geyser from the returned set and in turn fools canBuildHere into 
returning 
true.

A solution would be to use the static getGeyser function instead, I think.

Again, none of this has been tested yet.

Original comment by chad.zan...@gmail.com on 11 Dec 2009 at 11:21

[GoogleCodeExporter]

Yeah it would make sense to use getStaticGeysers rather than getGeysers since 
geysers
cannot be destroyed (refineries can, but the geyser remains), so I'll make that 
change.

However if I do the same thing for minerals and use the static mineral set, then
canBuildHere will always return false near mineral patches (even when they no 
longer
exist). Here is what I will do: canBuildHere will use the static mineral set, 
however
if the tile position the mineral is on is visible, and the mineral unit is not
visible, then canBuildHere can determine that the mineral no longer exists 
(since
mineral patches cannot move) and will not take it into account when determining 
build
position validity).

Original comment by lowerlo...@gmail.com on 12 Dec 2009 at 3:22

• Changed state: Accepted

[GoogleCodeExporter]

I think I've fixed this in r1787, however I cannot test it at this time.

Original comment by lowerlo...@gmail.com on 12 Dec 2009 at 3:29

• Changed state: Started

[GoogleCodeExporter]

Original comment by AHeinerm on 12 Dec 2009 at 4:38

• Changed state: Fixed