[MOD 0.12.x] Recursive Blueprints 0.2.0

[doc]

Recursive Blueprints

• Name: Recursive Blueprints
• Version: 0.2.0
• Factorio-Version: 0.12.34
• Description: A system to automatically deploy blueprints and allow blueprints that deploy more blueprints
• License: MIT
• Release: 2016-05-31
• Download-Url: download/file.php?id=11797
• Source-Url: https://github.com/chucksellick/factorio-bad-chest
• Website: viewtopic.php?f=93&t=24053
• Dependencies: base
• Category: Item
• Tags: blueprint, automation

recursive-blueprints_0.2.0.zip

Recursive Blueprints 0.2.0

(76.11 KiB) Downloaded 640 times

recursive-blueprints_0.1.0.zip

Recursive Blueprints 0.1.0

(204.63 KiB) Downloaded 249 times

Do you ever get bored of having to place blueprints by hand? Don't you wish you could automate that?

This mod currently adds three new entities: the Blueprint Deployer, the Destructive Deployer, and the Blueprint Anchor. Together these can be used to automatically deploy a blueprint for your construction robots to build. That blueprint can contain further Blueprint Deployers, potentially allowing infinite automated base expansion.

The Destructive Deployer is new in 0.2.0, in addition to deploying the Blueprint it will also schedule for destruction anything in the way, as long as those entities are valid for destruction. Be careful ... this has the potential to tear your base apart if used unwisely!

Instructions

Instructions for use (Video tutorial to follow soon, promise!)

To get started you will need to craft these items:
1 x Blueprint Deployer
1 x Blueprint Anchor
1 x Blueprint (blank)
(any) x items you wish to build

Firstly, place the Blueprint Anchor on the ground. The anchor determines where the blueprint will be deployed relative to the Deployer, in other words the anchor acts as a proxy to anchor your blueprint relative to the Deployer.

So, now place some entities around the Anchor. These can be anything for demonstration purposes.

Now using your blank blueprint, make a blueprint of these entities and make sure you include the Blueprint Anchor in this blueprint. If you insert a blueprint that doesn't specify an anchor position then the Deployer won't work.

Finally, place your Blueprint Deployer on the ground (somewhere with some space around it, and inside your construction network) and insert the blueprint into its only slot. This can be performed either by hand or of course via an inserter.

The blueprint should be immediately deployed around the deployer, creating ghost entities for your construction bots to build!

Now consider this setup:

bad-chest-example-1.jpg (100.75 KiB) Viewed 20295 times

That's an Anchor, an inserter arm, and a Deployer. When this blueprint is deployed by a Deployer it will create another Deployer into which it will insert the blueprint ... triggering the whole deployment over again. This will keep on going until it runs into an obstacle or reaches the edge of your construction network.

bad-chest-example-2.jpg (307.82 KiB) Viewed 20295 times

Throw a roboport into the blueprint and this will keep extending your construction network, so the deployment won't ever stop until you run out of space or the ghost entities start timing out (solutions for both these problems coming in future releases!)

Todo

TODO:
This still quite basic and I have a lot of ideas about how to improve it. Some additional features are planned:

* Blueprint Printer, this will make copies of blueprints, so from a single original blueprint you can expand in multiple axes
* Circuit network support, this will come after Factorio 0.13 is released. Both allowing the deployer to be triggered by a network condition, and emitting a circuit signal when a deployment has finished, allowing finer control of large-scale deployments.
* Long-lasting ghosts. Things start timing out when your deployment expands a long way from base. A feature will be added that continually resets the ghost timeout, giving things a chance to keep going once they get very spread out.
* Better graphics and an obvious distinction between standard and Destructive deployer.

Please let me know your comments and suggestions, and if you make anything cool with this I'd love to see it!

Known Issues

Known Issues
The Destructive Deployer is currently a bit buggy! Right now it will attempt to place ghosts over water even though that could never be a valid position, and the bots will keep hovering over there until the blueprint times out.

Changelog

