Minecraft Version

1.12.2

Forge Version

1.12.2-14.23.5.2768

Mod Version

1.12.2-0.11.0-353

Describe your problem, including steps to reproduce it

There are four tanks requesting gasoline and a nearly full refinery of gasoline. The logistics drone is not delivering to the right most tank even though it is covered by the range of the drone.

The drone is hovering above the first tank

The drone always filled the nearest tank first and eventually filled the last tank, now this doesn't seem to work.

Many thanks again.

The last one had 10 mb. When I dropped and replaced the drone it started to, mostly work again. It is filling the gasoline tanks and no longer filling the top of the two thermopneumatic processing plants and there's plenty of LPG there. My bad the minimum request size was 8 buckets.

Ah, so it's all working OK now?

Can I just check what kind of frame you have on the refinery tank holding the gasoline ?

Actually never mind, I can see it's an active provider. I'll try and reproduce this and let you know.

Maybe this will help, I set the minimum request size to be 100 mb and when I bucketed out 1 bucket from the first barrel the drone moved and filled the barrel back up to 8 buckets.

The drone was placed down on the fluid tank at the other side of the refinery. I changed the face of the refinery to face the tank, but this didn't change the behaviour.

What's the min. request size on the barrel that's not getting filled? (which is the one furthest from the refinery, right?)

I'm testing now in my dev instance and can't reproduce the problem. The drone seems happy to fill all 4 tanks (using EnderIO tanks rather than IE barrels but that shouldn't make a difference). Also using a min. request size of 100mB on all 4 tanks.

Not really, the drone seems to get stuck after a time and I need to drop and replace it for it to start working again.

Yesterday I added a second drone and placed it on a tank with Kerosene and a default storage frame, today this drone was sitting on the refinery and doing nothing. The refinery was nearly full with Kerosene. I tried moving the active faces of the active provider frame to different sides but it made no difference. Replacing the drone it started working again.

The image shows the drone sitting on the refinery, a kerosene lamp on the left and a tank on the right. The lamp wants 2 buckets has a minimum order size of 500 mB. There is 250 mB in the refinery that should be moved to the tank.

Yeah, this is going to be a tricky one to track down.

One thing to try: next time it happens, can you remove and replace a logistics frame (any one will do) or even just add a frame to a nearby unrelated inventory? Placing/removing frames forces drones to recalculate their cached map of nearby frames; my concern is that cache is becoming somehow stale or invalid.

Might also be worth trying build 364 - no specific drone fixes, but I added debug-logging (i.e. via helmet Drone Debugging) to Logistics drones for when the drone can't pathfind to an inventory. I doubt it's a pathfinding problem, but always useful to rule these things out...

Yeah both are good ideas, thought of doing the first but hadn't though of the clearing drones.

One of the reasons the drones take a while to charge is the pressure is halved and I'm not sure why the pressure is reduced after the regulator, I would expect it to be that same on both sides.

I have noticed problems in the past with taking a tube out the side of a regulator module; you're probably best not having regulators on tube junctions. I'll take a look at that as well, though.

Here is some more information, the routines are stopped, removing and replacing a requester frame didn't restart the drone.

The frame didn't update when removed, this is just cosmetic.

The regulator was on a T junction, maybe I need to have a pressure tube after the regulator.

I think I'm going crazy, there was nothing to do as the refinery was not running, now it is running one drone is busy and the other is just sitting there. Sorry I was giving you some incorrect information, the drones were charged but there was nothing to do. Normally logistic drones just hover when there is nothing to do.

The routines say they are stopped when they are busy. Does this help a bit?

Not been able to test much this week as I've had no internet.

This is strange and last time both drones were under the charging station. It is winter and the solar generator doesn't work when snow sits on the mirrors so there is no pressure to charge the drones. I reckon a game restart positions the drones under the station.

You have to break the station to get the drone out.

Yeah, I've found drones hiding under charging stations in the past. I thought they were able to fly out of there on their own, though - I'll double check that.

They have little or no pressure as the charging station had no pressure, so they can't fly out.

Ah, OK. You may need an alternate power source for your charger, then :) Or a way to keep the solar panels clear of snow (drones?)

