• 0 Posts
  • 80 Comments
Joined 1 year ago
cake
Cake day: August 9th, 2023

help-circle


  • There’s a small machine at the resource inputs that gets full resource priority and keeps a couple chests full of spoilage handy as well. Eggs decay fairly slowly so it doesn’t take that much to keep one circulating.
    It’s not a perfect solution but saves needing manual intervention for at least as long as it takes me to look back there again


  • For shutdown I have a few circuits monitoring the inputs/outputs to check if we’re getting backed up or running dry on either of the fruits. If that’s the case the input belts are stopped, egg->egg duplicator inserters are disabled and the chests that hold the one egg being recirculated go into trash mode.

    There is a separate unit that constantly ensures there are at least a couple eggs avaliable and “requests” (buffer chest) any excess and is surrounded by turrets.

    During startup (science below limit and ingedients on input belts) the spoilage->nutrient inserter is enabled which priority feeds just the first three chambers that make flux. Once any flux has been made (>0 flux on the belt || flux->nutrient machine working) the spoilage inserter stops. That’s enough for the flux->nutrient machine to start and the whole system becomes self sustaining.
    As part of startup a requester chest requests 1 egg, the rest of the egg duplicators are setup in such a way that they propagate down the line (a direct inserter between them is enabled if the recirculating chest for the next chamber is empty and the egg->sci inserter gets disabled). Once there are eggs in the recirculating chests the startup is considered complete and the requester chests turn off.

    There’s also a chest that pulls from the main nutrient line to make sure there’s always loads of spoilage ready for a restart.






  • I love seeing all the different approaches to this. My solution was to break all the recipes up into dependency tiers (coils & gears T1, circuits T2, inserters T3 etc.), which would then let me use the sorting on the advanced combinator to sort the execution. I guess it kinda works how the player crafting queue works:

    counter cell holding an index
    If logi_requests[index] is not craftable: increment index (counter resets at logi_requests.len)
    If we “lock on” to something craftable we save it to mem
    Calculate the total resources required (raw and intermediates) using lookup combinators and have that all on a line
    Raws get requested, intermediates get “oned out” by a decider and then multiplied by the tier values.
    That then gets picked by an advanced combinator which is sorting it by low to high and sent to the assembler.
    It then makes as many as needed before moving onto the next thing until eventually it satisfies the saved logi request
    It then resets the counter and everything starts again.

    I liked that it was resilient to constantly changing network requests and made efficient use of the logi bots with bulk requests