[MOD 0.12.x] Recursive Blueprints 0.2.0

[justarandomgeek]

I've got a partial update of this for 0.13 now, hopefully to release in the next few days. I've removed the anchor (it wasn't blueprinting right) and am using a wooden chest as an anchor. I've also removed the destructive deployer, as it will be superseded by my other plans...

My plan is to make a Deployer chest have multiple behaviors based on the circuit network:

• Blueprint>0 - Deploy the loaded print.
• Blueprint Book=n - Deploy the Nth print in the loaded book.
• {Decon print, {X,Y}, {U,V}} - Mark area for deconstruction.
• ???? (Maybe Repair Pack? something that doesn't build entities/tiles) - output materials needed for selected print.

This should allow reading a print, requesting all the needed materials (and maybe extra bots if needed?) be shipped in, and then deploying the print, all controlled by the network. Also, you could use a blueprint book and deploy different prints in sequence as needed, and/or remove temporary intermediate links as needed.

I'd prefer to have the input signals configurable, like stock items, but it doesn't appear we can make custom ControlBehaviors (or I haven't looked hard enough...), so for now I'll probably just hard-code them.

(Next up, of course, is to make a radar output information about map chunks, so I can deploy resource-gathering autonomously too )

[doc]

I've got a partial update of this for 0.13 now, hopefully to release in the next few days. I've removed the anchor (it wasn't blueprinting right) and am using a wooden chest as an anchor. I've also removed the destructive deployer, as it will be superseded by my other plans...

Thanks for doing this. Out of interest, in what way wasn't the anchor blueprinting right?

I'll admit I've been doing some other things and haven't even looked at 0.13 yet, about time I got around to that

I really hadn't thought about what to do about Blueprint Books. This does raise some interesting possibilities. Copying a single book around and then using numbered signals to deploy different phases of your machine does seem a lot neater than having to copy loads of blueprints and get the right one to the right place all the time. Just need to solve that cloning problem, I had a really good go at it before but there were so many issues

Also did you get anywhere with the circuit network conditions? It seems like this kind of setup will definitely be needed for any advanced builds. If you've already done some work on it, I'd rather incorporate your work rather than reinventing the wheel so to speak.

Regarding hard-coded signals ... why not just add some brand new signals specifically for this? That way there's no possible conflict with any existing signal systems.

I'm still toying with the idea of modules from earlier in the thread ... i.e. separate entities that affect the behaviour when placed next to the machine. Or there could simply be a "Deployment Configurator" machine that is just a constant combinator with a custom GUI to make it easy to set the signals.

Regarding deconstruction, I feel setting coordinates is fiddly; but with the above custom GUI you could have an interface that actually highlighted the area to be deconstructed. Anchors might yet be a better way to do this tho.

(Next up, of course, is to make a radar output information about map chunks, so I can deploy resource-gathering autonomously too )

Yes, this is absolutely essential. I was going to call this a Prospector. In my head it was somewhere between a pump jack and a drill, sampling nearby tiles and outputting a resource count on the circuit network. Maybe some specialised kind of radar is a better fit though, although that would have to be pretty advanced technology.

[justarandomgeek]

Thanks for doing this. Out of interest, in what way wasn't the anchor blueprinting right?

It wouldn't pick up at all in the blueprint, for no obvious reason. I hacked around it with a wooden box and realized I liked that better anyway. The current strategy is to try the following anchors, using whatever is found first:

1. The first wooden chest
2. The first deployer
3. {0,0} in the blueprint

I really hadn't thought about what to do about Blueprint Books. This does raise some interesting possibilities. Copying a single book around and then using numbered signals to deploy different phases of your machine does seem a lot neater than having to copy loads of blueprints and get the right one to the right place all the time. Just need to solve that cloning problem, I had a really good go at it before but there were so many issues

Much of my testing was with a book that built chests around my deployer one at a time as signaled by a circuit network! (Operated by hand-fiddling combinators and circuit-connected belts, but still...)

Also did you get anywhere with the circuit network conditions? It seems like this kind of setup will definitely be needed for any advanced builds. If you've already done some work on it, I'd rather incorporate your work rather than reinventing the wheel so to speak.

I actually posted a release to the mod portal and github last night, I guess I should have posted here too. See the info there for supported circuit signals, and for sources!

control.lua is basically entirely rewritten, because I also got rid of tick balancer - circuits have to be every tick anyway to catch single pulses!

Regarding hard-coded signals ... why not just add some brand new signals specifically for this? That way there's no possible conflict with any existing signal systems.

I'm already running short on signal slots in my CPU (that thread needs an update...), I don't want to take up more if I don't have to! I'm a little annoyed I couldn't use the Blueprint or Blueprint Book signal for deploying though, as those would always have an extra 1 from the chest content - At least as long as I'm stuck with the ContainerControlBehavior.

What I would *like* to happen would be to have a ModControlBehavior where we can give them a structure describing what signals we need

Code: Select all

ModControlBehavior.set_config{
  toggles={blueprint="Enable Blueprints",blueprintbook="Enable Blueprint Books",decon="Enable Deconstruction"},
  conditions={deploy="Deploy Print",deconArea="Deconstruct Area",deconSelf="DeconstructSelf"},
  signals={page="Blueprint Book Page",x="Offset X",y="Offset Y",w="Area Width",h="Area Height"}
} -- Obviously these are all LocalisedStrings and I'm being bad and filling in raw strings

and get a structure with their current configuration

Code: Select all

local state = ModControlBehavior.get_config_state

returns state == {
  toggles={blueprint=true,blueprintbook=true,decon=true},
  conditions={deploy=CircuitCondition,deconArea=CircuitCondition,deconSelf=CircuitCondition},
  signals={page=SignalID,x=SignalID,y=SignalID,w=SignalID,h=SignalID}
}

and a function put_signal(ArrayOfSignal,circuit_connector), and they generate the UI like they seem to already do. Maybe thrown in a mode table for a set of radio buttons.

But I kinda doubt we'll see anything like that any time soon

And dealing with conflicts is just a matter of sticking some arithmetic combinators inline to reassign things (for a slight delay penalty)!

Regarding deconstruction, I feel setting coordinates is fiddly; but with the above custom GUI you could have an interface that actually highlighted the area to be deconstructed. Anchors might yet be a better way to do this tho.

Building GUIs is fiddly, and I've already got a CPU for working with circuits

Making a pulse is also a lot simpler in 0.13 than it used to be.

Also, for the previous behavior of "order centered on the deployer" you can skip the X,Y signals entirely. Area deconstruction won't deconstruct itself (though, it will quite happily deconstruct the circuit controlling it!). Also, deconstruction orders are negative numbers for safety (it's a lot harder to accidentally generate a pulse of a negative signal) - and in fact in my current working tree, a 1 signal cancels an order given by a -1 signal, which allows (with fast circuits) deconstructing the border of a rectangle while leaving the inner area intact.

The Deconstruct-Area order needs *some* way to specify the area covered though, and I'm not sure how else to do it. Maybe a print with two wooden chests (to mark area) and a deployer (to mark alignment)?

Yes, this is absolutely essential. I was going to call this a Prospector. In my head it was somewhere between a pump jack and a drill, sampling nearby tiles and outputting a resource count on the circuit network. Maybe some specialised kind of radar is a better fit though, although that would have to be pretty advanced technology.

I've already got a combinator that outputs it's own X,Y coordinates (for making circuits that react differently when built in different places - useful for enumerating stations!). I've got lots of crazy ideas (but very little code so far) for serializing things into/out of circuit networks, including but not limited to: logistic network requests, logistic network ghosts (this one seems to be too performance-costly for now, unfortunately - or maybe just on large networks), on_sector_scanned (with some data about the chunk, ores, entities, etc, as much as I can pack into one tick!), blueprint data for reading/writing. Basically, I'm building IO ports for my combinator CPU to connect to the lua API to control the world.

I've also got most of the blueprint worked out for a radar-area sized power field that deploys the next-in-line neighbor in stages to clear any biters that might be in the way


Edit: and as an afterthought...

I really hadn't thought about what to do about Blueprint Books. This does raise some interesting possibilities. Copying a single book around and then using numbered signals to deploy different phases of your machine does seem a lot neater than having to copy loads of blueprints and get the right one to the right place all the time. Just need to solve that cloning problem, I had a really good go at it before but there were so many issues

I just realized that it should be fairly straight forward to copy a book's active print to all other pages in that book. Then we just need a way to get prints in/out of books and we can mass-produce prints. If loading them into books is predictable, then we can mass produce books too. And if one of the pages of that book is the book factory... wait no that's not right

[justarandomgeek]

Well, I basically had to re-implement crafting, but I have a working blueprint cloner now, and enough skeleton code that I expect to have picking/inserting pages out of/into books working tonight too, which allows mass producing individual blueprints or whole books!

Turns out clearing blueprints is as easy as just making a recipe that takes blueprint+electronic circuit and produce blueprint. You've now recycled your blueprint into a shiny new blank one!

For cloning, I have a custom machine (not entirely dissimilar to your commented out blueprint-printer...) to run scripted recipes. The first one, clone-blueprint consumes a blueprint book, and produces a blueprint book which has the same number of blueprints in it as the original, all matching the active print (which is copies as-is). It doesn't look like we can currently copy labels, but everything else in the print is copied over.

Then, I'm about to start work on insert/extract blueprint - extract takes the last blueprint out of the book in the input stack and moves it to the output stack. Main inventory first, then Active. When the book is empty, it will be destroyed (unless I come up with a better way to get it out of the way...). Insert blueprint will take a book and blueprint as input, and produce a book with the blueprint appended to it - active first, then main.

I haven't figured out a way to directly clone whole books in a single recipe that I like yet, I'm open to suggestions there!

Having the books as containers to work in makes this all quite nice, actually!


Edit: and here's a blueprint-book copier:

Code: Select all

H4sIAAAAAAAA/61c0W7bOBD8lSDP1sEULbtB4W8JHJtNhTqSK8lAisD/fkokt7Yokrs7+3I5FN4hd7XUiMORDvXDsd7vjg/P2w9XdWVXunb78VHt3tz2sT2/
tN2uK+vqcXGq2/Lz/7Yf79ssN/8Viz/bzPZ/L5fF+POmfqlPddPd/zhfjr9d3f725Xh2p6asuuzrv66ZjGCePmPyp8uicfvy1EeUVeuaLvsb+PgPq3zN3NHt
u6bcZ6f66CZYq3ECy9sJ/Ni1XTZg+oNvroMfyn74r39fcyK/3UbmfyPd+6lxbZt1za5qPyuVvbhjN4VY+4P/gzjWr2Xb9Xnuf7p+Go37fe7/+vNYX+cx/uL5
R3nsf/Z5bcvq4N63ZjG5EI+LfX2uum2xvFyYM17FZkyDKHCIHIewGqW37NJnL3X961p/wy7/Ek/cwBDfYIQnGCG6ckgIMwufiYCvBXwpRNuYhDCzllYShG/z
CG/uUJ7fYjdtc41nLj/N1UfkqILCUVHSGHA287XqGXj/Kxi6HkNFHLOeHzGZt1XK204nnxq5mA7s3vs897Mjp3tsXKubyUMBoa0Dl+pa+3PfaM1r0zfUIYxx
X/xF92co5OlMrZ6PsqYW0tAvYALJuyL7Y105AZC3liKXNpWdTn/67Ul48ivwJ78CuOuOEKt5iOj8C39w2jOvTQYSVlQg6a9w0nJaqSwnfvrp7OfjZtqFFGei
E03u2HIj2IUZJYazeGcrQOQQ6+G1sGMi6YtmlnMXjcUyOWFZsADtHGB97pgLLQd4i3QJ0vSfT68DiepuBseo7gYIeooZt3/0PJQa2e9jAj0anB4NfgdYiunR
RO7XpOWzpNIUCc3oLMZYVjHW48fNdAGH9QKBNBozGx0aM8i2eOhADYjA1ppGYwq1sGMiIhqZzB7npUlFpUvhfl48XqLVlEIyt0gQydwCKZDM7dUmkQzcZn6X
pUnGbGCSMYkNPgUiIK6kSeZ+cAHJGLK0QELb6KysWFYRkhHEzXQBg2RCgUSSsUokg6sAGhABIYFIMngt7JiIjBMomgALsKAsBRJX4KXxM1wzbuj5tLAkXrJa
vGR1eYmeh1Jn+o1J4CWL81JAu+BABBQUAi9ZlJcoYgQdTUeJiGYV4yV+3EwXcHgpEEjjJZKRgkBL+O5bAyKwgafREl4KO+YhIxGKBMAC1FEB7ufF2/rQbDoE
hnlSIpgnXX4xTH5BW8zvsKSwv+GZmyC3yNpDEC3jgIKRZqKAMSupo/s1oqwvurJAQaMIH8m1ynemWVmY3ysMxgrE0QhLyVWBb+RxBMhmoeSymHGIULqVtPfn
AKq4HgDTA6mcxO0T3bhSTIaGuE3L/jJwGz0JnX702jHNVbinIiBjMBBi/oQoV8VO+CkLhiQ5kNFUXBJCk4TQIyG1SATiiDKeDvvgbgUFvwMk4emwj5Wxj7Z5
Qcm7ABwRqZ0QaQlxqlzC9SDoWBBYDgTYgBCQHjjqhViAQ/U3TSohGxmimoNQexNKb1LlDWASneMgWDKDARAW0TkGksltyhSiIrXJCYRUSdruhS5pFfcDI3yj
euzDFOVUjnwMg2vg4x742U9qAwcPesibDAKWyiOb7IhHdsAjPN4JhKVk3zXbza1jgoOtBTAAIqrpmN8Kgjo/Ks9roX+bopYx4OhaQmQxycU3LX+ckjtO1RvH
dCCo+OI4Bz6wJw6WwaWnPaAbjnzeQsBSccLJfHAyF5zQA4c44IyOdAafLsIAkMlAoQr2KwnRJkXZYUA6ACXc/xWK4mXH9bzRHczFZMYI1RhVnY3pwobLPm3F
JNkYWGXDTUIhq1ySbwwos6m63HS8PdGUwpwjCPOvPp11QnE02tHxC4TckYy+wxEQ07VCHeyQhYh50O26N3j6XgOfDuM+efG7HgY5pDQ6nk78XRcFBORlNoU6
2CELsuyS8z4ldv9ymqRHQ6+sMkoceCBO96jQbXdfI1JH5zqnJfgrwgoIyIGJQh3skAW9R3NYrsa/zSD+bkmOeONzHUkU/26LAgKiiirUwQ5ZMLoO1qVCnxhj
IAToK911iE5idXSSXHJb/zqnWMKVhyUWK/0Qg5W9qzAeR+toM/nNjvhYV6/Zz13/gHyIfqnNBjbGqeeN+2+npph3+PVlUe7r6vO7d235Wu2O249xJ9q5t0fv
G3jXevVRw1fyeoDvjevOTfXw/N1Vh/8BZB6I+ylWAAA=

[doc]

Well, I basically had to re-implement crafting

Nice

Really good work anyway. I was experimenting with something similar, basically manually controlling an assembler to start/stop and create the output items by hand, but the problem was making an assembler have two output slots (someone on reddit did comment that this could be configured, however, so I will still have another go at my method).

I do still want to figure out why the anchor isn't blueprinting. Using a wooden box doesn't seem satisfactory to me, even though it's highly unlikely anyone would want to use wooden boxes in anything it seems like an unneccessary restriction ... also the Anchor entity's description is a good way to provide the player some in-game documentation. Explaining the use of the box would be quite tricky. And using the deployer itself as a marker has problems ... for any self-expanding machine you will need more than one deployer, and it would never be clear which one is "first".

I'm also not sure about running everything every tick ... obviously checking the circuit conditions has to be this way (I didn't even think about pulses), but if you have a huge machine expanding across the map then this will create UPS issues much quicker, every tick matters. I'll have a look at it and see if there's some kind of compromise where only the minimum amount of stuff runs per-tick.

Lots of other interesting ideas here too, I really should have a close look at that CPU. Unfortunately what happened (quite predictably) is I started a new game in 0.13 and now I have to finish building this factory before I can carry on with the mod. I could use sandbox I know but I prefer to test in real conditions

[justarandomgeek]

Well, I basically had to re-implement crafting

Nice

Really good work anyway. I was experimenting with something similar, basically manually controlling an assembler to start/stop and create the output items by hand, but the problem was making an assembler have two output slots (someone on reddit did comment that this could be configured, however, so I will still have another go at my method).

I do still want to figure out why the anchor isn't blueprinting. Using a wooden box doesn't seem satisfactory to me, even though it's highly unlikely anyone would want to use wooden boxes in anything it seems like an unneccessary restriction ... also the Anchor entity's description is a good way to provide the player some in-game documentation. Explaining the use of the box would be quite tricky. And using the deployer itself as a marker has problems ... for any self-expanding machine you will need more than one deployer, and it would never be clear which one is "first".

I'm also not sure about running everything every tick ... obviously checking the circuit conditions has to be this way (I didn't even think about pulses), but if you have a huge machine expanding across the map then this will create UPS issues much quicker, every tick matters. I'll have a look at it and see if there's some kind of compromise where only the minimum amount of stuff runs per-tick.

Lots of other interesting ideas here too, I really should have a close look at that CPU. Unfortunately what happened (quite predictably) is I started a new game in 0.13 and now I have to finish building this factory before I can carry on with the mod. I could use sandbox I know but I prefer to test in real conditions

I cheated on the crafting - I basically turn off the machine and just push it's status around to track my own state. This way I can still use the Assembling Machine UI, and run a script at the end of the recipe!

If you can get the anchor blueprinting again, I'll gladly put it first in the anchor search list! I mostly just patched around it to see what else was broken, and never cared enough to go back and investigate it.

"First" is determined by the order in the entity list in the blueprint. Helpful, I know. That's why the wooden chest takes precedence over the deployer, if they both exist Of course, with printing-at-offset, you can use a single deployer in your print, and deploy the print out where it needs to be. I wonder how hard it would be to set the anchor object via a circuit signal...

I don't love running stuff every tick, but I'm not gonna worry about optimizing too much (beyond generally failing fast) until I actually see where bottlenecks are. Premature optimization and all that Also, *most* of the stuff I'm running every tick most of the time just checks for stuff to do, finds nothing and returns, so it shouldn't be *too* bad. I can also fairly easily tweak the timing constants for the fake-crafting to use less time on the progress bar if needed (or skip the progress altogether even...). I'm currently running the circuit updates every tick for deployers and fake-crafting update for each printer every 20th tick after the machine was built. If this doesn't prove random-enough, I may bring back TickBalancer for the printers, but I think just tweaking the timing to get a low enough duty cycle should be enough. I'm also planning to make it stay in the 0-progress idle state until *all* ingredients are present, instead of just the first one, which should reduce a bit of the processing time too.

I think when I do ghost/requester querying into a combinator those will likely have a slower update cycle and just report last-update to the circuit network though, as both involving multiple nested loops, over potentially large sets of entites... (counting ghosts in my main logistics network drops me to like ~20UPS (from a normal 50ish)

Here's my timings with my CPU (nixies - for comparison, though I cranked up the refresh rate a bit) and book copier in a world together

I started a new game in 0.13 in which I made just enough parts to test/update the mods I needed to update my CPU world (basically all the ones I'm now developing on), so I could use that to test/update the CPU and write more mods! Mostly because I'd already spent the prior couple weeks rebuilding the CPU from it's original world into the nice clean modular layout of the current version, and didn't really want to build it again just yet...

[edvardm]

There seems to be some issue with copyPrototype function call in Factorio 0.13.8. The game refuses to start with mod error message

attempt to call global copyPrototype (a nil value)

Guessing this is due to 0.13.8?

[justarandomgeek]

Weird, I've had no complaints at all from copyPrototype on 0.13.8 here...

[edvardm]

Hmm.. odd. I tried disabling all other mods if they cause some issues, still the same

[edvardm]

Funny, for some reason I had the idea of running 'verify integrity' check on Steam. After that it worked! So it seems like upgrade process had missed something at some point. Sorry for the trouble, need to try that now

[justarandomgeek]

That's bizarre! Glad it was an easy fix though!

[triggerman602]

I was fiddling around with this mod a few weeks ago to make it work on 0.13 and I fixed the anchor not blueprinting by changing its type from a "simple-entity" to a "smart-container". It turned into a single slot chest but it was at least blueprinting. I'm sure there is something else that works better but that's beyond me.

[justarandomgeek]

I was fiddling around with this mod a few weeks ago to make it work on 0.13 and I fixed the anchor not blueprinting by changing its type from a "simple-entity" to a "smart-container". It turned into a single slot chest but it was at least blueprinting. I'm sure there is something else that works better but that's beyond me.

You might want to check my github (and the mod portal) for a version that already works on 0.13 (and/or send a pullreq for the anchor?)

[TheVeteraNoob]

Funny, for some reason I had the idea of running 'verify integrity' check on Steam. After that it worked! So it seems like upgrade process had missed something at some point. Sorry for the trouble, need to try that now

I had the exact issue as you. And this solution did not solve my problem.

[British_Petroleum]

I'm getting this error on 0.13.13 any help?

[justarandomgeek]

I'm getting this error on 0.13.13 any help?

short-term workaround: install FARL. I didn't realize I was using it's copyPrototype. I should have a new build some time this week that resolves this by including the function myself!

Also, future bug reports and such should probably go to github, much easier to keep track of there.

[justarandomgeek]

The issue with copyPrototype should be resolved in 0.2.4

[sebgggg]

Hi,

I just tested your mod, and it seems really nice!

But:

1-in data.lua copyPrototype should not be declared as local.
2-In digitizer.lua, the function onTickDigitizer seems to be called before onBuiltDigitizer which raise an null pointer exception :
line 191: if not pairedEnt.valid then
Enclosing the function in "if pairedEnt then" works.

Now if you'll excuse me, i'm going to replicate factories till i exhaust my ram!

[sebgggg]

You also forgot to check if there are any blueprints for thge printer

printer.lua
line16 : if (outInv[1].valid_for_read) or (inCopies < 1) then return end -- previous output not taken away!

[justarandomgeek]

Digitizers are definitely very broken in the builds so far - they're still in progress! Now that I've got Pushbuttons to test with, there should be and update with better Digitizers fairly soon.