Would you like comments or issue regarding the travel bot here or do you want to create a new thread since the old travel bot thread is obsolete?
Sounds like a problem. There is already a step in the bot to wait until the warp is finished:
Since your test result this seems insufficient. How should the bot decide if warp is finished?
How can we tell if the warp has finished?
The isShipWarpingOrJumping is only looking at the ship UI indication so far:
Depends on: Under what title would the people you want to see it expect to find your feedback under?
As long as someone would expect your post to find under this title:
How to Automate Mining Asteroids in EVE Online
Then this thread is a good place to post it.
However, I understand that you might want to improve visibility of your post even further, so feel free to choose a thread with a title that you find fits even better.
If you have something that should go under another title, you can create a new thread and enter the title there. You do not need to wait for me, as we have a user interface which supports users creating such a thread. You should see a button containing the text New Topic in the upper right corner. This button will lead you to the thread creation form.
The condition part makes sense, it is clear how this could be done in the game.
Two questions remain:
- Reading your post, I am not sure where you want to place that step. Should this go where this step was before?
“(for reliability wait until ship stopped)”
- Also, I am not so sure about the effect:
turn the lasers on
Could we achieve that by clicking on the modules in that step?
How can we tell if the warp has finished?
Possible multiple options.
Ship UI displays (warping) while the ship is warping and then starts to display speed in m/s when it drops out of warp. Absence of warping could be one method, reading ship speed in m/s could be another method. A third method could be 3 lines of above the ship UI. While warping it displays in the first line “WARP DRIVE ACTIVE” second line displays destination and third line displays distance to destination. When it drops out of warp these 3 lines disappear completely.
Yes instead of waiting for the for 0.0 speed you can replace it with one of the other conditions, less than 10 m/s or with less than 8,000 m distance to the ore asteroid.
yes, bot already clicks one laser module, only needs to click the second one right next to it.
Implemented this now here:
Implemented this here:
You can load the updated bot from bots/implement/applications/eve-online/mutant-wizard-mining-bot at f6cd8219e8cb1e27b26e0bc0894f9dba46eba10b · Viir/bots · GitHub
Can you copy the text output from the CMD window and post it here?
The application to execute does not exist: ‘C:\Users\Wizard\AppData\Local\Temp.net\BotEngine\gj3n0oct.plz\BotEngine.dll’.
C:\WINDOWS\system32>C:\EVE\BotEngine\BotEngine.exe start-bot --bot-source=“bots/implement/applications/eve-online/mutant-wizard-mining-bot at f6cd8219e8cb1e27b26e0bc0894f9dba46eba10b · Viir/bots · GitHub”
The application to execute does not exist: ‘C:\Users\Wizard\AppData\Local\Temp.net\BotEngine\gj3n0oct.plz\BotEngine.dll’.
C:\WINDOWS\system32>
Exactly the same output when trying to use the travel bot.
Interesting. Looks like I might find more information on the web when searching for this:
Yes, the output you get seems not related to the bot-source. I guess it is even the same when you only start the botengine.exe without giving it any arguments.
I was curious what is in this directory, so I looked into C:\Users\John\AppData\Local, but I see no subdirectory Temp.net in there 
It also does not seem to appear there when I run the botengine app.
Seems other people encountered this problem before: Publishing A Single EXE File In .NET Core 3.0 – .NET Core Tutorials
Do you see anything in this directory:
C:\Users\Wizard\AppData\Local\Temp.net\BotEngine
?
The reported path is wrong. The actual path is somehow changed by the forum text formating. In the actual directory path which you see below there is back slash between Temp and .net. Not sure why forum takes out the back slash??? If you have a look at the CMD shot I posted you will see the actual directory path.
C:\Users\Wizard\AppData\Local\Temp.net\BotEngine\gj3n0oct.plz\
The last directory gj3n0oct.plz is empty.
Anyway this is way over my head so cant help.
Ok, now I see an analog here, I have a directory at C:\Users\John\AppData\Local\Temp\.net\BotEngine. I do not see anything in there and that does not change during running of the app.
The problem you are seeing might be related to the single-file executable packaging recently introduced. As I understand the .NET tooling, at least some versions of this packaging cause some unpackaging to files before actually starting the program: https://github.com/dotnet/designs/blob/02237ac97879db431e4ffe1a3277432745c53e6b/accepted/single-file/staging.md#1-self-extractor
Maybe I can fix it by building a new version without the single-file packaging.
I uploaded such a version at https://botengine.blob.core.windows.net/blob-library/by-name/2019-10-21.BotEngine.Console.publish.debug.zip
If you run the BotEngine executable file contained in that zip-archive, what output do you get in the console?
Yup that will do it, now I’ll just play around with the bot for a while to see how it works.
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:
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.