HELP! Blueprint recovery???

[Silvador]

I accidentally overwrote a blueprint with another blueprint. Is there a way to revert or recover the old one?

I made a blueprint for smelting stone into silicon ore. Later (today) I made a blueprint to smelt silicon ore into silicon 'ingots' and after naming the address realised I'd named my stone-to-ore blueprint the same thing, so now that blueprint is just GONE.

WHY IS THAT A THING?! Who the F thought it would be a good idea to not prompt the player if there is a conflict when saving a blueprint name/address????

Is the old blueprint just lost to the void, now, or is there some way I can recover it? Or do I have to remake the old stone-to-ore blueprint, again?

[Rekal]

All gone if you named them entirely the same. Unless you have the buildings placed down some where you can copy and create the blueprint again you're out of luck. The blueprint UI for saving and building blueprints is pretty bare bones right now.

On a side note, stone to silicon is a horribly wasteful process. It's possible you did yourself a favor by overwriting the blueprint.

[XLjedi]

Agree with @Rekal; you'd eventually have deleted blueprints to convert stone to silicon anyway. So, if you're going to lose one and take it as "lesson learned", that's a pretty good one to lose.

FWIW, I have purposefully replaced every single blueprint from my first playthru and either wiped them completely or dropped them into my "Obsolete" folder.

[Hikron]

What kind of blueprint did you create that you'd worry about accidentally overwriting it? 😅

The building factory tends to get complicated, but everything else is pretty straightforward to just recreate by first creating one assembler or smelter, then dragging out the conveyor to the desired length. Finally you just shift-click on the assembler/smelter and then drag a line along the conveyor to get duplicates of the building with inputs/outputs preconfigured.

[josmith7]

The game does (somewhat subtly) alert you to this.
If you put in a filename that already exists it adds orange text right by (IIRC just above; but it might be just below) the filename text entry box saying something like "Existing file will be overwritten".

Personally I prefer that to having to acknowledge some sort of pop-up "are you sure; really sure" confirmation dialog box every time I was updating an existing blueprint (and so was deliberately saving the tweaked or corrected version over the earlier one) -- something I do fairly frequently. (So frequently that if they did add a confirmation dialog I'd just end up hitting yes automatically; so it wouldn't help if I actually did try to overwrite the wrong file)


Now, the one time I accidently nuked a blueprint I was fortunate enough to be able to recover a copy from my PC backup service. But yeah, if you don't have a backup or some kind of file-system level file versioning you're probably out of luck -- you told it to overwrite a file, it indicated it was going to overwrite a file, and then it overwrote the file.

[josmith7]

Originally posted by Hikron:

What kind of blueprint did you create that you'd worry about accidentally overwriting it? 😅

The building factory tends to get complicated, but everything else is pretty straightforward to just recreate by first creating one assembler or smelter, then dragging out the conveyor to the desired length. Finally you just shift-click on the assembler/smelter and then drag a line along the conveyor to get duplicates of the building with inputs/outputs preconfigured.

That's not necessarily true. Sure, many people go for the simplicity of an ILS feeding a few columns of buildings making a single item. But it's also perfectly valid to make complicated, ratio, designs that produce all the components for the blueprint's final product from nothing but raw ores.

Those take a while to set up. But they're great for scaling because you're never chasing cascading bottlenecks back through your production chain as one buffer after another gets exhausted by your latest expansion. The only things to check are 1) is it getting enough power; 2) is it getting enough ores.


The extreme example I have of that is a 2250/min white science build that I can just fit onto 1/3rd of a planet. Thousands of buildings, tens of thousands of belts, dozens of ILS.
I'd be seriously annoyed if I had to rebuild that blueprint from scratch. :D

[Silvador]

Originally posted by josmith7:

The game does (somewhat subtly) alert you to this.
If you put in a filename that already exists it adds orange text right by (IIRC just above; but it might be just below) the filename text entry box saying something like "Existing file will be overwritten".

