Okay, this is weird. I accidentally set GetLasersData for the amount when boosted, though in testing I was alone. The first time I only set the M3 field, and it didn't appear to use it because it continuously canceled after the roid would have popped. I thought it would cancel early because I told it that the lasers were mining 8% more than they actually were.

Then, suspecting that I had to use all fields for the m3 to be taken... I filled them all out with the info from the module (still 8% too high), and it turned the lasers off 5 seconds too soon.

Do you take the m3 and round it up by 5-10%?

How does the Survey Scanner work, does it work if the ship moves? I'm getting some weird results.

Is GoToSelectedObject the best way to get within 2,500m of roids, or is there a setting that could do that? It takes 2-3 loops of approaching it, getting too close, orbiting... before it stays within range. Not a big deal, only matters for jet-can reuse.

Oh, that JettisonCargo thing I wrote was wrong. It happens when the Looter pops the can when the bot is dragging ore into the can. I actually have it as:
375: JettisonCargo()[376;240+;370;640;370+]
376: CloseWindow(1)[900;377]
377: CloseWindow(8)[900;378]
378: JettisonCargo()[900+;240+;370;640;370+]

I got it working yesterday and it made it all the way through the session! No drones lost either.
I tried to do an efficiency comparison with another miner of equal skill, but realized too late that some things were different. So I'm going to try again during the next session.

Yay, a 16% increase with no mining drone rigs! (Lost one mining drone though.)

Funny note: My AHK is making the bot even more efficient because, without scanner, the drones will sometimes drain a roid that didn't start at the expected volume. In this case my AHK will see that the drones emptied it, and will turn off the mining laser saving me 2 minutes in some cases.

Okay, I was having trouble understanding what to test, but now I now see that I wasn't understanding. Then I found this quote:
Nondeth wrote:
It seems like I've encountered a condition which will cause the bot to ELO when mining to a jettisoned container. If the bot does a select all just as a laser finishes a cycle, it will lose the selection on the stack which just updated. It will then try to jettison, and will either have a little to jettison or nothing at all, at which point it appears to just panic as it watches for the cargo space to drop - which never happens because of the selection failure.
Even if I could catch it and pause at that exact time... It still wouldn't change your logic. So are you looking to see if the m3 went down by the exact amount, significant amount, or what?

Because you can't do anything about that timing, there are a number of items that could be checked:

1. Ore Hold m3 Before


2. New cannister created


3. Ore Hold m3 After


4. New cannister m3

I tend to heavily factor/split functions so that they can be reused more often. So here's what I'd try to do (leaving out the non-essential stuff):
JettisonCargo - Leave as a function that calls other functions and controls the overall logic flow (as it seems to do now).

innominate wrote:
Do you take the m3 and round it up by 5-10%? Need to test if formula to estimate asteroid content from asteroid size still valid. After eve update, refining table change etc. something could change. I also noticed that content estimation does not work properly for mission asteroids (in a deadspace) but did not check this in regular belt after DT.

p.s. Sorry I was busy last days with website migration. Your suggestions are valuable and I am glad that somebody is helping to develop better algorithms.

Hi guys, sorry to interrupt the conversation...

Can I, someone with no experience in algorithm use this code in my bot? It's very cool!

Best Regards