in the latest version of factorio 1.1 and w/ Auto Deconstruct 3.7 when it flags a miner for deconstruction there is one last ore left in the miner.

The API doesn't reveal when there is an ore left in the miner, and you can't just wait a few ticks because it could be stuck there a long time if the belt is backed up. Any hack to solve this will be complicated and I don't know when I will get around to it. Sorry. If you want to try it yourself and make a pull request, it may be an inspiration.

There might be a solution for that.
Drill as a LuaEntity has a prop "mining_progress".
When there's still ore inside, it is > 0, so we might want to check on that as well and wait till it's == 0 before ordering a deconstruct.
I'm not familiar with lua, so it might take a while till I find a solution and make a PR. But if someone beats me to it, I won’t be upset.

Sorry, just missed the "edit" button... twice. 😅

<deleted>

There might be a solution for that.
Drill as a LuaEntity has a prop "mining_progress".
When there's still ore inside, it is > 0, so we might want to check on that as well and wait till it's == 0 before ordering a deconstruct.
I'm not familiar with lua, so it might take a while till I find a solution and make a PR. But if someone beats me to it, I won’t be upset.

I've tried this before. It's actually not a reliable indicator. mining_progress can be either 0 or 0.0083333 when the last operation is done, but it doesn't depend on whether the ore has been ejected yet and it doesn't change when the ore is eventually ejected.

Just now I made a branch with a queuing function that we can turn on if we ever do get a way to tell when the ore has been ejected.

... can't just wait a few ticks because it could be stuck there a long time if the belt is backed up.

I would guess that the case where the last ore is left in the miner but the belt is full and cannot eject is a rare one; just getting to the point where there is one ore left underneath the miner generally means that there was space on the belt for all the previous ore that was ejected..

In my opinion, waiting a few ticks before marking to deconstruct, at the worst case, will be exactly the functionality that currently exists (one ore left in the miner); but if given the case above, the majority of the time (non-rare cases) would no longer have an ore in the belt. You shouldn't have to check to see if there's an ore there or not; just give it time to try to eject..

Even if the full belt (cannot eject) case happens 20% of the time, that means 80% of the time there won't be an ore in the miner. Right now 100% of the time there will be an ore in the miner.

Don't let perfection be the enemy of good enough. :)

I came to say this same thing. It may not fix everything, but still waiting a few ticks will cover the majority of the problem. I just ran into this in early game where everything is very slow and empty. It felt weird that there was leftover ore when I had completely empty belts. Could we implement this as an update, even if there's still a small problem for full belts?

That's fair. Now that the last ore does get properly collected if it's stuck, there is something to gain by waiting a fixed amount for it to probably be ejected.

I just uploaded a version that does this. It waits 1 second (60 ticks) before placing the deconstruction order. Please test it and make sure there are no other problems.

Don't know if this has anything to do with that but multiplayer with this mod (and Space Exploration and several others) did not work after the patch.
My friend could not join because the mod "is not multiplayer compatible" or something.

Okay, that's a big issue. Please go back to 0.3.8 until I can test it some more.

Don't know if this has anything to do with that but multiplayer with this mod (and Space Exploration and several others) did not work after the patch.
My friend could not join because the mod "is not multiplayer compatible" or something.

I can't replicate this on a simple test server with two players joining. Can you give me more information on your setup or the error message? I might just push this version again and see if anyone else has a problem.

Idea: Only deconstruct if the space in front of the miner is clear to output to. If it's a belt, the near lane should be not-full. If it's a container, it should have open space (or have a not-full stack of the item being mined).

Idea: Only deconstruct if the space in front of the miner is clear to output to. If it's a belt, the near lane should be not-full. If it's a container, it should have open space (or have a not-full stack of the item being mined).

I have thought about that, but it's a lot of work to check all possibilities. It's much simpler to assume that if a miner is able to mine the last ore, that its output is already flowing, so waiting a fixed time period is good enough in most cases. Right now I have the delay set to 1 second, but it could potentially be longer.

Here's ChatGPT response: The script you provided seems to be designed to mark mining drills for deconstruction when they run out of resources. However, it appears that the script doesn't handle the case where there's one last ore inside the mining drill that gets mined. To address this issue, you might want to make a modification to the has_resources function.

Currently, the script checks if resource.amount > 0 to determine if there are still resources inside the mining drill. However, this might not be sufficient to catch the case where there's only one resource left. To address this, you can modify the condition to check if resource.amount > 1 instead. Here's the modified part of the has_resources function:

from my test, it worked. The drill gets marked for desconstruction but won't leave a ore inside. Requires more testing tho

What does that even mean. ChatGPT has no idea what the problem is. You would be deconstructing the miner while there is still ore left on the ground.

I finally implemented this feature--it waits up to 30 seconds for the transport line (half-belt) in front of the miner to be empty. It took 150 lines of code to account for all the permutations of splitter inputs and outputs.