Recursive Blueprints+

by FoxLBA

Automate blueprints to build a self-expanding factory. Fork of Recursive Blueprints with new small features: navigation through nested blueprint books, deployer logging and scanner upgrade.

Content
10 months ago
1.1
14.4K
Blueprints

i Ability to Deconstruct Area + Deployer

1 year, 3 days ago
(updated 1 year, 3 days ago)

I've found myself wanting to deconstruct an area and not even leaving the deployer there.
From the commands in the mod i've had trouble coming up with a solution for it that that require some kind of manual step. (If there is i'd love to learn it)
Would it be possible to either add a new command or an additional signal (the blueprint deployer -1) to indicate that we would like the deployer to be selected for deconstruction?

1 year, 3 days ago

I've found myself wanting to deconstruct an area and not even leaving the deployer there.

It doesn't have to be there in the first place, you can deconstruct areas anywhere with any deployer.

From the commands in the mod i've had trouble coming up with a solution for it that that require some kind of manual step. (If there is i'd love to learn it)

If the deployer is in the deconstruction area, isn't it marked for deconstruction anyways?

1 year, 3 days ago

It doesn't have to be there in the first place, you can deconstruct areas anywhere with any deployer.

True, but then again I have to manually input the location of deployers I want to deconstruct for that. I want to do that dinamically.
I'll give you a use case:
Blueprint [A] - Stuff necessary to build BP [B] (e.g. A trainstop for a one time train with the materials to setup BP [B]. Once the train arrives BP [B] is deplyoed and the station and the deployer are no longer need)
Blueprint [B] - Stuff that doesn't require BP [A] once its construction started.

If the deployer is in the deconstruction area, isn't it marked for deconstruction anyways?

Unfortunately it doesn't appear to work that way from my tests.
Area deconstruction requires deconstruction-planner signal [-1] to activate the command.
Deployer deconstruction requires deconstruction-planner signal [-2].
The deployer will not be deleted if it is in the area that will be marked for deconstruction.

1 year, 3 days ago

Unfortunately it doesn't appear to work that way from my tests.

Can a deployer remove another deployer with -1?

What if you have 2 deployers given the same signal? One is 1 tile south of the other. Height is 1 less, so their combined area is the original (overlapping except for top and bottom row). If they both get the command in 1 tick, then they should both be able to execute the command at the same time. However, the mod might be incorrectly processing deployers and give within-tick ordering behavior so that only one executes the command.

1 year, 3 days ago
(updated 1 year, 3 days ago)

Can a deployer remove another deployer with -1?

Yes it can. I used it in a self-moving landfill glider: the next copy cleans the previous, then it landfills the area, builds a trainstop, requests more landfill, places itself 128 tiles east, signals that copy to start working, turns itself off.
rinse repeat.

One could also signal back to a master-deployer that will clean up anywhere you like. Having the circuits for that is always nice.

1 year, 3 days ago
(updated 1 year, 3 days ago)

Can a deployer remove another deployer with -1?
Yeah, and seems to be a good soluton for vikenemesh's scenario, but for me it means i'm always going to depend on a second deployer which I will have to manually delete. In my scenario I don't want to create an infite cycle of blueprints.

What if you have 2 deployers given the same signal? One is 1 tile south of the other. Height is 1 less, so their combined area is the original (overlapping except for top and bottom row). If they both get the command in 1 tick, then they should both be able to execute the command at the same time. However, the mod might be incorrectly processing deployers and give within-tick ordering behavior so that only one executes the command.

This might be getting a bit to difficult for me to understand, sorry.
But let me see if I understand your proposal:
Have 3 deployers - A, B and C.
Deployer A is the one that I wanted to destroy innitially, and is configured to remove an unnecessary station.
B and C are set up in a way that they will both receive decontruction request for an area that includes the other 2 deployers.
Assuming that they are triggered at the same time (or that they can still process a deconstruction request despite being already marked for deconstruction) they should be able to deconstruct

I can even see a possibility of doing it with only 2 deployers... I'll run some tests when I have a chance.
Thanks for the tips btw.

EDIT:
Ok seems to work with 2 deployers. [A] deconstructs whatever it needed to deconstruct innitially + [B], and [B] deconstructs [A].
Its a decent workaround and I apreciate the help provided - i'll guess i'll use this for now.

But I still think adding a way to accomplish this result without relying on a second deployer is still interesting and a cleaner option.

1 year, 3 days ago

I never said anything about 3 deployers. Just 2.

Instead of having 1 deployer A doing the construction and decontruction, you add 1 more deployer B 1 tile south of the A deployer.

Only A receives construction requests. A and B receive deconstruction requests. That's it.
Basically there's a decider before B that only forwards signals (each out) on condition deconstruction planner == -1 or similar.
Also a combinator before A, just to delay it 1 tick and keep in sync with B. So it is just Each + 0 or Anything != 0 output each.

Now these 2 together work just like 1 deployer, but with the difference that deconstruction areas are 1 tile more in height (minimum 2 tiles) and deconstructions should deconstruct both deployers if they are in the area. Each is in both areas for the 2 deconstruction regions, but they remove each other. But you just think of them and use them as 1 deployer for the most part.

If you want to add +0 Y to deployer A and -1 Y to deployer B to have the deployers do the exact same thing and stay in sync then you could add that if that makes it easier for you.

New response