Automated PickUp-Delivery from warehouses

[Mat]

I need a bit of help after hours of experimentation, I'm about to scream in pain. What I'm trying to do should be very simple yet nothing works.

So I've got 2+ warehouses storing crystal and several warehouses (7+) supplying crystal to factories. What I need is a behaviour that:
1. Scans all warehouses for the ones storing crystal
2. Count crystal in storage
3. If stored crystal>1 then load up
4. continue cycling through warehouses until full, but do not touch delivery warehouses
5. scan warehouses that are expecting crystal (all slots locked for crystal)
6. Deliver crystal

If I could work out how to do that, I think I can work out the rest of the programmin myself. Has anyone a working program like that so I could gget my head around how it works?

Thanks.

[Polypusher]

I'm trying to do something like this too. I'm maybe a little further along but Im having my own trouble.
1. Loop Signals (Match) - Blue signal. I set my suppliers to blue signal
2. Move unit - moves to the matching signal, I'm not setting GoTo directly but using Move Unit command
3. Pick up Items - with the source set to the source of the blue signal
4. Loop Signals (Match) - Green signal. I set my requester storage units to emit green
5. Move Unit - moves to the new match
6. Drop Off Items - with the destination set to the source of the green signal

The first part (1-3) works great, the unit completely fills up
The second part doesnt work. In the first half the script pauses until the drone arrives at the destination. In the second half, the script keeps moving and I dont get why, its the same script. I tried writing to the Storage parameter, but that resets immediately. So its pretty weird, the drone drops off more that way, but only coincidentally since it's standing right there for part of the loop.

Even if I solve that I can see this wouldnt scale up past 1 suppliy/demand pair, you'd get anything going to anything else, but I think you could fix that with parameters.

[darkmathis]

Don't try to push. Use a pull.

First of all, lock all the slots you want crystal overflow into and add a "Shared Storage." That'll let the logistics network automatically put things there.

Second, use a behavior where you need to *receive* a certain amount of crystal and write a script to simply request that number.

Trying to push in a way that requires you to read another entity's inventory doesn't really work. Maybe we'll get a behavior for it. The closest you can get is the "Have Item" behavior, but that only gives you a 'yes/no' response. It does let you specify another entity to check, but it won't tell you anything other than "yes, other entity has item".

[Grimm]

Originally posted by darkmathis:

Don't try to push. Use a pull.

First of all, lock all the slots you want crystal overflow into and add a "Shared Storage." That'll let the logistics network automatically put things there.

Second, use a behavior where you need to *receive* a certain amount of crystal and write a script to simply request that number.

Trying to push in a way that requires you to read another entity's inventory doesn't really work. Maybe we'll get a behavior for it. The closest you can get is the "Have Item" behavior, but that only gives you a 'yes/no' response. It does let you specify another entity to check, but it won't tell you anything other than "yes, other entity has item".

You can count items in another unit. Activate the Extra Options on the Count Items command. I haven't needed to use it myself, just found it by accident.

[ExavierMacbeth]

Originally posted by darkmathis:

Don't try to push. Use a pull.

First of all, lock all the slots you want crystal overflow into and add a "Shared Storage." That'll let the logistics network automatically put things there.

Shared Storage Pull doesn't work properly with Ore & Crystal (Works fine with other mineables). So having a couple of bots service multiple warehouses still has a use... I am curious as well a good way to set it up :P

[darkmathis]

Originally posted by Grimm:

Originally posted by darkmathis:

Don't try to push. Use a pull.

First of all, lock all the slots you want crystal overflow into and add a "Shared Storage." That'll let the logistics network automatically put things there.

Second, use a behavior where you need to *receive* a certain amount of crystal and write a script to simply request that number.

Trying to push in a way that requires you to read another entity's inventory doesn't really work. Maybe we'll get a behavior for it. The closest you can get is the "Have Item" behavior, but that only gives you a 'yes/no' response. It does let you specify another entity to check, but it won't tell you anything other than "yes, other entity has item".

You can count items in another unit. Activate the Extra Options on the Count Items command. I haven't needed to use it myself, just found it by accident.

Really...I have been all over behaviors for the last few days. How on earth did I miss this. There have been so many situations where I wanted to count what another unit has.

Good looking out.

[Mat]

OK I managed to make it work(ish):
Loop Signal (blue)
Count items
if>40 then move there
if not go back to loop
move unit
pick up
loop for green
move unit
check for space
if yes - drop off
if no wait 10 ticks then check for spare items

