For some reasons, fences don't get extracted when one on top of the other. That may explain other problems seen with the Quarry. See http://mod-buildcraft.com/forums/index.php?topic=585.0

@OrionDevelopment feel free to try that out.

Okey, will take a look at it. But it might take a couple of days. Have an exam next week... Will report if I have any progress on this or if I cannot find a solution.

@SpaceToad While rebuilding the algorithm should i take a look at issue #1803?

@OrionDevelopment if you want to do that just take a look at my code for the tools, just decrease the base energy the quarry uses, and make it mulitply that with the block hardness and the gamedifficulty + 1

@AEnterprise Yeah was planning to that. Have to rewrite the algorithm anyway so i will propably then take a look at this as well. Hitting two flies with one stone (or what is the right sentence :P)

I have been looking into some algorithms to use. My personal favourite is a DataMap (Maybe custom implementation needed) that contains for each column the height data of the area the Quarry has to mine (1), and the height until he can mine (2). For example For x1, y1 => (1) 76; (2) 13. Initialize this map before mining and use random updates to check if the map is still update for a random column.

Second in row would be a 'live' detection algorithm that just keeps the next couple of blocks in mind.

Third would be a implementation kind like it now is with a multiple leveled buffer that is recreated once it runs out of data.

What are your ideas for these systems guys?

I have been looking into this. A change of the algorithm of the quarry did not fix it. Tried multiple things and in the end CPW code is just as fast as any algorithm I tried.

I will have to take a look in the detection of Softblocks to fix this issue.

I will take a look at this.

Thanks @OrionDevelopment :-)

@OrionDevelopment that's be good intel indeed!

I have been tracking this down. It looks like the Quarry treats a fence on top of a fence as a nonsolid block. For now the easiest way to solve this is a hardcoded exception. I will continue to check as i am not 100% sure of what he cause might Be.

I still want to check how he treats them when that fence post is attached to a block though

Should I try to make a fix for this (either a special one or a generic one, into which other modder (or even we self) can hook to allow a block to be force broken (or set a block unbreakable) for the quarry and other related blocks) or has someone else interest in doing this?

@OrionDevelopment please, have a go!

Moving that to the 6.1 branch though - not critical enough for 6.0,

Yeah probably for the best. But should I try a generic one (or extend the backlist system) or should I write a hard coded exception?

This problem isn't only for fences. There are multiple ore types that are ignored as well. (Nether ores I think.)

What do you mean better Heuristics?

Okey i will give a generic solution a try. I will use IMC for communication to register the blocks i think..... That way modders do not have to depend on BC

Can't there be some better heuristics?

I mean, what's the decision that makes the Quarry believe that there's no block to be mined there, and how can we modify that decision by a better general rule?

He treats it as a softblock. But as i said i am not 100% certain, i am still doing some tests on how he makes the decision, for example i would like to test if it makes a difference if the fence post is connected to a block. (I have not got a chance to do that....sadly). Before i make any changes i will run some more tests just to be sure. And of course i will post the results here (maybe even with examples on how to solve them)

Cool - I'm looking forwards to the results of your investigations!

Okey i have been looking into this...... There seems to be more to this, then the eye reveals. After looking through the initial code the quarry runs before he starts digging he creates a two high overview of all the columns that he can visit. (See TileQuarry.java lines 315-321)

To determine that he grabs the block on the current location. And here comes the weird part if that block is a two high fence (Not a one high) he determines that the block that he is checking it for is the block that was there before i placed the fence. (WOW: if there was a grass block and i would break that grass block and would replace that with a fence on top of a fence he would detect a grass block not the fence.)

If he does the digging he has the same problem. I have been looking through the code to determine why this is happening and it seems to me that he is using an outdated (or out of sync) worldObj to determine the if he has to break that block or not.... I tried looking into the vanilla fence code, but failed as there are no proper namings for variables etc.

I tried a force update of that world. But I cannot get him to grab the proper world.

Okey, i have been testing some different solutions and i have no idea how to solve this. Anybody?

my sugestion: it was mentioned before that the quarry targetting code is not efficient (checking everything every tick) so start over with it, remove the code and rewrite it (using the function to check if it can see the sky should be better then checking everything for example) that way you can make sure there is nothing left to cause this issue (just a sugestion though)

and before anybody sais it: i'm NOT going to do this, i won't do much modding cause i have exams comming up

Well, I rewrote the search the quarry uses. I suspect there's an off by one error in the soft block checking code.. Using canseethesky breaks underground quarries, don't do that..

right, sorry didn't thought of that

Actually it is not off on the location. The block it retrieves out of the world is just not up to date. I can create an example test environment and upload that if someone wants to verify my results?

But I can take a crack on a rewrite and see it solves the issue?

Yes that might indeed be the issue here.
I had no time since my last comment to try stuff. (University and Work got in the way), If you want you can fix it if you know how.

If you need any information please feel free to contact me.

The getHeightValue function called in the createColumnVisitList function on line 305 of the TileQuarry.java file, may be the cause for the stacked fence posts and other non Opaque blocks being missed by the quarry.

The getHeightValue(x,z) function returns the block above the first opaque block, this causes it to miss non opaque blocks unless there is a opaque one directly below it.

So a fence post on dirt will be quarried, but one over air, or more then 1 block above a opaque block will be missed. This also is the case with glass and any other non opaque blocks. the Quarry ignores them unless the block directly below it is opaque.

if create a tower of glass blocks over a flat grass field, only the first glass block directly over the grass will be quarried. If while the quarry is running one replace any of the other glass blocks with dirt, the quarry would get the glass block directly over the new dirt block and the dirt block.