Some time ago I posted a wishlist... now I think I may try and expound a bit upon those on a more case-by-case basic, as thinking back a wishlist is really pretty useless. So here we go... I tried searching and it seems this might be an original post:
IDEA:
Apply dyes directly onto placed dyeable blocks to change either the entire block; or ideally change just that specific side.
In either case, it'd enable users to more easily change the color scheme; whereas my current methods entail having to destroy & replace each block one-by-one. ...Or when I'm short on sleep, I get the "I could do this with fire!" idea that soon results in a couple inadvertently missing city blocks.
Being able to dye individual sides could also enable differing paint schemes from room to room, helping reduce some of the architectural planning that accompanies needing at least two layers of blocks for each wall.
I have to disagree as this will increase the amount of data necessary for each world six-fold. This would further increase lag times, performance hits, and other problems that I don't have the heart to mention.
I have to disagree as this will increase the amount of data necessary for each world six-fold. This would further increase lag times, performance hits, and other problems that I don't have the heart to mention.
I have to disagree as this will increase the amount of data necessary for each world six-fold. This would further increase lag times, performance hits, and other problems that I don't have the heart to mention.
I don't see how it could get that bad unless you paint every single block you see.
I have to disagree as this will increase the amount of data necessary for each world six-fold. This would further increase lag times, performance hits, and other problems that I don't have the heart to mention.
I don't see how it could get that bad unless you paint every single block you see.
The system would have to render each side of every placed paintable block individually, just because they can be painted. So, even though this is a fun idea, I disagree for my FPS's sake.
Rollback Post to RevisionRollBack
Proud Minecrafter since Alpha 1.1.0 OH GOD LOOK OUT IT'S A SLUUUUT
Very simply: Each block has 1 type of look. Each side has it's own specific schema; regardless, even the most complicated block has 1 "color" associated with it.
Painting individual sides means you have 6 new sides to establish color with. Let's assume there are 15 colors you can paint, 1~15 are colors, the 0 bit is the transparency/no color.
With 6 sides that can possibly be colored (top, bottom, 4 sides), you are already looking at 6 times the bandwidth on the servers; and 6 times the memory needed to run locally. This means you are looking at increased load times, reduced sight distance, etc.
With 15 colors and the transparent color, you are looking at 16 colors (represented in hexidecimal as F).
Now, take the 6 and multiply it by 16. This is 96 extra bits or 12 extra bytes.
"Oh, 12 bytes, that's not much-"
PER BLOCK. Let's say you have the game load up 10 chunks for you to view through, each chunk is 64x64x128 (If I remember correctly). This would end up with an increase of 55 mb for these chunks (uncompressed). This is actually an increase of 1100%.
Very simply: Each block has 1 type of look. Each side has it's own specific schema; regardless, even the most complicated block has 1 "color" associated with it.
Painting individual sides means you have 6 new sides to establish color with. Let's assume there are 15 colors you can paint, 1~15 are colors, the 0 bit is the transparency/no color.
With 6 sides that can possibly be colored (top, bottom, 4 sides), you are already looking at 6 times the bandwidth on the servers; and 6 times the memory needed to run locally. This means you are looking at increased load times, reduced sight distance, etc.
With 15 colors and the transparent color, you are looking at 16 colors (represented in hexidecimal as F).
Now, take the 6 and multiply it by 16. This is 96 extra bits or 12 extra bytes.
"Oh, 12 bytes, that's not much-"
PER BLOCK. Let's say you have the game load up 10 chunks for you to view through, each chunk is 64x64x128 (If I remember correctly). This would end up with an increase of 55 mb for these chunks (uncompressed). This is actually an increase of 1100%.
Good idea, difficult to implement.
Actually, not quite. I'd assume only certain types of blocks (such as wool) would be paintable. It wouldn't bog it down as much as you said, but it would be a considerable amount nonetheless.
Rollback Post to RevisionRollBack
Proud Minecrafter since Alpha 1.1.0 OH GOD LOOK OUT IT'S A SLUUUUT
To post a comment, please login or register a new account.
IDEA:
Apply dyes directly onto placed dyeable blocks to change either the entire block; or ideally change just that specific side.
In either case, it'd enable users to more easily change the color scheme; whereas my current methods entail having to destroy & replace each block one-by-one. ...Or when I'm short on sleep, I get the "I could do this with fire!" idea that soon results in a couple inadvertently missing city blocks.
Being able to dye individual sides could also enable differing paint schemes from room to room, helping reduce some of the architectural planning that accompanies needing at least two layers of blocks for each wall.
Simple wool on top of stick torch style.
[] [] []
[] []
[] []
That paints 1 side of a block at a time.
[]
[]
This paints an entire block.
Simply craft them with a dye to give them an amount of 'durability' and once that runs out it simply reverts to a normal brush.
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)
How so?
I don't see how it could get that bad unless you paint every single block you see.
The system would have to render each side of every placed paintable block individually, just because they can be painted. So, even though this is a fun idea, I disagree for my FPS's sake.
OH GOD LOOK OUT IT'S A SLUUUUT
Painting individual sides means you have 6 new sides to establish color with. Let's assume there are 15 colors you can paint, 1~15 are colors, the 0 bit is the transparency/no color.
With 6 sides that can possibly be colored (top, bottom, 4 sides), you are already looking at 6 times the bandwidth on the servers; and 6 times the memory needed to run locally. This means you are looking at increased load times, reduced sight distance, etc.
With 15 colors and the transparent color, you are looking at 16 colors (represented in hexidecimal as F).
Now, take the 6 and multiply it by 16. This is 96 extra bits or 12 extra bytes.
"Oh, 12 bytes, that's not much-"
PER BLOCK. Let's say you have the game load up 10 chunks for you to view through, each chunk is 64x64x128 (If I remember correctly). This would end up with an increase of 55 mb for these chunks (uncompressed). This is actually an increase of 1100%.
Good idea, difficult to implement.
OFFICIAL POSTING/REPLYING GUIDELINES
UNOFFICIAL POSTING GUIDE (PRT)
UNOFFICIAL REPLYING GUIDE (FTC)
Actually, not quite. I'd assume only certain types of blocks (such as wool) would be paintable. It wouldn't bog it down as much as you said, but it would be a considerable amount nonetheless.
OH GOD LOOK OUT IT'S A SLUUUUT