Factorio Forums

Situation: I have Freighter 1 dropping off cargo. In this instance it's running a route of Nauvis->Fulgara->Aquilo->Fulgara->Nauvis, picking up random mall-type supplies from Nauvis, Fulgara-limited supplies there, dropping off to Aquilo, then bringing Aquillo and Fulgara science back to Nauvis. Freighter 2 is doing a fairly similar plan except it's going Vulcanus->Gleba->Aquilo.

First Issue: How to get Freighter 2 to hang around but not waste time? Right now I've been using 30s of inactivity. The problem is that if Freighter 1 is dropping off 20k resources it will tie up the cargo pad for more than 30s, meaning Freighter 2 will leave. I could increase inactivity time, but that's wasting time, and also leads to issue #2

Second Issue: Say Freighter 1 has 5k supercapacitors. But Aquilo only requests 500. That's fine, drop 500. Wait 30s of inactivity and... at 29s Aquilo now has used 200 of those capacitors, so Freighter 1's timer resets as it drops some more. Continue this pattern and now Freighter 1 has wasted like 30 mins drip-feeding Aquilo supercapacitors and has shirked its duties of delivering 10k science packs back to Nauvis, stalling research.

How to handle both of these, ideally with fairly minimal circuitry? I get that I could make dozens of very specific-purpose freighters that only carry one item, then I could have them wait till the item is fully delivered and go back for more, but that seems really unwieldy and annoying to manage.

First Issue: Add Cargo Pods to the landing pad. It'll accept more drops from space that way. With enough of them, you can accept all 20k in one sweep.

Second Issue: Use an SR latch as part of your Set Request circuit on Aquilo. You want 500, but you don't put the request in for 500 until you're under 300. That way you don't ask for 1-2 at a time.

Didn't realize you could add cargo pods to landing pads. That works well.

Latter is really annoying through when you have dozens of resources and you have to play with circuits every time you want to change orders. Wish the min/max settings of the logistic request just worked like that to begin with.

You could do it with a set of combinators that start with a constant combinator using a logistics group. Constant Combinator has what you want, math 50 and 80% of that, use those numbers in the SR latch, though you'd have to do it per item still. But then if you wanted to adjust the resources you just adjust the value in the logistics group and it would flow the the rest of the math.

Just watch out for it auto adjusting the import from planet back to default if you use it on a platform and don't adjust from there.

HadesSupreme wrote: ↑Sun Nov 10, 2024 1:36 am Didn't realize you could add cargo pods to landing pads. That works well.

Latter is really annoying through when you have dozens of resources and you have to play with circuits every time you want to change orders. Wish the min/max settings of the logistic request just worked like that to begin with.

https://factoriobin.com/post/750oa2

Here, it's ugly but it'll work to wire up to your landing pad where the Substation is at and only put your request on when it breaks the Lower threshold and will remove it at the Upper Threshold.

For problem #2:
Multiply your logistic network content with -1, and add the amount you want to have of each item with a constant combinator. Then you can have a decider combinator check for "each > X" and forward the input to the landing pad. That way the landing pad will request each item by chunks of at least X. If you want to set different Xs for different requests, you can build more constant+decider pairs for the items with the different threshold.

I would consider this minimal circuitry, as it contains only 2n+1 combinators.

I just got this idea 5 minutes ago, so I also need to try it to see if it works. I will post a demo when I get the chance.

edit: Here's what it looked like in my head. Check the save file for combinator descriptions

Copy blueprint

That solution is much less than 2n+1 combinators, but doesn't actually solve his problem. It's what I do for my networks usually. The drip problem still happens because as soon as even one item is taken from the network, the request becomes 1, which causes the platform to send 1 down.

I was already using the "for each * -1 + request" thing.

Think I found a simple way to do it. Do

1. Constant combinator N of each resource, outputs green to step 3
2. Arithmetic combinator that takes Constant Combinator and divides by -2, outputs red to step 3.
3. Decider combinator takes red from step 2 + your chest contents, does "for each < 0 ", output each input count on green to the cargo landing pad.

So you put on 10k tungsten on your combinator, it will send the request whenever it falls below 5k. It does have the problem that it doesn't hold the signal all the way from 5k to 10k resources in your chest but if you are doing big drops at a time with lots of cargo bays to receive cargo you can throw down 10k resources in one go no problem so it works. Only 1 more combinator over what I was using so I'm happy with it.

Lochar wrote: ↑Sun Nov 10, 2024 12:26 pm That solution is much less than 2n+1 combinators, but doesn't actually solve his problem. It's what I do for my networks usually. The drip problem still happens because as soon as even one item is taken from the network, the request becomes 1, which causes the platform to send 1 down.

Can you show your version with less combinators? I'm thinking we're not talking about the same design, because the one I explained can never request items one by one, unless X=1 in one of the modules.

altaykilic wrote: ↑Mon Nov 11, 2024 2:07 am

Lochar wrote: ↑Sun Nov 10, 2024 12:26 pm That solution is much less than 2n+1 combinators, but doesn't actually solve his problem. It's what I do for my networks usually. The drip problem still happens because as soon as even one item is taken from the network, the request becomes 1, which causes the platform to send 1 down.

Can you show your version with less combinators? I'm thinking we're not talking about the same design, because the one I explained can never request items one by one, unless X=1 in one of the modules.

I usually don't include your magnifier, which is where the drip problem comes in. But I've added it here which does neatly solve drip issues by magnifying the request.

Total of 7 combinators, and that's including making X adjustable and cleaning unnecessary inputs.

Copy blueprint

make have a combinator counting to 29s after unloading has started and then sets all request to 0?`

HadesSupreme wrote: ↑Sat Nov 09, 2024 8:57 pm The problem is that if Freighter 1 is dropping off 20k resources it will tie up the cargo pad for more than 30s, meaning Freighter 2 will leave. I could increase inactivity time, but that's wasting time, and also leads to issue #2

You can build more cargo bays, so the 20k can be dropped off faster and there’s room for both space platforms to simultaneously drop their cargo without delaying each other. Each cargo bay on the planet adds more slots for cargo pods to be landing.

HadesSupreme wrote: ↑Sat Nov 09, 2024 8:57 pm Second Issue: Say Freighter 1 has 5k supercapacitors. But Aquilo only requests 500. That's fine, drop 500. Wait 30s of inactivity and... at 29s Aquilo now has used 200 of those capacitors, so Freighter 1's timer resets as it drops some more. Continue this pattern and now Freighter 1 has wasted like 30 mins drip-feeding Aquilo supercapacitors and has shirked its duties of delivering 10k science packs back to Nauvis, stalling research.

My no-circuits solution for this problem is to keep each my platforms mostly configured as one of two types:

• “Mall”-type platforms, for buildings and valuable resources which are worth transporting between planets in small quantities (e.g. foundries, electromagnetic plants, high tier+quality modules). These platforms use the “Time passed” condition at every planet, so they’re not efficient transporters but they don’t get stuck “drip-feeding” or stuck waiting for a request to be satisfied.
• Platforms that primarily transport bulk resources from one planet to another planet. (They might carry something non-critical in the opposite direction, too.) These platforms can simply wait at the destination until their cargo is all unloaded; nothing else is waiting on them.

This means making many platforms, but I’ve got a basic platform design that is compact and works well for the first four planets, so I just build copies of that to haul more resources. I’m still figuring out reliably safe travel to Aquilo, though.