How to Automate Mining Asteroids in EVE Online

Thank you for the clarification, this helps with prioritizing. You are right, skipping all nonessential features makes it a lot easier to program.

Having this information will reduce the time needed to develop this. Prioritizing completion of the loop is fine.

Yes this makes it simpler because the bot does not need to read information about the modules.

Great to do this with you, thoroughly enjoying trying to foresee eventualities and results.

This is the loop please feel free to insert questions for required clicks or data read that I missed to list.

I closed all non essential windows. Keeping open inventory window (list view, full tree) and Overview window (default Eve settings). I keep sort order by name so the order of asteroids and belts doesn’t change when moving from asteroid to asteroid. This way I always know which has been completed and which is next. This sacrifices a bit of travel time between asteroids but still acceptable.

Please note I did not build into this loop moving from depleted asteroid belt to the next asteroid belt coz I didn’t get to this occurrence. This should be built in so if you need me to I can try to simulate this occurrence.

Start Loop
docked with an empty ore hold (remember station to bot variable)
click undock
click Mining tab in overview
right click first asteroid belt and warp to 0
when warp ends scroll down in overview to bring ore asteroids to visible
right click first ore asteroid and approach
when in range right click same ore asteroid and lock target
click first high slot with Mining laser (for reliability wait until ship stopped)
click second high slot with mining laser
click ore hold in inventory window
wait until ore hold full or asteroid depleted (both mining lasers stopped)
if ore asteroid depleted (both mining lasers stopped and ore hold not full) go to start depleted ore asteroid sub-loop
if ore hold full skip sub-loop and continue

start depleted ore asteroid sub-loop
right click first ore asteroid and approach
when in range right click same ore asteroid and lock target
click first high slot with mining laser
click second high slot with mining laser
wait until ore hold full or asteroid depleted (both mining lasers stopped)
if ore hold full exit sub-loop
otherwise go to beginning of sub-loop
end depleted ore asteroid sub-loop

click General tab in overview
right click originating station and dock (retrieve from bot variable)
click and hold to drag ore from ore hold to item hangar
go to beginning of loop
End Loop

This is the basic and simplest loop I could come up with that still works for a single asteroid belt. Even do not need to use afterburner. No exit from loop needed except CTRL + ALT interrupt. i would also suggest for bot to simulate human clicks by inserting a short random time delay between clicks.

1 Like

Think the code might be more efficient this way.

Start Loop
docked with an empty ore hold (remember station to bot variable)
click undock
click Mining tab in overview
right click first asteroid belt and warp to 0
when warp ends scroll down in overview to bring ore asteroids to visible

start sub-loop
right click first ore asteroid and approach
when in range right click same ore asteroid and lock target
click first high slot with mining laser (for reliability wait until ship stopped)
click second high slot with mining laser
wait until ore hold full or asteroid depleted (both mining lasers stopped)
if ore hold full exit sub-loop
otherwise go to beginning of sub-loop
end sub-loop

click General tab in overview
right click originating station and dock (retrieve from bot variable)
click and hold to drag ore from ore hold to item hangar
go to beginning of loop
End Loop

1 Like

I did forget one thing in the above process. There is a real possibility that the above process returns the ship to dock with multiple ore types in the ore hold. so the drag and drop from the ore hold will have to be repeated until the ore hold is empty (another small sub-loop).

I tried to change asteroid belt under assumption that the belt has been depleted. I determine depletion if I warp to the belt and there aren’t any ore asteroids available. Then I just click on the next asteroid belt in the list to find out if any ore asteroids there.

Its easy enough to do it manually but I guess a bit more complex to automate it. The only way I came up with was to keep the overview sort by naming so the order in which they are listed doesn’t change by ship moving around and take a count of the number of asteroid belts. Then I pick the first and warp to 0 then others one by one in the same order in which they are listed in the overview. Adding 1 to the counter each time we visit the next asteroid belt tells the both which belt should be next by counting down the list. Hope this is doable.

1 Like

Thank you for sharing this mining process. Seeing this approach was enlightening. When designing bots, I am used to the more tree-ish structure found in more evolved bots like A-Bot and the mission running bot. The strongly sequential approach shown here makes development more straightforward.

I will use your approach as a check-list in development.

For now, I am not looking at handling belt-depletion. I do not see a problem with considering this after implementing the other parts of the bot.

It looks a lot shorter than the earlier version, so I think it will be easier to understand, which in turn makes it easier to improve.

Not sure how we can identify such a clickable representation of asteroid on the screen. We have clickable objects in the overview window. Some those rows in the overview represent asteroids, but which ones? Can we assume that any row in the overview containing the text “Asteroid” in the Name column is such an asteroid? Or is this not specific enough when we have asteroid belts in the overview too?

Would the “Asteroid” text match be specific enough if we hide the belts from the overview? (For warping, we can use bookmarks (easier to program) or the solar system menu).

Asteroid belt is represented by the line which includes text “Belt”. If the line includes the string “Asteroid” but not the string “Belt” then we can safely assume its an ore asteroid but feel free to do it the easiest way.

1 Like

Im old school from Cobol days and have not done almost any coding since then. Seems logical it would be quite different from what you guys do nowadays. Hope my contribution is useful.

I think we may have to address belt depletion quite quickly. The belts in HS 1.0 systems deplete quite quickly during the day. Very often by the end of the day there is only a few belts left with asteroids that contain ore. None the less you are right, step by step. First without this logic will be easier.

Seeing this example is very helpful, beyond the development of the mining bot. It will also benefit the people who want to learn how to develop bots. I see now many people landing here could be familiar with the sequential/looping approach. As a result, they might have a hard time following the current guides on bot development. Adding a comparison of the different design approaches to the guides should support readers from a more diverse range of previous experience.