When any drone runs low on air, it'll go to the nearest charging station and go to standby while charging. So it's not unusual to see a logistics done on standby - it just hasn't had any tasks since charging, I'd guess.

Regarding the "stopped" message, I've seen that before - I don't think it's the cause of the problem (may just be server->client sync issue) but I'll add it to the list to check :)

Just confirmed that drones hiding under a Charging Station are able to fly out themselves when they have a reason to. So that's OK.

And I believe I've figured out why the drone were wrongly claiming to be "Stopped" - it's down to The One Probe. The ToP info panel creates a client-side instance of the drone for display purposes, and because the client-side drone has no program (programs only exist on the server-side entity), the label got overwritten as "Stopped" (normally the active label is sync'd from the server).

Today after starting the game the logistics drones are working just fine. I'm using pneumaticcraft-repressurized-1.12.2-0.11.2-364 but don't think the upgrade is the reason. Moved the charging station to a new place and changed the piping on to the refinery.

Thanks for your help

OK no problem. It could be a pathfinding issue, which are always a pain to reproduce, let alone track down. I'll keep an eye out for any odd done behaviour though.

Going to close this one out... I don't think there's much else to do here. Feel free to reopen if the drone problem comes back.

This is happening again with 1.15.2. I suspected this was previously caused by upgrading the mod pack where mods have been added and removed. In this pack the only mod that has been upgraded is pneumaticcraft-repressurized.

Here is the list of mods.
AppleSkin-mc1.15.2-forge-1.0.14.jar
BBOutlineReloaded-2.2-1.15.2-forge.jar
ChunkNoGoByeBye-1.15.2-1.2.0.jar
config-2-3.0.jar
Controlling-6.1.5.6.jar
Cucumber-1.15.2-3.0.8.jar
FastLeafDecay-v22.jar
findme-1.15.2-1.3.0.jar
gravestone-1.17.5.jar
Harvest-forge-1.15.1-1.2.11-24.jar
invtweaks-1.15.2-2.0.8.jar
jei-1.15.2-6.0.2.12.jar
journeymap-1.15.2-5.7.0b3.jar
justenoughbeacons-2.0.jar
JustEnoughResources-1.15.2-0.10.1.77.jar
light-overlay-4.7.0.jar
MouseTweaks-2.13-mc1.15.1.jar
MysticalAgradditions-1.15.2-3.0.1.jar
MysticalAgriculture-1.15.2-3.0.8.jar
NaturesCompass-1.15.2-1.8.5.jar
OreExcavation-1.7.151.jar
Patchouli-1.15.2-1.2-35.jar
pneumaticcraft-repressurized-1.15.2-1.4.1-56.jar.disabled
pneumaticcraft-repressurized-1.15.2-1.4.2-58.jar.disabled
pneumaticcraft-repressurized-1.15.2-1.4.3-60.jar.disabled
pneumaticcraft-repressurized-1.15.2-1.4.4-61.jar.disabled
pneumaticcraft-repressurized-1.15.2-1.4.4-62.jar.disabled
pneumaticcraft-repressurized-1.15.2-1.4.4-63.jar.disabled
pneumaticcraft-repressurized-1.15.2-1.4.4-64.jar.disabled
pneumaticcraft-repressurized-1.15.2-1.4.4-68.jar.disabled
pneumaticcraft-repressurized-1.15.2-1.4.5-69.jar
shapeselector-1.15.2b3.jar
StorageDrawers-1.15.2-7.0.2.jar
theoneprobe-1.15-2.0.4.jar
TrashSlot_1.15.2-11.0.0.jar

Here is the set up and it hasn't changed for quite a while. This was working until the drone was picked up and placed down again.

Can't see anything obviously wrong there, but without being able to reproduce the problems myself, there's not an awful lot I can do. I will keep an eye out for problerms, but my Logistics Drones are all behaving themselves properly in my various dev & test worlds...

The most likely cause of failures is pathfinding, which can often be a bit flaky. I can see the frames on the compressors are facing the repeaters, which shouldn't cause problems, but try pointing them upwards instead to see if that helps.

So newly crafted drones work, but if you wrench and redeploy a misbehaving drone, it doesn't work?

Just tested this and yes. This it is the case a newly crafted drone works but a redeployed drone doesn't work.

That's very interesting. Not much of the drone's internal state is serialized to the item when it's wrenched, so it's surprising that a redeployed logistics drone would act differently from a fresh one. I'll do some testing with your world on that anyway and see what comes up.

I would be surprised if it is path finding as multiple drones are behaving like this and other drones that were placed a while ago are still working fine.

There was a crash when I placed a tank with a fluid on a tank with another fluid and cannot be sure if this has caused a corruption to the world save or this problem. You only see a drone not working when it is placed down and it sits there doing nothing.

I could export the pack with the world, they are not large and you could test against this. Exporting and importing the world is painless with MultiMC, would this be an option?

Sure, feel free to do an export. Might help me to spot the problem, although if I can't get it into my IDE dev environment (which is unlikely if there a lot of mods - it's not just a matter of dropping mods in), debugging won't be an option. Worth a go, though.