Changelog
* 0.2.0 Added the Destructive Deployer, same graphics as the standard Deployer at the moment.
* 0.1.0 Renamed mod to "Recursive Blueprints", minor performance and stability tweaks.
* 0.0.2 - 0.0.4 Initial releases (as "Blueprint Automated Deployment")

doc.

[bammalar]

is it possible for there to be more than one anchor within a placed blueprint? so for instance building a blueprint that is designed to expand as it goes.

[doc]

is it possible for there to be more than one anchor within a placed blueprint? so for instance building a blueprint that is designed to expand as it goes.

You can do this with only one anchor. The blueprint can contain additional BAD Chests which can themselves accept a blueprint. But the chest needs to know how to place the blueprint relative to itself, which is what the anchor is for. So there can be only one anchor per blueprint otherwise the chest just wouldn't know which one to pick!

It might be clearer once I've made a video. Also once I implement the blueprint cloner it will be possible to build designs that expand in both axes.

[doc]

Update 0.0.4 - integrated the N-lane Tick Balancer for better scalability, see this post for more info: viewtopic.php?f=34&t=24147

[Adil]

Hey, nicely done mod.
I see that chest can only place single blueprint ever. Have you considered replacing them after they do their thing to provide visual indication of that?
Also, I believe one of the obsolete blueprint mods provided deconstruction functionality as well. Think you could add some bad-deconstruction-marker as well? (A non-colliding entity, which ghost marks anything below it for deconstruction and then selfdestroys?)

[doc]

Hey, nicely done mod.
I see that chest can only place single blueprint ever. Have you considered replacing them after they do their thing to provide visual indication of that?
Also, I believe one of the obsolete blueprint mods provided deconstruction functionality as well. Think you could add some bad-deconstruction-marker as well? (A non-colliding entity, which ghost marks anything below it for deconstruction and then selfdestroys?)

Thanks for the feedback. Actually both of these mechanics were already planned, I have just been sidetracked by that pesky thing called Real Life for a few weeks. I plan to come back and properly finish this mod very soon.

The way I had planned this is as follows:

- Firstly, the deployer should reset whenever a blueprint is removed from it. This will leave it ready to deploy another blueprint when inserted. Currently there is a flag so it doesn't keep deploying over the top of the existing ghosts! But this flag never gets unset once a blueprint is inserted.
- For destruction I was going to have a "Destructive Deployer" entity. This would take a normal blueprint and just mark for destruction anything in the way before creating the ghosts. I didn't plan a way to purely destroy things without deploying new stuff ... I'll definitely think about your marker idea as this would give more flexibility, but sounds like more work for the player to set up.
- Oh, I also wanted to add a feature where the blueprint will be automatically re-deployed IF the ghosts expire before everything is built. This gets useful when things scale to a certain point and manufacturing/delivery of items can't keep up.
- Finally, there does I think need to be some way you can detect when a deployment is completed, maybe a custom circuit condition?

What I have been thinking about here is a modular base building setup where, combined with circuit conditions, you could decide to build either a mining facility or a power plant (for instance), depending on the presence of resources at a deployment location. It might look as follows:

1. Deploy a blueprint with drills and smart chests.
2. If the chests detect resources, destruct the chests and deploy belts and whatever other means to extract the resources. You probably want a network of belts connecting all the way back to your main base.
3. Otherwise, destruct all the drills and deploy panels/accumulators (or you could randomly insert manufacturing facilities, perhaps build a smelting plant if there is an adjacent mining facility, and so on...)
4. Either way ... at this point send all the blueprints into cloning machines and send copies on to be deployed in adjacent sectors.

I can imagine advanced players building some VERY complex setups with all of these principles.

[Adil]

Oh, you have rather complex behavior planned out there. Well, good luck on that commendable endeavor.
I've thought about self-replicating, self-moving factories too, but in the framework of standard blueprint systems. After all you can build both item counter and timer with just a couple of combinators. So if player is so inclined to ensure robustness of the automated system, he could just build some self-evaluation in it: check how many items have arrived to the site, check whether they arrived in time, if not - reinsert blueprint.

But hey, you can just check whether ghost or entity is present at position before placing new one, if you want your deployer to be more than one-launch.

[doc]

