Is there some selection for "Herobrine Thread" on the mod tools? I see moderators posting "Herobrine never did, does not, and never will exist." with links on each of those time-related phrases.
Aww, I liked it when it "shot lightning bolts out of their ...I can't say any more". Can you come up with a family-friendly varient under the REPORTED!!!! section?
So basically, a Tile entity that acts as a sort of "variable" block that stores values of various things and then other blocks draw from there?
Tile entities allow for more information to be stored than just damage values, whether it falls down, orientation, and color. For example, mob spawners are tile entities because they store the above and extra, which would be, for example, zombies. This could also store health of zombie, armor on zombie, speed, range, and many other factors. Currently, this is impossible to move in game because it is more information than block 36, which acts as storage for normal blocks with damage values, physics, orientation, and color. In this suggestion, block 36 takes on all possible values as needed.
This has the bonus of it taking any value programmed in by a mod, so tile entities created by a developer with extra, non-standard parameters would still transfer to block 36, which is currently a pain. And even if a developer did that, there would be no point currently because it would not move. This covers both aspects, making it both easier and a better choice for developers.
I get ansry at myself when I forget this is not possible at the time, when making complicated traps. I support. In fact, I had a suggestion, that would really go welll with this. I Support!
Your reply came in while I was typing the above. You'll be added to the supporter list! Thank you.
All my suggestions are either hits or complete flops.
A New Skylands: Complete and total failure. Nobody at all commented.
Solar Oven: Failure, almost everybody hated it. It just wasn't useful enough.
Recurve Bow: Total hit! It bounced up and gained concept art.
Pyrotechnic Stand: It got over 100 rep points, which impressed me.
Tile Entities: Looking good right now!
I like the idea and I always have. I'm not fully sure what the top part with the modding API has to do with this so I could use some clarification on that.
I like it. Although, I do believe it has already been suggested as 'moving chests' or 'moving tile entities'.
Alright, that's great! You've all been added to my supporter list, though I really want someone who doesn't like this idea.
I'll go one-by-one:
Deonyi, thank you for your support. As far as I know, this is not redundant, I searched those and 10 related and it did not show up on the first page. If there is one, then it' well buried.
Badprenup, this suggestions is mostly about improving tile entities, which I think have a lot of potential as flexible blocks that can store information across all blocks. The Modding API would tie in mostly because it gives more reason for future developers to use metadata stored in tile entities, which currently are limited in flexibility due to the fact that they can't move. I feel developers will enjoy having the framework for new parameters built in and flexible.
blue_bear_94, thank you for your support. This is amazing? Wow-ow-ow.
TL;DR: All of the ways of doing those are covered below.
Make tile entities movable
Make tile entities moddable
I'm sure we've all tried this at some time: we took a chest and a piston, put them together, and sent power to the piston. What happened? Exactly and excitingly zzzzzero. We thought we had found a bug, but it actually 'just couldn't work that way'.
There are two key elements in Minecraft: the Block and the Entity. The Block is very simple, carrying damage values and a few other values, but nothing more. The Entity is any dynamic, moving block-like physical object, such as falling sand.
Tile entities are those that carry extra information. In the case of a chest, it carries the position, type, and amount of blocks being carried by it at any time.
How do pistons actually push blocks?
Beyond the blocks we know and love, such as wool and wood, there are "technical blocks". They are there, but you can't get them from normal means. Air, for example, is one of those.
Block 36, which is a very romantically named block, is one of those. It is responsible for "holding" a space for the piston while the piston arm extends. It takes care of all the soon-to-be filled spaces and prepares the area for the incoming block. In short, it's a slave, who is forced to hold positions for the prestigious blocks that the player wants to move.
------------------------------------------------------------------------------------------------------------------------------
Part I: The Modding API.
What's the deal about the Mod API I keep hearing all about?
Well, the Modding API will allow for official mod support on Mojang's part, making it easier for developers who won't need extra APIs like Forge. With this type of integration, we can expect great things.
What is wrong with it right now?
In all honesty, nothing.
It could, however, be improved. Tile entities are extremely useful, storing information from mob spawners to dispensers. What if a developer wanted to adjust the redstone torch to have power level 6 instead of 15 in his genius redstone improvement mod? Well, all he would have to do is define it as a tile entity and easily add a new category, which would be output_power. Our genius adds in a few classes, which rule how the game works. Then the torch finds and uses the new output_power category and outputs a different amount of power. If another developer wants to modify that, he just finds the redstonetorch.output_power and edits that value to seven.
With this idea, we can create a network of easy improvements to mods when one just needs a few tweaks. Instead of rewriting values within a class, he just edits one value and all other instances of it change. Simple and easier for everyone, just saved by one tile entity. In addition, not just that redstone torch but EVERY block will have that value. For almost all of them, it will be 0, but for the redstone block perhaps you could make a 15 power level. Then it can be easily edited at will and fine-tuned.
------------------------------------------------------------------------------------------------------------------------------
Part Two: Actually moving that old, old chest.
Why can't we move those tile entities right now?
Block 36 (remember, our slave 36) cannot handle these values as of now. To change that, Block 36 must adopt all values, such as our genius' wonderful new output_power. Then it carries over that value into Block 36. Block 36 is set to not actually react with any of those values but simply store them. Then it may actually be possible to move them.
I don't get it at all. Are you trying to murder me with Block 36?
No, I did not intend to do that at all.
So please actually talk the language we speak in.
Fine.
Here we go. The piston is lined up against the chest.
The lever has been flipped!
Block 36 has been created. It is actually invisible, but it's turned into red wool for now.
At this point, all attributes from the chest, such as position of items, number of items, and type, are carried into Block 36. If our genius is still around, it's also carrying its output power, which is hopefully zero.
Now, it assumes its original graphics and replaces Block 36s values into itself.
This can't work all of the time. What if a row of chests got pushed into each other?
Chests will not move if the tile entity is adjacent to a chest other than the one it is moving, so no double chests will be created in this process.
What if it's a block that can be powered and carries information?
You mean like this?
Piston pushes the dispenser. We're going to skip the next few steps.
It slides under the torch, which should power it. A block update is sent, which checks nearby blocks and tries again to see if anything has changed.
It realizes something is different: It's under a redstone torch. Water is dispensed.
So why would I even care?
Well, this allows for many vanilla, survival traps. For example, I can quickly make something that can pop from the ground when a player hits it, shoot an arrow, and then pop right back down. It's a tiny survival project codenamed Project Porcupine, for obvious reasons.
It's so very easy with this, and so very not obvious when it's a small stone passageway.
Another idea, submitted by Cheatster9000, was an automatic armor equipping device. I've fleshed out the device, here it is:
Add another piston with a dispenser on top and fill each with one piece of armor and one sword. Then when you stand on the plate, the four dispensers on the side pop up and automatically activate due to the pressure plate. The middle one shoots up a sword.
CHOOSE YOUR PATH: Alright! Sounds good to me!
Great! If you can add something like a picture of its use, that would be great. Your name in the supporter list will be extra-big and highlighted in gold.
I-V
themariofireball
Deonyi
Badprenup
blue_bear_94
unitedsquadron3 VI-X
InfoTeddy
colorfusion
Cheatster9000, thank you for your automatic armor dispenser. I've added the concept into the uses.
GOLD SUPPORTER
Meh. I have no use for such things.
Fair enough! I'm good with that, as long as you actually tell me why you don't like it. I'd rather you critique this than not say anything. And if you actually say some reason beyond "No support, it doesn't make sense", then I'll actually give you your own list, of critics.
Ribsterz, thank you for your help. Because of your feedback I realized the flaw and decided that due to the nature of chests, sometimes they can be pushed and other times they cannot. I've edited the OP to reflect that.
GOLD CRITIC
Don't be shy! You'll only be helping my idea out, and my future ideas.
I'll add a banner pretty soon right now. Thank you for your time!
Supporting banner-- You get an extra-big name as well if you don this on your "About Me" page or your signature.
Tile entities allow for more information to be stored than just damage values, whether it falls down, orientation, and color. For example, mob spawners are tile entities because they store the above and extra, which would be, for example, zombies. This could also store health of zombie, armor on zombie, speed, range, and many other factors. Currently, this is impossible to move in game because it is more information than block 36, which acts as storage for normal blocks with damage values, physics, orientation, and color. In this suggestion, block 36 takes on all possible values as needed.
This has the bonus of it taking any value programmed in by a mod, so tile entities created by a developer with extra, non-standard parameters would still transfer to block 36, which is currently a pain. And even if a developer did that, there would be no point currently because it would not move. This covers both aspects, making it both easier and a better choice for developers.
This is a very interesting feature. If I recall correctly, there was a way to make minecarts invisible as well. If that is true, it might be possible to have a sphere with an opening without the obvious mass of minecarts.
Will be interested to see if this is used in other maps, perhaps by the creator of the Code. The final destruction sphere shown in this video showed obvious similarity to Code III's ending,
0
Is there some selection for "Herobrine Thread" on the mod tools? I see moderators posting "Herobrine never did, does not, and never will exist." with links on each of those time-related phrases.
0
0
Off topic: Nice profile picture!
You are right though, more realistic cauldrons could work with this. And the cauldrons could actually move.
Thank you for your support. I suppose that could be done with a trapped chest and a inverted floor flush double-piston extender.
0
0
0
It should not, as Badprenup stated. Also, default values are not stored, such as an empty chest slot, so it shouldn't have much lag.
How so? The image link is this:
[IMG.]http://i.imgur.com/jodbt1j.png[/IMG.]
Remove those two periods after IMG.
0
Good, that works.
0
0
You are wrong. It's making profit based of copyrighted content, which is illegal under Mojang's TaC.
0
Tile entities allow for more information to be stored than just damage values, whether it falls down, orientation, and color. For example, mob spawners are tile entities because they store the above and extra, which would be, for example, zombies. This could also store health of zombie, armor on zombie, speed, range, and many other factors. Currently, this is impossible to move in game because it is more information than block 36, which acts as storage for normal blocks with damage values, physics, orientation, and color. In this suggestion, block 36 takes on all possible values as needed.
This has the bonus of it taking any value programmed in by a mod, so tile entities created by a developer with extra, non-standard parameters would still transfer to block 36, which is currently a pain. And even if a developer did that, there would be no point currently because it would not move. This covers both aspects, making it both easier and a better choice for developers.
Your reply came in while I was typing the above. You'll be added to the supporter list! Thank you.
All my suggestions are either hits or complete flops.
A New Skylands: Complete and total failure. Nobody at all commented.
Solar Oven: Failure, almost everybody hated it. It just wasn't useful enough.
Recurve Bow: Total hit! It bounced up and gained concept art.
Pyrotechnic Stand: It got over 100 rep points, which impressed me.
Tile Entities: Looking good right now!
Thanks all for pushing this!
0
Alright, that's great! You've all been added to my supporter list, though I really want someone who doesn't like this idea.
I'll go one-by-one:
Deonyi, thank you for your support. As far as I know, this is not redundant, I searched those and 10 related and it did not show up on the first page. If there is one, then it' well buried.
Badprenup, this suggestions is mostly about improving tile entities, which I think have a lot of potential as flexible blocks that can store information across all blocks. The Modding API would tie in mostly because it gives more reason for future developers to use metadata stored in tile entities, which currently are limited in flexibility due to the fact that they can't move. I feel developers will enjoy having the framework for new parameters built in and flexible.
blue_bear_94, thank you for your support. This is amazing? Wow-ow-ow.
0
Thank you for your support! You have been added into the supporters list.
Do you have any good uses for this? Those would be helpful.
0
There used to be. Next time, please look at the date: That was on october, which is about eight months ago. A lot has changed.
Now let's leave this thread to die, there's no more value.Actually, it was bumped a year after it was first posted and now eight months later.
11
UTILITY
OF TILE ENTITIES
TL;DR: All of the ways of doing those are covered below.
I'm sure we've all tried this at some time: we took a chest and a piston, put them together, and sent power to the piston. What happened? Exactly and excitingly zzzzzero. We thought we had found a bug, but it actually 'just couldn't work that way'.
Why?
------------------------------------------------------------------------------------------------------------------------------
Introduction:
What is a tile entity?
There are two key elements in Minecraft: the Block and the Entity. The Block is very simple, carrying damage values and a few other values, but nothing more. The Entity is any dynamic, moving block-like physical object, such as falling sand.
Tile entities are those that carry extra information. In the case of a chest, it carries the position, type, and amount of blocks being carried by it at any time.
How do pistons actually push blocks?
Beyond the blocks we know and love, such as wool and wood, there are "technical blocks". They are there, but you can't get them from normal means. Air, for example, is one of those.
Block 36, which is a very romantically named block, is one of those. It is responsible for "holding" a space for the piston while the piston arm extends. It takes care of all the soon-to-be filled spaces and prepares the area for the incoming block. In short, it's a slave, who is forced to hold positions for the prestigious blocks that the player wants to move.
------------------------------------------------------------------------------------------------------------------------------
Part I: The Modding API.
What's the deal about the Mod API I keep hearing all about?
Well, the Modding API will allow for official mod support on Mojang's part, making it easier for developers who won't need extra APIs like Forge. With this type of integration, we can expect great things.
What is wrong with it right now?
In all honesty, nothing.
It could, however, be improved. Tile entities are extremely useful, storing information from mob spawners to dispensers. What if a developer wanted to adjust the redstone torch to have power level 6 instead of 15 in his genius redstone improvement mod? Well, all he would have to do is define it as a tile entity and easily add a new category, which would be output_power. Our genius adds in a few classes, which rule how the game works. Then the torch finds and uses the new output_power category and outputs a different amount of power. If another developer wants to modify that, he just finds the redstonetorch.output_power and edits that value to seven.
With this idea, we can create a network of easy improvements to mods when one just needs a few tweaks. Instead of rewriting values within a class, he just edits one value and all other instances of it change. Simple and easier for everyone, just saved by one tile entity. In addition, not just that redstone torch but EVERY block will have that value. For almost all of them, it will be 0, but for the redstone block perhaps you could make a 15 power level. Then it can be easily edited at will and fine-tuned.
------------------------------------------------------------------------------------------------------------------------------
Part Two: Actually moving that old, old chest.
Why can't we move those tile entities right now?
Block 36 (remember, our slave 36) cannot handle these values as of now. To change that, Block 36 must adopt all values, such as our genius' wonderful new output_power. Then it carries over that value into Block 36. Block 36 is set to not actually react with any of those values but simply store them. Then it may actually be possible to move them.
I don't get it at all. Are you trying to murder me with Block 36?
No, I did not intend to do that at all.
So please actually talk the language we speak in.
Fine.
Here we go. The piston is lined up against the chest.
The lever has been flipped!
Block 36 has been created. It is actually invisible, but it's turned into red wool for now.
At this point, all attributes from the chest, such as position of items, number of items, and type, are carried into Block 36. If our genius is still around, it's also carrying its output power, which is hopefully zero.
Now, it assumes its original graphics and replaces Block 36s values into itself.
This can't work all of the time. What if a row of chests got pushed into each other?
Chests will not move if the tile entity is adjacent to a chest other than the one it is moving, so no double chests will be created in this process.
What if it's a block that can be powered and carries information?
You mean like this?
Piston pushes the dispenser. We're going to skip the next few steps.
It slides under the torch, which should power it. A block update is sent, which checks nearby blocks and tries again to see if anything has changed.
It realizes something is different: It's under a redstone torch. Water is dispensed.
So why would I even care?
Well, this allows for many vanilla, survival traps. For example, I can quickly make something that can pop from the ground when a player hits it, shoot an arrow, and then pop right back down. It's a tiny survival project codenamed Project Porcupine, for obvious reasons.
It's so very easy with this, and so very not obvious when it's a small stone passageway.
Another idea, submitted by Cheatster9000, was an automatic armor equipping device. I've fleshed out the device, here it is:
Add another piston with a dispenser on top and fill each with one piece of armor and one sword. Then when you stand on the plate, the four dispensers on the side pop up and automatically activate due to the pressure plate. The middle one shoots up a sword.
CHOOSE YOUR PATH:
Alright! Sounds good to me!
Great! If you can add something like a picture of its use, that would be great. Your name in the supporter list will be extra-big and highlighted in gold.
I-V
themariofireball
Deonyi
Badprenup
blue_bear_94
unitedsquadron3
VI-X
InfoTeddy
colorfusion
Cheatster9000, thank you for your automatic armor dispenser. I've added the concept into the uses.
GOLD SUPPORTER
Meh. I have no use for such things.
Fair enough! I'm good with that, as long as you actually tell me why you don't like it. I'd rather you critique this than not say anything. And if you actually say some reason beyond "No support, it doesn't make sense", then I'll actually give you your own list, of critics.
Ribsterz, thank you for your help. Because of your feedback I realized the flaw and decided that due to the nature of chests, sometimes they can be pushed and other times they cannot. I've edited the OP to reflect that.
GOLD CRITIC
Don't be shy! You'll only be helping my idea out, and my future ideas.
I'll add a banner
pretty soonright now. Thank you for your time!Supporting banner-- You get an extra-big name as well if you don this on your "About Me" page or your signature.
FAQ: Formerly Answered Questions
What, exactly, does a tile entity handle?
0
I shall withhold rating until you come back on that.