https://www.dropbox.com/s/ho4aktno6tl4mf1/PnC-Repressurized-0.0.3.zip?dl=1 the file is about 156 MB and there is the crash report too.

It is not related to the crash, I have two backups, one before and one shortly after the crash. A new drone behaves as expected.

I have redeployed logistics drones in the past, and they worked correctly afterwards. Usually, when a drone runs out of air or get stuck on something. So, it is not a general problem with redeploying the drones.

The instance you exported won't import into MultiMC (using "import from zip") - I get Archive does not contain a recognized modpack type.

Sorry, about that, I didn't export the mmc-pack.json file

https://www.dropbox.com/s/5cvot17f9yfzlid/PnC-Repressurized-0.0.3.zip?dl=1 worked for me.

That works thanks. I found the "comatose" Logistics Drone, and yep - it doesn't seem to be doing much.

Wrenching it and inspecting the NBT (/dumpNBT command with the drone in hand) shows it has a little Kerosene (41 mB) in its tank. I think it's trying to export the Kerosene to the tank above it (with the storage frame), which fails since the tank is full. And it's fixated on that task, ignoring any other possible tasks which need doing.

I'll need to go through the code and work out if this is what's actually happening, but that's my theory...

It is strange, the tank has 83 mB space and the drone has 41 mB of kerosene.

If you take a bucket of kerosene from the tank and place it in the left fluid compressor the drone works again.

I can imagine with multiple drones covering the same area two can try to fill the same tank concurrently.

I saw it had 41 mB when it is in your inventory but the dumpNBT is very helpful, thanks.

I do believe I've nailed this one. The drone was indeed getting fixated on dropping off the fluid it held, and ignoring any potential item tasks that could be done. I've altered the code so if a drone is carrying a fluid it can't drop off, it'll still check for item tasks (and vice versa: carrying items, it will still check for fluid tasks).

The other thing that might be nice to add is the ability to extract fluid from a drone (that you own), by right-clicking it with a fluid tank. This is more important than for items, since drones drop their items when wrenched, but don't drop their fluids.

Anyway build 74 has the fix, if you'd like to try it out.

Something else I think is happening is that the drone really wants to supply the requester, but currently can't, because the fluid it's carrying is less than the requester's min order size. I believe I can fix this by ignoring min order sizes if the drone is already carrying some of the requested resource (but continue to honour min sizes where it would involve the drone going to collect the requested resource from a provider).

OK, give build 75 a go....

The drone doesn't go to stand by when it is holding fluid.

There are two places that the drone can at this time deliver the kerosene, the tank and the liquid compressor. (A second liquid compressor has more than required.)

The tank has space for 83 mB and the liquid compressor has space for 25 mB. The drone has 41 mB of kerosene.