Oh, you have rather complex behavior planned out there. Well, good luck on that commendable behavior.
I've thought about self-replicating, self-moving factories too, but in the framework of standard blueprint systems. After all you can build both item counter and timer with just a couple of combinators. So if player is so inclined to ensure robustness of the automated system, he could just build some self-evaluation in it: check how many items have arrived to the site, check whether they arrived in time, if not - reinsert blueprint.

But hey, you can just check whether ghost or entity is present at position before placing new one, if you want your deployer to be more than one-launch.

Yes, that last comment is going to be my workaround initially at least. And the combinator method you described would also work, but would be really tricky to set up, my aim is to at least take complexity out of the common requirements, allowing the player to build much more complex stuff on top of that!

Edit: Just a quick note, I have uploaded the v0.1.0 release, there are no major functional changes but the mod has been renamed to "Recursive Blueprints" (which it will stay as). I just got this release up as I do intend to continue work on this and get the Destructive Deployer and Blueprint Printer working soon, but getting the rename out of the way seemed like a good thing as there will not be a migration path.

Edit 2: v0.2.0 released, adding the Destructive Deployer.

[Shrooblord]

(...)I have plans for some parts of this, I actually just expanded on this in the description. Let me just address those points:

1. Needing physical blueprints. I actually think this is the right way to implement this. To me the logistical puzzles are what Factorio is about. Designing a method for your blueprint to move to the next deployer is an interesting challenge, but it is actually pretty easy to remove it with an inserter and belt it along to the next deployer. I'm not entirely sure what other method would make sense, but further suggestions are welcomed.

Yes, I agree. Your method seems more in nature with the original spirit of Factorio.

3. Deleting structures. Yes, also planned. The idea is to have a second version of the Deployer, called "Destructive Deployer". This will schedule any conflicting entities for destruction, as well as deploying the new blueprint. Someone else in the original thread suggested a different type of anchor, e.g. "Destructive Anchor". This could achieve the same effect but you couldn''t create and destroy in the same operation which in my opinion would be less useful. The reason I want to have different entities (rather than e.g. a GUI setting) is so you can design your deployments around which behaviour you want, and custom GUI settings can't be stored in blueprints.

I like your idea of storing the behaviour of this device in the Blueprints themselves rather than a GUI setting. It's more flexible and intuitive (or at least more like what one would expect from Factorio's original Blueprint functionality).

Of course maybe players will only really ever want the destructive deployment, but I think it could be useful to have both, and destructive deployment could be really dangerous. Like, you could wipe out your entire base by accident

That seems bad. There should at least be some sort of safeguard against this scenario happening. Like a warning if the player indeed intends to delete a large area of landscape; a flashing border signalling the destruction zone with a cooldown timer to give the player a tiny amount of time to realise their mistake and destroy the Deployer before it executes its evil master plot to wreck the player's factory; a blatant 'nope' from the machine if the destruction plan includes a large area around itself unless some security signal is also input - something like that.

4. Using circuit. The deployer inherits from smart chest meaning you can at least detect whether it has a blueprint or not, and I was thinking about making it emit some kind of flag to detect when deployment has finished. (...) Please tell me if you have any ideas, yes this would be a nice thing to support. Although I don't see that having to use a smart inserter is actually a bad problem, the point of Factorio is to build complex machines from lots of components. I am trying to provide the simplest solution to enable the scenario, if you have to use it in combination with other machines then that might actually be a good puzzle ...

Yep, agree wholly. Factorio is all about solving logistics puzzles. But indeed, Factorio is also about giving the player options to approach these problems from different angles. Circuit integration is a must.


Great work, doc! Will love tinkering with this in-game.

[doc]

That seems bad. There should at least be some sort of safeguard against this scenario happening. Like a warning if the player indeed intends to delete a large area of landscape; a flashing border signalling the destruction zone with a cooldown timer to give the player a tiny amount of time to realise their mistake and destroy the Deployer before it executes its evil master plot to wreck the player's factory; a blatant 'nope' from the machine if the destruction plan includes a large area around itself unless some security signal is also input - something like that.

