How to Automate Mining Asteroids in EVE Online

Show and Tell
,
101

Thanks for the feedback, glad to read that works.

Regarding the mining bot: Now that I see how these steps have accumulated in the bot over the recent iterations, I think we could find a way to model a mining bot in a simpler way.
Looking again at the latest version I suspect for example module clicks could be simplified:

102

By all means please feel free to simplify it. Im sure my outdated methodology has been improved over time.

The bot is very close to being able to loop multiple mining instances. All the actions at the station seems to work fine inclusive of docking, undocking, removing ore from ore hold to item hangar. Below are comments on items to look at.

  • Warping to the mining site is still via the bookmark but it works. Will you change from bookmarks to system menu belts?
  • When arriving at a belt an ore asteroid is right clicked and approach is clicked. I did get one fail of this (only one on the first one out of a dozen instances) it clicked the first line in the overview but it was an asteroid belt instead of an ore asteroid. should keep an eye one this for possible recurrence.
  • Bot still fails to turn on the second mining laser. At the time of turning on the lasers for the first mining ore asteroid an Eve warning message pops up advising that we are trying to turn on a passive module. Maybe bot is clicking some module other than the second mining laser that produces this result. The other possible issue is that bot is starting the laser before Lock Target is completed. Locking take 3-5 seconds to complete so we should wait that long or read the lock from eve client.
  • In the overview window there is one additional redundant right click on an ore asteroid at this time which does nothing, context menu just stays open until i manually click on anything else.
  • When an ore asteroid is depleted bot doesn’t auto target the next ore asteroid. If i right click manually on a new ore asteroid the bot will take over, Lock Target it and start mining the next ore asteroid but still turning on only one mining laser. Maybe the one additional redundant right click I mentioned above is expected to stay on the screen from the time it was clicked (5-10+ minutes) but its quickly gone coz i do stuff while bot is working. Stuff like this board comment. If this is the case please move this action to after ore asteroid depletion.
  • Not sure what trigger you are using for deciding to warp back to station when mining is complete but before initiating warp please insert turning off mining lasers otherwise the last cycle of mined ore is lost. Alternatively U can just wait until both lasers are off. Lasers are on a 60 second cycle so if ore asteroid is depleted or ore hold is full they should turn off within max 60 seconds.
  • Im sure not to be the only one multitasking. Doing something on a second screen while eve and bot are running. Is this an issue that could interrupt bot operation?

So the only issue that break the complete bot cycle is ore asteroid depletion and not moving onto the next step of targeting the next ore asteroid. Even this might work if I was able to leave the computer alone while doing this testing. Not turning on the second laser only makes it work at half speed but it still works. Looks quite good. Think a couple more cycles between us and this ting will be fully functional.

103

Not sure if you are aware of all of this but here is some equipment specs to make it easier to decide on the timing. These vary from module to module, level to level and some are be dependent on skill level so giving it some margin for error (maybe 30-35%) would be a good thing.

  • Approach is possible from 150 km
  • Target lock is possible from 16 km
  • Target lock takes up to 5 seconds
  • Mining lasers work from 10 km
  • Mining lasers shut down in up to 60 seconds

BTW i let it run and went to feed the dogs. Screen lock kicked in (not sure if that makes any difference) and bot didn’t react to ore hold full. When I came back found it sitting in space and waiting with 5k ore in the hold and bot lasers off. I didn’t restart the bot, I just performed manual action from there until the bot picked up but now warp back to base doesn’t get triggered any more on ore hold full and both mining lasers off.

After restarting the bot the above issue is gone but on the first run after undocking it wouldn’t open the system menu where the mining bookmark is. I opened it up manually and the bot picked up from there.

104

I repeated the bot ops quite a few times now and conclude that some of the inconsistent issues are actualy due to my multitasking and working on other things and messing it up for the bot. The real bot issue that I previously mentioned are:

This seems to be a real bot issue.

This seems to be a real bot issue.

Quite possibly if we solve these the bot will be function but with of course a few opportunities for improving things.

105

Thank you for the detailed feedback, good to see we are making progress.

Yes.

I think the ordering of entries in the overview changes between taking the memory reading and the execution of the mouse click. It is possible to change the bot to account for this.
What about removing the asteroid belts from the overview? Would this avoid the problem?

How could a player click another module?
Do you see any other module than the mining lasers in the ship UI? If yes, can we avoid this problem by hiding all modules which are no miners?

Now that we know that, I can change the bot to Lock Target before starting the laser. In addition, I can make it wait until the target appears in the targets list.

106

Yes its possible and probably would solve the problem but that is not a standard setup and it can get complicated for beginners to do this. Normally one would then have to change back after finished using the bot. Not really practical.

I don’t think its possible to hide mounted modules but I have a feeling this is an issue with early activation of the mining lasers as per the subsequent comment on waiting for Lock Target. I would suggest to go with the wait for the target to appear in the target list and then activate. If that doesn’t solve the problem then we can look at other solutions.