Personally I prefer that to having to acknowledge some sort of pop-up "are you sure; really sure" confirmation dialog box every time I was updating an existing blueprint (and so was deliberately saving the tweaked or corrected version over the earlier one) -- something I do fairly frequently. (So frequently that if they did add a confirmation dialog I'd just end up hitting yes automatically; so it wouldn't help if I actually did try to overwrite the wrong file)


Now, the one time I accidently nuked a blueprint I was fortunate enough to be able to recover a copy from my PC backup service. But yeah, if you don't have a backup or some kind of file-system level file versioning you're probably out of luck -- you told it to overwrite a file, it indicated it was going to overwrite a file, and then it overwrote the file.

I don't recall seeing such text. Maybe I didn't notice it?

As for the repeated dialog box when frequently updating blueprints, I can understand that point. Though, personally, it probably wouldn't be that much of an issue for me since, when updating a blueprint, the old one gets deleted before the new one gets saved.

Since I have to save a whole new blueprint to update an old one, I have to write in all that info again, in the three description boxes. Instead of manually writing all that out, though, I just copy/paste the old text to the new blueprint, saving the address for last. Once I've copied the address I hit delete on the blueprint and paste the address into the new one and save.

[Hikron]

Originally posted by josmith7:

Originally posted by Hikron:

What kind of blueprint did you create that you'd worry about accidentally overwriting it? 😅

The building factory tends to get complicated, but everything else is pretty straightforward to just recreate by first creating one assembler or smelter, then dragging out the conveyor to the desired length. Finally you just shift-click on the assembler/smelter and then drag a line along the conveyor to get duplicates of the building with inputs/outputs preconfigured.

That's not necessarily true. Sure, many people go for the simplicity of an ILS feeding a few columns of buildings making a single item. But it's also perfectly valid to make complicated, ratio, designs that produce all the components for the blueprint's final product from nothing but raw ores.

Those take a while to set up. But they're great for scaling because you're never chasing cascading bottlenecks back through your production chain as one buffer after another gets exhausted by your latest expansion. The only things to check are 1) is it getting enough power; 2) is it getting enough ores.


The extreme example I have of that is a 2250/min white science build that I can just fit onto 1/3rd of a planet. Thousands of buildings, tens of thousands of belts, dozens of ILS.
I'd be seriously annoyed if I had to rebuild that blueprint from scratch. :D

You're misinterpreting what I said, wherever your're doing Just In Time production of shipping everything seperately shouldn't really change anything, you're still fundamentally building things in rows .

take the basic Engines for example, you're gonna make 6x Iron, 3x Magnets, 1x Copper per fab, so once you've decided you want to produce "n" fabs, you're gonna create the base * "n" of the same kind, which effectively boils down to once again just dragging lines 😅

/edit: though i have to point out that just-in-time production is strictly speaking inferior unless you're super early-game, as the game engine will always get held up, so at least one of your fabs *will always* be idling *at some point*, no matter how exact you've calculated the ratio. So you're effectively loosing easy expansion with no upside. (if this issue didn't exist, just in time would be arguably more efficient however)

but i admit that esp. the cubes are very nice to chain, as they're all relational to each other and have such long production times that this issue doesn't really manifest - even more so as you're unlikely to be researching all the time.

[Rekal]

Originally posted by Hikron:

/edit: though i have to point out that just-in-time production is strictly speaking inferior unless you're super early-game, as the game engine will always get held up, so at least one of your fabs *will always* be idling *at some point*, no matter how exact you've calculated the ratio. So you're effectively loosing easy expansion with no upside.

I'm really confused about your logic here. I'm assuming just-in-time production is another name for building a factory to ratio? Ratio factories are inferior to what exactly? Over building capacity for intermediate components and shoving every single item into the logistics network?

What do you mean by "the game engine" being held up? Are you talking about late game frame rate and update slow downs? That's not going to effect a factory built to ratio any different than other factories. The entire game slows down evenly so it doesn't disrupt the factory balance at all.

There are only two times a factory step built to ratio will have idle buildings and even then it's only a brief time before the one building that idled starts up again. Those times are when initially starting up and saturating the belts which causes the last assembler in the next step to be temporarily starved of items, and when the belts are fully saturated which causes the first assembler in the last step to be temporarily idle. The number of idle buildings by design is much lower than any other type of factory setup you can create.