Well, it's maybe not quite as devastating as that. Destruction is still scheduled by your bots so there is some time to cancel, and it would be pretty hard (maybe not even really practical) to wipe out an entire base because at some point your bots would start unloading all your storage and have nowhere to put it, as well as deconstructing all their own roboports. When I tested this myself the blueprint broke down pretty quickly because existing belts messed up the blueprint belt. Also it's always very clear where the destruction will take place, because it's exactly the same places you are building new stuff ... it's like a shift-click-plus ... if I add the destruction anchor as well then it might get a bit less obvious.

The problem with any kind of warning/prevention is it's very arbitrary to decide what is and isn't intended by the player. Really this is an advanced tool and players should be aware of the potential dangers. I would certainly recommend saving before deploying a large and complex blueprint (even a non-destructive one), it's just easier to reload rather than clean up the mess if things go0 a bit wrong. With a non-destructive one things can still grow exponentially out of hand. Anyway with more feedback and testing maybe it'll be clearer how to tweak the behaviour.

I'm considering making the standard one also schedule trees for destruction, so just like a normal blueprint shift-click. I don't think there's any case where you really want trees getting in the way. So standard deployer will only be stopped by buildings, whereas destructive deployer will also clear the buildings out of the way.

It's really a shame I can't pop up a GUI and have a few options to toggle, the settings I would like would be: destroy trees yes/no, destroy buildings yes/no, landfill yes/no, only deploy entire blueprint yes/no. I only can't use a GUI because the settings do also need to be blueprintable. I *might* be able to provide this interface in 0.13 with some circuit condition trickery, we'll see.

Yep, agree wholly. Factorio is all about solving logistics puzzles. But indeed, Factorio is also about giving the player options to approach these problems from different angles. Circuit integration is a must.

Agreed definitely. Circuit integration should be easy in 0.13. Soon But I want to make sure that it can do things without requiring any circuits, I think the other similar mod to this wouldn't work at all without, and I think it's important to provide some simple functionality. Circuit networks are really tricky to understand and I want some scenarios to be possible with very little setup.

Let me know how you get on and any other thoughts!

[Shrooblord]

The problem with any kind of warning/prevention is it's very arbitrary to decide what is and isn't intended by the player. Really this is an advanced tool and players should be aware of the potential dangers.

I'll give you that one. I assume players fooling around with a mass-scale Deconstruction Planner can expect to make a few slip-ups along the way.

I'm considering making the standard one also schedule trees for destruction, so just like a normal blueprint shift-click. I don't think there's any case where you really want trees getting in the way. So standard deployer will only be stopped by buildings, whereas destructive deployer will also clear the buildings out of the way.

A good idea. I'd have thought trees would have been cleared before any sort of building commences anyway - I thought this was normal Blueprint behaviour but maybe I'm confused.

It's really a shame I can't pop up a GUI and have a few options to toggle, the settings I would like would be: destroy trees yes/no, destroy buildings yes/no, landfill yes/no, only deploy entire blueprint yes/no. I only can't use a GUI because the settings do also need to be blueprintable.

OK so I don't know how hard/clumsy this would be to implement, but how about different 'module buildings' that can achieve this? For example, you have the normal Blueprint Deployer to place buildings, then also a tiny 1x1 green 'box' that can be placed next to the Blueprint Deployer or in its vicinity to tell the BD "hey, also clear trees please" and then also a small 1x1 red 'box' that signals "remove buildings beforehand too", etc. Then you could place and Blueprint these settings as you see fit, simply by adding or not adding the different modular parts of the Auto-Blueprint factory.


A quick question in between discussion points: can the BD/Destructive BD currently delete and replace itself in its functionality, acting as a sort of inchworm drive that replicates itself along a path and destroys its predecessor in the process, creating, say, a 'line' of identical blocks of furnaces at the end of which is the final block with at its head the (D)BD ready to replicate itself once more and create a new block? Is that behaviour planned, if it isn't currently possible?


EDIT:
Found a bug when CTRL+Clicking a blueprint into the Blueprint Deployer:

crash

Code: Select all

