google-code-export / bwapi

Automatically exported from code.google.com/p/bwapi
0 stars 0 forks source link

SCV do not report status as Idle after is failed building #160

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Command two SCVs to build a Refinery on the same vespene geyser.
2. One of them will arrive first and begin building.
3. The other will arrive, but won't be able to build.
4. in onFrame() probe each SCV, (SVC.isIdle())
5. The stopped SCV will not return true when isIdle() is called.

What is the expected output? What do you see instead?
The second SCV should return isIdle() == true.

Currently, the SCV sits and waits, but isIdle() returns false

What version of the product are you using? On what operating system?
Beta 2.4, XP, VS 2008 C++ Express

Please provide any additional information below.

Original issue reported on code.google.com by rustyhow...@gmail.com on 5 Dec 2009 at 8:20

GoogleCodeExporter commented 9 years ago

Original comment by lowerlo...@gmail.com on 7 Dec 2009 at 1:09

GoogleCodeExporter commented 9 years ago
I'm not sure, but may this bug be actual for Drones too. My drone tries to 
build a
Spawning Pool while the player has not got 200 minerals, so the drone and stops
itself at build position. Although the AI sends all idle drones to gather each 
frame
- this drone was not sent.

Original comment by bigfatbr...@gmail.com on 11 Dec 2009 at 10:09

GoogleCodeExporter commented 9 years ago
I suspect this issue may affect workers of all three races. To work around 
this, I
had to do something like this:

void ScanForStalledWorkers()
{
    for(std::set<Unit*>::const_iterator
i=Broodwar->self()->getUnits().begin();i!=Broodwar->self()->getUnits().end();i++
){
        if ((*i)->getType().isWorker())    {
            Unit* worker = (*i);

            bool isResponsive = worker->isGatheringGas();
            isResponsive = isResponsive || worker->isGatheringMinerals();
            isResponsive = isResponsive || worker->isConstructing();
            isResponsive = isResponsive || worker->isIdle();
            isResponsive = isResponsive || worker->isMoving();
            isResponsive = isResponsive || worker->isAccelerating();

            if (!isResponsive){
                Broodwar->sendText("Found an unresponsive worker");
                //assume an error in a build command
                AssignWork(worker); // This sends the worker back to gathering minerals
            }            
        }
    }    
}

Original comment by rustyhow...@gmail.com on 11 Dec 2009 at 2:12

GoogleCodeExporter commented 9 years ago
When a worker is commanded to build a building, the command will succeed if 
there are
enough resources and the build site is valid. The resources are not deducted 
from the
players supply until the actual construction begins. So there a few critical 
seconds
where things could change to cause the building to fail and cause this bug to 
appear. 
  1) Change in resource supplies. Another unit was trained that took some of the
resources.
  2) Another unit has moved onto the build site. The unit could even be walking
through the site to another location and the timing was just perfect(ly bad). 

Original comment by rustyhow...@gmail.com on 11 Dec 2009 at 4:32

GoogleCodeExporter commented 9 years ago

Original comment by lowerlo...@gmail.com on 12 Dec 2009 at 2:58

GoogleCodeExporter commented 9 years ago
I think I've fixed this in r1786, however I cannot test it at this time.

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

GoogleCodeExporter commented 9 years ago

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