After using the bot for a while without interfering with it by working on the other things on the computer I think there is an issue after undocking with clicking the small sun icon in the system info panel. The bot stopped there a few times. I would say 20-30% of the times it will not activate the menu from the icon. If I do a single click on that icon to activate the menu the bot takes over and continues working normally. No idea why this is such an intermittent problem but I am now pretty sure it has nothing to do with me interfering.

107

Ok, then here is the next idea I have to solve this problem: We could repeat this part (open menu on overview entry and then click approach) as long as no asteroid is in range.

We could test this approach here: Do not click on the sun icon as soon as the overview window appears. Instead, wait some more time before making this click.

Besides, I am inclined to abandon the current approach to modeling the bot program in such long sequences of steps. Instead of attempting this click only once after undocking, I would make it dependent on the state of the game. So it would look more like this:

When all these conditions are met:

  • we are not warping.
  • the ore hold is less than 99% full.
  • there are no asteroids in the overview.

Then start the attempt to warp to the mining site.
The difference to the previous approach is that the bot does not care anymore what it did in the last step. It does not care if it undocked before or if it just started.

The warp-to-the-mining-site part might remain a sequence of 3 - 4 steps. But in contrast to before, we do not need to wait in any of these steps for the menu to appear. If one of the submenus does not appear for whatever reason, we could instead abort this sequence. Because after canceling this sequence, the bot will again look at its environment to decide what to do next.

Another benefit I see in this design is that it makes the bot more beginner-friendly, as it reduced the number of constraints for the in-game setup. It would not be required anymore to start the bot in a station.

108

You mean bot to wait or I wait before making the manual click? If you mean me then I already do wait plenty of time before I realize the bot will not open the menu by itself.

Ahaaa, if i understand it correctly. The bot would be a non sequential list of subroutines and a conditional test which you use to decide which subroutine to run. That way instead of following a strict long sequence of actions, you follow a shot sequence of actions after each time you test. Am I getting this right? Sounds pretty good but this is your baby I would have to do quite a bit of thinking to figure out how set this up and what conditions should be tested for to run the appropriate subroutine. Anyway go for it and if you need specific testing or questions answered feel free to let me know.

109

I meant the bot.

Yes, that sounds correct. Thanks for explaining it, maybe this helps folks to understand the concept.

We start with a decision tree that we use at the current impression of the environment, that is, the reading from the game client. The leaves of this decision tree are those sequences of actions. When we have completed or failed such a sequence, we go back to the root of the decision tree.

For the simple mining bot, the tree could look like this:

  • Branch: Are we docked?
    • Yes: Branch: Is an item in the ore hold?
      • Yes: Act: Move item from the ore hold to the item hangar.
      • No: Act: Undock.
    • No: Branch: Is the ore hold 99% full?
      • Yes: Act: Dock to station.
      • No: Branch: Do we see a target?
        • Yes: Branch: Do we have an inactive mining laser module?
          • Yes: Act: Activate this mining laser module.
          • No: Repeat.
        • No: Branch: Read the closest asteroid from the overview. Does this entry exist?
          • Yes: Branch: Is this asteroid close enough?
            • Yes: Act: Lock target this asteroid.
            • No: Act: Approach this asteroid.
          • No: Act: Warp to the mining site.

I see several ‘subroutines’ which contain only a single step:

  • Move item from the ore hold to the item hangar
  • Activate this mining laser module.

The longest sequence could be the one to warp to the mining site, with four steps.

While I am at illustrating the architecture: Another thing that might not be obvious and should be part of the guide for developers: All branches in the tree are evaluated on the same reading from the game client. For each of the steps in the sequences (which are not detailed above) the bot takes a new reading from the game client when transitioning from one step to the next.

For a beginner (user) bot, the tree will have some more nodes to guide the user (display a text message) or to take care of the setup, for things like:

  • Open the inventory window.
  • Select the ore hold.
  • Select the list view in the inventory. (I remember some people had trouble with this).
  • Report missing bookmark (station).
110

That makes it really clear, looks quite good and will probably work a lot better than my sequential process.

111

Can you also incorporate prioritization of ore asteroids to mine? Like the following priority list by ore value from high to lower.

  1. Asteroid (Dense Veldspar)
  2. Asteroid (Concentrated Veldspar)
  3. Asteroid (Veldspar)
  4. Any other
112

Sure.

At the moment, I am translating the tree from the post above into a bot code.

(Following is for developers)
My first idea for types to model the tree:

type alias TreeLeafAct =
    { firstAction : Sanderling.EffectOnWindowStructure, followingSteps : List (MemoryReading -> BotProgramStepResult) }


type TreeLeaf
    = Repeat
    | Act TreeLeafAct

In this case, the branches would be functions:

pickNextAction : MemoryReading -> TreeLeaf
pickNextAction memoryReading =
    if memoryReading.overviewWindow == CanNotSeeIt then
        pickNextActionWhenDocked memoryReading

    else
        pickNextActionWhenInSpace memoryReading