I started development on the sensor/seeing side of this mining bot.
I am using this bot description from above, to find out what information the bot needs about the game:

  • Something to initiate undock: → Undock button in station window? Now I remember seeing somewhere you could also undock with a context menu on the active ship in the inventory window. So maybe that would be an alternative.
  • Decide ‘if ore hold full’ → Probably using the capacity gauge in the inventory window.
  • Context menu (for warp, approach, lock target): Seems already covered: The travel bot uses the context menu and the structure should be the same for context menus opened on other objects, such as overview entries.
  • In overview window:
    • Tabs, each with region and title.
    • Entries, each with region, name and distance.
  • Modules in the ship UI. For each module:
    • Indication if it is active.
    • Region (for the click)
  • In the inventory window:
    • Representation of the item hangar (Region)
    • Items in the selected container (Regions)

I think reusing the Sanderling memory reading framework is the fastest way to get all the input we need. I collected samples of what we get from this framework. It looks like two snapshots of the game are sufficient to cover these parts of memory reading. One in station, and one in the belt. I uploaded these samples here:

I am not sure about these parts:

Where would we read this station name from when docked?
Anyway, by using a bookmark instead we can avoid waiting for this.

Yes Undock from context menu works, this would seem to be more future proof than the button.

Keep in mind that the ore bay is sometime full while being a fraction short of full simply coz space left available is smaller than a single ore unit.

I expected the system info panel in the top left corner could provide this info. Clicking the small sun icon there toggles this panel on/off but a BM seems more reliable, then for sure.

BTW Travel Bot CMD window flickering is very annoying and could cause issues for some people. Is it possible to stop it from doing that?

I implemented another batch of the memory reading functions for the mining bot here:

That is good to know; I will try to undock via the inventory window context menu first. It looks like we will anyway depend on reading the entries in the tree on the left of the inventory window, to be able to drop items to the item hangar.

Currently detecting whether it is full is based on the text which is displayed in the inventory capacity gauge. For example, the following is classified as full:

5,000.0/5,000.0 mÂł

If we find other cases we should consider full, I can adapt the bot.

Probably it can be at least reduced somehow. Does it flicker as much when you start it using the Windows PowerShell app?

Sometime we mine ore where unit size is for example 15 m3. which means 333 units will fit in the hold. 333 *1 5 = 4,995 m3. This is also considered as full since another unit will not fit. I think there are a few different ores that fill the hold in this way. We may be able to identify most of the cases one by one and hard code them as we do but not sure we will get all of them that way. Option is algorithm that would decide when the hold is full even if short of 5k. If you are able to read the ore unit m3 size this might be a very simple math equation that decides if the hold is full.

This is what it looks like for the venture or a ship with 5k ore hold. So to declare it full you would need to consider which ore and m3 in hold. Off course if you change the ship you would need a whole new table for each ship.

Ore, Full with m3
Veldspar 5000.0
Concentrated Veldspar 5000.0
Dense Veldspar 5000.0
Scordite 5000.0
Condensed Scordite 5000.0
Massive Scordite 5000.0
Pyroxeres 4999.8
Solid Pyroxeres 4999.8
Viscous Pyroxeres 4999.8
Plagioclase 4999.8
Azure Plagioclase 4999.8
Rich Plagioclase 4999.8
Omber 4999.8
Silvery Omber 4999.8
Golden Omber 4999.8
Kernite 4999.2
Luminous Kernite 4999.2
Fiery Kernite 4999.2
Jaspet 5000.0
Pure Jaspet 5000.0
Pristine Jaspet 5000.0
Hemorphite 4998.0
Vivid Hemorphite 4998.0
Radiant Hemorphite 4998.0
Hedbergite 4998.0
Vitric Hedbergite 4998.0
Glazed Hedbergite 4998.0
Gneiss 5000.0
Iridescent Gneiss 5000.0
Prismatic Gneiss 5000.0
Dark Ochre 5000.0
Onyx Ochre 5000.0
Obsidian Ochre 5000.0
Spodumain 4992.0
Bright Spodumain 4992.0
Gleaming Spodumain 4992.0
Crokite 4992.0
Sharp Crokite 4992.0
Crystalline Crokite 4992.0
Bistot 4992.0
Triclinic Bistot 4992.0
Monoclinic Bistot 4992.0
Arkonor 4992.0
Crimson Arkonor 4992.0
Prime Arkonor 4992.0
Mercoxit 5000.0
Magma Mercoxit 5000.0
Vitreous Mercoxit 5000.0

This is why Im thinking a formula might be a better idea then hard coding something that Eve could change with any update. In Excell the formula would look something like this with the final result at 1 decimal digit.

=(Rounddown((Hold Size m3 / Ore unit m3),0))*(ore unit m3)

Basically you would need to read hold size and ore unit size m3 to be able to do it, but this should be eve future update proof.

Travel bot flickering is pretty much the same in PowerShell but the bot is not working any more. It doesnt see a route in the system panel so just waiting for a route to be set. I though can see it and keep wandering who is blind…

I light of these discoveries, I will adapt the bot to read the number and compute the percentage of the ore hold fill. Parsing the numbers out of the text is not so difficult. The original reading function was so simple only because I did not have any example to justify going beyond just comparing the text.

If I read the table correctly, a threshold of 99 percent should cover all cases.


I just implemented the expansion of the inventory capacity reading here:

Following is an excerpt of the code containing cases which are automatically tested to work:

That works too and is much simpler.

Travel bot works again. :slight_smile:

Do you think it might be interesting to implement a bounce of a random celestial where the route takes one through a system other than high sec?

I don’t know, I would first ask people who are familiar with the game. I don’t remember reading about this before.