Error while running the event handler:
__recursive-blueprints__/control.lua:74: bad
argument #1 to 'pairs' (table expected, got nil)

EDITII:
As a response to your "or until ghost placements start timing out (solution coming in future releases!)" :
This is not necessary. There's a mod out there called Ghost Time that does just that.

[Qon]

I created another mod similar to this one. The old version is here, but I have a much improved 0.1.0 version which I haven't released yet (moving house slightly got in the way) : viewtopic.php?f=93&t=24053

It is basically the same idea but the mechanics of how it works are slightly different, hopefully a bit more flexible.

Your mod doesn't use circuit, has no deconstructor and needs physical blueprints. Which means it is a hassle to make repeating structures (need to somehow move the blueprint from one chest to the next within your blueprint), multiplying structure (you only have 1 blueprint item which can't be copied), no "walkers" (because no deconstructor), no circuit, which means you have to do tricks with smart inserters delivering the blueprint instead since those can have circuit conditions. It's just very limited at the moment and not really useful. But it has great potential! And it actually does something without crashing q:

Yep, right now you are correct. But I have plans for some parts of this, I actually just expanded on this in the description. Let me just address those points:

1. Needing physical blueprints. I actually think this is the right way to implement this. To me the logistical puzzles are what Factorio is about. Designing a method for your blueprint to move to the next deployer is an interesting challenge, but it is actually pretty easy to remove it with an inserter and belt it along to the next deployer. I'm not entirely sure what other method would make sense, but further suggestions are welcomed.

2. Multiplying structure. The plan is a "Blueprint Printer" assembler. This will support one recipe, "Clone Blueprint". So it requires two blueprints, one of them should be blank, it will output the original blueprint and a new clone -- something like that at least. This is a priority to get implemented, hopefully I will have something this weekend.

3. Deleting structures. Yes, also planned. The idea is to have a second version of the Deployer, called "Destructive Deployer". This will schedule any conflicting entities for destruction, as well as deploying the new blueprint. Someone else in the original thread suggested a different type of anchor, e.g. "Destructive Anchor". This could achieve the same effect but you couldn''t create and destroy in the same operation which in my opinion would be less useful. The reason I want to have different entities (rather than e.g. a GUI setting) is so you can design your deployments around which behaviour you want, and custom GUI settings can't be stored in blueprints. Of course maybe players will only really ever want the destructive deployment, but I think it could be useful to have both, and destructive deployment could be really dangerous. Like, you could wipe out your entire base by accident

4. Using circuit. The deployer inherits from smart chest meaning you can at least detect whether it has a blueprint or not, and I was thinking about making it emit some kind of flag to detect when deployment has finished. Using a circuit condition to *trigger* deployment is trickier ... the problem is requiring a base entity to inherit from that has both properties: a) being able to have an entity inserted b) being able to control it via circuit conditions (and being able to select the condition in a GUI, and being able to store that condition in subsequent blueprints...)! Basically I need a base entity that has *both* the properties of a smart inserter *and* the properties of a chest. I could maybe invent a new signal instead, so you wouldn't be able to pick your own, you'd need combinators to generate that specific signal. I would also like to wait on this one until 0.13 is released so I can see what the changes to circuit networks are ... maybe there will be something new that enables this. Please tell me if you have any ideas, yes this would be a nice thing to support. Although I don't see that having to use a smart inserter is actually a bad problem, the point of Factorio is to build complex machines from lots of components. I am trying to provide the simplest solution to enable the scenario, if you have to use it in combination with other machines then that might actually be a good puzzle ...

Anyway thanks for your feedback and yes I agree there is a lot of potential with this concept!

Edit: Just had a closer read of https://www.factorio.com/blog/post/fff-138 - and the great news there is that 0.13 will indeed make it extremely easy to support circuit conditions on any entity, so I'll be adding this feature for sure once the release arrives.

Edit 2: After thinking about this so much again I decided to tinker and implemented the Destructive Deployer, this is the 0.2.0 release on the original thread, so at least part of the above is done already

The name change had me really qonfused for a while there.

If all these are implemented then yes it will probably be even better. You could then probably do things like alternate between 2 blueprints and other things.