Sort of works but after waiting for 10 sec it goes back to source :(

[TheOrigin]

Originally posted by Mat:

OK I managed to make it work(ish):
Loop Signal (blue)
Count items
if>40 then move there
if not go back to loop
move unit
pick up
loop for green
move unit
check for space
if yes - drop off
if no wait 10 ticks then check for spare items

Sort of works but after waiting for 10 sec it goes back to source :(

Share the code so we can optimize it...

[Firestorm]

As far as I can tell, you'll only get close if you use a signal receiver on your transport bot and split the logic. Have one building scan the item count for the warehouses supplied to logic registers. Once it finds a warehouse that needs a delivery, set that one to the unit signal register.

Transport bot waits until it reads a valid drop location on the unit signal register, then standard transport logic.

Probably a lot easier to just have a separate bot for each destination warehouse.

[dermanus]

Can't you do all of this with the built-in logistics? Is there a reason you need custom behavior?

[Polypusher]

The default pickup behavior fixes your start and end point. If either changes (node runs out, etc), you have to find your transporter and update it. We're looking for ways to make that more dynamic or to handle more than one start/end point, or make it easily configurable/modifiable.

[dermanus]

Is that happening a lot? The logistics system should reserve the stack so it doesn't get taken by something else. If you're moving warehouse to warehouse there shouldn't be any cases of the node running out, that's upstream of the issue.

[darkmathis]

Originally posted by dermanus:

Is that happening a lot? The logistics system should reserve the stack so it doesn't get taken by something else. If you're moving warehouse to warehouse there shouldn't be any cases of the node running out, that's upstream of the issue.

The logistic system tends to not reserve entire stacks. What ends up happening is you get an order for 32 of something that a container already has 27 of, which ends up with a net of 5 being reserved for pickup. But then a hauler comes in with another 28 of that item as another pending request for 10 was waiting for something to become available, right as two separate requests....and so on, and so on.

If you want a hauler to be moving full stacks of items around, it's been my experience that you generally have to bake that into a behavior controller.

There's also a weakness in the basic transport request where you have a hauler going to a source. The source has 15 of an item. The hauler picks up that 15 and then immediately turns around, but right as it does this another miner deposits 20. The default transport route logic doesn't know to sit and wait for a full inventory. It grabs whatever it can that isn't reserved for another order and then immediately leaves.

Then maybe you want a hauler to sit and wait for up to 10 seconds, checking every second to see if there's more it can take. The default transport route can't handle that case either.

[Blueberry Muffins!]

If you always make sure to overproduce at the bottom a lot of annoying logistics problems go away.

[Firestorm]

Here's the code you put on your requester storage:

DSCBn2czUiW1BX0oT1xfBVQ2d1CZs2wx8pk1imN0h3J3JmV3HA3fn3lnV0t1k9eGg0jn7JY2O9nFa2YfF0a2OLwZD0tRD9T0951R93Dq16h2IE9yl3uLtKE1IeiSG3ElUd33qnR634ZdVZv1PKwBa3kEtDa4T9WGC3gfGHJ1ATuC51663ub20wuSX1ECxuz2RtSBz2DVfJr2mXjir00zamv25ls2p2yx62i0OYOLk4K9NIx4ccm3C3EI6jI1grUG03sxy9B09nu9m2SuEd22TWJEy2vyW9V4f98wR22HKFm3Rn1Js2RgJuU1qvyH60lxmN42pvXxP1mjfx62pUSuO0v1ubz220eZy4Sd4XL2Sn8Ym2QnC0d132

Here's the code you put on your source storage:

DSCHc2e5gqW0tMgil3NlVCS1EgaRN47u0Hg2eBDOW0cbyLY35RBpv0GrECn1GiOua4HfUU82MaWET1bUYhY01O1g809Nxwd34pOu33RiskN19oNFP40SWZb3FrADJ0fcCFU0DzGai1GAmjW1Osoa51GOQva0d2iTx0hKSwy30RhMS2PYt441e1MTA0IcLwN1E6EPp1OmeNy3YKYtQ29UqZk0wwYcW0vJ20w14DGSk4e1UiU4RRoaX3aLzim3AGjhm3YdArt0zUNcb0wNibW2ZQotv3Ux9Bp1Hq5FB23SUGU2xF02I0bkPTT1iKTrt2KFz0T3jgUjv4FNXUv1FOSpY0qVSzj3DGk0D3Wvzpk3A3KWU4cdFql3DSKhz0ykxCJ1BmkqJ0DAWal3xWzpT0RTsdx1bBv4e1zo5Wq2DppKI2TwIrQ3m4dzj3QCINJ3RNgcA39c7kQ0H4cSB0jBBGG2bobKU0AsSmm1Q3V9p2v4HrR4EVOMj1UnBgX06trwN0Kcrug2lwjO035QjcA151Fwk0XTmof

I haven't done the transport bot logic that's completely correct for this setup. Was just using a generic one to test. But I need a break. Trying to figure out how loops are suppose to work in this game is kind of trial and error hell.

[Firestorm]

Transport Bot Code:

DSCDb2dz5fk0tMgkb32giau2nAm0K0EFNe40UwcF20bbtyb3h2Ofp2AAOvJ3auEUK1xYrKM1DDtzQ1o0Djw3iEzlR3uAQw74Yz2za1ksWXm1h5oEh3lvAm82pdfG02mfEi80PtSTd11svQX28s4yc2Pl2531Y7zi62ZLdSk33q33b0RwxFf0xwFOm2YM3ss4JWzsf4PL0uO4fH00w3f4L561l8Wh43I9H1j0i5I9f0eBRrg4dPXCP4WcUGE0Z1AzJ29BQjp3PQwOm0LIiHk2Vsvja2govJ51Xdgsv3NFrWf3t6e1e3iNeNC4FjUqI3kxq3h25vint4PHwWg2eE5Ah2wUonD41ubO80hjR0O3VMbMy424UsZ3Jcgds1Ww2yx3VEDUF0Rj9fD3pdTxI280ca04PwqvQ2tsN

P1: Source Storage
P2: Drop Storage
P3: Item

Transport Bot needs a Signal Reader pointed at the Source Storage. The Signal Register on the Signal Reader needs to be linked to P2 on the logic module so it can update the requester storage value.

Requestor Storage:
P1: Item to request
P2: Signal to send - Use a signal code like "Blue" and number value for channel. Blue 1 is differentiated from Blue 2 at source storage.
P3: Item Cutoff Value - When item count is less than this number, sets signal to request more.

Source Storage:
P1: Signal Code to scan for - Again, Blue 1 is different than Blue 2
P2: Item
P3: Item Cutoff Value - Should be same as what you set on Requestor Storage

Yeah, I should have standardized that a bit better. Oh well.