Because you know you need copy-paste :-) Clicking too much is boring.

It was already discussed in #848, but I agree that copy-paste is an essential feature and should be implemented.

Again, it won't be needed once you can nest ICs inside each other.

Will it have nesting limit (not default one, but ability to set it in config)? Because maliciously crafted ICs with nesting feature could cause a big performance problems and can yield inadequately large NBT tags that can consume a lot of storage space.

Also, infinite nesting can quickly become useless for complex circuits because you are still limited to 64 i/o pads.

Again, it won't be needed once you can nest ICs inside each other.

Wow! I like that idea!

Will it have nesting limit (not default one, but ability to set it in config)? Because maliciously crafted ICs with nesting feature can cause a big performance problems.

Maybe limit total circuit complexity instead? Or better, introduce several tiers of "raw chips" with different complexity limits, and of course make creative chip have no (or rather large) limit.
Because literally nesting ICs makes no sense, so I'd rather think of blueprint as just schematic, not as physical layout. And in this case, nested circuits are just an abstraction.

Hmm. Yes, current blueprint editor seems to be rather limited compared to real schematic capture software. It is rather Minecraft-ish I'd say :-)

If Computercraft support is added, Verilog would be rather convenient alternative, if a bit geeky.
If someone will also create CC mod that adds something like Tektronix 4014 vector graphics terminal, it would be possible to implement proper schematic capture software in CC, with whatever bells and whistles one may wish for.

Edit: It already exists! Well, more or less. It's called CCLights2. But it uses raster graphics. Maybe true vector graphics terminal would be more efficient in multiplayer.

My best guess is that it will be dynamically limited by how much CPU time it takes to calculate output. If the compiler is as efficient as planned, this limit will be very large.

I do not agree that blueprints are just schematics and do not represent physical layouts. If they would be like so, then MrTJP would not enforce size limits and enforce complexity limits instead. But now size is limited, so blueprints represent physical layout, not just abstract connection scheme.

(An ideal blueprint is a HDL definitions, but it's very hard to write efficient compiler for it that will compile these definitions into physical layout)

As for limiting CPU... I think that storage space limits also needed.

If they would be like so, then MrTJP would not enforce size limits and enforce complexity limits instead.

But allowing nested ICs lifts size limitation! You can fill the whole 64x64 IC with nested 16x16 ICs with bundled IO and effectively get IC with 868x868 useable area. And it is with only single nesting level allowed!

Yes, and it's some kind of contradiction. Also, 16x16 IC fiiled with 64x64 ICs is not equivalent to 868x868 IC, because you are limited in a number of connections per side.

Also you may think about nested ICs as upgrade of fabrication technology. But everything has a limit in real world.

In real world, it makes no sense to make some components in IC larger than others. The smaller chip is the cheaper it is to produce.
The only real-world thing I know about that uses something similar to "nested ICs" are small enclosed assemblies, like complete RF module that is soldered onto target PCB as a whole.

larger than others.

Smaller than others :) More advanced fab technology is more expensive. If you can fit your IC at 500 nm fab technloogy, you will not use 10 nm one because it is just too expensive.

Yeah, in nested ICs some parts are smaller than others. My comparasion was about increased size of this IC.

If you can fit your IC at 500 nm fab technloogy, you will not use 10 nm one because it is just too expensive.

If a part of circuit uses 10nm process, the whole circuit will use 10nm process. You can make some components bigger, but it will not reduce cost. In fact, it will increase cost, as less chips will fit on one wafer.

Also, I did suggest to add several "technology levels", with different complexity (i.e. gate count) limits per chip (i.e. 500nm vs 10nm technology).

Yes, but nested IC's definitely are not abstraction, because you must still think about layout and compactness of your circuit. As I mentioned, perfect but infeasible choice is HDL-like language.

Well, maybe "nested ICs" make sense. Kind of.
One may think of IC gate as dirt-cheap PCB, half a meter in size. And this PCB can have some actual ICs on it. Or even plug-in boards with ICs on them. In this case, nesting depth is quite limited.

The whole purpose of HDL languages (like Verilog) is to allow abstraction in IC design. They allow for modular designs and libraries of commonly used snippets (like registers, adders and whatnot).
Also, e.g. Verilog code can be easily compiled into FPGA rom, or into a photomask for photolitography. You don't have to think about physical realization much. In fact, FPGAs are commonly used to test and debug IC designs before first test samples are produced using photolitography.

You don't say? That's why I said 'perfect' - just because it's abstraction over IC design. I also said 'infeasible' because it's very hard to write compiler that will create optimal physical implementation.

Well, in this case you don't need to actually generate optimal physical implementation. You need to generate optimal simulation code. And its complexity / size is a reasonable approximation of how complex physical implementation would be.

No, it's bad to generate direct emulation code. Where are those beautiful wires and gates that IC's consist from? They all are gone! :)

Yes, you can relatively easy (compared to compilation to a physical layout) create compiled internal IC representation from HDL, but you can't see compiled IC as an actual logic.

Is anyone actually going to look at it? It would be cool, but almost completely useless in context of P:R. As I understand, compiled ICs are just compiled java classes plus maybe some metadata.
Also, I guess one would not see much on a 16x16 (or slightly more) texure that would show IC contents inside IC gate or IC printer.

As an external app, physical layout generator might be a cool thing to have.

but almost completely useless in context of P:R

You're right, HDL compiler does not worth it's implementation in context of P:R, as nobody will use it, I think. But some tools that will make IC design process easier for humans worth.

But some tools that will make IC design process easier for humans worth.

I did not quite get it. IC workbench GUI is already more or less WYSIWIG schematic capture utility. Nested ICs will be a kind of "abstract subassemblies". Final design is compiled into wire nets & gates representation, and that is then compiled into java class.

It might be reasonable to write a Verilog compiler in Computercraft and allow loading nets & gates representation directly into IC printer (as CC peripheral). Outside of Computercraft-like mod, it does not make much sense.

IC GUI lacking copy-paste functionality. Also I will appreciate tool that will replace colors of wires. Bundled IO pads should have color picker instead of endless clicking of ">".

I would personally argue that copy and paste does have a use. My current project is a 6 bit binary to decimal converter and most of the project is simply repeating the same pattern of the first 3 bits with a extra gate checking if the third three are correct. Just being able to select, copy, and paste, would save at least a hour off designing the circuit since most of it is busy work.

Additionally, if it's formatted as plain text, it would allow for sharing of IC designs via the web since text is universal. Also for external editors / visualizers / testers. (Heck, just make is a CSV, would it be efferent? No. But it would work.)

Also the nested IC (#1502) is still not a thing 5 or so years later. And while it may bring nice speed improvements, I don't really need it, or the miniaturization. Just a reduction in editor time.

It would also help when you find out that a entire section of a IC is a few squares off and you want to move it all over. Just Copy, delete and paste.