PneumaticCraft: Repressurized

PneumaticCraft: Repressurized

43M Downloads

Logistics Drones how does it select an inventory

duncanwebb opened this issue ยท 26 comments

commented

For feature requests, just erase this template and clearly describe the feature you'd like to see

Minecraft Version

1.14.4

Forge Version

28.2.4

Mod Version

pneumaticcraft-repressurized-1.14.4-1.0.5-16

Describe your problem, including steps to reproduce it

I have a number of provider frames some active and some passive. Most of the frames has logistics modules attached.

I wanted to take water from a gas lift and place it into a thermopneumatic processing plant, so I set an active frame on the lift and a requester frame on the processing plant. When I placed down a drone it selected an inventory on the refinery and as there is no free space it hovered there. I noticed after killing the drone with a wrench it lost the stored fluid. Next a small tank was placed down and attached a default storage frame on it and replaced the passive provider frame with an active one, nothing happened until a second drone was placed down. Then one of the drones deposited 16 buckets of gasoline in the tank. A third drone was placed down went to the same place and then switched to standby. None of the drones took the water from the lift to the processing plant.

Next logistics modules were attached and water was transferred to the plant.

Am I doing something wrong?

Any other comments?

The pack has two types of water and from the logistics interface does not show the mod names so it was tricky to identify which water was correct as the look identical.

I recorded the whole build so if you need to see the steps I'll make it available.

Thanks

commented

Do you mind if we reopen this? The logistics drones don't seem to be working with pneumaticcraft-repressurized-1.14.4-1.0.8-21.

Here is a chest with it contents

2020-06-22_20 55 42

Here you can see a fully charged drone on a chest and what the chest is providing. IIRC the filter defaults to the contents of the chest, so maybe this could be empty.

2020-06-22_20 55 51

Here is a requester frame asking for the items.
2020-06-22_20 56 34

The drone is doing this, not sure why the start has a red border. Showing the working area shows grey markers.

logistics-drone

commented

Yeah, I noticed in one of your videos that your logistic drones weren't behaving. I'll take a look into it.

Regarding the grey rendering, I think some other mod is interfering there. Hard to know what, though.

The red border there is harmless (I think some of the program state isn't fully synced to the client on debug... I feel like I've seen this before and fixed it, maybe that was in 1.15...)

commented

Can you give build 23 a go when you get a chance? I backported a bit more 1.15.2 code relating to drone block interaction to 1.14.4, which may or may not help...

commented

May be this helps? hard to see but increasing the items required from one to two made the drone work decreasing the number stop it working.

minimum-order-size

commented

Getting stuck on that cable is possibly a problem with the cable, not the drone. The way Minecraft pathfinding works is that blocks have a allowsMovement() method, which is used by the pathfinding code to determine if an entity can path through that block. By default, allowsMovement() is false for solid full-blocks (like stone, or dirt etc.) and true otherwise.

