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.
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.
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.
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.
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.
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.
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.
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).
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)
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.
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.
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.
Asteroid (Dense Veldspar)
Asteroid (Concentrated Veldspar)
Asteroid (Veldspar)
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.
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.