[doc]

I'll give you that one. I assume players fooling around with a mass-scale Deconstruction Planner can expect to make a few slip-ups along the way.

It's a mistake you'd (hopefully) only make the once

A good idea. I'd have thought trees would have been cleared before any sort of building commences anyway - I thought this was normal Blueprint behaviour but maybe I'm confused.

They only do this when you shift-click. A single click won't build the blueprint at all if there are any trees in the way.

OK so I don't know how hard/clumsy this would be to implement, but how about different 'module buildings' that can achieve this? For example, you have the normal Blueprint Deployer to place buildings, then also a tiny 1x1 green 'box' that can be placed next to the Blueprint Deployer or in its vicinity to tell the BD "hey, also clear trees please" and then also a small 1x1 red 'box' that signals "remove buildings beforehand too", etc. Then you could place and Blueprint these settings as you see fit, simply by adding or not adding the different modular parts of the Auto-Blueprint factory.

This is a really interesting idea, and it can plausibly work. I'm not sure if it really simplifies things though, since this does mean you still end up having to build multiple building types. It might be easier to just have 4 different kinds of deployers with different configurations. Hmm ... it could also work more like actual modules, i.e. there are some special items that you can put inside the deployer which change how it works, but you would then need to sort out the logistics of making sure those items get distributed to newly created deployers too. These are some interesting ideas to think about anyway over the next couple of design iterations

A quick question in between discussion points: can the BD/Destructive BD currently delete and replace itself in its functionality, acting as a sort of inchworm drive that replicates itself along a path and destroys its predecessor in the process, creating, say, a 'line' of identical blocks of furnaces at the end of which is the final block with at its head the (D)BD ready to replicate itself once more and create a new block? Is that behaviour planned, if it isn't currently possible?

A deployer can't delete itself (because it's always represented by the anchor in the blueprint, which never gets placed) but it can certainly delete other deployers. So you could have this inchworm drive design yeah, where each one deletes the previous one.

Found a bug when CTRL+Clicking a blueprint into the Blueprint Deployer:

crash

Code: Select all

Error while running the event handler:
__recursive-blueprints__/control.lua:74: bad
argument #1 to 'pairs' (table expected, got nil)

Thanks for your report, was the blueprint blank by any chance? If not that's a bit worrying, I'm not sure why get_blueprint_entities() would return nil. Could you maybe copy me your save if this bug is still reproducible? I can guard against the function returning nil, I'd just like to know why it's doing so!

As a response to your "or until ghost placements start timing out (solution coming in future releases!)" :
This is not necessary. There's a mod out there called Ghost Time that does just that.

Well, that mod changes the ghost time for all blueprint placement presumably. It's really easy to modify the timeout globally, but I wanted to have these ones be long-lived without modifying the vanilla gameplay. But yeah that mod is probably a good stop-gap while experimenting!

[doc]

The name change had me really qonfused for a while there.

Sorry about that, will definitely stick with this name now. I think it better conveys what the mod is for, and it's also more distinct from the other mod.

If all these are implemented then yes it will probably be even better. You could then probably do things like alternate between 2 blueprints and other things.

I'm pretty sure it would already be possible to alternate, but still only expanding linearly. I'll go and set up a test and see if I can do it, this would be a nice demo example anyway.

Regarding all the other changes, development has slightly stalled until 0.13 is released. There are quite a lot of API changes incoming that should help me a lot, not just the circuit stuff. I ran into technical challenges making the blueprint copier how I wanted it so I want to see if 0.13 helps this at all, otherwise I'll have to change the design a bit. I wanted it to be a special type of assembler with recipes like "copy blueprint", "wipe blueprint", "flip blueprint" etc. Unfortunately assemblers don't seem to play very nicely with blueprints for various reasons but largely due to their tiny stack size!

[Shrooblord]

Found a bug when CTRL+Clicking a blueprint into the Blueprint Deployer:

crash

Code: Select all

Error while running the event handler:
__recursive-blueprints__/control.lua:74: bad
argument #1 to 'pairs' (table expected, got nil)

