Mining bots missing some ores #3

Closed
opened 2023-11-14 08:11:50 +00:00 by BlakeRain · 3 comments
Owner

The mining bots seem to be sometimes missing ores. I think this might be to do with the population of the AA whilst excavating. The excavationScan function builds a table of blocks surrounding the bot, which it uses to populate a table of blocks to excavate. Notice that each call of the form self.bot:query() is not passing true to the query method. This means that, if the AANode returned is AANode.EMPTY, we're not actually populating it with the real block. In which case, it is possible for us to actually skip some blocks if we never actually turn to them during excavation. This is probably why we only see one or two ore blocks being missed.

We should change the excavationScan function to pass true to each of the query functions, which will prompt the bot to scan that direction (possibly with a temporary turn) in order to fill out the AA.

This could be what is causing #1.

The mining bots seem to be sometimes missing ores. I think this might be to do with the population of the AA whilst excavating. The `excavationScan` function builds a [table](https://git.blakerain.com/BlakeRain/bans-automata/src/commit/706cbfe967d4435716aa7264a1081202cf731a62/automata/strip-miner.lua#L306-L312) of blocks surrounding the bot, which it uses to populate a table of blocks to excavate. Notice that each call of the form `self.bot:query()` is not passing `true` to the query method. This means that, if the `AANode` returned is `AANode.EMPTY`, we're not actually populating it with the _real_ block. In which case, it is possible for us to actually skip some blocks if we never actually turn to them during excavation. This is probably why we only see one or two ore blocks being missed. We should change the `excavationScan` function to pass `true` to each of the query functions, which will prompt the bot to scan that direction (possibly with a temporary turn) in order to fill out the AA. This could be what is causing #1.
BlakeRain added the
bug
label 2023-11-14 08:11:50 +00:00
Author
Owner

Looking at the code for query, it doesn't seem that we need to set the refresh argument to true for the bot to perform a new scan in the required direction. In fact, setting refresh forces the AA to be refreshed:

function Bot:query(dir, refresh)
  local v = self:relativePosition(dir)
  local node = refresh and AANode:createUnknown() or self.aa:query(v)

  if node.state == AANode.UNKNOWN then
    if dir == Direction.Up then
      self:cacheBlockUp()
    elseif dir == Direction.Down then
      self:cacheBlockDown()
    else
      local old_dir = self.dir
      self:face(dir)
      self:cacheBlockFront()
      self:face(old_dir)
    end

    node = self.aa:query(v)
  end

  return node
end
Looking at the code for `query`, it doesn't seem that we need to set the `refresh` argument to `true` for the bot to perform a new scan in the required direction. In fact, setting `refresh` forces the AA to be refreshed: ```lua function Bot:query(dir, refresh) local v = self:relativePosition(dir) local node = refresh and AANode:createUnknown() or self.aa:query(v) if node.state == AANode.UNKNOWN then if dir == Direction.Up then self:cacheBlockUp() elseif dir == Direction.Down then self:cacheBlockDown() else local old_dir = self.dir self:face(dir) self:cacheBlockFront() self:face(old_dir) end node = self.aa:query(v) end return node end ```
BlakeRain added the
question
label 2023-11-14 09:48:14 +00:00
Author
Owner

This may well have been due to #2, where the bot inventory was getting filled up with things like cobbled deepslate. This has since been addressed by dropping unwanted items after each excavation.

This may well have been due to #2, where the bot inventory was getting filled up with things like cobbled deepslate. This has since been addressed by dropping unwanted items after each excavation.
Author
Owner

It is indeed true that the bot has not been collecting Fluorite. This is due to the ores list containing a misspelling.

It is indeed true that the bot has not been collecting Fluorite. This is due to the [ores](https://git.blakerain.com/BlakeRain/bans-automata/src/commit/41123f175bef3f111dc2173499506ce13a23bd82/lib/bot/ores.lua#L9) list containing a misspelling.
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: bans-minecraft/bans-automata#3
No description provided.