Max-moduled stone brick smeltery

Circuit-free solutions of basic factory-design to achieve optimal item-throughput.
Involving: Belts (balancers, crossings), Inserters, Chests, Furnaces, Assembling Devices ...
Optimized production chains. Compact design.
Please provide blueprints!
Forum rules
Circuit-free solutions of basic factory-design to achieve optimal item-throughput
Post Reply
Copy link
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Max-moduled stone brick smeltery

Post by golfmiketango »

I've been working on a series of max-moduled mechanical smelting designs for a while now. Many of them are kind-of stuck due the limitations of 0.15 splitters but I've found that if I slightly overproduce and join lines with "a bit more" than is needed then I can achieve full compression quickly and reliably. This is an example of that mechanic at work. If we replace the productivity modules in the smelters with speed modules (or provide precisely 8/5 blue belts of stone), we would in theory get fully compressed output with no buffering at full tilt with this design, but, alas, it will tend to sputter and cough for astronomically long periods before settling down into a fully compressed rhythm (if it does so all). It's hard to be sure if this is due to splitter misbehavior or an intrinsic issue with my design but I strongly suspect the former.
a max-moduled stone smelter
a max-moduled stone smelter
MaxModuledStoneSmelter.png (2.99 MiB) Viewed 9911 times
Blueprint
I have included an input-lane balancer, as otherwise this thing consumes ore in a profoundly lopsided pattern; but this won't matter for many applications; in the picture above the first five rows of tiles (and resulting stray underground) could be removed to omit this feature and preserve a tiny smidgen of UPS.

Some aspects of the implementation might seem kind-of wierd but there are reasons for most of the design choices I made. For now I won't elaborate too much, for fear of tldr problems. I'd be happy to consider any ideas or answer any questions.

One thing worth mentioning is the decision to feed the bottom row separately from the top two rows, which share the same belt (but not lanes) for input and output. If we tried to put the ore for all three smelters on one belt-lane, we create a maths problem. If we want each column of smelters to produce 1/3 of a belt of output this will require 2/3 of a belt of input. Obviously (but not obviously enough that I failed to discover this the hard way) only one belt-lane cannot provide this. Productivity modules almost-but-not-quite rescue us from this problem -- each column would require 8/15 belts of input, just 1/30 more than one lane can hold. But the result is less than satisfying. We could solve the problem by sharing input and output lanes; but even if we get rid of or replace the productivity modules, inevitably, a bit of raw stone slips through. I did manage to produce some designs which solved this using belt circuit conditions, but that kind of violated the no-circuits constraint I was trying to work within, and resulted in a big ugly mess. The three splitters and reliance on backpressure seemed like a lesser concession. Earlier designs used a second layer of 1->3 splitters and routed ore to each smelter individually which worked fine but seemed like overkill; this seems to work just as well and is presumably much more UPS-efficient.
Top
quyxkh
Smart Inserter
Smart Inserter
Posts: 1031
Joined: Sun May 08, 2016 9:01 am
Contact:
Contact quyxkh

Re: Max-moduled stone brick smeltery

Post by quyxkh »

What splitter problems are you referring to? I look at that and think your trouble's trying to belt-feed machinery boosted that high.

Here: this should do it.
blueprint
Image

