block finder: respect the event loop

[andrewrk]

there should be a variable called something like MAX_CPU_TIME and when it has spent that much time looking, it stops searching and uses process.nextTick to resume where it left off.

this would make findBlock callback-based instead of returning the result.

this way the bot does not quit due to a timeout error if searching is taking a long time. it would also provide the ability to cancel an in-progress search.

[vogonistic]

I've also used an approach where I have a short timeout. If it triggers, I walk to the closest position it got to and then restarts the search. It doesn't find very complicated paths, but had generally good results.

[andrewrk]

@vogonistic, sounds like you're talking about pathfinding, while this is talking about searching memory for blocks.

[vogonistic]

@superjoe30 Oh, sorry about that. I was reading about finding a path out of the mine and got the context mixed up.

[Darthfett]

I would like to see this have findBlockSync and findBlock versions of the command, where the async version would take a callback and fork, and the sync version would work in the current way.

var blockPositions = blockFinder.findBlockSync(point, blockTypeID, radius, count);

function callback(err, blocks) { // ... }

blockFinder.findBlock(point, blockTypeID, radius, callback, count);

I am also considering an event-based API for the asynchronous finder, that allows you to queue up blocks, but I haven't yet thought of a good API.