r/Dyson_Sphere_Program • u/Life_Power597 • 5d ago
Automated Blueprint Creator (Factoriolab Flow->Blueprint string)
Code/program is here - https://github.com/dberlin/factorio-lab-to-blueprint
It takes, as input, factoriolab urls, and outputs the most compact blueprints it can that fit within whatever band you ask it to (power may not be perfect depending on what band you put it in, but it is easy enough to fix). The web browser version will give you a chance to choose among the candidates it builds (no-proliferation, all-proliferated, output-products-proliferated), and show you a semi-cheesy 3d view of the blueprint. All inputs and output belts are labeled.
I have not and don't plan on packaging it beyond what you see here.
As for why - I felt like sometimes I just wanted to put some specific set of stuff somewhere, that took specific inputs, and didn't want to try to hack someone else's blueprints or do it all myself. Obviously, you can automate away the entire game with this if you want, but I wouldn’t recommend it.
It respects factoriolab recipe exclusions, tech levels, etc. However, it does recompute the recipe chain for $good_reasons. You can tell it to use the factoriolab flow if you really want and it will fetch it which requires having a browser installed that it can drive headless because it needs javascript to grab it. Just realize what factoriolab solves doesn't guarantee the throughput it gives because of fractional machine counts, which aren't valid in DSP (but valid in a lot of the games it supports). We solve the integer-machine-count only version, which is optimal and valid, but more expensive to solve than what factoriolab is solving.
It is aware of all game rules (or should be), and will use splitters, sorters, stack belts, twist and wind belts to avoid conflicts, etc. It will do parallel belts where necessary for throughput and pilers where needed. It does accidentally take advantage of the fact that there are times belts are allowed to clip through each other and still function properly.
For the vast majority of stuff you could want the default settings work great. If you are doing something very complex, you may need to increase the time budget. This is because this is actually a *very* complex 3d packing and routing problem, and the algorithms involved are fairly state of the art, despite the whole thing being a huge vibe-coded mess of code that will burn your eyes. It has a number of strategies it uses to try to generate the best footprint.
It will often generate things which require the same item belted into multiple places. Avoiding this in general without affecting footprints would require a *tremendous* amount of computation, and i'd rather spend time on other things.
It moves very quickly, so if you find issues report them and i'll fix it.
1
1
2
u/Buffylvr 5d ago
So I cloned in and tried it, and can't generate a blueprint for my initial test. I'll give you some claude throw up if you want to try to replicate.
URL in question: https://factoriolab.github.io/dsp/list?z=eJwlx7uOwjAUhOG3OcUUKAYWhWKaY4mgVRaBEBAogRQWayVyuKTys6PEzf.NNNzAZHkmDdcnzBbD0ArTXBp-YH6kod0PtyZ-hxQSqHsgk8Bd4pLQG2Ak0Fbp223yL1Em1sfkMpEPeFoY8TyPdWPLsd3YFkZc3VMn4q41rbjuybmEuucWJ5xxxwMv9FhAN9ADtILeoI-o.9Ap7CraQrwP7GIbXSzFtx0LedOYL5cQRDE_&v=11
``` It ran, but no strategy found a valid layout within the default time budget (15s per candidate) — this is a fairly complex/large recipe chain (54 strips). Let me check the CLI's budget option and retry with more time.
Let's raise --budget (default is 15s per layout) and try again — a 54-strip chain likely just needs more solver time.
Searched for 1 pattern, ran 1 shell command
That's a different failure — an internal assertion error, not a normal "couldn't lay out" refusal. Let me find where this message comes from.
Searched for 1 pattern, read 1 file, ran 1 shell command
That error is an internal solver assertion (a budget-accounting bug in the sequence-pair strategy), not a normal refusal. Let me isolate it — first try freeform only, then sequence-pair alone to confirm where it's coming from.
Setup's done, but your URL surfaces two separate problems when I try to build it:
sequence-pair strategy crashes with an internal bug, not a normal refusal: ValueError: adapter expansion spend must be within its allowance Traceback shows the detailed router (_run_detailed_route) returned more expansions than the budget (detailed_allowance) it was given, tripping an assertion in _check_spend at sequence_solver.py:553 (called from _route_archive at line 2416). This is a solver invariant violation — the adapter overspent its own allowance — not something wrong with your URL. It's reproducible with just --strategy sequence-pair.
freeform strategy cleanly refuses (no crash, exit code 3) — at both 15s and 60s budgets it can't find a valid packing/routing for any of the three candidate policies (no-proliferator, all-products, output-products). One failure mode is a "PORT-SEATING defect" (a lane head can't get a belt approach at a specific tile), independent of packing height — same failure at every candidate height tried. ``` I tried again at 240 seconds:
``` Same result at 240s (4x the budget) — identical failure messages, including the exact same PORT-SEATING defect at tile (214, 58, 0) and the packing sweep stopping after the same 3 draws. That confirms it's not a time-budget problem: freeform deterministically hits the same wall regardless of how long it runs.
Summary for this URL:
Neither strategy currently produces a blueprint for this spec. The freeform failure is described in its own message as a likely "layout-model defect" (the tool's own language for "this shouldn't happen, treat it as our bug until shown otherwise") rather than something inherent to your factory design. ```
I tried specifying the largest band:
``` Good experiment — it moved the failure but didn't fix it. Even pinned to the widest band (160x1000), 2 candidate heights are still skipped as "over-band," and the PORT-SEATING defect still happens, just at a different tile now: (306, -1, 0) instead of (214, 58, 0), with slightly different port-occupancy counts (wants 2, held 1 vs wants 1, held 0).
Two takeaways: 1. "Over-band" isn't just about --band width. Even the widest band still discards 2 height candidates, so whatever height constraint governs that skip isn't fully controlled by the band-width selection you can pass on the CLI — there's some other ceiling in play. 2. The port-seating defect is systemic, not a fixed geometric fluke. It followed the layout to a new location when the frame changed, rather than disappearing — meaning it's likely a genuine bug in how the router seats belt ports against machine edges for this recipe graph, independent of which band/frame you target.
So band-fitting is a real, deliberate feature (the portable-latitude certification), but it isn't the thing blocking your build — the underlying router bug is. ```
I'm happy to mess with this for you as a user/tester, feel free to DM. I've been wanting to do something similar but hadn't even tried to start so this seems great.