(edit: added bp pic. Also, you could squeeze it vertically by losing the substations to get red-belt ug inputs the whole way, which would also save you four beacons and 8 S3's)

(edit 2: yup, here you go, 6% saving on S3's and beacons, plus smaller stuff down in rounding-error:territory
blueprint
)
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

quyxkh wrote:What splitter problems are you referring to? I look at that and think your trouble's trying to belt-feed machinery boosted that high.
In practice they work fine but in the laboratory it's quite challenging to achieve 100% fully compressed output. The exact "problem" is to sustain fully compressed outputs. It is quite subtle and very difficult to describe concisely as it requires sufficiently careful observation that mere casual inspection often does not cut the mustard -- you really need an in-game test-mode laboratory.

To be clear, the design I posted does not suffer from any problem. But as I stated above, if you replace all the efficiency modules with speed modules and observe the output belt compression you'll see it is impacted negatively. Now: is that a problem with splitters? The more you think about that question the more hazy things get, because extremely complicated polyrhythms legitimately exist in this sort of smelter without any splitter bug. But there /are/ splitter bugs in 0.15, that's well-established, and smelting arrays like these are the perfect vehicle to bring them out. When you join a lot of material with a little bit of material, you will tend to get a little hiccup in the output. As you scale up your smelting designs, these bugs can become extremely pronounced -- but this smelting array is not nearly big enough to cause any dramatic problem, just little subtle ones.
quyxkh wrote: Also, you could squeeze it vertically by losing the substations to get red-belt ug inputs the whole way, which would also save you four beacons and 8 S3's)
As you probably discovered, the only way to remove beacons from a grid like this is to square-up your rectangles. As you approach a perfect square, you maximize beacon-sharing in the interior areas; once you have an n x n grid like these, there is no further way to optimize the beacon-to-smelter ratio while preserving 14 effect-sources per smelter, the maximum possible un-modded coverage level for an electric smelter.[edit: see a few posts below, I am 100% incorrect here]
Last edited by golfmiketango on Thu Nov 30, 2017 2:32 am, edited 3 times in total.
Top
quyxkh
Smart Inserter
Smart Inserter
Posts: 1031
Joined: Sun May 08, 2016 9:01 am
Contact:
Contact quyxkh

Re: Max-moduled stone brick smeltery

Post by quyxkh »

Well, here's a speed-module-only version that converts two blue belts of stone to one blue belt of brick without missing a beat once the supply belts have warmed up. I don't see the point of using 20% more stone than is really necessary, though. Seems to me it just makes everything work harder for the same result.
snap@T6574445=2045x2502-15.9609375-14.03125,z2.jpg
snap@T6574445=2045x2502-15.9609375-14.03125,z2.jpg (481.41 KiB) Viewed 9850 times
(edit: screenshot corrected, this is the one that runs for 1M+ ticks, ticks*-2+bricks*3 doesn't budge from its three-tick cycle).
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

quyxkh wrote:Well, here's a speed-module-only version that converts two blue belts of stone to one blue belt of brick without missing a beat once the supply belts have warmed up.
I have a test-rig dedicated to "time to full compression" questions... I've tried to clean it up to a point where I wouldn't be ashamed to show here but... well it's pretty rough and there are parts of it which clearly work but which I no longer understand (circuit spaghetti). I'll have to keep working on that but in the meanwhile I'll take a look at your build and see what the numbers look like.

But, I have some predictions, sight unseen:
  • The input buffering does not significantly affect the time-to full-compression outcome (or affects it negatively)
  • The speed-only version takes significantly longer to achieve full compression than the productivity version
Part of this is a tricky reversal of the common-sense expectation that speed modules should be faster: even though productivity modules slow down the smelters, the limiting factor is on the output side for the productivity version, which has been provided with enough input to produce 1.2 belts of stone brick but cannot due to backpressure (assuming the throughput is sufficient internally). The limiting factor in the speed version is probably going to be on the input side (again, unless we screw up the throughput logistics somehow). So the constraint dynamics are completely different despite identical builds, identical inputs, and identical expected outputs.
quyxkh wrote: I don't see the point of using 20% more stone than is really necessary, though. Seems to me it just makes everything work harder for the same result.
You're right, there is no benefit outside of the laboratory. However in the laboratory, I think the speed module version is a much more interesting puzzle as perfect input-output ratios like this lead to all sorts of surprising results. For example, some smelters I've put together will "never" (at least, not for many RL hours at approximately 6x normal game speed) achieve compression from a dry start, but, if you constrain the output until a teeny tiny buffer is built up (maybe compressing just 30 or 40 items on the output side), appear never to lose compression.

Testing for such things presents some unfortunate "science" challenges: a build that compresses a belt for 1000 years may lose compression in year 1001, and vice-versa. Lots of patience helps to weed out false positives but never proves anything fundamentally (if we can establish certain properties of the distribution of pseudorandom results, statistical tools exist to achieve a desired confidence level, though)
Top
quyxkh
Smart Inserter
Smart Inserter
Posts: 1031
Joined: Sun May 08, 2016 9:01 am
Contact:
Contact quyxkh

Re: Max-moduled stone brick smeltery

Post by quyxkh »

You mentioning time-to-compression as a factor got me to revisit this, and I'm starting to catch on to why this is interesting, thanks! For the P3'd setup I saved four more beacons and eight more S3's with this:
snap@T3865603=2231x2189+131.27734375-14.96484375,z2.jpg
snap@T3865603=2231x2189+131.27734375-14.96484375,z2.jpg (345.84 KiB) Viewed 9728 times
blueprint
If my own ugly attempt at a time-to-compression circuit is accurate that hits full compression in about sixteen seconds counting from when the first brick reaches the exit. I of course want to believe that's a really good time :-)

For the pure-S3'd version that performs _worse_, because there's not enough stone to keep them all busy and the front two smelters buffer stone the back smelter could be smelting. I think 1-3 splitters and belt braiding would necessarily do the best possible job, but that seems pretty brute-force. I'll see if playing with inserter types can balance it.
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

quyxkh wrote:Image
By the way, how did you make this beautiful picture? I'd love to get my hands on the source code if it's available.
Top
Jap2.0
Smart Inserter
Smart Inserter
Posts: 2425
Joined: Tue Jun 20, 2017 12:02 am
Contact:
Contact Jap2.0

Re: Max-moduled stone brick smeltery

Post by Jap2.0 »

golfmiketango wrote:
quyxkh wrote:Image
By the way, how did you make this beautiful picture? I'd love to get my hands on the source code if it's available.
I believe it's a reddit bot or something.
There are 10 types of people: those who get this joke and those who don't.
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

quyxkh wrote:You mentioning time-to-compression as a factor got me to revisit this, and I'm starting to catch on to why this is interesting, thanks!
I certainly think so. They're probably more interesting in 0.14/0.16 where we aren't/hopefully-won't-be, respectively, left guessing about whether a particular problem is due to splitter-join misbehavior or design shortcomings.
quyxkh wrote:For the P3'd setup I saved four more beacons and eight more S3's with this:
--- *snip!* -- >% ---
Looks pretty good. Since all the max-moduled configurations discussed before this left a smelter or three inoperative for at least a small amount of time, it stands to reason that some overkill was involved wrt modules/beacons. This looks like a meaningful improvement on my original since the average power draw will be less, especially idling, plus you seem to have found some redundant balancing and stuff that can be omitted (I worry those omissions may negatively impact our time-to-full statistic, however).
quyxkh wrote:If my own ugly attempt at a time-to-compression circuit is accurate that hits full compression in about sixteen seconds counting from when the first brick reaches the exit. I of course want to believe that's a really good time :-)
It certainly ain't bad. But, see below about how otherwise superfluous balancing can have a big impact here.

Normally I've always measured time from input activation; which metric is more meaningful (my time from input activation vs. your time from first output trickle after most recent input activation) is obviously quite subjective. I suppose mine might be better for comparing wildly structurally different builds whereas yours might be better for comparing structurally similar builds.

The simplest way I know of to get a fully reliable compression test is to sum the "hold" from nine contiguous segments of belt (let's call that H), along with 1-tick and 2-tick lags of H, and compare to 192. IIRC you can just take H and compare to 64 to get an accurate negative result, but if you're wiring that up to a light-bulb it's going to flash like crazy when you have a single item that is uncompressed by one or two "min-spaces" on the belt.

However, it's important that your test rig not assume that just because you achieved full compression once, that it stayed compressed, because, well, a lot of the time that is not going to be the case. So you have to do something more elaborate. My current implementation (which could be a lot nicer with some re-tooling) shows:
  1. how long it took from dry-start to the most recent transition from non-fully-compressed to fully compressed while the input was active
  2. whether or not the thing is fully compressed right now or not (in the latter case, (a) measures an historical "false start" and you know your rig has not yet achieved continuous compression)
  3. for how long the inputs have been running (leaving the poor operator to subtract (a) from (c) to learn how long compression has been maintained for)
All the timers and the inputs are controlled by the same boolean master toggle switch (building a one-click toggle switch in factorio is its own challenge... I have a fun solution but it breaks sometimes and I should probably break down and resort to employing the push-button mod).

It's a pretty good harness but kind of falls down during stopping and starting -- turns out, in practice, you'd very often like to see the "(a) iff (b)" statistic your previous run provided, if any, so that you can race your current build against your previous attempt. But my current build resets all the statistics the moment you open the input-side floodgates.
quyxkh wrote:For the pure-S3'd version that performs _worse_, because there's not enough stone to keep them all busy and the front two smelters buffer stone the back smelter could be smelting. I think 1-3 splitters and belt braiding would necessarily do the best possible job, but that seems pretty brute-force. I'll see if playing with inserter types can balance it.
I tried braiding at one point but didn't love the results. However I think I had a more elaborate output scheme at the time... so it might be fine in your build although I suspect you'd have to give back some of that vertical space you squeezed out of it. Come to think of it, it's notable that one red-belt should provide precisely the correct amount of ore to produce one third of one blue belt worth of stone bricks; this can probably be exploited in a no-productivity-module build, somehow, to prevent the columns from starving each other, without employing any balancer on the input side. If somehow we could precisely nail the distribution of modules so there is no idle time for the smelters at full-tilt, this would also prevent early smelters from gobbling up all the ore destined for later smelters (without creating any column-wise asymmetry as this would mean, (I think?) the one red belt would not be enough for the faster columns), then there would presumably be no time-to-full benefit for output-side balancing, either.
,
I also think you are absolutely right about input side balancers. Indeed in my bigger builds input-side balancing has become the primary focus of all my efforts and makes me feel like I finally have an answer to questions like "why would anyone ever need an 18->12 balancer!?" The fastest time-to-full I got for a no-productivity build in these 3x3 stone smelteries was when I did count-perfect 2-9 input balancing. But that definitely seemed like a lot of spaghetti for not a lot of benefit and ultimately didn't seem to merit serious consideration.
Top
quyxkh
Smart Inserter
Smart Inserter
Posts: 1031
Joined: Sun May 08, 2016 9:01 am
Contact:
Contact quyxkh

Re: Max-moduled stone brick smeltery

Post by quyxkh »

Thinking about gap-stuffing and each smelter lane needing to produce exactly one redbelt lane led me to this:
Boosted Blue Belt Brick Bakery
Boosted Blue Belt Brick Bakery
snap@T6070032=2241x2305+131.23046875-14.91015625,z2.jpg (387.06 KiB) Viewed 9701 times
blueprint
which works really well in my tests. Everything's S3'd, the smelters aren't overproducing at all, so it naturally takes a bit longer for the gaps to back the outputs up far enough, but the back smelter's guaranteed to always be overfed and once its input belt backs up the other two are guaranteed to be fed exactly the remainder, evenly, so the extra 0.38+/s bricks are always produced in the right place and the gaps that do get produced are always small enough to cover with the excess.

You get the pretty grid+BOM pix from reddit /u/BlueprintBot, send a pm with "!blueprint" and a blueprint string or url in the body, it'll reply with the pic.

p.s. the eliminated beacons were purely redundant, every smelter's still crafting speed 16 here.
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

quyxkh wrote:Thinking about gap-stuffing and each smelter lane needing to produce exactly one redbelt lane led me to this:
Image
blueprint
which works really well in my tests. Everything's S3'd, the smelters aren't overproducing at all, so it naturally takes a bit longer for the gaps to back the outputs up far enough, but the back smelter's guaranteed to always be overfed and once its input belt backs up the other two are guaranteed to be fed exactly the remainder, evenly, so the extra 0.38+/s bricks are always produced in the right place and the gaps that do get produced are always small enough to cover with the excess.

You get the pretty grid+BOM pix from reddit /u/BlueprintBot, send a pm with "!blueprint" and a blueprint string or url in the body, it'll reply with the pic.

p.s. the eliminated beacons were purely redundant, every smelter's still crafting speed 16 here.
Looks pretty sweet. I suspect the input side is susceptible to simplification somehow, but your output apparatus and vertical squishification look really amazing. Question: is there any particular reason you've used two regular inserters instead of one stack inserter on the input side?
Top
quyxkh
Smart Inserter
Smart Inserter
Posts: 1031
Joined: Sun May 08, 2016 9:01 am
Contact:
Contact quyxkh

Re: Max-moduled stone brick smeltery

Post by quyxkh »

golfmiketango wrote:Looks pretty sweet…your output apparatus and vertical squishification look really amazing.
Thanks! I was very happy with how that turned out.
I suspect the input side is susceptible to simplification somehow
Heh. I realized over dinner the belts and braiding splitters could do more for me, found your reply when checking whether to edit the result in:
Better-belt-backpressure-balancing braided blue belt brick baking
Better-belt-backpressure-balancing braided blue belt brick baking
snap@T7055192=2236x2174+131.078125-14.91015625,z2.jpg (381.62 KiB) Viewed 9685 times
blueprint
Question: is there any particular reason you've used two regular inserters instead of one stack inserter on the input side?
Pickup latency causes stutters, machines expect better response than you can get loading a full stack inserter hand from an iffy or often even a full belt (edit: the full loop at the end of the input belt on the first speed-module-only attempt above is necessary to keep that stack inserter loading fast enough, try tinkering with that to see how much it matters). When latency is even a potential issue if I can't get a chest I like to have at least one fast inserter for quicker response. Just one doesn't have enough throughput here, two is enough, the one thing I know for certain is with a single stack inserter the red/yellow-fed smelters would be idle for longer intervals, even if the throughput was the same. Call it a safety play...Gubble. You probably just got me to spend hours testing this, I hate you (no, I don't :-))

I'm gonna tinker with the compression-detector circuitry, I guess it doesn't belong in this thread tho, what with "circuit-free" on the subboard name and all.

And:
squishification
would seem to be a word to live by :-)
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

This spin incorporates a bunch of your ideas, quyxkh, while using a single tile-column for input and output to claw back three horizontal tiles. 0->fc in 23 seconds it seems :P [edit: this seems to depend on quasi-random start conditions, presumably i.e., unsmelted bits of ore sitting in the smelters, etc. With further testing, I've seen times as low as 22 and as high as 27]
Stealing from quyxkh
Stealing from quyxkh
StealingFromquyxkh.png (3.18 MiB) Viewed 9680 times
Blueprint
Also, even though this is totally embarassing, here is my shitty compression test harness (requires text plates and creative mode mods I think):
Terrible Blueprint
To use:
  • put a single slowdown capsule in two contiguous chests (near TOG); this is your on/off switch; rotate the inserter to toggle the switch on or off. don't do this too quickly or it will break.
  • for each output belt, connect nine contiguous straight belt entities to a single red wire network & set to "read(hold)" for each; connect all of these to the upper left terminal
  • multiply the constant in the two upper-left-ish "Anything" combinators by the number of output belts (if using more than one output belt)
  • for each output belt, connect a single belt entity to a different red wire network, set these belt-tiles to "read(pulse)" and connect to upper-middle terminal
  • connect a green wire to each input-controlling entity & set "A > 0" enablement condition; connect these to the bottom left-ish terminal; idea here is to slave your contraption's input to the harness's toggle
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

quyxkh wrote: You get the pretty grid+BOM pix from reddit /u/BlueprintBot, send a pm with "!blueprint" and a blueprint string or url in the body, it'll reply with the pic.
I tried this but he just ignored me. the !blueprint is supposed to go in the subject line, correct? I'll have to look into this ability to wire bots up to reddit. Presumably the whole site will consist of 99% bots trying to glitch/troll each other within a year or two :)
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

golfmiketango wrote:
quyxkh wrote: You get the pretty grid+BOM pix from reddit /u/BlueprintBot, send a pm with "!blueprint" and a blueprint string or url in the body, it'll reply with the pic.
I tried this but he just ignored me. the !blueprint is supposed to go in the subject line, correct? I'll have to look into this ability to wire bots up to reddit. Presumably the whole site will consist of 99% bots trying to glitch/troll each other within a year or two :)
nvm, figured it out:
bpbot_2_1_3x3_stone_brick_smeltery.png
bpbot_2_1_3x3_stone_brick_smeltery.png (664.42 KiB) Viewed 9627 times
Top
Jap2.0
Smart Inserter
Smart Inserter
Posts: 2425
Joined: Tue Jun 20, 2017 12:02 am
Contact:
Contact Jap2.0

Re: Max-moduled stone brick smeltery

Post by Jap2.0 »

golfmiketango wrote:
golfmiketango wrote:
quyxkh wrote: You get the pretty grid+BOM pix from reddit /u/BlueprintBot, send a pm with "!blueprint" and a blueprint string or url in the body, it'll reply with the pic.
I tried this but he just ignored me. the !blueprint is supposed to go in the subject line, correct? I'll have to look into this ability to wire bots up to reddit. Presumably the whole site will consist of 99% bots trying to glitch/troll each other within a year or two :)
nvm, figured it out:
bpbot_2_1_3x3_stone_brick_smeltery.png
If somone would convince whoever made that to make a version for the forums too - perhaps with the same PM thing, or make it work somehow else - that would be amazing.
There are 10 types of people: those who get this joke and those who don't.
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

After some fussy changes I managed to squeeze out a couple more vertical tiles and reliably sustain compression within 19 seconds of activation:
bp bot image
blueprint
Top
quyxkh
Smart Inserter
Smart Inserter
Posts: 1031
Joined: Sun May 08, 2016 9:01 am
Contact:
Contact quyxkh

Re: Max-moduled stone brick smeltery

Post by quyxkh »

That's some pretty sweet braiding there, plus I love the yellobelt compresser at the exit. Is that much lane balancer on the input needed? I suspect that could get squishified some. Gtg, been busy.
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

quyxkh wrote:That's some pretty sweet braiding there, plus I love the yellobelt compresser at the exit. Is that much lane balancer on the input needed? I suspect that could get squishified some. Gtg, been busy.
I was guessing it did matter for time to full compression, as we'd have to wait for buffering and backpressure to propagate through the system. Seems I was wrong. I find the result to be extremely counterintuitive. If I favor the middle lane, it does fill the buffer in the top middle smelter, but somehow backpressure never seems to build up (at least not for half an hour in-game). If I favor the left or right column, somehow, buffering never occurs, and even the favored column fails to compress its output. So something crazy appears to be happening. The only explanation I can invent is that somehow splitter bugs must play a role in this result, or my test rig has some as-yet unidentified design bug.
Top
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:
Contact golfmiketango

Re: Max-moduled stone brick smeltery

Post by golfmiketango »

golfmiketango wrote:
quyxkh wrote:That's some pretty sweet braiding there, plus I love the yellobelt compresser at the exit. Is that much lane balancer on the input needed? I suspect that could get squishified some. Gtg, been busy.
...
my test rig has some as-yet unidentified design bug.
Ah, it was that one. Once I got both inputs running instead of just one :? I tested with the rightmost column favored and it achieves backpressure in about five minutes, but has trouble compressing the output, possibly due to splitter bugs or complex polyrhythms at the final join. Almost an hour in it still could not sustain compression. Probably one could attempt to fight this by screwing around with the inserter stack sizes but my conclusion is, as I expected, the input-side balancer is apparently doing something useful in v1.03 above.
Top
Post Reply

Return to “Mechanical Throughput Magic (circuit-free)”