Thanks for your report, was the blueprint blank by any chance? If not that's a bit worrying, I'm not sure why get_blueprint_entities() would return nil. Could you maybe copy me your save if this bug is still reproducible? I can guard against the function returning nil, I'd just like to know why it's doing so!

Actually, no. I was testing an infinite blueprint placing set-up and just CTRL+clicked the appropriate BP into the BD, but that crashed the game. Yep, totally reproducible. Each time I CTRL+click a non-empty blueprint into a Blueprint or Destructive Deployer, it will crash with the same report. Received nil when table expected.

Here's the save.

Testworld.zip

Original save. crashes

(3.58 MiB) Downloaded 210 times

Also tested with a game modded with exclusively this mod and the Test Mode mod in a new world. No crash. After testing, it doesn't seem to be a conflict with a specific mod (the crash doesn't occur in a new test world with the same mods installed), but with a specific thing present in the world save itself. Strange. I've tested whether it's the fact that TM God Mode is toggled on or not, but that doesn't seem to produce the crash in new world. However, the crash definitely keeps occuring in the old save file...!
Creating a new Blueprint and testing that yields the same result.

Here's also the test save made exclusively for the testing of this crash, which didn't happen in this save file.

testcrash.zip

Crash testing world. No crash!

(1.28 MiB) Downloaded 208 times

===

After a lot of testing, my results are the following:
The active God Mode toggle of Test Mode in the save Testworld is somehow creating the crash. If you toggle out of the God Mode and spawn in a new Blueprint, create it and CTRL+click it into the machine, no crash occurs. If you then toggle back on the God Mode, recreate a blueprint and CTRL+click it in, no crash occurs. If you save the game while in the God Mode with a BP created, then reload, no crash occurs. If you save the game in God Mode with no BP created, reload, create a BP from the empty one in your inventory, no crash occurs.

The only condition in which you get a crash seems to be when you load the save Testworld.zip, then either place in the BD the BP that's already in the player inventory, or when you create a new BP from any of the ones currently in the player's inventory.
HOWEVER
If you place down a chest and put all the blueprints from the player's inventory in there, then take one empty one out and create a new BP from the empty one, then place it in the BD, no crash occurs.

So the crash is related to the specific blueprints currently in the God Mode player's current inventory. If they get placed in a chest, then retrieved, they are safe. It is as if these specific blueprints are currently 'dirty' while they remain in the inventory for some reason. They can be 'washed' by first putting them in another inventory.

[justarandomgeek]

Well here I was all excited to build a self-expanding memory array (and a solar/battery array that expands when given a signal), but the auto-deployer doesn't do red/green wires

(Oh, and concrete doesn't place either, which is probably a simpler fix - it's in bp.tiles instead of bp.entities)

[doc]

So the crash is related to the specific blueprints currently in the God Mode player's current inventory. If they get placed in a chest, then retrieved, they are safe. It is as if these specific blueprints are currently 'dirty' while they remain in the inventory for some reason. They can be 'washed' by first putting them in another inventory.

Ok, thanks for the really thorough investigation. It seems like this is buggy behaviour in Factorio itself, so probably the only thing I can do is check for the table being nil and pop up a warning in that case (and submit a bug report to Wube of course!) Worth testing again after 0.13 lands since so much has changed, this behaviour could be incidentally fixed. As I said I've frozen work on this until 0.13 anyway since I hit something of a brick wall; so we'll see next week.

Well here I was all excited to build a self-expanding memory array (and a solar/battery array that expands when given a signal), but the auto-deployer doesn't do red/green wires

(Oh, and concrete doesn't place either, which is probably a simpler fix - it's in bp.tiles instead of bp.entities)

I knew about concrete, but I admit I hadn't tested with circuits.

The issue with concrete is (as far as I know) it's impossible to create a blueprint containing both entities and tiles - it's either one or the other. So the anchor entity can't be captured in the same blueprint as the tiles! The only fix I could think of for this is having an additional "anchor tile" recipe that you use instead if you want concrete deployments. So you'd need to set up a deployment chain with 2x blueprints, one for the entities and one for the tiles. Or am I overthinking this, and there's actually a keypress or something that allows you to capture both entities & tiles in the same blueprint?