The problem arises for non-full-blocks (with a big enough collision box) which fail to override allowsMovement() - entities think they can path through, but as soon as they get there, they get stuck - forever, like the drone trying to get past that pipe. What mod is that pipe from (and what's the block name) ?

As for the other logistics problems you're seeing, I'm pretty much stumped at this point. I can't reproduce the problems.

commented

Of course, I'll test it, no problem.

Still, not working :-(. This is an empty chest and behind is a chest with 64 cobblestone. The logistics drone is sitting there.

requesting-cobble

Today the grey blocks are back to normal. I think this is something to do with the order mods are initialized which seems to be random.

2020-06-24_15 08 39

commented

Can you just verify a few more things for me:

  • Double-check the facing of the provider frame (i.e. make sure it's a face that the drone can access)
  • Double-check the min order size you have set in the requester frame
  • Make sure the Logistics Drone isn't carrying something that it can't get rid of anywhere, i.e. its inventory isn't blocked (don't think it is from the picture, but just to be sure...)

And finally, if you put the same test setup together in a test world (with only 2 chests, 2 frames and one drone), do you get the same problem?

commented

Also, does it work if you use Logistics Modules? That would tell me if it's a problem with the drone, or a more general problem with the logistics system (both drones & modules use the same back-end logistics code to determine what needs to be moved where).

commented

With a drone and a logistics module it works but not always. This time it put cobble in the chest and, after a while, items in the first crafter. It didn't provide to the second crafter. I may have triggered it placing items in the first craft by either opening the crafter's gui or checking the requester frame.

chest-with-cobble

drone-logistics

The drones have a problem with pathing, this one got stuck on a cable and another one wanted to fly through the refinery.

drone-pathing

commented

Nope, sorry, I can't get any logistics cases to fail in my 1.14.4 dev world.

I think we need to take a step back here, all these screenshots and videos aren't telling me much. What I need is a super-simple case where you can make a logistics drone fail to carry out a task. Ideally in a test world with nothing but a couple of inventories and a logistics drone, and full steps so I can build a reproduction of it.

commented

I did however fix the problem where updating an area widget in the programmer doesn't get sync'd to the server (which you encountered while trying to reprogram the drone to avoid the heatsink). That'll be in the next release.

commented

The mod is cyclic and the block is energy cable and I can reproduce it. I guess that this a bug in cyclic.

Something is strange that you cannot reproduce these errors. I can reproduce them almost at will. In the example with the logs the chest had iron ingots, one glass and 64 oak logs, so it could only insert logs. With only one log in the requester it didn't work, increasing the requested logs it worked decreasing the requested logs it didn't work.

Here is the proof
Drone in standby
2020-06-24_20 53 58

Requesting 2 items
2020-06-24_20 53 12

Inventory has 1 item
2020-06-24_20 53 22

It is placing requested items -1 in the inventory of the rftoolsutility crafter tier 1.

In a chest it works with a drone. The logistics drone does nothing.

Here is a case where I program a drone to move to a location. It is currently programmed to move to the position of the heat sink, it cannot move there. Now it is reprogrammed to move to a block beside the heat sink but it does not move. I have to delete the go-to location piece and add a new one, for it to work.

Here is the proof.

reprogram-drone-0
reprogram-drone-0a

reprogram-drone-1
reprogram-drone-2

commented

So I found one other problem, which is fairly specific and may or may not help you, but you never know. When I had a Tag Filter (with a configured tag matching the requested item) in my requesting inventory, the Tag Filter was being matched as that item, and therefore causing one fewer item to be delivered. That's fixed now. Not sure if you're using Tag Filters at all, but anyway...

Oh, having checked the Cyclic code, yes - he's not overriding allowsMovement() for any cables, so drones (or indeed any entity) won't have a good time trying to pathfind around them. You can test that by spawning e.g. a cow on one side of the cables, stand on the other side, and hold some wheat. I bet the cow will get stuck (and if it doesn't, then I have another bug to track down :)

Fixed that in build 24 (along with programmer Area widget updates not getting synced) so maybe give that build a go?

commented

The version of the original mod pack was All-the-Mods-4-0.2.0 and the current version is All-the-Mods-4-1.3, there has been many updates between the versions. I realize that modded Minecraft is not very good with updates, mods removed and added.

After creating a new world from the mod pack I cannot reproduce the problems in this world.

So, what I'll do is kill the current series to start a new series "Surviving with PneumaticCraft Repressurized" using 1.15. PneumaticCraft deserves its own series. Then only ask questions and discuss problems with these versions.

If you want I'll persist with the current issue otherwise we can start afresh.

commented

Sure am, now I need to find some time :-)

commented

Sounds good :) Also, PNC is getting a lot more love in 1.15.2 as far as features go - 1.14.4 is pretty much maintenance mode now (and 1.15 is getting around 30x the downloads of 1.14, so there's that too).

I'm fine to start afresh if you are!

commented

The drone losing its fluid when wrenched is a bug (forgot to add the code to serialize/deserialize the tank to the itemstack). Will fix for the next release.

And the fluid mod name in the tooltip is something I only added in the 1.15.2 version of the mod but it's a really easy backport, so that will also be added to the next 1.14.4 release.

commented

My tests so far with a logistics drone shows it has no problems moving water from a Gas Lift (with passive provider, no filter), to a Small Tank (with requester frame requesting 32000mB water). But I'd need to know all of the other frames in your setup, and exactly what they're filtering on and/or requesting to do a proper test.

commented

Takes a little time to prepare (mostly automated) and upload the video, https://youtu.be/_yQemWzL2rM. I cover the setting up of the network in the video that was published today https://youtu.be/tmdWktw0Pmo

Thanks again.

commented

Yeah, think I'll need to see a recording of this (and do some experimentation myself...)

commented

Can you give build 17 a go? I think it should fix all the problems you encountered (including trapdoors), but I will warn that the third commit there is quite experimental, and could possibly break drone pathfinding in other ways (so it needs a lot more testing than I've given it...)

commented

I've tested build 17 and as soon as the game loaded the drones went to work. The tanks with storage frames (didn't have trap doors) were also filled. May be changing the provider frame from passive to active didn't update the drones' path finding.

I like the design much better with the tanks and fluid hoppers connected to the refinery outputs, gives insulation and places for the drones to work.

Trapdoors did work in 1.12.2. However, the drone used to sneak under them but get stuck from time to time.

I like using carpet on top of the processing plant as it is appropriate as an insulator.

At the moment my base doesn't really test path finding very much, but it will later.

Thanks again.

commented

Yeah, having watched that, those Logistics Drones are definitely behaving weirdly. I don't think you've done anything wrong there. I'm not sure what they're up to there, but I'll see if I can reproduce it in my dev world.

commented

The Logistics Drone has never accepted any inventory upgrades, even back in 1.12.2. (In 1.12.2 it was Dispenser Upgrades rather than Inventory Upgrades, but those were only accepted by standard programmable drones).

commented

Okay, I've found one issue, which is that the trapdoors are confusing the drones; with a trapdoor (even open) on the target inventory, the drone will collect the fluid and sit there wondering what to do with it, since it can't pathfind into the open trapdoor block to deliver the fluid. That's why the drone picked up your gasoline and then just waited there - it wanted to fill your TPP that's requesting gasoline, but the trapdoor is blocking it. (I think this behaviour has changed since 1.12, but I didn't make any code changes relating to that, so it could be down to different vanilla block behaviour between 1.12 and 1.14+).

Short term workaround: place a block with no hitbox (e.g. a carpet or flower) on the side of your TPP. The drone should be fine with that.

I'll see how difficult it would be to fix drones to pass through open trapdoors. However, I have been planning a "Heat Lagging" block which can go on the side of heat machines, and has no hitbox (just a sort of semi-transparent texture which can be clicked through, and drones will have no trouble with). That's probably only going to 1.15.2 though...

commented

Should all be working now in 1.0.6 (and 1.2.2) release