1)wallpaper. Recipe: any full block of your choice surrounded by 8 paper. This item would function like maps placed in item frames, but would simply apply the block texture instead of the part of the world shown in the map. Tile entities would somehow result in some sort of patterned variation based on that item texture, but I'm not sure if such a thing would be possible or viable (ie, it could be done but would be too laggy).
2)2-dimensional redstoning. Any redstone item (dust, block, repeater, comparator, etc) wrapped in 8 map items. The item retains its original redstone functionality, but this would be limited to the 2-dimensional space created by the item frames. Item frames that have a 2d redstone item applied will no longer have 3d redstone functionality, being unable to power blocks they're attached to. The exception to this would be a new item (tentatively, a conduit wrapped in 8 maps) that specifically interfaces 2d and 3d redstone signals. A second new item, an item frame wrapped in 8 maps, would form a placeholder frame that allows for powerable blocks to be used in monostable circuits and similar constructs, allowing the 2d pistons to move blocks in and out of such spaces within the 2d area.
3)quantum tunnels. Crafted with a hopper surrounded by 2 beacons above and below and 6 ender pearls along the sides, producing a pair of tunnels. To use these, separate two of them into their own item stack and right-click to pair them together (you can do this with any 2 tunnels or you can rightclick one onto an existing tunnel placed in the world to replace the pairing it had). These items are not inventories nor do they interact with inventories in any way (ie, they are not wireless hoppers). What they do is allow the immediate translocational movement of items, liquids, redstone signal, and entities (mobs, players) from one place to another wirelessly. Liquids will still only flow a max of either 8 or 4 blocks, items will still have momentum and vector, entities will still face the way they were travelling and would take fall damage as appropriate, and redstone signal would still decay and power the appropriate blocks and suchlike.
1)I'm not sure how it would be a problem to code, unless you're referring to the lag aspect that would occur from a large amount of tile entities. Based on the way I assume that blocks themselves are assigned texture data, though, perhaps we could entirely avoid all use of tile entities for this idea and have the wallpaper item edit the block data directly, freeing up that block space in the process. I don't know anything about the internals of block class data, however, so I'll leave this out of the OP until I get more info on that.
2)keep in mind that this is a functional system of redstone that operates in a mass grouping of tile entities (item frames). Even if you just used this as a blackboard system to display examples, that's essentially two sources of lag you're dealing with (redstone lag and tile entity lag). I don't think we should make this relatively cheap because of that, but perhaps the map recipe could be refactored to produce more per recipe as a compromise. Maybe this could be coupled with a "debug stick" sort of item that lets you draw out the functionality of the redstone
3)hmm, I wonder...if we could target a block's data directly like in #1, could we potentially even replace it with a whole new entity? Might be pretty interesting to texture a block with item frames, giving us an in-block way to use item frames AS item frames so that liquids and other issues just don't matter (ie, they're inset to the block).
1)wallpaper. Recipe: any full block of your choice surrounded by 8 paper. This item would function like maps placed in item frames, but would simply apply the block texture instead of the part of the world shown in the map. Tile entities would somehow result in some sort of patterned variation based on that item texture, but I'm not sure if such a thing would be possible or viable (ie, it could be done but would be too laggy).
2)2-dimensional redstoning. Any redstone item (dust, block, repeater, comparator, etc) wrapped in 8 map items. The item retains its original redstone functionality, but this would be limited to the 2-dimensional space created by the item frames. Item frames that have a 2d redstone item applied will no longer have 3d redstone functionality, being unable to power blocks they're attached to. The exception to this would be a new item (tentatively, a conduit wrapped in 8 maps) that specifically interfaces 2d and 3d redstone signals. A second new item, an item frame wrapped in 8 maps, would form a placeholder frame that allows for powerable blocks to be used in monostable circuits and similar constructs, allowing the 2d pistons to move blocks in and out of such spaces within the 2d area.
3)quantum tunnels. Crafted with a hopper surrounded by 2 beacons above and below and 6 ender pearls along the sides, producing a pair of tunnels. To use these, separate two of them into their own item stack and right-click to pair them together (you can do this with any 2 tunnels or you can rightclick one onto an existing tunnel placed in the world to replace the pairing it had). These items are not inventories nor do they interact with inventories in any way (ie, they are not wireless hoppers). What they do is allow the immediate translocational movement of items, liquids, redstone signal, and entities (mobs, players) from one place to another wirelessly. Liquids will still only flow a max of either 8 or 4 blocks, items will still have momentum and vector, entities will still face the way they were travelling and would take fall damage as appropriate, and redstone signal would still decay and power the appropriate blocks and suchlike.
1) I suppose people would find uses for it, but it could be a problem to code,.
2) Yes please. A pretty good and sensible idea for 2-D redstone. I think the recipes are a bit too expensive, though.
3) Given how item frames function, I don't think this is a good way to implement that concept.
So, while the suggestion might need tweaking, it's still a pretty good one. Partial Support.
I'm a Whovian squid who likes drawing.
I'm also quite nerdy with an interest in game developing and the concept of a fourth spatial dimension.
All hail chickens.
1)I'm not sure how it would be a problem to code, unless you're referring to the lag aspect that would occur from a large amount of tile entities. Based on the way I assume that blocks themselves are assigned texture data, though, perhaps we could entirely avoid all use of tile entities for this idea and have the wallpaper item edit the block data directly, freeing up that block space in the process. I don't know anything about the internals of block class data, however, so I'll leave this out of the OP until I get more info on that.
2)keep in mind that this is a functional system of redstone that operates in a mass grouping of tile entities (item frames). Even if you just used this as a blackboard system to display examples, that's essentially two sources of lag you're dealing with (redstone lag and tile entity lag). I don't think we should make this relatively cheap because of that, but perhaps the map recipe could be refactored to produce more per recipe as a compromise. Maybe this could be coupled with a "debug stick" sort of item that lets you draw out the functionality of the redstone
3)hmm, I wonder...if we could target a block's data directly like in #1, could we potentially even replace it with a whole new entity? Might be pretty interesting to texture a block with item frames, giving us an in-block way to use item frames AS item frames so that liquids and other issues just don't matter (ie, they're inset to the block).
Some alternate recipe proposals:
2D-3D interface: Conduit wrapped in paper.
Placeholder: Item frame wrapped in paper.
I just think using maps is a bit expensive. Like having a sword made of diamond blocks.
I'm a Whovian squid who likes drawing.
I'm also quite nerdy with an interest in game developing and the concept of a fourth spatial dimension.
All hail chickens.