I was watching a recording of the Redstone panel from Minecon and was interested in one of the questions around new ideas for Redstone. One proposal was to support one of the existing mods that adds new Redstone-related blocks/tiles for existing Redstone contraptions like logic gates, latches, etc. The general consensus from the panel was that those kinds of additions would actually detract from the fun of the game, that you learn more and enjoy the game more when you have to build these things yourself.
While MCX360 still has a lot to catch up on when it comes to Redstone (hoppers, droppers, latched repeaters, comparators, etc.), there's an opportunity to differentiate the Xbox 360 (or Xbox One) versions through new capabilities that don't yet exist on the PC. My suggestion would be to add a new craftable item called a "Miniaturizer".
While I haven't given much thought to the crafting recipe for the "Miniaturizer" itself, what's more interesting are the mechanics of the device. The purpose of the "Miniaturizer" would be to point it at a redstone contraption you have already made (such as a logic gate, clock, etc). If the correct requirements are met, you would spend XP to "miniaturize" the contraption into a block (the larger the contraption, the more XP is required).
The requirements for the contraption are the following:
The contraption must be enclosed in an Iron Block wireframe that has uniform dimensions on all sides. This sets a resource constraint when devising contraptions in Survival. This also helps define the boundary of the contraption for the Miniaturizer.
The contraption cannot enclose any unbreakable block (e.g. bedrock).
For a contraption to support input or output, a suitable block must be placed in the wall of any of the six sides of the contraption (such as a colored wool). It doesn't matter where the wool is placed, or how many are placed. When the miniaturized block is powered from that side, all wool blocks on that side are provided power. If the contraption in a miniaturized block supplies power to one or more wool blocks on a single side, the power is transmitted only from that side of the miniaturized block (using the greatest signal strength sent from through any of those blocks).
The miniaturized block would have a texture based on the contents of the miniaturized block at the time of miniaturization (animating the entire block might be too resource intensive, so a snapshot could be used).
When miniaturizing a contraption, the XP cost for miniaturization would be calculated based on the number of blocks or tiles included in the contraption.
Miniaturized contraptions would exist in an always loaded chunk. There would also be a limit to the number of miniaturized contraptions allowed in a world. Destroying a miniaturized block (drop in lava or void, its entity despawns, or destroyed by explosion) would reclaim the space of the contraption from the contraption chunk.
Miniaturized contraptions can be restored to normal size for a small XP cost as long as the block is placed in a flat area large enough for the original contraption. Re-miniaturizing the contraption would incur an XP cost just as it did the first time.
Miniaturized blocks can be placed by a player or broken and picked up as an entity just like a repeater or piston.
Pistons cannot push a block past the inside of the wall of the contraption when miniaturized, nor can they pull a block out from the wall.
Dispensers can be positioned in the wall of a contraption, if they are activated they will dispense out from the side they are placed.
Once miniaturized, any air gaps in the iron block wireframe of the contraption act as if they are filled with a transparent block, like glass, for the purposes of any blocks affected by gravity (sand, gravel, dragon's egg, minecarts), running water or lava, or entities.
If hoppers/droppers are added to the game, they could be placed in the walls of the contraption and act directionally just like a dispenser.
A contraption cannot be miniaturized if a player is inside of its boundary (no using the miniaturizer to capture players).
I'm sure there are a lot of other game rules and logic that would have to be taken into account, but there's a lot of interesting value in a feature like this. Smaller redstone contraptions like logic gates, pulse limiters, edge detectors, etc. could be made to fit in much smaller spaces and allow for more interesting redstone based builds. This could appeal both to those who want new and more interesting redstone devices for use in their builds as well as those that prefer that those devices be built by hand. The concept could apply to a number of other uses, such as crafting custom styled blocks (using the texture snapshot capability) or creating a portable shelter (drop the block and restore it to size, spend XP to shrink it down and carry it with you).
Something like this could add a whole new (pocket?) dimension to the game.
I can see a LOT of logistical and programmatic problems with trying to implement this idea.
You are taking (effectively) an unknown redstone contraption of an unknown size and with an unstructured design method, and relying on the program to try and interpret how the redstone contraption really works, and moving all those unknown algorithms reliably into a 1 block space.
So basically, you are asking 4J to build a free form computer psuedo-compiler and interpreter... to work inside Minecraft.
I'm not saying that it couldn't work... just that it seems to bring this to a new level of complexity.
I suppose the program could save the layout in a 'pseudo-space' that experiences the same day/night weather as the miniaturized circuit block, and then executes the inputs and generates outputs on the normal redstone cycle as if it was built fully in normal space.
But I can see this getting multi-layered, where miniaturized objects are put inside miniaturized objects, etc. and I'm not sure what effect that would have on long term game play.
As you your fenced design above, instead of a wool block, can I suggest having one point on each side tied to a specific input/output.
The faces that have I/O could just have a red dot on a stone face, if a dispenser faces out, then you have the front of the dispenser for that face of the block, if a hopper is on top, then the top surface graphic matches the hopper input. If there is a Hopper on the bottom, then the bottom matches the Hopper output. Solar Panel, Dropper, etc. If a Repeater or torch attached to a block is the termination and a clear Input or Output facing can be determined, then that side could be de-marked in redstone dust with an I or an O on that face (or a plus '+' or minus '-')
For this to work, I think a whole chunk of 'puedo-space' needs to be allocated to RAM, the limit for miniaturization would have to fit at least within a 16 x 16 x 16 space (this allows for 16 different block patterns), or 8 x 8 x 8 space (allowing for 128 different block patterns).
It might need to treat each of these block patterns as a subroutine (if as you create the pattern, you can now make more of the same type, as there may be multiple calls to the same logic pattern at different times and under different conditions), so it would need to use stack logic to store the state during redstone ticks, and restore it as needed.
I'm sensing a lot of potential memory constraint problems from this idea, not sure it is feasible, nor sure if it is in-line with the spirit of the game itself, as much as I like the overall concept.
If I visualized this in terms of software design patterns, this follows a composite pattern (as much of Minecraft itself does I'm sure). Yes I'm sure there are a number of unhandled issues with this design, but as I'm not familiar with the internals of the Minecraft codebase I can only guess as to what those might be.
I originally did envision this as having a single input or output on any face of the block, but though having multiple inputs or outputs could be useful. Simpler usually is better however, so allowing a contraption to only have a single input or output on any face would likely be easier to implement (a 3-dimensional block visitor that could perform rule verification when minified would establish that the contraption meets all requirements (dimensions, inputs, outputs, clearances for things like pistons). For things like day/night, I would calculate the light level and direction that would hit each side of the miniaturized block and interpret those calculations as the same light level and direction for each space in the contraption scaffolding (as this would have an effect on things like day/night sensors inside the contraption if they are ever implemented).
As a further rule simplification, you could restrict the ability to miniaturize a contraption that contains a miniaturized contraption (reducing the need to perform additional jumps to other chunks of memory for other contraptions when evaluating the redstone).
The PC version already has a "poor-man's" version of subroutine execution via command blocks, which I don't see the 360 getting any time soon (unless they want to build a visual UI for programming a command block or require everyone use chatpads or keyboards).
I could see how aligning the size of the contraption to a two's-compliment chunk of memory for efficiency, though arbitrarily sized contraptions could be padded to an appropriate size.
Another possibility would be efficiently encoding the contraption into an intermediate language/bytecode. By not providing any animation of the interior of the minified contraption (except for possible animation of the texture applied to any surface of the block based on the kind of input/output), they could reparse the contraption into a syntax tree or workflow. Compiling it to a custom IL/bytecode as a set of instructions that can be executed via an interpreter. Yes this is likely a very complicated bit of engineering for a single feature in the game, but there is already the need for a parser/interpreter in the PC version for command blocks. Being an engineer, I could imagine this as a three-dimensional programming syntax (redstone and hoppers/droppers/dispensers as input, output, and in/out (ref) parameters, chests as variables (or vectors), comparators as control-flow, common redstone contraptions like logic gates and latches re-encoded as logical operations and variables) and an abstract syntax tree that encompassed the kinds of blocks used in the program. You could use scheduling and coroutines (or a similar model) for scheduling executions based on in-game redstone ticks. Storing the bytecode and some block metadata could be an efficient model for storage and runtime execution that could increase efficiency.
If this were the case, supporting multiple nested contraptions would be similar to defining addresses for other subroutines that are also efficiently encoded as IL.
This is all very pie-in-the-sky wishful thinking on the part of someone who really enjoys tinkering with redstone, and spends a lot of time tinkering with compilers, transpilers, interpreters, and dynamic languages. It may likely never be done by 4J or Mojang, but it definitely sounds cool.
Another possibility would be efficiently encoding the contraption into an intermediate language/bytecode. By not providing any animation of the interior of the minified contraption (except for possible animation of the texture applied to any surface of the block based on the kind of input/output), they could reparse the contraption into a syntax tree or workflow. Compiling it to a custom IL/bytecode as a set of instructions that can be executed via an interpreter. Yes this is likely a very complicated bit of engineering for a single feature in the game, but there is already the need for a parser/interpreter in the PC version for command blocks. Being an engineer, I could imagine this as a three-dimensional programming syntax (redstone and hoppers/droppers/dispensers as input, output, and in/out (ref) parameters, chests as variables (or vectors), comparators as control-flow, common redstone contraptions like logic gates and latches re-encoded as logical operations and variables) and an abstract syntax tree that encompassed the kinds of blocks used in the program. You could use scheduling and coroutines (or a similar model) for scheduling executions based on in-game redstone ticks. Storing the bytecode and some block metadata could be an efficient model for storage and runtime execution that could increase efficiency.
I was trying to use the existing game mechanics to avoid having to build an internal 3 dimensional psuedo-compiler/interpreter just for one aspect of the game. If you are asking for them to work on something that converts your random redstone contraption into byte-code to be interpreted by the game on the fly, then I doubt that this would ever see the light of day.
IMO, you are asking WAY too much if you are asking for that level of analysis. Using the method I described above, it still interprets the redstone circuitry AS the player set it up, using existing in game mechanics rather than relying on a programmatic interpretation, psuedo-compilation to bytecode, and interpreted again on the fly...
IMO, you are asking WAY too much if you are asking for that level of analysis. Using the method I described above, it still interprets the redstone circuitry AS the player set it up, using existing in game mechanics rather than relying on a programmatic interpretation, psuedo-compilation to bytecode, and interpreted again on the fly...
I realize that, the thought about leveraging something like bytecode was more to consider the possibilities for redstone in general. I've often heard about complex redstone contraptions on PC and console causing lag (although there are a lot of other reasons for that as well), and considered this as a possible remediation, as well as addressing things like storage space and memory usage.
I concur this may never be implemented, but it does provide some food for thought. Similar concepts can be built on the PC today via creative through command blocks and scoreboard, building contraptions in an always loaded chunk and using scoreboard to communicate the state of remote wiring and computation ("wireless redstone"). The primary focus of this concept is really to formalize this capability in a way that could be used without command blocks on a platform like the Xbox.
Here's a simpler concept with a similar footprint. An "ender block" (borrowing loosely from the concept of an "ender chest") that acts like a wireless input/output for a redstone contraption. Two "ender blocks" could be paired in some way (entering a unique name that is tied to the player). Any redstone supplied to one "ender block" is transmitted by the other "ender block". A dispenser that dispenses through one "ender block" has its contents dispensed from the other "ender block". A hopper input attached to one "ender block" would cause the other "ender block" to act as a hopper on the face opposite the one connected, while a hopper beneath an "ender block" would cause the other "ender block" to act as a hopper input on the top. "Ender blocks" could be directional (a texture that indicates which direction is the input and output, or different symbols or indicators on each face of the block).
Given that concept, you could build a contraption in an always loaded chunk (for example, the spawn chunk), and have an official way to do "wireless redstone" in survival. It has all the same capabilities as the miniaturizer above, but less complexity with regards to storage.
There are a number of downsides to something like this too. Either the player would have to know where to find an always loaded chunk, or anywhere an "ender block" exists would have to be always loaded (which could add to memory pressure and decrease performance). It also removes the XP cost that the miniaturizer would have enforced, and reduces some of the possible other uses of the feature (i.e. dropping a "pop-up" miniaturized base in a sufficiently large flat space). There are plenty of other issues, I'm sure.
All of this is conjecture and hopefully some food for thought. I've really come to enjoy Minecraft and decided if I was to suggest something I might as well "go big" :). I'm always happy to put in my $0.02 for other features from the PC I'd love to see sooner rather than later, but adding to that conversation is not likely to have as much of an impact as trying to invent or innovate a new concept. I appreciate the feedback and analysis, so thanks for the input.
I realize that, the thought about leveraging something like bytecode was more to consider the possibilities for redstone in general. I've often heard about complex redstone contraptions on PC and console causing lag (although there are a lot of other reasons for that as well), and considered this as a possible remediation, as well as addressing things like storage space and memory usage.
I concur this may never be implemented, but it does provide some food for thought. Similar concepts can be built on the PC today via creative through command blocks and scoreboard, building contraptions in an always loaded chunk and using scoreboard to communicate the state of remote wiring and computation ("wireless redstone"). The primary focus of this concept is really to formalize this capability in a way that could be used without command blocks on a platform like the Xbox.
Here's a simpler concept with a similar footprint. An "ender block" (borrowing loosely from the concept of an "ender chest") that acts like a wireless input/output for a redstone contraption. Two "ender blocks" could be paired in some way (entering a unique name that is tied to the player). Any redstone supplied to one "ender block" is transmitted by the other "ender block". A dispenser that dispenses through one "ender block" has its contents dispensed from the other "ender block". A hopper input attached to one "ender block" would cause the other "ender block" to act as a hopper on the face opposite the one connected, while a hopper beneath an "ender block" would cause the other "ender block" to act as a hopper input on the top. "Ender blocks" could be directional (a texture that indicates which direction is the input and output, or different symbols or indicators on each face of the block).
Given that concept, you could build a contraption in an always loaded chunk (for example, the spawn chunk), and have an official way to do "wireless redstone" in survival. It has all the same capabilities as the miniaturizer above, but less complexity with regards to storage.
There are a number of downsides to something like this too. Either the player would have to know where to find an always loaded chunk, or anywhere an "ender block" exists would have to be always loaded (which could add to memory pressure and decrease performance). It also removes the XP cost that the miniaturizer would have enforced, and reduces some of the possible other uses of the feature (i.e. dropping a "pop-up" miniaturized base in a sufficiently large flat space). There are plenty of other issues, I'm sure.
All of this is conjecture and hopefully some food for thought. I've really come to enjoy Minecraft and decided if I was to suggest something I might as well "go big" . I'm always happy to put in my $0.02 for other features from the PC I'd love to see sooner rather than later, but adding to that conversation is not likely to have as much of an impact as trying to invent or innovate a new concept. I appreciate the feedback and analysis, so thanks for the input.
Ohhh.... I like your idea of the enderblock. But I would want to be able to us multiple different communication paths... how would you link/pair one enderblock to another enderblock, or would they all just pair together for each player?
Anyway, a lot of the problems with redstone are lag related due to rendering issues. (ie. lighting rendering can impact redstone in dark areas, crossing chunk boundaries can cause lag issues since each chunk is rendered separately, etc.) the advantage of using the virtual chunk space for the redstone 'miniaturization' is that it maintains the redstone structure contained within 1 chunk that doesn't have to be rendered at all.
You do, unfortunately, have to cross over a chunk space when entering the miniaturization, and when leaving miniaturization, but other than that, and once it is first used, it could be one of the always loaded chunks... if RAM space could be dedicated to it in game.
Ohhh.... I like your idea of the enderblock. But I would want to be able to us multiple different communication paths... how would you link/pair one enderblock to another enderblock, or would they all just pair together for each player?
One possibility is simple a custom UI like for signs (on pc or 360) or command blocks/anvil (on pc) where you give it a name. Two ender blocks with the same name become bonded, but you can't use a name more than twice (for each side) as long as either block still exists as either a block or an entity.
On the miniaturizer side, I imagined the in-game mechanics of using the miniaturizer to be similar to using a flint/steel (crafted) on a frame of obsidian blocks (placed) to make a nether portal, with the addition of a prompt that informs you the XP cost and (if you have enough XP) lets you craft the miniaturized block. In this case the overall game mechanic is a familiar one.
You do, unfortunately, have to cross over a chunk space when entering the miniaturization, and when leaving miniaturization, but other than that, and once it is first used, it could be one of the always loaded chunks... if RAM space could be dedicated to it in game.
I never really envisioned the player crossing from the normal world into the miniaturized version (which would introduce another world similar to the Nether or End), but rather using the "miniaturizer" to send a framed contraption to that space, or using the "miniaturizer" on the block that was created to restore it back to original size (which would only work if there was enough space in X/Y/Z for the full-size contraption). This would mean the player doesn't need to physically go to the chunk where the contraption exists, but rather just moves the blocks to the current chunk.
I never really envisioned the player crossing from the normal world into the miniaturized version (which would introduce another world similar to the Nether or End), but rather using the "miniaturizer" to send a framed contraption to that space, or using the "miniaturizer" on the block that was created to restore it back to original size (which would only work if there was enough space in X/Y/Z for the full-size contraption). This would mean the player doesn't need to physically go to the chunk where the contraption exists, but rather just moves the blocks to the current chunk.
Maybe I should have chosen my words a little better, not 'you' as in the player, but the more abstract 'you' as in the redstone circuitry itself. Once the redstone current hits the block, (under the way I had proposed above) that would cause a change in chunk space to finish computing out the next step in the circuitry, and the redstone current would cross over chunk spaces once again once it returns to normal space.
This could cause up to two instances that might meet a little bit of lag, but if this is an always loaded/never rendered chunk, it shouldn't be a noticeable issue.
For Minecraft 1.5.2 with Forge I have managed to get work these three together, though it was not easy with new version launcher.
LittleBlocks works buggy with RedLogic, I could not remove LittleBlocks block and after an exit, part of my circuits had dissapeared. Also for version 1.5.2 you can not copy littleblocks.
As for me, I was actually thinking about kind of circuit board item in minecraft. Player can embed part or whole his redstone (or RedLogic, Project Red) circuit blocks into this board. And it really should be converted to java bytecode and heavily optimized. When placed in world, it fits into one block but works much much faster. When I say "much faster", I mean really fast, you know, today we have mpeg codec and nes emulators written on javascript.
Why is this important mod? It has great potential for discovering new ways of making programs projected over 3d world. The majority of today programming languages are declarative, there just should be another interesting way! Just imagine, a program would become halls and rooms and programmers could work on it together like virtual mechanics. Also it might be much better for parallel processing, minecraft community is huge, and who knows, what can we find.
In perspective, these boards can be placed into mobs to control their movements and actions.
Boards should be also easy copyable and shareable among players and be reuseable in other circuits and boards to keep modular principle, so these modules could evolve and be reused in community.
It is difficult to predict what result it would give. But if we look on real circuit boards history, we can see some elements were grouped into processors and memory modules. And these processors are programmed declaratively, so we back to the point we started. So there is something to think about.
Well... I really like those ideas, but as I said before... they would require way too much in the way of system resources for the xBox 360... and this is a xBox 360 specific suggestion forum.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
While MCX360 still has a lot to catch up on when it comes to Redstone (hoppers, droppers, latched repeaters, comparators, etc.), there's an opportunity to differentiate the Xbox 360 (or Xbox One) versions through new capabilities that don't yet exist on the PC. My suggestion would be to add a new craftable item called a "Miniaturizer".
While I haven't given much thought to the crafting recipe for the "Miniaturizer" itself, what's more interesting are the mechanics of the device. The purpose of the "Miniaturizer" would be to point it at a redstone contraption you have already made (such as a logic gate, clock, etc). If the correct requirements are met, you would spend XP to "miniaturize" the contraption into a block (the larger the contraption, the more XP is required).
The requirements for the contraption are the following:
I'm sure there are a lot of other game rules and logic that would have to be taken into account, but there's a lot of interesting value in a feature like this. Smaller redstone contraptions like logic gates, pulse limiters, edge detectors, etc. could be made to fit in much smaller spaces and allow for more interesting redstone based builds. This could appeal both to those who want new and more interesting redstone devices for use in their builds as well as those that prefer that those devices be built by hand. The concept could apply to a number of other uses, such as crafting custom styled blocks (using the texture snapshot capability) or creating a portable shelter (drop the block and restore it to size, spend XP to shrink it down and carry it with you).
Something like this could add a whole new (pocket?) dimension to the game.
Thoughts?
You are taking (effectively) an unknown redstone contraption of an unknown size and with an unstructured design method, and relying on the program to try and interpret how the redstone contraption really works, and moving all those unknown algorithms reliably into a 1 block space.
So basically, you are asking 4J to build a free form computer psuedo-compiler and interpreter... to work inside Minecraft.
I'm not saying that it couldn't work... just that it seems to bring this to a new level of complexity.
I suppose the program could save the layout in a 'pseudo-space' that experiences the same day/night weather as the miniaturized circuit block, and then executes the inputs and generates outputs on the normal redstone cycle as if it was built fully in normal space.
But I can see this getting multi-layered, where miniaturized objects are put inside miniaturized objects, etc. and I'm not sure what effect that would have on long term game play.
As you your fenced design above, instead of a wool block, can I suggest having one point on each side tied to a specific input/output.
The faces that have I/O could just have a red dot on a stone face, if a dispenser faces out, then you have the front of the dispenser for that face of the block, if a hopper is on top, then the top surface graphic matches the hopper input. If there is a Hopper on the bottom, then the bottom matches the Hopper output. Solar Panel, Dropper, etc. If a Repeater or torch attached to a block is the termination and a clear Input or Output facing can be determined, then that side could be de-marked in redstone dust with an I or an O on that face (or a plus '+' or minus '-')
For this to work, I think a whole chunk of 'puedo-space' needs to be allocated to RAM, the limit for miniaturization would have to fit at least within a 16 x 16 x 16 space (this allows for 16 different block patterns), or 8 x 8 x 8 space (allowing for 128 different block patterns).
It might need to treat each of these block patterns as a subroutine (if as you create the pattern, you can now make more of the same type, as there may be multiple calls to the same logic pattern at different times and under different conditions), so it would need to use stack logic to store the state during redstone ticks, and restore it as needed.
I'm sensing a lot of potential memory constraint problems from this idea, not sure it is feasible, nor sure if it is in-line with the spirit of the game itself, as much as I like the overall concept.
I originally did envision this as having a single input or output on any face of the block, but though having multiple inputs or outputs could be useful. Simpler usually is better however, so allowing a contraption to only have a single input or output on any face would likely be easier to implement (a 3-dimensional block visitor that could perform rule verification when minified would establish that the contraption meets all requirements (dimensions, inputs, outputs, clearances for things like pistons). For things like day/night, I would calculate the light level and direction that would hit each side of the miniaturized block and interpret those calculations as the same light level and direction for each space in the contraption scaffolding (as this would have an effect on things like day/night sensors inside the contraption if they are ever implemented).
As a further rule simplification, you could restrict the ability to miniaturize a contraption that contains a miniaturized contraption (reducing the need to perform additional jumps to other chunks of memory for other contraptions when evaluating the redstone).
The PC version already has a "poor-man's" version of subroutine execution via command blocks, which I don't see the 360 getting any time soon (unless they want to build a visual UI for programming a command block or require everyone use chatpads or keyboards).
I could see how aligning the size of the contraption to a two's-compliment chunk of memory for efficiency, though arbitrarily sized contraptions could be padded to an appropriate size.
Another possibility would be efficiently encoding the contraption into an intermediate language/bytecode. By not providing any animation of the interior of the minified contraption (except for possible animation of the texture applied to any surface of the block based on the kind of input/output), they could reparse the contraption into a syntax tree or workflow. Compiling it to a custom IL/bytecode as a set of instructions that can be executed via an interpreter. Yes this is likely a very complicated bit of engineering for a single feature in the game, but there is already the need for a parser/interpreter in the PC version for command blocks. Being an engineer, I could imagine this as a three-dimensional programming syntax (redstone and hoppers/droppers/dispensers as input, output, and in/out (ref) parameters, chests as variables (or vectors), comparators as control-flow, common redstone contraptions like logic gates and latches re-encoded as logical operations and variables) and an abstract syntax tree that encompassed the kinds of blocks used in the program. You could use scheduling and coroutines (or a similar model) for scheduling executions based on in-game redstone ticks. Storing the bytecode and some block metadata could be an efficient model for storage and runtime execution that could increase efficiency.
If this were the case, supporting multiple nested contraptions would be similar to defining addresses for other subroutines that are also efficiently encoded as IL.
This is all very pie-in-the-sky wishful thinking on the part of someone who really enjoys tinkering with redstone, and spends a lot of time tinkering with compilers, transpilers, interpreters, and dynamic languages. It may likely never be done by 4J or Mojang, but it definitely sounds cool.
I was trying to use the existing game mechanics to avoid having to build an internal 3 dimensional psuedo-compiler/interpreter just for one aspect of the game. If you are asking for them to work on something that converts your random redstone contraption into byte-code to be interpreted by the game on the fly, then I doubt that this would ever see the light of day.
IMO, you are asking WAY too much if you are asking for that level of analysis. Using the method I described above, it still interprets the redstone circuitry AS the player set it up, using existing in game mechanics rather than relying on a programmatic interpretation, psuedo-compilation to bytecode, and interpreted again on the fly...
I realize that, the thought about leveraging something like bytecode was more to consider the possibilities for redstone in general. I've often heard about complex redstone contraptions on PC and console causing lag (although there are a lot of other reasons for that as well), and considered this as a possible remediation, as well as addressing things like storage space and memory usage.
I concur this may never be implemented, but it does provide some food for thought. Similar concepts can be built on the PC today via creative through command blocks and scoreboard, building contraptions in an always loaded chunk and using scoreboard to communicate the state of remote wiring and computation ("wireless redstone"). The primary focus of this concept is really to formalize this capability in a way that could be used without command blocks on a platform like the Xbox.
Here's a simpler concept with a similar footprint. An "ender block" (borrowing loosely from the concept of an "ender chest") that acts like a wireless input/output for a redstone contraption. Two "ender blocks" could be paired in some way (entering a unique name that is tied to the player). Any redstone supplied to one "ender block" is transmitted by the other "ender block". A dispenser that dispenses through one "ender block" has its contents dispensed from the other "ender block". A hopper input attached to one "ender block" would cause the other "ender block" to act as a hopper on the face opposite the one connected, while a hopper beneath an "ender block" would cause the other "ender block" to act as a hopper input on the top. "Ender blocks" could be directional (a texture that indicates which direction is the input and output, or different symbols or indicators on each face of the block).
Given that concept, you could build a contraption in an always loaded chunk (for example, the spawn chunk), and have an official way to do "wireless redstone" in survival. It has all the same capabilities as the miniaturizer above, but less complexity with regards to storage.
There are a number of downsides to something like this too. Either the player would have to know where to find an always loaded chunk, or anywhere an "ender block" exists would have to be always loaded (which could add to memory pressure and decrease performance). It also removes the XP cost that the miniaturizer would have enforced, and reduces some of the possible other uses of the feature (i.e. dropping a "pop-up" miniaturized base in a sufficiently large flat space). There are plenty of other issues, I'm sure.
All of this is conjecture and hopefully some food for thought. I've really come to enjoy Minecraft and decided if I was to suggest something I might as well "go big" :). I'm always happy to put in my $0.02 for other features from the PC I'd love to see sooner rather than later, but adding to that conversation is not likely to have as much of an impact as trying to invent or innovate a new concept. I appreciate the feedback and analysis, so thanks for the input.
Ohhh.... I like your idea of the enderblock. But I would want to be able to us multiple different communication paths... how would you link/pair one enderblock to another enderblock, or would they all just pair together for each player?
Anyway, a lot of the problems with redstone are lag related due to rendering issues. (ie. lighting rendering can impact redstone in dark areas, crossing chunk boundaries can cause lag issues since each chunk is rendered separately, etc.) the advantage of using the virtual chunk space for the redstone 'miniaturization' is that it maintains the redstone structure contained within 1 chunk that doesn't have to be rendered at all.
You do, unfortunately, have to cross over a chunk space when entering the miniaturization, and when leaving miniaturization, but other than that, and once it is first used, it could be one of the always loaded chunks... if RAM space could be dedicated to it in game.
One possibility is simple a custom UI like for signs (on pc or 360) or command blocks/anvil (on pc) where you give it a name. Two ender blocks with the same name become bonded, but you can't use a name more than twice (for each side) as long as either block still exists as either a block or an entity.
On the miniaturizer side, I imagined the in-game mechanics of using the miniaturizer to be similar to using a flint/steel (crafted) on a frame of obsidian blocks (placed) to make a nether portal, with the addition of a prompt that informs you the XP cost and (if you have enough XP) lets you craft the miniaturized block. In this case the overall game mechanic is a familiar one.
I never really envisioned the player crossing from the normal world into the miniaturized version (which would introduce another world similar to the Nether or End), but rather using the "miniaturizer" to send a framed contraption to that space, or using the "miniaturizer" on the block that was created to restore it back to original size (which would only work if there was enough space in X/Y/Z for the full-size contraption). This would mean the player doesn't need to physically go to the chunk where the contraption exists, but rather just moves the blocks to the current chunk.
Maybe I should have chosen my words a little better, not 'you' as in the player, but the more abstract 'you' as in the redstone circuitry itself. Once the redstone current hits the block, (under the way I had proposed above) that would cause a change in chunk space to finish computing out the next step in the circuitry, and the redstone current would cross over chunk spaces once again once it returns to normal space.
This could cause up to two instances that might meet a little bit of lag, but if this is an always loaded/never rendered chunk, it shouldn't be a noticeable issue.
These mods somehow solve the problem:
- http://www.minecraftforum.net/topic/730795-164152smp-little-blocks-mod-2221-now-compatible-with-loads-of-mods-custom-blocks-670kdls/ (LittleBlocks)
- http://www.minecraftforum.net/topic/1852277-162-redlogic-wip-replacement-for-rp2-wiringlogiccontrollighting/ (RedLogic)
- http://www.minecraftforum.net/topic/1112856-152mlforge-gulliver-the-resizing-mod-v0138-beta-aug-10-changing-your-perspective-of-minecraft-over-90000-downloads/ (Gulliver)
For Minecraft 1.5.2 with Forge I have managed to get work these three together, though it was not easy with new version launcher.LittleBlocks works buggy with RedLogic, I could not remove LittleBlocks block and after an exit, part of my circuits had dissapeared. Also for version 1.5.2 you can not copy littleblocks.
As for me, I was actually thinking about kind of circuit board item in minecraft. Player can embed part or whole his redstone (or RedLogic, Project Red) circuit blocks into this board. And it really should be converted to java bytecode and heavily optimized. When placed in world, it fits into one block but works much much faster. When I say "much faster", I mean really fast, you know, today we have mpeg codec and nes emulators written on javascript.
Why is this important mod? It has great potential for discovering new ways of making programs projected over 3d world. The majority of today programming languages are declarative, there just should be another interesting way! Just imagine, a program would become halls and rooms and programmers could work on it together like virtual mechanics. Also it might be much better for parallel processing, minecraft community is huge, and who knows, what can we find.
In perspective, these boards can be placed into mobs to control their movements and actions.
Boards should be also easy copyable and shareable among players and be reuseable in other circuits and boards to keep modular principle, so these modules could evolve and be reused in community.
It is difficult to predict what result it would give. But if we look on real circuit boards history, we can see some elements were grouped into processors and memory modules. And these processors are programmed declaratively, so we back to the point we started. So there is something to think about.
But what you think about this idea in general?