For the circuit wires I'll need to investigate, circuit wires are obviously normally included in blueprints but it all gets a bit weird when you create ghosts manually. But again the 0.13 API includes a new method called something like place_blueprint_as_player() so I'll actually just switch to that method which should completely simplify the deployment code which is fraught with peril already (and maybe into the bargain eradicate the bug Shrooblord posted). So again I'll probably just wait for 0.13 rather than doing work now that'll be redundant in a week anyway, sorry about that! I really had hoped 0.13 would release sooner so things wouldn't get stalled this long

Thanks for the reports and feedback anyway, it's really encouraging to see people are interested in this idea.

[justarandomgeek]

I knew about concrete, but I admit I hadn't tested with circuits.

The issue with concrete is (as far as I know) it's impossible to create a blueprint containing both entities and tiles - it's either one or the other. So the anchor entity can't be captured in the same blueprint as the tiles! The only fix I could think of for this is having an additional "anchor tile" recipe that you use instead if you want concrete deployments. So you'd need to set up a deployment chain with 2x blueprints, one for the entities and one for the tiles. Or am I overthinking this, and there's actually a keypress or something that allows you to capture both entities & tiles in the same blueprint?

For the circuit wires I'll need to investigate, circuit wires are obviously normally included in blueprints but it all gets a bit weird when you create ghosts manually. But again the 0.13 API includes a new method called something like place_blueprint_as_player() so I'll actually just switch to that method which should completely simplify the deployment code which is fraught with peril already (and maybe into the bargain eradicate the bug Shrooblord posted). So again I'll probably just wait for 0.13 rather than doing work now that'll be redundant in a week anyway, sorry about that! I really had hoped 0.13 would release sooner so things wouldn't get stalled this long

Thanks for the reports and feedback anyway, it's really encouraging to see people are interested in this idea.

You can make a blueprint with both entities and tiles by making ghosts of the tiles under entities (or ghosts of entities) and blueprinting that. The one I tested with had both concrete and wires in it, and placed both when laid down manually, but neither when placed by the chest. Sounds like 0.13 is just gonna fix this all though, so I guess I'll just wait!

Alternately, you can take two blueprints and export them with Foreman (to get non-compressed prints), and copy/paste the tiles/entities together and re-import it

[stellatedHex]

With circuit network integration and blueprint duplication, you could absolutely make a true Von Neumann machine, making this objectively. You'd probably have to set copper and iron to Big, at least, and it would probably be horrendously wasteful resourcewise, but, it could definitely happen. The hardest part would be oil for lubricant and advanced circuits. I'm imagining a line oil wells, having themselves deleted and moved over a bit when they don't produce anything...hilarious and terrifying.
Maybe only make the expansion for resources in one direction and production in the orthogonal one, that would make it easier...oil to the left and copper/steel/coal to the right...

[justarandomgeek]

With circuit network integration and blueprint duplication, you could absolutely make a true Von Neumann machine, making this objectively. You'd probably have to set copper and iron to Big, at least, and it would probably be horrendously wasteful resourcewise, but, it could definitely happen. The hardest part would be oil for lubricant and advanced circuits. I'm imagining a line oil wells, having themselves deleted and moved over a bit when they don't produce anything...hilarious and terrifying.
Maybe only make the expansion for resources in one direction and production in the orthogonal one, that would make it easier...oil to the left and copper/steel/coal to the right...

Well, I was planning to make my memory array (for my CPU build) expand if written to within some range of it's current end

I've also been thinking about trying to hack up a radar to output information about the chunk it just scanned (coordinates and ore contents, for example), which combined with the location-combinator I've already made would allow a factory to locate ores, lay rails to them and extract them all automatically (if slowly, the CPU isn't very fast... around 3-5 IPS depending on which instructions)

Edit: Oh, and also thinking about how one might specify blueprints one entity at a time via circuits for a blueprint-writer, so that they could be compiled in place by the aforementioned combinator-based CPU. This is probably solidly in the realm of insanity though.