[josmith7]

Originally posted by Rekal:

There are only two times a factory step built to ratio will have idle buildings and even then it's only a brief time before the one building that idled starts up again. Those times are when initially starting up and saturating the belts which causes the last assembler in the next step to be temporarily starved of items, and when the belts are fully saturated which causes the first assembler in the last step to be temporarily idle. The number of idle buildings by design is much lower than any other type of factory setup you can create.

Though it's pretty hard to find a good match for desired size and perfect ratio - at least for a factory of any complexity.

So I end up settling for factories that are only approximately at ratio; where for scaling reasons I'll settle on a final output level that requires, say, 17.7 assemblers or some subcomponent. So that 18th assembler is either going to be backing up due to over-production or stalling 30% of the time waiting for material to arrive (depending on quite where it sits in the process).

I still prefer these integrated designs both because they're more interesting to create than endless identical columns, and because they simplify tracking down bottlenecks when you're expanding production. Because they're at ratio (or close enough) they can't cause shortfalls in anything other than power or raw ores.


So after expanding you're not constantly finding new delayed bottlenecks as one ILS buffer after another finally gives out and belatedly exposes that production of yet another subcomponent wasn't actually sufficient to support your expansion.

[Hikron]

Originally posted by Rekal:

I'm really confused about your logic here. I'm assuming just-in-time production is another name for building a factory to ratio?

basically, yes. Its a pretty estabilshed term. it means to acquire exactly the amount you need to produce. Thats what this boils down to, or do you disagree?

wikipedia explains it like this:

> Just-in-time manufacturing tries to match production to demand by only supplying goods which have been ordered and focuses on efficiency, productivity (with a commitment to continuous improvement) and reduction of "wastes" for the producer and supplier of goods

Originally posted by Rekal:

What do you mean by "the game engine" being held up? Are you talking about late game frame rate and update slow downs?

Thats another issue entirely. No, i mean that litterally one of your fabs will do nothing despite having a perfect ratio. thats why i gave a specific example with the basic engine (electric motor) recipee. If you scale that recipee up to something like ~5-6, one of your fabs will go idle for about a second on each production cycle if you're not adding buffers, which shouldn't be necessary if the ratios match exactly. And if you're adding buffers, why not use an ILS for that, as it'd also stack the products, which makes followup production easier to manage.

/edit: just to be clear though, this is a game. Everyone should do whatever they're getting the most enjoyment out of it. There is no need to particularly chase efficiency, as there are no competitors forcing you to do so. (nor will there ever, as that would kill most of the fun in the game)

[josmith7]

Originally posted by Hikron:

wherever your're doing Just In Time production of shipping everything seperately shouldn't really change anything, you're still fundamentally building things in rows .

There are rows in that compact mess, but squeezing it all into a compact footprint that can still fit into the 2, 4, or 6 horizontal copies within a planet's equatorial area forces some mixing of this.
https://steamcommunity.com/sharedfiles/filedetails/?id=3037066331

[Hikron]

Did you manage to get 1 mio sustained research with that? while i can see that you had fun creating it, which is great - its nonetheless not particularly effective.

[josmith7]

No, that's just my starter white research. It's only good for 60/min.

To hit 1 million hashes/sec sustained you need around 54,000/min.
I did that with 24 copies of my large science blueprint, which covers about 1/3rd of a planet.

(Due to it's larger scale the individual columns are bigger; and are mostly buffered by an ILS or PLS. And the rate you need to move smelted materials around forced me to use drones for those -- but the other intermediate materials are getting moved by belt within the blueprint; it's just now they tend to get moved from one PLS to another.)


I've also got a mid-sized version at just 360/min [2 high equatorially]; which doesn't need that kind of buffering or drone logistics.

I've also got 'from raw' blueprints for:
* 300/min proliferated antimatter fuel rods [6 high equatorially]
* 575/min proliferator Mk. III, 900/min warpers [6 high equatorially]
* 112.5/min small rockets [2 high equatorially]
(Though the fuel rods and rockets don't make their own proliferator -- probably should update them to do so)