I reckon that the drone is waiting for the compressor to have 41 mB of space. When a bucket of kerosene is placed in the compressor then it is full and the drone looks for an alternate place.

Take a bucket or kerosene from the right compressor and place it in the left compressor (facing the farm)

The drone now take kerosene from the bottom tank (with a passive provider frame) and places in the top tank (with a default storage frame) instead of filling the right compressor.

Dancing drone

Maybe this is related, the default storage frame does not have a minimum order size so the drone flies around all the time when the refinery is running. Could it have a minimum order tab?

I've been thinking about that as it happens. I'll experiment with that and see how it works. I have a feeling there was a reason I didn't add this back when I added it to the requester frames, but I can't remember why...

Regarding the compressors, yes the drone will try fulfill requester frame orders before storage frame orders (requester frames having the highest priority). But it should be dropping off at the storage frame when it can't fulfill the requester frame order. What's the minimum order size on the requester frames currently?

The frames are a default storage frame and this can only be filled from an active provider frame. The tanks as you noticed are set so that the stop frame is a default storage and the bottom frame is a passive provider.

The idea is that the drone take the fluids from the refinery and place them into the tower of tanks. The bottom frame is passive so it can only provide to a requester frame - i.e. the compressors.

Build 75 is taking items from a chest with an active provider frame and placing them into the storage controller with a default storage frame. Previously it would only place items there if they were already there - like right-clicking the controller. Did you mean to change this?

The frames are a default storage frame and this can only be filled from an active provider frame.

Yeah you're right of course, the passive provider will only provide to requester frames. I re-wrenched the two tanks together, and the logistics drone is behaving itself now, sitting beside the tanks on standby. I also tweaked the stored amount in the liquid compressors and that started behaving itself too. The drone was ignoring one of them for some reason, not sure why. I did notice that one of your frames was pointing sideways (at one of the pressure tubes) - I reoriented that to point up. Not sure if the tube would block the drone from accessing that face of the compressor, but frame orientation can be important since it tells the drone which face to import/export resources on.

Build 75 is taking items from a chest with an active provider frame and placing them into the storage controller with a default storage frame.

(Assuming you're talking about the mystical agriculture field) I can see it steadily moving items from the provider chest to the controller slave, but I don't see anything wrong here. Any empty unlocked drawers (and there are a couple in your setup) would be treated like empty slots in a chest - fair game for the drone to move items to. I haven't really changed anything here that I can see and I don't see the drone doing anything wrong. Locking the drawers stops the drone from moving anything that isn't already in there, as expected.

Yes, you are correct, I couldn't remember if a new seed type essence and seeds were taken from the chest of not, now I remember they are removed. Do you know if the behaviour is different with the yellow storage frame, if the only existing items are placed in the controller - like double right-clicking the controller?

I don't think it makes a difference about the orientation of the frame, in this case, as taking a bucket of kerosene from the tank and placing it into the left compressor and the drone starts working. I tried increasing the requested amount to 4 buckets and changing the orientation, the drone didn't move until there was no space in the compressor. Removing a bucket of kerosene still didn't cause the drone to place the kerosene in the compressor.

If there's fluid in the drone, try right clicking it with an empty tank, which will extract any fluid. Not sure why it isn't working for you otherwise, it was behaving OK for me in your world.

The only difference between the green and yellow storage frames is that the green ones have a lower priority, and drones will also move resources from green frames to yellow frames when possible.

It is more related not to the minimum order size as this was 1 but to the two bucket request. I'll let you know about build 75.

Note that build 75 also allows you to set min order sizes on storage frames.

I just also noticed you have the two kerosene tanks (one with provider and one with default storage) wrenched together, so the top tank will always empty itself into the bottom tank. That's going to confuse the poor drone, since it's constantly moving fluid from the bottom tank (provider) to the top one (default storage), only for it to flow straight back down into the bottom tank.

Wow, you implemented that already - that was fast.

One last test was to restore the original world (actually copy and past the world and play the copy) and remove the requester frames on the liquid compressors, clear the frames and reconfigure them. The drone started behaving normally.

Think this one's OK to close now...