Minecraft Version

1.16.4

Forge Version

35.1.13

Mod Version

pneumaticcraft-repressurized-1.16.4-2.8.1-96

Describe your problem, including steps to reproduce it

Quarrying with the program controller the dig piece ignores glowstone. There are no blacklisted items in the big piece.

Are you whitelisting?

Update: just set up a PC in the nether and it had no trouble at all digging Glowstone. If you're whitelisting, be sure you're filtering by the Glowstone Dust item and not the Glowstone block (unless you're using a silk touch tool). Item filtering for the Dig widget works by dropped item, not by the block being mined, remember.

Alternatively, tick the "Blockstate" checkbox in the Item Filter widget to force matching by block rather than dropped item.

My pickaxe is a mystical agriculture supremium pickaxe with silk touch and there is a supremium paxel for the other blocks. I would expect it to use the pickaxe. The dig piece has no whitelist or blacklist so everything should be dug.

Will you try with a silk touch efficiency V pick?

I'll try with a Netherite pick too, but it'll take a couple of days. Must admit that this is a strange observation.

It use the tool that had the fastest mining speed for the block in question. Not sure if the pick or the paxel will win there... both are suitable tools for mining glowstone IIRC.

I'll do some more testing with different tools. Just tried a plain netherite pick so far.

It uses the silk touch pickaxe as nether gold ore and nether quartz ore are mined. The pickaxe has efficiency V enchant so this will be fastest for all ores.

Just tested with a Silk Touch & Efficiency V netherite pick, and it also works fine. Glowstone blocks are mined up, as expected.

Merry Christmas to you too.

No worries, I won't be around for a day or two either. Have a Happy Christmas!

Having seen that video and tested a bit myself, my theory is that gravel has fallen from above into the horizontal slice that the drone is mining. When it finishes the slice, it moves onto the next slice below, ignoring the gravel that fell into the blockspace that it already mined. And that continues on, since gravel will keep falling into the slice that's just been mined, and the drone will just ignore it until it can't fall anymore.

Not a bug in PNC as such, more of a general awkwardness with gravel, or other falling blocks. A couple of workarounds I can think of:

1. Now that you have a Netherite drill bit (I watched your last video :) you could try using a Jackhammer in Vein+ mode as the digging tool. You may be pleasantly surprised at how fast it digs, but it will use air very fast. Switch on tool charging in the Programmable Controller, and also the next build (coming today) will increase the rate at which the PC can charge the Jackhammer. Expect it to use a lot of air, though.
2. You could bodge it in the program and do two passes of the slice, to catch any blocks falling in. Not ideal, since there could be more gravel waiting to fall...

I also noticed that the drone isn't great at picking up lava. This is because the drone won't move into lava (at all), and any extra flowing lava around the block the drone wants to absorb also stops it from getting close enough to source blocks to pick them up. Again, not really a bug, though it might be nice to allow moving into lava, for just the Programmable Controller (not real Drones). I'm undecided about this right now.

Having seen that video and tested a bit myself, my theory is that gravel has fallen from above into the horizontal slice that the drone is mining. When it finishes the slice, it moves onto the next slice below, ignoring the gravel that fell into the blockspace that it already mined. And that continues on, since gravel will keep falling into the slice that's just been mined, and the drone will just ignore it until it can't fall anymore.

The video showed the top level of lava, it wasn't falling down at this stage. After the third row the drone started to mine the gravel and it rapidly caught up, by the fifth row the lava was level with the lava.

I added the "trashcans" mod and fed the lava into one from a liquid hopper with two speed upgrades. Lava was minded correctly, The video shows the end of one lava level until the next. I was pleasantly surprised how well the drone mined up lava, it worked perfectly.

The problem you observe is I placed the gravel one block too far back so there was a column of lava source blocks.

The mini drone does sort of go through lava, isn't it a virtual drone, https://user-images.githubusercontent.com/4198031/103172842-ae160c80-4856-11eb-87ce-b3f32b44b73f.mp4

What is odd is that it skips glowstone.

I'll record a new smaller segment and convert it to a time-lapse, then it should be clear as to what is happening.

I tested with a silk touch, efficiency V Netherite pickaxe and it made no difference.

I reckon this is something to do with relative coordinates when mining in slices from top to bottom. Using the program https://pastebin.com/3bM3vUxq, I can see that it does not mine gravel until the height of the gravel is more than three high.

Here you can see it mine the nether blocks and skips the gravel.
https://user-images.githubusercontent.com/4198031/103165719-73db4980-481b-11eb-80fc-646d94369676.mp4

Honestly no idea why it won't mine glowstone for you. I haven't tried the mystical tools, but the jackhammer and vanilla picks are working fine for me...

The minidrone uses the same block movement checks as regular drones when deciding if it can move to a particular block, and lava is always considered non-pathable. When I did some testing, I noticed the PC skipped quite a few lava blocks because it didn't want to path into them, or into neighbouring flowing lava.

Two videos for you.

Digging with the jack hammer - it did mine the glowstone.
There is a new behaviour that has changed in version 2.8.1 from version 2.8.0, the handling of lava.
https://user-images.githubusercontent.com/4198031/103353186-73a3ae00-4aa8-11eb-8b4f-6b17db6371b8.mp4
https://user-images.githubusercontent.com/4198031/103353314-d301be00-4aa8-11eb-982a-9ffad21522e4.mp4

I have previously tested this with a Netherite pickaxe, and it didn't mine the glowstone, I'll test with this area.

Would have helped if the correct clip was given :-(
https://user-images.githubusercontent.com/4198031/103362864-06007d80-4aba-11eb-8680-55f5b4c9ad80.mp4

The PC with a Netherite pick ignores glowstone and gravel, with a Supremium pick it behaves the same, ignore glowstone and gravel and with a Supremium Paxel, it mines gravel and ignores glowstone.

https://user-images.githubusercontent.com/4198031/103358759-a6ed3980-4ab6-11eb-9715-ef95cf9ad784.mp4
https://user-images.githubusercontent.com/4198031/103358764-a94f9380-4ab6-11eb-8c7e-a68bfc8c0000.mp4
The Netherite pick clip is here.
https://youtu.be/zi9Gl_bTOwM

Both glowstone and gravel can be mined with "no tool", could this be a reason why they are not mined?

I honestly don't know at this point. All my testing (including stepping through with the debugger) shows glowstone being mined absolutely fine with a netherite pick. I simply can't reproduce the problem you're seeing.

I think I might just have figured it out. Do you have "Require digging tool" checked on your dig widget?

That would prevent glowstone & gravel being dug, since the digging speed with a pick for these blocks appears to be the same as digging with an empty hand, which makes the drone think it doesn't have a specific tool equipped. In that case, it won't try to dig those blocks.

I can fix this very easily though (by ignoring the "requires tool" check for those blocks which are mineable by hand such as glowstone and gravel...)

Can you give build 104 a go when you get a chance?

What specifically has changed about lava handling? It's not entirely clear from the video. If it's the iteration order, that can be somewhat non-deterministic in my experience.

I did fix the lava voiding bug, although that fix is in the 2.8.2 release (along with a Void Fluids widget if you still want to get rid of the lava).

BTW, if you're on discord, PNC does have a discord server now: https://discord.gg/Zf5XwbfBRj (relatively quiet, but slowly picking up various PNC afficionados... you're welcome to drop by!)

Many thanks, you figured the digging problem out! Build 104 works as expected. I always set "requires digging tool" to true just in case I forgot to insert the digging to into an inventory of for the drone or into the PC. It also helps with debugging programs - no tool also to test the setup logic.

The lava handling it very strange, why does the drone move around the lava lake as it now does?
Here is build 104 handling gravel, glowstone and missing lava source blocks. https://youtu.be/kKniWodq0Xg

I think part of the problem with liquid import is that you can't set the order like you can with Dig and Place widgets. It always uses an order of "Closest", i.e. the lava blocks to be imported are done in order of closeness to where the drone is when the widget starts executing.

Lava is particularly problematic here, since the drone will never path to a block that contains lava, and once it starts importing lava blocks, flowing lava confuses its pathing quite badly. So the lava block it wants to import might be not importable any more due to flowing lava being where it expected it to go; and then it will just skip over that block and try something else.

Difficult to completely fix, but there's a couple of things I can do which might help:

1. For the PC specifically, allow the minidrone to path into lava. It will already fly through lava as long as the its destination block isn't lava, so I'm not too bothered about allowing it to path into lava (part of the point of the PC is that the minidrone isn't "real")
2. For non-PC drones, possibly have the Security Upgrade allow pathing through lava, but at a non-trivial air cost (similar to how the Chestplate allows it with a Security Upgrade, but probably without turning lava to obsidian). I'm not totally sold on this idea, though.
3. More generally, allow setting a block sort order for the Liquid Import piece. Top-down would generally be the right option for this, though there might be times when some other order is useful...

Odd. The only possibly relevant fix I can see was this one in build 97: 8541292 - which is the fix for the fluid import widget always voiding fluids picked up from the world.

Happy to try with this commit reverted. How is the commit related to importing the fluid, in the condition, I would have thought that it should be part of the code when the condition is true?

May be worth a go, but I have another idea I'm trying out right now which might solve this. Basically, it appears the area the drone is processing is getting sorted too frequently and changing during the iteration process. Should have another build to try out tomorrow...

Did you watch, the lava handling between build 96 and build 101?
https://user-images.githubusercontent.com/4198031/103362864-06007d80-4aba-11eb-8680-55f5b4c9ad80.mp4
https://user-images.githubusercontent.com/4198031/103353314-d301be00-4aa8-11eb-982a-9ffad21522e4.mp4
Build 96 works as expected and build 101 starts off as expected and then import lava from the random positions. If you want I can test with builds 97 to 100 to see where the behaviour changed?

For the PC specifically, allow the minidrone to path into lava. It will already fly through lava as long as the its destination block isn't lava, so I'm not too bothered about allowing it to path into lava (part of the point of the PC is that the minidrone isn't "real")

Sounds like a plan. The minidrone can move through walls so why not fluids.

For non-PC drones, possibly have the Security Upgrade allow pathing through lava, but at a non-trivial air cost (similar to how the Chestplate allows it with a Security Upgrade, but probably without turning lava to obsidian). I'm not totally sold on this idea, though.

Me neither.

More generally, allow setting a block sort order for the Liquid Import piece. Top-down would generally be the right option for this, though there might be times when some other order is useful...

Top down is logical for fluids, not sure when the others would be used, it's interesting how people choose to use puzzle pieces. The program I'm using mines a vertical slice at a time, so it should not matter in this case.

There is something else that you can think about and that would be to have a void option on the import items and fluid pieces. The inventory of a PC and drone can only hold a limited number of buckets of a fluid or items so the capacity can be filled before the area has been imported.

This is a snippet of https://pastebin.com/b7kqa3qa and here you can see that the layer needs to be completed before the next layer is processed. Eventually, the mining level will reach zero and repeat but this would be very slow.

Happy new year and many thanks for your time developing this outstanding mod.

Would be interested to see how build 105 works for you. I've made quite a few changes to block interaction code (see commit message above), and I found a PC can now import a lava lake pretty effectively. Sort order isn't 100% top-down, but a lot more predictable now, and the PC's new ability to path into lava blocks fixes a lot of the issues, I think.

Also fixed the search particles not showing (that's broken for a little while), and added colouring for the particles based on the widget that's searching (e.g. blue for liquid import, brown for dig...)

There is something else that you can think about and that would be to have a void option on the import items and fluid pieces

Do the Void Item and Void Fluid widgets not work for you here?

Not working for me yet. There are four source blocks that are not being imported since build 100, I can restart the PC from 1 slice above the lava, and they are being skipped every time.

How big is the fluid tank in the PC with 35 inventory upgrades? If it is less than 2048 buckets then void fluid won’t work as the tank will become full and the program would the move to the next piece and leave the remaining blocks. There is no reason why the mine is 32x64, (It is actually 33*65 as I forgot about the first block) The mine could be 500x500 = 250,000 blocks

With 35 inv upgrades, the tank is 576 buckets (16 + 16 * 35) in size. Yeah, I see the problem there. I'll consider that. I'll also check the commits in build 100 that might have changed this behaviour though nothing obvious jumps out at me right now. That build only changed two things:

1. bugfix for the coordinate operator x/y/z field selection
2. increased held item charging rate for tools used by the PC minidrone

Nothing directly related to area iteration at all, really. Definitely works ok with build 99 and earlier?

Builds 97-99 had the missing commit bug, so I cannot test these. Actually, I checked all the builds from 97 for 105 today.

I let the program run for a few levels with build 104 and then tried build 105 (restarted at level 35) and the result was the uneven lava and finally used build 96 (restarted at level 35) and you can see how the lava was imported.
https://youtu.be/mX5yPvlSwD8

After some more research, a bit more info...

• I think the fix in build 97 didn't cause the problem, but more likely exposed an existing bug which was previously masked by the inspection process wrongly removing the fluid blocks
• The reason blocks sometimes get missed is down to the way the algorithm works: the drone is regularly re-sorting the area to get the closest blocks to itself. Re-sorting is actually not that important for a solid area (like a quarry or a lava importer), but it's critical if the area is hollow (e.g. building a frame or walls) - without it the drone will be constantly moving back and forth to alternately build opposite sides of the structure.
• The re-sorting process can shuffle block positions around so that nearby positions get missed from time to time. But even with re-sorting active for your lava importer, those blocks should get picked up when the program cycles back round to that Y-level. In all my tests, that has been the case.

I could perhaps have a "Dynamic Sort" checkbox on the progwidget to enable/disable this re-sorting (default: active). It could be switched off for widgets that excavate or fluid-import a solid area, and would have a tooltip explaining that...

Update: thinking about it more, I believe there's an even better option: use re-sorting for sparse areas (e.g. a big hollow box like a building), but not for solid areas (like your quarry). Since I have the "density" information easily (total volume of the extents divided by the number of actual block positions), that could be a very useful heuristic.

Happy to try when you are ready.

I wondered if there was a buffer, when watching the PC with One Probe I noticed that the items were coming in in batches of up to eight items.

What happens if the tank of the PC becomes full, does the drone wait for space in the tank or move onto the next puzzle piece? The dig puzzle piece just drops the items and the import item piece waits.

If the tank is full, the fluid import finishes immediately (i.e. stops scanning) and the program moves to the next piece. Digging items behaves differently - items will be left lying on the ground (and of course there are two ways of picking up items - magnet and the item import widget).

I think a void option might be useful for fluid import, but probably not for item digging/import - solid blocks can still be mined when the PC inventory is full, but fluid blocks can't be touched at all if the tank is full.

Having said that, this can actually be worked around in the program with a Drone Condition: Fluid piece right after the fluid import is done - if the tank is full, void it (with the recently added Void Fluid piece) and go back to the start of the fluid import process. Note the tank's volume in mB is 16000 + 16000 * inv_upgrades if you want to test for fullness.

Build 108 is available for testing. You should see a far more predictable iteration of the area with this build...

Hmm, interesting pattern:
https://user-images.githubusercontent.com/4198031/103458273-b498fe00-4d06-11eb-8d3e-01cd4abddf3a.mp4

The previous digging mode was closest.
The scanning of empty rows is much faster.
https://user-images.githubusercontent.com/4198031/103458490-0fcbf000-4d09-11eb-9ad9-3ae7379657aa.mp4
High to low behaves the same as closest.

Hmm, interesting pattern

Yep, makes sense if you think about it: if the drone is at the corner of the area, it sorts by blocks closest to its current position. In your first video there, the dig order is sorted by distance from the front right of the picture.

So, does it appear to be working well?

High to low behaves the same as closest.

Since your program handles a horizontal slice at a time (iirc), that would make sense. You would notice the difference if you quarried a large cubic area in a single operation (not that I'd necessarily recommend doing that... slicing and coordinate arithmetic tends to work better for these applications)

It seems to have skipped most of the lava.

Not sure what closest means, does it mean closest to the current drone position of closest to the first position. The second level it minded in a circle from side to side.

Closest to where the drone is when the piece executes. So if the drone starts off to the side somewhere, the first slice will likely be side-to-side, and the drone finishes in a corner of the area, so the next slice will be diagonals across the area.

I really don't know why lava isn't getting imported for you... everything I've tested works :(

I missed what it was doing when importing lava first time, this time I caught it. It does a bit until it hits the first non-lava block.
https://user-images.githubusercontent.com/4198031/103459887-65f16100-4d12-11eb-8b10-30b5ea22ca1e.mp4

If you want I can give you a world save or a multimc export.

Build 96 still handles both item and lava the best for speed and completeness.

Hmm, is your tank full? that would explain why it gives up and moves to the next level. And build 96 wouldn't have had that problem since it voided everything....

I'll add a fluid voiding option, but as a test you could try extracting the lava from the PC with a liquid & Creative Upgrade. With the Creative Upgrade, the liquid hopper will act as an infinite fluid sink (as well as source).

I added trashcans-1.0.5-mc1.16.4 and feed it with a fluid hopper and two speed upgrades. I think it should be fast enough. I'll test with a creative upgrade.

Many thanks for your efforts.

Added the creative upgrade, the drone mined up 24 lava blocks before moving onto the netherack.

Any speed upgrades? You will need several, or it won't extract fast enough.

Build 109 for voiding of excess fluids - new checkbox in the liquid import options gui.

I had two speed upgrades, now I added 11, and it works much better, I was wondering it this could have been a problem.

It's rather slow when it imports fluid in this pattern. I'll try build 109 with the void fluid option set. I'll also try an earlier build to see if too few upgrades were causing the drone to miss blocks.

There might be something else. With 35 inventory upgrades in the PC shouldn't the stored fluid amount be more than 16 buckets?

With the speed upgrades and void excess this is what happens and the video is the same as in #692 (comment).

Top video is build 109 and bottom one is build 104. I prefer the behaviour of build 104 but like the speed that build 109 processes empty layers and voiding off the excess.

Sorry for all the trouble, I should have realized earlier that it was lack of speed upgrades that was causing the problem.

Yeah, thinking the new autosort thing is possibly a mistake. As long as the tank doesn't fill, we're probably good. I'll have another play with it tomorrow though.

Build 110 backs the re-sorting disabling that I added. It does mess up the drone's iteration order, and you're right that's it better without it.

Also, try debugging the programmable controller with this build :) And let me know if you can break it, the code is very new and only lightly tested so far.

I think you're right: the fluid tank isn't taking inventory upgrades into account. It should really work the same drones, i.e. using the formula I gave above.

Actually, the code does update the tank's capacity according to the installed upgrades... I'll need to test this and see what's up.

Update: found the problem, will be fixed in next build/release.

On the topic of releases, I plan to get a 2.9.0 release out very soon. Would you say all the problems in this issue are resolved at this point? This is the only one holding up a release now...

We can't see the capacity of the tank, but it does look like the capacity is 16 buckets.

Debugger looking excellent

We can't see the capacity of the tank, but it does look like the capacity is 16 buckets.

It is. Problem is a bug where the PC ignores inventory upgrades (for tank sizing purposes) on world reload. If you take the inv upgrades out and put them back right now, it will increase the tank size... until the next world reload, anyway.

Note the tank's volume in mB is 16000 + 16000 * inv_upgrades if you want to test for fullness.

Don't think this is the case, otherwise the tank wouldn't have filled up so quickly.

I'll test this new build today and many thanks for debugging feature, I'll check this too, and it will be a real help.

Maybe you can change the "can't reproduce" label as you figured out what the original problem was.

Fixed in 2.9.0 release

The behaviour of the mini-drone is now excellent it minded correctly even with lava flowing above it. And I see replacing the upgrades does increase the tank - that would be a tricky bug to find.