Alt-F4 #61 - Draftsman: A Python module for creating blueprints

[AlternativeFFFF]

For this week's issue of Alt-F4, we return to the roots of being a spiritual successor to the FFF by going deep on a technical topic. To that end, redruin1 presents his newest invention: Factorio Draftsman. Sure, there have been other projects trying to build a library for generating blueprints for the game, but this one tries to be the new gold standard. Motivations, technical details, and a few fun projects realized with it - all that, and more, this week!

Continue reading: https://alt-f4.blog/ALTF4-61/

[Qon]

I was just considering making my own tool like that for my combinator computer that is used to control a self-expanding factory...
I would have preferred JavaScript though. Any chance you will make DraftsmanJS as well?

[Redruin]

I was just considering making my own tool like that for my combinator computer that is used to control a self-expanding factory...
I would have preferred JavaScript though. Any chance you will make DraftsmanJS as well?

If node counts, you could take a look at factorio-blueprint, which is actually linked in the article.
It hasn't been updated in a while, but it might be sufficient if you just need simple modification/re-encoding.

In the TODO of the module I was thinking about backporting it to C so I could write bindings for Lua in addition to Python; I'm not as familiar with how that would work with JS specifically, but I wouldn't be opposed. Maybe you can fork it!

[Qon]

If node counts, you could take a look at factorio-blueprint, which is actually linked in the article.
It hasn't been updated in a while, but it might be sufficient if you just need simple modification/re-encoding.

For this project, that should work. I mainly just need to dump a lot of signal data into constant combinators which I can paste over an empty shell I make with blueprints in game anyways.

For more complex projects later I might want something better.

Anyway thanks for making a bunch of cool stuff in and for Factorio. Hope to see more of your SEF. My own SEF is coming along. I'm currently coding it by placing combinators by hand in a setup which is fast but has no breakpoints or other ways to pause except adding in loops which requires cut and paste and messing with broken wire connections. That is the tradeoffs I have decided to live with for now. It is excruciatingly painful of course. Debugging is really hard and just gets harde rthe more complex the project becomes. I can step through it with the Editor of course, but that means I can't pause my program and run other code to diagnose the state of the SEF because everything is paused. My SEF is built with one central hardware program (without CPU because each program line contains the combinator hardware to run that line) + memory and each factory cell has its own compute unit which the central program sends instructions to via global wire, essentially uploading fragment shaders on a factory which is a GPU with small amount of memory and compute in each cell. The cells aren't turing complete, they just run some equations and comparisons and memory load/store operations for filtering out and configuring the correct one. Again, a choice made for speed first and with some consideration for minimizing combinator count.

I am considering making a CPU with code as data with a small assembly language I can just type out in my sublime text and then assemble easily. Even if it would be orders of magnitude slower.

Also, the videos embedded in the article didn't work for me (Firefox/Ubuntu).

[BlueTemplar]

They did work for me (Firefox/Ubuntu) ..?

Looks very impressive and awesome !

[Qon]

They did work for me (Firefox/Ubuntu) ..?

Looks very impressive and awesome !

They work for me now too! Maybe they fixed it? Or it was a temporary issue with the server or my computer that fixed itself?

[BlueTemplar]

Hmm, this reminds me of hacks with blueprints using higher levels than you already have of Bob's Adjustable Inserters...
Wube decided that that exploit wasn't worth fixing, but they might change their minds if it becomes too frequent ?

[Qon]

Hmm, this reminds me of hacks with blueprints using higher levels than you already have of Bob's Adjustable Inserters...
Wube decided that that exploit wasn't worth fixing, but they might change their minds if it becomes too frequent ?

If you import blueprint from others or from external tools to alter your gameplay then you get the experience you desire, nothing that needs fixing. There are mods that do the same thing, and Wube is obviously not going to stop those for the same reason. Factorio is a single player game, there are no rules against imorting blueprints. The blueprints can't be made from inside a game so if you want the intended experience then just don't install third party content. It isn't really that different from using any other blueprint from someone else, they are both "exploits" by a similar standard.

[atomizer]

Wube decided that that exploit wasn't worth fixing, but they might change their minds if it becomes too frequent ?

I think it would be a straight value-add if the functionality of setting arbitrary item requests in blueprints was available in-game. The fact that it is only available for modules and train fuel seems like more of a legacy thing than a balance choice.