Schemacode: block replacement

[cardillan]

Two new keywords will be added to Schemacode: fill and replace. They can be specified before the at keyword:

schematic
    C: @copper-wall at (1, 1) * (4, 4)
    B: @memory-bank replace at (2, 2)
    T: @titanium-wall fill at (0, 0) * (6, 6)
end

this should create

T T T T T T
T C C C C T
T C B B C T
T C B B C T
T C C C C T
T T T T T T

• When a block is marked with replace, any earlier defined block which overlaps it - even partially - is completely removed from the schematic. It's label(s), if any, must not be reused and must not be referenced from any configuration.
• When a block is marked with fill, it is placed only on positions which do not overlap already defined blocks. Positions that would overlap a block are not used and labels assigned to those blocks are not created.
• When a region being placed is marked with rectangle or fill, all blocks instantiated by the region are handled as if declared with this flag.

Expected use-cases:

• replace allows making changes to block arrays created with blocks or regions, for example a factory constructed by repeating a region containing a basic unit may be customized on the input/output edges.
• fill allows creating rectangular walls around compact regions, or filling empty areas in the schematic with filler blocks (such as batteries, solar panels, walls).

Furthermore, @air will be accepted as a valid block name. There are two possible uses:

• When used with replace, @air can be used to completely remove blocks from the schematics.
• When used with a label, the label can be used to refer to the position of the block from configuration links (processor, nodes or bridges). Before, the only valid way to specify a position without an actual block was using absolute or relative coordinates.

Currently, any valid block type is accepted in Schemacode, even when the block type doesn't correspond to a buildable block. This is a bug; non-buildable block types will be refused.

[hiSandog]

The fill/replace semantics should probably be specified with overlap ordering examples before implementation. The tricky cases are partial overlap, labels attached to blocks that get replaced, and references from later configuration to a removed label. A small golden-test suite for fill-before-replace, replace-before-fill, and invalid label references would make the behavior predictable.

[cardillan]

@hiSandog Thanks for your comment. Would you find these features useful?

I'm already developing this together with #331, as it doesn't really make sense without regions.

• Partial overlaps: in the replace mode, all blocks overlapping the new block, even partially, are removed. In fill mode, the new blocks are only added when they do not overlap anything.
• Labels: a label attached to a replaced block is invalidated. A label attached to a filled block which doesn't get instantiated doesn't become valid
  • ETA: a label can be used to refer to a block to be replaced. After the replacement, the original block's labels can no longer be used.
• All fill/replace operations are done on a final layout of blocks. So, for example, if I have a region which contains fill blocks, the fill operation isn't applied when the region is constructed, but when all blocks are placed. Example:

schematic
    @phase-wall at (0, 0) * (2, 2)
    REG: region
        @copper-wall at (0, 0)
        @titanium-wall fill (0, 0) * (2, 2)
    end replace (1, 0)
end

produces

The titanium wall is only placed on tiles that are free in the entire schematics, not on tiles that are free within the REG region.

Similarly, if a region contain empty tiles, and is placed using replace, the original blocks at the empty tiles don't get erased. However, putting @air explicitly in the region does erase underlying blocks when using replace with the entire region.

Currently, the fill/replace is meant to touch up the entire schematic after constructing it using regions. It would probably make more intuitive sense to resolve all fill/replace operations within the region first, and then apply the region's fill/replace to all blocks within it. I may add this as a separate feature in the future (it would make a lot of sense if there was a support for reusable regions across schematics, but I'm not currently planning that).

A more complex example (which represents the expected use-cases):

schematic
    Segment = region
            @liquid-router       at (0, 0)
        p1: @pulse-conduit       at (0, 1) facing north
        u1: @cultivator          at (1, 0)
        c1: @titanium-conveyor   at (3, 0) facing north
        c2: @titanium-conveyor   at (3, 1) facing north
        u2: @cultivator          at (4, 0)
            @liquid-router       at (6, 0)
        p2: @pulse-conduit       at (6, 1) facing north
    end

    // S$ is a label array (see #311), producing region labels S1, S2, S3, S4, S5.
    // The label numbers are generated from bottom to top in this case. 
    S$: Segment at (0, 0) * (1, 5)

    @power-node          replace S1.c1 connected to S1.u*, S2.u*, S3.u*
    @power-node          replace S5.p1 connected to S5.u*, S4.u*, S3.u*
    @air                 replace S5.p2
    @plastanium-conveyor replace S5.c2 facing north
end