It would be nice if stairs could be made from any hard material -- stone, cobblestone, glass, wood, dirt, brick, iron, gold, diamond, obsidian... all the workbench would have to do is verify that the blocks are the same type are all placed in the right positions for a stair shape.
Some kind of stair tool would be nice, perhaps a chisel. While holding that tool, you could rotate the stairs horizontally by left-clicking, rotate them vertically by right-clicking.
With those two features, stairs would become easier to use AND it would also be possible to use them for architectural features, too, such as sloped roofs.
The thing that really stuck out at me, was the any material idea. What if we had certain blocks be the same shape, just a different material? Could make wooden half-blocks, obsidian stairs,
I think the game only allows like 256 different block types or something like that, so I don't think it would be worth it, though having curved stairs would be nice, so I can make an actually spiral staircase
I'm sure there's a way to tangle with the code a little to make it allow more than 256 though, but I don't know anything about coding so
Well Chads the idea is it's the same block, but a different material.
Which means it's a different block.
See Block id page: http://copy.mcft.net/mc/blocks/
Notice how even Furnace, and Furnace Lit have different IDs.
And Both stairs are seperate, IDs 67 and 53.
Rollback Post to RevisionRollBack
Quote from boxturtle »
The hole the Creeper left in the earth is nothing compared to the hole it left in my heart.
If I were doing it, from the start, I would have defined shapes and then textures to go with them for materials... but if the blocks are all taking separate spaces, I don't know how he's doing it. I'm not sure why there would be such a low limit on block types either!
I think it would be nice to have the different materials/orientations available simply for architectural purposes. If you make an obsidian palace, you don't really want wood or cobblestone stairs making it look clunky. If you want an angled surface, such as a roof, you'd probably want more options other than wood or cobblestone, if only for color.
Well Chads the idea is it's the same block, but a different material.
Which means it's a different block.
See Block id page: http://copy.mcft.net/mc/blocks/
Notice how even Furnace, and Furnace Lit have different IDs.
And Both stairs are seperate, IDs 67 and 53.
Notch is working on adding colors to blocks. (Atleast that's what it said in the wiki) What I'm saying is, it would be pretty cool if he found a way to modify the code so it's the same block, just a different material pasted on the side & maybe a different health value. He could save a lot of blocks that way. (Dirt, stone, diamond blocks, gold blocks, etc would all be a single block, freeing up a lot of space.)
An improvement I'd like to see with stairs is the removal of it's auto-orientation. It can be a pain in the ass when I'm trying to build a spiral staircase or just a simple stair upwards where for some reason it thinks it needs to point sideways. Why not make it so stairs point up the direction you're facing?
If I were doing it, from the start, I would have defined shapes and then textures to go with them for materials... but if the blocks are all taking separate spaces, I don't know how he's doing it. I'm not sure why there would be such a low limit on block types either!.
Remember, there are ALOT of blocks, which have to be accessed quickly, and saved and loaded frequently. They are likely stored in a very low-level format, such as arrays of words(A word is two bytes, or 16 bits), one word per block. This gives it one byte for the block type(256 possibilities), leaving 1 byte for everything else. Part of that is used for lighting, and there other few bits are used for whatever else(probably things like orientation, or water height).
If the space per block were increased, it would need to be doubled(for technical reasons), which would instantly double the filesize, and approx. double the time it takes to save and load chunks, giving a huge performance hit.
That is why we have a hard limit of 256 block types.
The way Team Fortress 2 allows you to orient items seems a good way: One button rotates, the other places.
They are likely stored in a very low-level format, such as arrays of words(A word is two bytes, or 16 bits), one word per block. This gives it one byte for the block type(256 possibilities), leaving 1 byte for everything else. Part of that is used for lighting, and there other few bits are used for whatever else(probably things like orientation, or water height).
How does he do signs and chests then? He must be linking to extra information elsewhere, otherwise signs and chests would not be possible. Perhaps use that ability to have extra information to implement it.
Rollback Post to RevisionRollBack
When all is said and done, Will you have said more than you have done?
Stairs should be deployed with the steps facing the player at the time you deploy them. Holding SHIFT or CTRL or ALT should rotate them LEFT, RIGHT, AWAY from the player respectively.
+1 For the Stairs suggestion. As of right now it's a huge hassle to make roofs or even just regular double stairs.
Rollback Post to RevisionRollBack
"I love how supporters of finite torches say they want a more challanging game and then in later threads talk about using peaceful mode when building."
The way Team Fortress 2 allows you to orient items seems a good way: One button rotates, the other places.
They are likely stored in a very low-level format, such as arrays of words(A word is two bytes, or 16 bits), one word per block. This gives it one byte for the block type(256 possibilities), leaving 1 byte for everything else. Part of that is used for lighting, and there other few bits are used for whatever else(probably things like orientation, or water height).
How does he do signs and chests then? He must be linking to extra information elsewhere, otherwise signs and chests would not be possible. Perhaps use that ability to have extra information to implement it.
The extra information likely works on a as-needed basis; you interact with a chest, and it looks up the chest in another data structure.(I am purely hypothesising at this point; I don't have any knowledge of how he does this, this is just my theory). This is not the type of thing you want to do for every block, only on certain blocks that you don't expect to be very common. Using this as a way to justify expanding blocks like crazy seems problematic. However, without knowing exactly how he did it I cannot really comment on the feasibility of it.
If I were doing it, from the start, I would have defined shapes and then textures to go with them for materials... but if the blocks are all taking separate spaces, I don't know how he's doing it. I'm not sure why there would be such a low limit on block types either!.
Remember, there are ALOT of blocks, which have to be accessed quickly, and saved and loaded frequently. They are likely stored in a very low-level format, such as arrays of words(A word is two bytes, or 16 bits), one word per block. This gives it one byte for the block type(256 possibilities), leaving 1 byte for everything else. Part of that is used for lighting, and there other few bits are used for whatever else(probably things like orientation, or water height).
Then the only change required to bump up that limitation is change A word from two bytes to two shorts, thereby giving him 65,536 types to work with, and that many more options for whatever else he needs (though he probably doesn't even need that many, a Word being 1 short and 1 byte would probably suffice). As far as I know, lighting shouldn't be part of the block entity itself, that should be part of rendering and an ongoing logic area in Memory as opposed to having to write that to each and every block every time the sun comes up and down. (Instead, leave the blocks alone, leave lighting to the render stage, and then apply logic like crops after lighting is completed)
I mean, in my opinion a small Array of 2 properties like that really not the best way to do it, in order to be ultimately scalable (which I think is something he should have in mind) he should have 3 properties (at least), simply have materials and block types separated, and a block has those two properties, plus another byte or short for handling everything else - that way it's technically feasible to have a "Bacon Staircase" - as it knows the shape from the block type and the texture from the material, without having to write in a new entity for it- and any new materials he adds like say Marble, are also technically available without having to write any new code to handle it.
The only thing he needs to handle himself would then be crafting - if he doesn't want a Bacon Staircase in the game, make it so that you cannot craft a bacon Staircase. But then when he thinks "You know, a gold staircase might be nice" he doesn't have to write anything but the craft recipe.
I'd be interested in knowing how much of a performance hit the game would take by going in a more object oriented approach. (or maybe he does this already, I don't know) Oh Notch, just one weekend, let me see it all for just one weekend...
If I were doing it, from the start, I would have defined shapes and then textures to go with them for materials... but if the blocks are all taking separate spaces, I don't know how he's doing it. I'm not sure why there would be such a low limit on block types either!.
Remember, there are ALOT of blocks, which have to be accessed quickly, and saved and loaded frequently. They are likely stored in a very low-level format, such as arrays of words(A word is two bytes, or 16 bits), one word per block. This gives it one byte for the block type(256 possibilities), leaving 1 byte for everything else. Part of that is used for lighting, and there other few bits are used for whatever else(probably things like orientation, or water height).
If the space per block were increased, it would need to be doubled(for technical reasons), which would instantly double the filesize, and approx. double the time it takes to save and load chunks, giving a huge performance hit.
That is why we have a hard limit of 256 block types.
One possible way this can be alleviated is to attach special properties to blocks (for this example, block in stair form, block in half-step form, etc).
And reserve one bit to indicate that said block has a special property attached to it.
of course, if too many block has special properties attached... then it would be worse then simply doubling the storage size for each block.
And... http://minecraftwiki.net/wiki/Data_Values
It looks like it goes as followed.
8-bits - block type (256 possible values)
4-bits - special data (door direction, stair direction, soil wetness, etc).
4-bits - probably light level (which goes from 0~15).
One possible way around some performance issue is figuring out which "detail" of the block don't need to be loaded immediately. So for example, a block may have a tag indicating whether it's just a block or actually stair. Beyond certain distance, you may not notice whether its a block or stair, so the game ONLY load information that tells it what type of block it is, and only load in more detailed information as you get closer.
The difficult part may-be figuring out what's the hierarchy.
Stairs should be deployed with the steps facing the player at the time you deploy them. Holding SHIFT or CTRL or ALT should rotate them LEFT, RIGHT, AWAY from the player respectively.
+1 for this. I would like more control over the placement of stairs.
One way to expand the system without adding a lot of overhead for semi-common blocks like stairs would be to use a Unicode like system, where common items use one byte, and less common items use two bytes. One of the bits in the 8-bit value would indicate whether to use one or two bytes. That would reduce the number of possible common items to 128, but would increase the total number of items to 32768.
EDIT: Although if we're gonna be using it to store small amounts of metadata that may take up several bits, it may be best to allow it to expand to several bytes and not just two.
Rollback Post to RevisionRollBack
When all is said and done, Will you have said more than you have done?
Some kind of stair tool would be nice, perhaps a chisel. While holding that tool, you could rotate the stairs horizontally by left-clicking, rotate them vertically by right-clicking.
With those two features, stairs would become easier to use AND it would also be possible to use them for architectural features, too, such as sloped roofs.
Maybe if you right click a stair block with another stair piece in your hand. It would be harder to place them where you want but would be nice.
Or maybe face which ever way they are placed, like signs.
6 Obsidian is a lot for stairs too.
I'm sure there's a way to tangle with the code a little to make it allow more than 256 though, but I don't know anything about coding so
Which means it's a different block.
See Block id page: http://copy.mcft.net/mc/blocks/
Notice how even Furnace, and Furnace Lit have different IDs.
And Both stairs are seperate, IDs 67 and 53.
I think it would be nice to have the different materials/orientations available simply for architectural purposes. If you make an obsidian palace, you don't really want wood or cobblestone stairs making it look clunky. If you want an angled surface, such as a roof, you'd probably want more options other than wood or cobblestone, if only for color.
Notch is working on adding colors to blocks. (Atleast that's what it said in the wiki) What I'm saying is, it would be pretty cool if he found a way to modify the code so it's the same block, just a different material pasted on the side & maybe a different health value. He could save a lot of blocks that way. (Dirt, stone, diamond blocks, gold blocks, etc would all be a single block, freeing up a lot of space.)
Remember, there are ALOT of blocks, which have to be accessed quickly, and saved and loaded frequently. They are likely stored in a very low-level format, such as arrays of words(A word is two bytes, or 16 bits), one word per block. This gives it one byte for the block type(256 possibilities), leaving 1 byte for everything else. Part of that is used for lighting, and there other few bits are used for whatever else(probably things like orientation, or water height).
If the space per block were increased, it would need to be doubled(for technical reasons), which would instantly double the filesize, and approx. double the time it takes to save and load chunks, giving a huge performance hit.
That is why we have a hard limit of 256 block types.
How does he do signs and chests then? He must be linking to extra information elsewhere, otherwise signs and chests would not be possible. Perhaps use that ability to have extra information to implement it.
The extra information likely works on a as-needed basis; you interact with a chest, and it looks up the chest in another data structure.(I am purely hypothesising at this point; I don't have any knowledge of how he does this, this is just my theory). This is not the type of thing you want to do for every block, only on certain blocks that you don't expect to be very common. Using this as a way to justify expanding blocks like crazy seems problematic. However, without knowing exactly how he did it I cannot really comment on the feasibility of it.
Then the only change required to bump up that limitation is change A word from two bytes to two shorts, thereby giving him 65,536 types to work with, and that many more options for whatever else he needs (though he probably doesn't even need that many, a Word being 1 short and 1 byte would probably suffice). As far as I know, lighting shouldn't be part of the block entity itself, that should be part of rendering and an ongoing logic area in Memory as opposed to having to write that to each and every block every time the sun comes up and down. (Instead, leave the blocks alone, leave lighting to the render stage, and then apply logic like crops after lighting is completed)
I mean, in my opinion a small Array of 2 properties like that really not the best way to do it, in order to be ultimately scalable (which I think is something he should have in mind) he should have 3 properties (at least), simply have materials and block types separated, and a block has those two properties, plus another byte or short for handling everything else - that way it's technically feasible to have a "Bacon Staircase" - as it knows the shape from the block type and the texture from the material, without having to write in a new entity for it- and any new materials he adds like say Marble, are also technically available without having to write any new code to handle it.
The only thing he needs to handle himself would then be crafting - if he doesn't want a Bacon Staircase in the game, make it so that you cannot craft a bacon Staircase. But then when he thinks "You know, a gold staircase might be nice" he doesn't have to write anything but the craft recipe.
I'd be interested in knowing how much of a performance hit the game would take by going in a more object oriented approach. (or maybe he does this already, I don't know) Oh Notch, just one weekend, let me see it all for just one weekend...
One possible way this can be alleviated is to attach special properties to blocks (for this example, block in stair form, block in half-step form, etc).
And reserve one bit to indicate that said block has a special property attached to it.
of course, if too many block has special properties attached... then it would be worse then simply doubling the storage size for each block.
And...
http://minecraftwiki.net/wiki/Data_Values
It looks like it goes as followed.
8-bits - block type (256 possible values)
4-bits - special data (door direction, stair direction, soil wetness, etc).
4-bits - probably light level (which goes from 0~15).
One possible way around some performance issue is figuring out which "detail" of the block don't need to be loaded immediately. So for example, a block may have a tag indicating whether it's just a block or actually stair. Beyond certain distance, you may not notice whether its a block or stair, so the game ONLY load information that tells it what type of block it is, and only load in more detailed information as you get closer.
The difficult part may-be figuring out what's the hierarchy.
+1 for this. I would like more control over the placement of stairs.
One way to expand the system without adding a lot of overhead for semi-common blocks like stairs would be to use a Unicode like system, where common items use one byte, and less common items use two bytes. One of the bits in the 8-bit value would indicate whether to use one or two bytes. That would reduce the number of possible common items to 128, but would increase the total number of items to 32768.
EDIT: Although if we're gonna be using it to store small amounts of metadata that may take up several bits, it may be best to allow it to expand to several bytes and not just two.