Idea is to right click Slime Blocks with paper to make that side of the block not sticky until you break it of course. This will improve redstone builds alot I believe.
Basic idea is that you put paper on that side of the block basically covering up the slime.
Technical Info: This would probably require NBT tags seeing that a data tag would require 64 different data tags to account for each of the 6 sides.( Math 2^6). Of course if wanting to use data tags just convert to binary and each digit could count as a side.
Slime_Block:0 -- Normal, all sides stick
Slime_Block:63-- No sides stick
Slime_Block:46--?????
46 = 011101
2 sides stick, let's say the north and the bottom if we go with a NESWBT rule.
Anyways who else would like to see this in Minecraft?
I hate to bump my own thread, but I'd like to add some examples of how this could improve builds on minecraft when dealing with slimeblocks.
1. No longer have to use furnaces or other non-moving blocks next to slime blocks allowing for better ascetics.
2. Can have slimeblocks next to each other without interacting with each other allowing more compact builds.
3. Finally be able to have a slimeblock launcher that is flushed with the ground without picking up the ground.
Finally I'd like to also like to acknowledge that there have been suggestions to color slimeblocks so they don't interact with each other, but I feel this method of adding paper to the sides of slimeblocks would solve this as well, at least for most cases. I could imagine some complex design where this wouldnt work, but colored slimeblocks would, though I imagine this would not be a problem for most builds.
This should be useful, since slime blocks too much slime blocks can clash with each other, so inhibiting one of the sides should actually be very useful to redstone mechanisms.
Also a tip for you, try to make your suggestion a bit more attractive by adding custom fonts or some images explaining your suggestion.
I'd prefer if we just had the ability to dye Slime Blocks. Then you don't need NBT, you could just make so similarly colored Slime Blocks stick to each other but not to Slime Blocks of a different color.
Rollback Post to RevisionRollBack
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
I wish I was good at modding I would add this. I'm sure I could make some animations when I find the time to show how this would work. Perhaps coloring the sides of slime blocks is the way to go, getting the best of both worlds.
I'd prefer if we just had the ability to dye Slime Blocks. Then you don't need NBT, you could just make so similarly colored Slime Blocks stick to each other but not to Slime Blocks of a different color.
3 problems I see with the paper-in-side idea:
- Using NBT tags means block entities = slooooow performance. the game is optimized for normal blocks, not for blocks with extra data.
- All blocks with extra metadata are currently immovable by pistons. So it wouldn't be slime blocks having sides that don't interact with adjacent blocks. It would be slimes blocks that donyt even move at all anymore anyway. Quite sure that ain't what you're aiming for.
- There would be ZERO visible reminder of which block sticks to what. i.e. you see 2 slimeblocks adjacent to each other. Currently you can try to guess at the overall functionality WITHOUT pushing "start" on the redstone machine. But then you'd not be able to know if the two blocks are "paperized" or not. There is a feature visibility problem here. Imagine if Redstone Comparators looked symmetrically the same in both directions i.e. if you could not tell which side they are facing just by looking at the block. That would be exactly the same kind of problem this would cause here which is a big no-no. If if the paperized side was exposed, you'd still have to constantly fully turn all around the slime blocks to guess which sides can stick to what. Ergonomically, it's just a bad choice here. Redstone machines are complicated enough as they are without making analyzing them extra unwieldy.
IMHO, the proper approach would be the multiple colors, but NOT to allow dying slime blocks into 16 colors.
Instead, let's add a new slime-type mob: Let's say we would have Yellow Goop in addition to Green Slime. Rarer mob, basically a slime yes but thougher (maybe a special attack). it's yellow Goop Balls could be crafted into a yellow Goop Block, basically same as a slime block that for stickiness works like Green Slime (maybe different "bouncing" properties), but doesn't stick to Slime at all (and vice-versa of course). Merely having a single extra color would probably be enough here. More compact slime blocks builds, but not 100% flexibility either. If 1 extra color ain't enough, add another, let's say the infamous Olive Ooze lol. but I wouldn't go all the way 16-colors mode here.
- Using NBT tags means block entities = slooooow performance. the game is optimized for normal blocks, not for blocks with extra data.
- All blocks with extra metadata are currently immovable by pistons. So it wouldn't be slime blocks having sides that don't interact with adjacent blocks. It would be slimes blocks that donyt even move at all anymore anyway. Quite sure that ain't what you're aiming for.
I'm pretty sure that all blocks have exactly the same metadata tags. For example, while coarse dirt with the /setblock command requires extra datatags, regular dirt still has those types of tags, just a different value (the default value) which you don't have to put in the setblock command since it's the default.
I'm pretty sure that all blocks have exactly the same metadata tags. For example, while coarse dirt with the /setblock command requires extra datatags, regular dirt still has those types of tags, just a different value (the default value) which you don't have to put in the setblock command since it's the default.
There is a big difference between simple metadata, which only allows for 4 bits or 16 possible values, and NBT tags, which allows virtually anything, even entire inventories filled with blocks with inventories (you can use Ctrl+pickblock to get a chest filled with items, then place that chest in another chest, and so on until you have gigabytes of data stored in a single block).
The inability for pistons to push block entities (again, any block that requires more than just simple metadata) is likely due to the piston extension block being unable to store anything else other than a block ID and metadata, although it is actually a block entity itself, and as mentioned above you can store them inside of other block entities (albeit in item form; you are not actually storing a chest block inside of a chest; but the data is the same).
Block entities are also not necessarily laggy, especially if they are not doing much:
Slime blocks currently do nothing at all; when a piston moves the game checks for slime blocks connected to it, and their bounciness is a simple property of the block like the slipperiness of ice (when an entity detects that it has landed on a solid block it calls a generic method which determines whether to reduce/negate fall damage, or reverse its velocity to make it bounce).
Personally, I think that having a few different colors or types of slime blocks makes more sense than making a block that has 64 possible states; while being more useful I don't think it is really that necessary, and (to a point) restrictions lead to creativity.
I do see how NBT tags would not be the way to go, but I still believe that a 6 bit tag would still work. As of the visible aspect I feel the making 1 side paper would have to effect all adjacent sides to give the user a better idea of what side has paper and which do not. Simply coloring the edge of the slime block white when it's adjacent side has paper could solve that problem.
The biggest problem I believe in actually doing this is the increase in lag when pushing slime blocks. Massive slime contraptions already create a good amount of lag and for the server/client to have to perform another check when pushing a slime block may make these matters worse as well as the fact that moving these blocks means moving the meta data as well. I have not looked into the game's code to know exactly how this is done but I can see this problem causing unnecessary lag.
Nevertheless, I believe both the dyed slimes and the papered slimes could be useful, but there is no need for both. The problem I have with the dyed slimes is that we would still require furnaces or obsidian or some non-movable block next to the slime in order to make them not move or in some contraptions even work. Example, If I were to build a slime block elevator I currently am limited in what blocks I would like to build the shaft out of. An elevator shaft made from iron would be nice. Dying slime blocks or having different color slime blocks would still limit you from what you can and cannot place next to slimes, unless of course each dye has a strength of what can and can't be pushed.
Idea is to right click Slime Blocks with paper to make that side of the block not sticky until you break it of course. This will improve redstone builds alot I believe.
Basic idea is that you put paper on that side of the block basically covering up the slime.
Technical Info: This would probably require NBT tags seeing that a data tag would require 64 different data tags to account for each of the 6 sides.( Math 2^6). Of course if wanting to use data tags just convert to binary and each digit could count as a side.
Slime_Block:0 -- Normal, all sides stick
Slime_Block:63-- No sides stick
Slime_Block:46--?????
46 = 011101
2 sides stick, let's say the north and the bottom if we go with a NESWBT rule.
Anyways who else would like to see this in Minecraft?
I hate to bump my own thread, but I'd like to add some examples of how this could improve builds on minecraft when dealing with slimeblocks.
1. No longer have to use furnaces or other non-moving blocks next to slime blocks allowing for better ascetics.
2. Can have slimeblocks next to each other without interacting with each other allowing more compact builds.
3. Finally be able to have a slimeblock launcher that is flushed with the ground without picking up the ground.
Finally I'd like to also like to acknowledge that there have been suggestions to color slimeblocks so they don't interact with each other, but I feel this method of adding paper to the sides of slimeblocks would solve this as well, at least for most cases. I could imagine some complex design where this wouldnt work, but colored slimeblocks would, though I imagine this would not be a problem for most builds.
This should be useful, since slime blocks too much slime blocks can clash with each other, so inhibiting one of the sides should actually be very useful to redstone mechanisms.
Also a tip for you, try to make your suggestion a bit more attractive by adding custom fonts or some images explaining your suggestion.
Support.
This would make a lot of redstone builds a lot more compact!
Support!
If you ask me to click your dragons, I will click them until they are a pile of ashes.
I'd prefer if we just had the ability to dye Slime Blocks. Then you don't need NBT, you could just make so similarly colored Slime Blocks stick to each other but not to Slime Blocks of a different color.
Want some advice on how to thrive in the Suggestions section? Check this handy list of guidelines and tips for posting your ideas and responding to the ideas of others!
http://www.minecraftforum.net/forums/minecraft-discussion/suggestions/2775557-guidelines-for-the-suggestions-forum
Yes finally, no more immovable blocks.
Support.
"90% of the Internet's statistics are made-up, and 7/8 of its quotes are misattributed."
-Abraham Lincoln, 16th US President
Would be extremely useful, I'm going to support.
hi
I wish I was good at modding I would add this. I'm sure I could make some animations when I find the time to show how this would work. Perhaps coloring the sides of slime blocks is the way to go, getting the best of both worlds.
3 problems I see with the paper-in-side idea:
- Using NBT tags means block entities = slooooow performance. the game is optimized for normal blocks, not for blocks with extra data.
- All blocks with extra metadata are currently immovable by pistons. So it wouldn't be slime blocks having sides that don't interact with adjacent blocks. It would be slimes blocks that donyt even move at all anymore anyway. Quite sure that ain't what you're aiming for.
- There would be ZERO visible reminder of which block sticks to what. i.e. you see 2 slimeblocks adjacent to each other. Currently you can try to guess at the overall functionality WITHOUT pushing "start" on the redstone machine. But then you'd not be able to know if the two blocks are "paperized" or not. There is a feature visibility problem here. Imagine if Redstone Comparators looked symmetrically the same in both directions i.e. if you could not tell which side they are facing just by looking at the block. That would be exactly the same kind of problem this would cause here which is a big no-no. If if the paperized side was exposed, you'd still have to constantly fully turn all around the slime blocks to guess which sides can stick to what. Ergonomically, it's just a bad choice here. Redstone machines are complicated enough as they are without making analyzing them extra unwieldy.
IMHO, the proper approach would be the multiple colors, but NOT to allow dying slime blocks into 16 colors.
Instead, let's add a new slime-type mob: Let's say we would have Yellow Goop in addition to Green Slime. Rarer mob, basically a slime yes but thougher (maybe a special attack). it's yellow Goop Balls could be crafted into a yellow Goop Block, basically same as a slime block that for stickiness works like Green Slime (maybe different "bouncing" properties), but doesn't stick to Slime at all (and vice-versa of course). Merely having a single extra color would probably be enough here. More compact slime blocks builds, but not 100% flexibility either. If 1 extra color ain't enough, add another, let's say the infamous Olive Ooze lol. but I wouldn't go all the way 16-colors mode here.
I'm pretty sure that all blocks have exactly the same metadata tags. For example, while coarse dirt with the /setblock command requires extra datatags, regular dirt still has those types of tags, just a different value (the default value) which you don't have to put in the setblock command since it's the default.
There is a big difference between simple metadata, which only allows for 4 bits or 16 possible values, and NBT tags, which allows virtually anything, even entire inventories filled with blocks with inventories (you can use Ctrl+pickblock to get a chest filled with items, then place that chest in another chest, and so on until you have gigabytes of data stored in a single block).
The inability for pistons to push block entities (again, any block that requires more than just simple metadata) is likely due to the piston extension block being unable to store anything else other than a block ID and metadata, although it is actually a block entity itself, and as mentioned above you can store them inside of other block entities (albeit in item form; you are not actually storing a chest block inside of a chest; but the data is the same).
Block entities are also not necessarily laggy, especially if they are not doing much:
http://www.minecraftforum.net/forums/minecraft-discussion/discussion/2736893-would-making-slabs-a-tile-entity-really-be-bad
Slime blocks currently do nothing at all; when a piston moves the game checks for slime blocks connected to it, and their bounciness is a simple property of the block like the slipperiness of ice (when an entity detects that it has landed on a solid block it calls a generic method which determines whether to reduce/negate fall damage, or reverse its velocity to make it bounce).
Personally, I think that having a few different colors or types of slime blocks makes more sense than making a block that has 64 possible states; while being more useful I don't think it is really that necessary, and (to a point) restrictions lead to creativity.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
I do see how NBT tags would not be the way to go, but I still believe that a 6 bit tag would still work. As of the visible aspect I feel the making 1 side paper would have to effect all adjacent sides to give the user a better idea of what side has paper and which do not. Simply coloring the edge of the slime block white when it's adjacent side has paper could solve that problem.
The biggest problem I believe in actually doing this is the increase in lag when pushing slime blocks. Massive slime contraptions already create a good amount of lag and for the server/client to have to perform another check when pushing a slime block may make these matters worse as well as the fact that moving these blocks means moving the meta data as well. I have not looked into the game's code to know exactly how this is done but I can see this problem causing unnecessary lag.
Nevertheless, I believe both the dyed slimes and the papered slimes could be useful, but there is no need for both. The problem I have with the dyed slimes is that we would still require furnaces or obsidian or some non-movable block next to the slime in order to make them not move or in some contraptions even work. Example, If I were to build a slime block elevator I currently am limited in what blocks I would like to build the shaft out of. An elevator shaft made from iron would be nice. Dying slime blocks or having different color slime blocks would still limit you from what you can and cannot place next to slimes, unless of course each dye has a strength of what can and can't be pushed.