When using the Venture you can get closer than 1.5m to the roid but the overview shows it as 999m instead of 0.999m this causes the bot to to flag the warning “distance between asteroids too large” and the bot just sits there flagging that warning over and over.
I am not a good enough scripter to work out how to fix this any help welcome .
Thank you
I think ive solved the problem the bot is not reading the tool tip properly for the “particle bore compact mining laser” it seems to work ok with other mining lasers.
Sorry I already switched to t2 miners and resold the others.I will buy some more and look sometime but for now I have another bigger problem.
When mining now using t2 miners everything works ok at 1st but after 2 or 3 trips the bot suddenly looses a module and starts mining with only 1 module on every trip from then on and the script is reporting its only got 1 module but the api says it has 2 modules. restarting the script does not help the only way I am able to fix is to restart Sanderling.
Think ive solved the problem by lowering the graphics and running the eve client directly instead of using steam to run it.I will test it for longer later.
Sorry I already switched to t2 miners and resold the others.
Nevermind, it is not that important.
Yet another problem.
I left the script mining for a couple of hours came back to find the bot in a belt the ship had a full cargo but the bot said it was empty and was sitting there repeatedly cycleing the lasers.
Most of these problems seem to be sanderlings fault and not the actual script.I guess its possible to write fail safes into the script so it sorts itself out when sanderling falls over but the point of sanderling is this is not supposed to fall over and be easyier to script. At the moment writting a screen scraping bot with fail safes is more reliable and easier to understand what went wrong when things do .
I left the script mining for a couple of hours came back to find the bot in a belt the ship had a full cargo but the bot said it was empty and was sitting there repeatedly cycleing the lasers.
The cargo fill percentage is determined by reading capacity gauge from the inventory window. If for example, the inventory window is not open anymore, the reading fails.
Hi in this case nothing had changed the window was still open and readable but was returning no value at all. So on the log it was just showing the % character with no value.
I manual sent the ship to dock but left the script running and when docked the script unloaded went back to roid belt and started to work properly again reading the cargo guage correctly again .
I dont understand enough yet about how the script and sanderling work together to reverse engineer and work out what went wrong.
Thanks for describing your observatios, I now have a better picture of what happened.
I dont understand enough yet about how the script and sanderling work together to reverse engineer and work out what went wrong.
One way to better understand how they work together is by looking at the Sanderling side in the API Explorer. The API Explorer shows what Sanderling reads from the eve client process and updates with each reading. There you will also find the capacity gauge in the SelectedRightInventoryCapacityMilli property of the inventory window. If the information from the API Explorer is not consistent with what is on the screen, then we can assume that there is a problem in the Sanderling part.
Using a sample of the eve client process from a time when a memory reading problem can be observed, I might be able to fix it.
The guide at http://forum.botlab.org/thread/collecting-samples-for-memory-reading-development/ explains how to take such a sample.
But what did the script do when back at dock that corrected this issue or was it just the change to station enviroment that fixed it?.Because if it was the script I could add a failsafe but if it was the enviroment change it would be harder as it would have to dock to fix it.
But what did the script do when back at dock that corrected this issue or was it just the change to station enviroment that fixed it?.Because if it was the script I could add a failsafe but if it was the enviroment change it would be harder as it would have to dock to fix it.
There is a higher probability that it was the environment change. There might be a simpler way to fix the issue that does not require docking or changes to the script. If the issue can be reproduced with a sample snapshot of the eve online client, I can fix this soon.
Ok I have downloaded the sampler and done a successful test sample now I will just have to hope the bug happens again while I am watching as a bit scared to leave it running now as this bug running for say 1hr is like having a sign on my ship saying “I`m a macro miner” LOL .
Ok I have not been able to reproduce the cargo reading bug but while trying I have discovered another bug. The bot was having problems locking 2 roids and I noticed the reason was the overview shortest distance was not at top so I clicked distance to fix it. I come back a 30 min later and is done it again. The script seems to be hitting 1 of the other tabs which is making the distance column not in order. Unlike the other bugs this is happening allot but I’ve not been looking at the screen when it happens yet so not sure what it is doing.
Is the sorting of the entries is saved per Tab?
In case the bot misclicks on the Tab Column header, we can make an addition to detect the sorting and then click on the distance tab header as long as the sorting is not ascending anymore.
Is the sorting of the entries is saved per Tab?
.I am not sure what you mean I have saved an overview preset I cannot find away to save the sorting I am only able to set manually…
.I am not sure what you mean I have saved an overview preset I cannot find away to save the sorting I am only able to set manually…
Thanks, I guess that rules out the possibility to have it fixed by loading an overview preset. I will look into detecting the current sorting in the distance column then.
I guess once we know the sorting of the column, we can fix it by clicking on the column header.
I need some more info about what happened when you tested.
In particular about this:
The bot was having problems locking 2 roids and I noticed the reason was the overview shortest distance was not at top
How did the shortest distance not being at the top result in a problem with locking?
I do not yet understand how the next asteroid to lock being in the second row would cause a problem with locking.
As I understand the script, the asteroids are sorted by distance anyway before selecting the asteroid to lock.
The script also writes a log entry to identify the asteroid it will try to lock as you can see at https://github.com/Arcitectus/Sanderling/blob/5dc223deb738f9b835d2d09d78196bd0702dbaae/src/Sanderling/Sanderling.Exe/sample/script/Mine.ore.cs#L310-L311
The log entry contains name and distance of this asteroid after the text “, next asteroid not targeted:”.
Because the distances became random and the bot decided the distance between roids was to big so the miss click must be hitting another tab not the distance tab.
Because the distances became random and the bot decided the distance between roids was to big so the miss click must be hitting another tab not the distance tab.
I am confused, is this still about the locking issue you saw earlier? I see no connection to locking here. To lock an asteroid, the bot opens the contextmenu on that asteroids entry in the overview and then clicks the menu entry to lock.
Is no contextmenu opened if you click on an overview entry which is in the second row of the list?