After implementing more and refining, the overall model looks different from the first idea above, now like this:

type alias TreeLeafAct =
    { firstAction : Sanderling.EffectOnWindowStructure
    , followingSteps : List ( String, MemoryReading -> Maybe Sanderling.EffectOnWindowStructure )
    }


type TreeLeaf
    = Repeat
    | Act TreeLeafAct


type DecisionPathNode
    = DescribeBranch String DecisionPathNode
    | Leaf TreeLeaf


decideNextAction : MemoryReading -> DecisionPathNode
decideNextAction memoryReading =
    if memoryReading.shipUi |> maybeNothingFromCanNotSeeIt |> Maybe.andThen isShipWarpingOrJumping |> Maybe.withDefault True then
        DescribeBranch "I see we are warping. Wait until warp ends." (Leaf Repeat)

    else if memoryReading.overviewWindow == CanNotSeeIt then
        DescribeBranch "I see no overview window, assume we are docked." (decideNextActionWhenDocked memoryReading)

    else
        DescribeBranch "I see we are in space." (decideNextActionWhenInSpace memoryReading)
113

Just uploaded an implementation of this bot. You can test it with the bot source from bots/implement/applications/eve-online/eve-online-mining-bot at 440cf7afc69637cb8c0ac4e19704621c08dd3a1a · Viir/bots · GitHub

114

It works to the point of activating the mining lasers. Its trying to activate a wrong module “Mining Laser Upgrade II” while it should be activating two modules both named “Miner II”. They could also be called “Miner I” or “Civilian Miner” depending on the skill level of the character. The correct modules are circled in green in the attached shot.

https://photos.app.goo.gl/2PDMXpBw46J2VZ2Z7

115

Looking at the screenshot, this is a new kind of setup, unexpected. I will adapt the bot to support this scenario too.

116

Yea posted the shot coz had a feeling that all this time there was something wrong here. From the beginning we were not getting laser activation right.

117

I uploaded this version of to support the arrangement of ship UI modules as in the screenshot: bots/implement/applications/eve-online/eve-online-mining-bot at cccdd729f42c752740b88b4e41e26161b9f8c434 · Viir/bots · GitHub

Implementation details:
We can identify the modules he marked (‘circled in green’) to activate as the upper row of modules (Adapt the EVE Online mining bot to today's feedback · Viir/bots@2c8f00a · GitHub)

118

Works perfect according to the original scope we discussed and as such we could say the task has been successfully completed. We could leave it alone and use as is. None the less, while still keeping it a beginners bot I would though like to see a couple efficiency improvements and maybe add a a couple very simple things.

  • I suggest to shut down any active mining laser before warping back to station for unload. During a 60 second laser cycle, ore is stored in the laser. If we don’t shut them down before warp then this ore stored in the laser is lost. Shutting down the laser transfers the ore to the hold. Since we consider hold full at 99% of capacity then some of this ore is regularly lost if we don’t shut it down.
  • Bot is still using “mining” bookmark to warp back and forth which makes it a bit more complex to set up. Using Asteroid Belt items from the system menu would make that setup a bit easier. Not sure if its the same over all Eve systems but where I am testing the NPC mine from the top to the bottom belts in the menu. Consequently first belt gets depleted first. If proceeding with this I am suggesting to start with the last belt.
  • If the above is implemented it could also support for moving from a depleted asteroid belt to another asteroid belt. This would be very cool as it would allow for mining cycling even after NPC and bot deplete an asteroid belt.
  • This last bit could get very complicated if we wished to take it to that level but I would suggest to keep it simple. Ore type prioritization based on ore value to get biggest isk return for the time the bot operates. To keep it simple I would just prioritize ores existing in a belt until belt is depleted and then change belts. As per a few comments above this is ore value list that I suggest to use for prioritization. If you do implement please try to ensure the bot works even if any or all of these ore asteroids are not present.
  1. Asteroid (Dense Veldspar)

  2. Asteroid (Concentrated Veldspar)

  3. Asteroid (Veldspar)

  4. Any other ore asteroid

While writing this I been monitoring the bot operation. It simply works even though its sometime fighting with me for the pointer. Great job mate! I hope any users coming across this appreciate your work.

1 Like
119

Thank you @MutantWizard for the relentless testing and detailed feedback. Also good to see the ideas for further efficiency improvements, I am looking forward to it.

I like this part. That it works despite a user interfering with the mouse is a testament to its robustness. When a mouse click fails this way, the bot will recognize that the task was not completed and attempts again.

Seeing that it now works so well, I will update the guides so other people can find this bot.

Since the first posts in this thread contain outdated instructions and refer to a completely different bot, I will close this thread to avoid confusing future visitors. In most cases, it’s best to open a new thread (Create Topic) to ask a question or share ideas for improvements.

For the people who just landed here at the bottom of the thread, you find the new guide on how to use the bot at https://to.botlab.org/guide/app/eve-online-mining-bot