"Every texture and colours on every model, easily, logically; simply amazing for maps!"
TL;DR
It will make files lighter, should cause less lag, give a lot of customizability, and help type human readable names like
/give player "blue brick stairs" (OR) /place "inverted north red oak stair" ~0 ~0 ~1
Then easily be interpreted both in code and in commands.
The principle
Look at â, from French’s bâtir (to build) - it’s not a new letter but rather a + ^.
You can even have more than one accent like with this cute and evil looking ặ.
Blocks in Minecraft vary in model, texture, colour, and state.
Brick Stairs, heading North? Block id, Data value.
Wool, Red? Block id, Data value.
Oak door opened to the west? Block id, Data value.
This actually works fine for the moment.
Yet… this unclear model-texture and colour-state-texture distinction does not help customization, because, in order to have polished andesite stairs, trapped painted doors, obsidian red painted levers, or whatever your mind can create, one can only play with more and more block id and the same small amount of data value.
So let’s ease block/item/mob/biome addition by making the current system more intuitive and still light.
How?
Varying bytes. Using this way of coding and due to its variable size, quick calculations can be made with great customizability.
Looking at the Chunk Format and NBT structure, block ID and data value are kept in cubic chunks of 16*16*16 block ID under 256 in one list (4'096 bytes of information), block IDs over 256 in another list called "Add" (2'048 bytes of information), and data value in a third list (2'048 as well). Which makes that each cubic chunk weighs between 4 and 8 kilobytes.
I'm proposing differently which can make each cubic chunk weigh between less than 1 kilobyte to (unfortunately but unlikely) up to 20 kilobytes when super hyper customized. Let's...
separate Y and Z into subcategories inside the cubic chunk
allow 16 bytes in each Z-lines of each Y-Leaflets for "blocks"
keep added information in a new 8-bytes "Add" format melting old "Add" and "Data", and there can be multiple "Add" lists.
have the number of 1 before the zero in bytes from the "Blocks" array represent the number of four-bits related to it in the new "Add" format (At most 8 four-bits per blocks but that's quite unlikely).
This is how it would work:
0AAAAAAA 128 blocks where data=0
10AAAAAA: BBBB 64 blocks with data value
110AAAAA: AAAA BBBB 512 blocks with data value
1110?AAA: AAAA BBBB CCCC
128 blocks (A) with data value (B) and colour (C)
or 2'048 blocks (A+B) with data value (C)
11110?AA: AAAA AAAA BBBB CCCC
1'024 blocks (A) with data value (B) and colour (C)
OR 4'096 blocks (A+B) and data value (C)
111110AA: AAAA AAAA BBBB CCCC CCCC
1'024 blocks (A) with data (B) and 256 textures (C)
1111110?: AAAA AAAA AAAA BBBB CCCC DDDD
4'096 blocks (A) with data (B), colour (C), and 16 textures (D)
OR data (B) and 256 textures (C+D)
11111110: AAAA AAAA AAAA BBBB CCCC DDDD DDDD
4'096 blocks (A) with data (B), colour (C), and textures (D)
If that is too complex, we can let go of the varying bit idea and simply add a new list for a third set of 4-bits for colours (2'048 bytes per cubic chunk, or 128 bytes per Y-leaflets, or 8 bytes per Z-lines) and a fourth for textures (16 possible texture related to the mix of block ID and data value, which can be hair pulling to prepare the code for it though). Of course blocks that are already coloured (stained clay) can't get coloured again.
Who can do it?
Generalized simplified recipe in survival
The principle (first presented by Alexcamostyle) is simple, really. So that all of this greatness is accessible in survival, the recipes should be simplified. 3 of the same blocks horizontal? Slab. A dye with a block whatever it is? Dye with said block. Can't get much simpler. For this the way recipe works probably has to be changed as well a little. We'll see.
New GUI when in creative
The old separation of blocks/items in creative may or may not continue to exist, but one could be able to make from a three to four sided window, first with model (block ID actually), second with texture, third with color, and fourth with miscellaneous data value and otherwise tags aspects.
Command-accessible only
Or we can leave it to the command savvy, simply doing /give %p 'big cyan obsidian boat' (Link Removed)
Extra customizable ressource pack
So you want a pink-stained golden door? But how does it look?
The program will look first for a file in the ressource pack called "pink.gold.door.png", if absent then "gold.door.png" adding to it a pink tint, and if absent then take the oak door, add gold texture, then pink tint.
You have orange brick stairs? Same thing, if there is an orange brick texture, it will choose it first, otherwise it will tint the existing texture.
Beyond blocks
A similar potential can be done with entities from which the number would never go beyond a relatively small number, thus allowing more modulability to each ones like villagers with strange item exchanges, bigger creepers which could drop a TNT block, friendly spiders... And what about a swamp in which water is poisonous, or a mountain with loads of ore but water-filled caves? the limits are really far
The system for entities and biomes would be a quite different different though, and instead of having 4 bits per additional 1 in front of the first zero, it would have 8:
0AAAAAAA for 128 normal unspecific mobs/biomes.)
10AAAAAA: AAAABBBB for 1'024 entities/biome/etc. (it can't get more numerous) with 16 different basic changes (that can include the different kind of villagers, guardians, golems, or M/X/whatever other version of biomes)
110AAAAA: AAAAABBB BCCCCCCC same thing plus one of 128 predefined add-on (outfit, exchange, poisonous water)
1110AAAA: AAAAAABB BBCCCCCC CDDDDDDD same thing plus another 1/128th add-on
- It's going to be arduous change yet when it's done it's done for good.
- It may break many mods in their current form yet it will simplify mod making afterwards.
- By separating texture and data value, slabs and stairs for example will have unused bits yet it can be used to have side way stairs or slabs (the latter useful for thinner walls).
- Also, there will be block ID and texture overlapping, so the code is not fully efficient but at least enables future addition of blocks. By the way, this, if well made, will not screw up existing world, only update it. Of course it's good to make a copy of your world before opening it like after any update.
Show your support
Copy the code below the image into your signature if you like! Image Removed
It's quite space to me as well as when something is not existing already, it's hard to describe.
For example. Think of the letter A. Â can be considered either a new letter altogether, or A with ^.
The first being how computers originally worked, the second being how it has been for a while now.
Some alphabets like vietnamese can have quite a fair bit of diacritics and accents, making a as ặ.
Is it a new letter altogether, or the letter a with accents?
Now think about this. Is chiseled sandstone a new block altogether, or sandstone chiseled?
Minecraft does that with states and color already, but although it works well for the moment, it's an unclear distinction that does not allow for great customization - polished andesite stairs, as of now, only exist in the hope of the Minecraftan nation.
I'm way far from being a tech wiz, but by looking at this it almost seems like it would be possible way to customize biomes. Correct me if I'm wrong.
I think I get you, yes. Anything can get specific aspects this way after all, and in the most efficient way. Biomes. Blocks. Mobs. Items. Maps. Worlds. Sub-biomes like Mesa M are customized mesa, written for convenience as adjectives ("accents"/sub-biome/etc) + noun ("letter"/biome/block/mob).
Quote from Mart_b77jumpFor example. Think of the letter A. Â can be considered either a new letter altogether, or A with ^.
The first being how computers originally worked, the second being how it has been for a while now.
Actually, Unicode prefers having  as a separate character rather than A + ^. Also, the string ID system effectively renders this obsolete.
The string ID system is only for necessary when coding to describe the actual ID, the same way that "→" (U+2192) is called "RIGHTWARDS ARROW" and "LOWER RIGHT PENCIL" could be understood as U+270E rendering ✎.
But I do not want to copy the system from Unicode either, simply the principle of varying byte width with a certain kept logic.
We have colour. We have orientation. We have position. We have type.
If there is a way to keep all this information easy to get and at the same time allowing a lot of freedom, and be able to apply the same system to more than one aspect of coding, then full on customization as well as hopefully less lag are the end goals.
Rollback Post to RevisionRollBack
Link RemovedImage RemovedLink RemovedImage RemovedLink RemovedLink RemovedLink RemovedImage RemovedLink Removed Link RemovedImage RemovedLink RemovedImage Removed
Updated quite a fair bit the byte system. It's almost playing with dark matter but something tell me this is the way to go.
To sum things up, data value would be embedded in block id but separated in model, colour and state in order to give much more customizability of blocks while still being file efficient.
As for the current minecraft:filled_map string id, sure, it works somehow, but wouldn't it be great to not have to remember the exact name of blocks, and be able to write "black brick slab" and be understood?
Hi Talons, I agree it will cause a lot of coding to change and I've been saying it since the beginning. But aside of the hard work, I am assertive that it will make files lighter and from it cause less lag, as well as give a lot more customizability.
Heya! Sorry for the terribly late reply... I'm not good at remembering things... ^^"
Anyway, so you're saying that you want the programming to handle the "specs" of objects separately, instead of being bound to object types?
Like, for example, instead of having a code that ties a characteristic, like for example the stairs and slab "shapes", only to blocks like stone and wood, change it to a more "free" coding, making it able to handle blocks and characteristics, like shapes, colors, and whatso,separately from the blocks, in a way that could make them be appliable universally to any sorts of blocks. Be it wools, pumpkins, or even gravel.
Like, for example, instead of having a code that ties a characteristic, like for example the stairs and slab "shapes", only to blocks like stone and wood, change it to a more "free" coding, making it able to handle blocks and characteristics, like shapes, colors, and whatso,separately from the blocks, in a way that could make them be appliable universally to any sorts of blocks. Be it wools, pumpkins, or even gravel.
No worries thanks for answering!
In fact yes, that is the reason for the "Model" component. 16 different shapes for block types. Here is 7 already off the bat and there could (and will) be more overtime:
Block
Stair
Slab
Door
Fence
Mid-Wall
Gate
But as you point out, pumpkin and gravel are a different deal. But in fact, due to the quantity of gravel in the world, it is kept in the program as one byte only along with 128 other blocks.
Let's remember not every block should have all shapes, but the principle allows simplicity and quick computing on that matter.
What I'm looking for is standardisation of block id allowing for easy customizability.
Rollback Post to RevisionRollBack
Link RemovedImage RemovedLink RemovedImage RemovedLink RemovedLink RemovedLink RemovedImage RemovedLink Removed Link RemovedImage RemovedLink RemovedImage Removed
I actually disagree with you there. ...I mean, in Vanilla and regular gaming I agree 100%.
but for map-makers and modders I DO think ALL BLOCKS should be able to render in ALL SHAPES in Vanilla itself.
It allows for even greater possibilities of creativity and much more variety in buildings and/or creative use of the game's bugs/glitches (like for example when people make use of the fact that stairs don't block light to make hidden light sources.) and it also opens doors for those that simply can't, for one reason or another, handle modding Minecraft (Or even just don't want to, since some just wanna stick to Vanilla, but without losing freedom of choice.)
Other than that, great to know I got it right. And you have my Full and undying support! ^^
Other than that, great to know I got it right. And you have my Full and undying support! ^^
Great, le me le happy
But I agree with you that they could, but normally can't. Hell, an andesite door would be awesome! But what these thing should not be, is craftable.
They in fact could be /given as "andesite stone door" (or hell square, even "trapped cracked stone door" ^^)
2^46+2^31+2^26+2^21+2^16+2^11+2^7=70,370,960,935,040 possibilities is what you can call almost limitless.
Rollback Post to RevisionRollBack
Link RemovedImage RemovedLink RemovedImage RemovedLink RemovedLink RemovedLink RemovedImage RemovedLink Removed Link RemovedImage RemovedLink RemovedImage Removed
TL;DR
It will make files lighter, should cause less lag, give a lot of customizability, and help type human readable names like
Then easily be interpreted both in code and in commands.The principle
Look at â, from French’s bâtir (to build) - it’s not a new letter but rather a + ^.
You can even have more than one accent like with this cute and evil looking ặ.
Blocks in Minecraft vary in model, texture, colour, and state.
Brick Stairs, heading North? Block id, Data value.
Wool, Red? Block id, Data value.
Oak door opened to the west? Block id, Data value.
This actually works fine for the moment.
Yet… this unclear model-texture and colour-state-texture distinction does not help customization, because, in order to have polished andesite stairs, trapped painted doors, obsidian red painted levers, or whatever your mind can create, one can only play with more and more block id and the same small amount of data value.
So let’s ease block/item/mob/biome addition by making the current system more intuitive and still light.
How?
Varying bytes. Using this way of coding and due to its variable size, quick calculations can be made with great customizability.
Looking at the Chunk Format and NBT structure, block ID and data value are kept in cubic chunks of 16*16*16 block ID under 256 in one list (4'096 bytes of information), block IDs over 256 in another list called "Add" (2'048 bytes of information), and data value in a third list (2'048 as well). Which makes that each cubic chunk weighs between 4 and 8 kilobytes.
I'm proposing differently which can make each cubic chunk weigh between less than 1 kilobyte to (unfortunately but unlikely) up to 20 kilobytes when super hyper customized. Let's...
This is how it would work:
or 2'048 blocks (A+B) with data value (C)
OR 4'096 blocks (A+B) and data value (C)
OR data (B) and 256 textures (C+D)
If that is too complex, we can let go of the varying bit idea and simply add a new list for a third set of 4-bits for colours (2'048 bytes per cubic chunk, or 128 bytes per Y-leaflets, or 8 bytes per Z-lines) and a fourth for textures (16 possible texture related to the mix of block ID and data value, which can be hair pulling to prepare the code for it though). Of course blocks that are already coloured (stained clay) can't get coloured again.
Who can do it?
Generalized simplified recipe in survival
The principle (first presented by Alexcamostyle) is simple, really. So that all of this greatness is accessible in survival, the recipes should be simplified. 3 of the same blocks horizontal? Slab. A dye with a block whatever it is? Dye with said block. Can't get much simpler. For this the way recipe works probably has to be changed as well a little. We'll see.
New GUI when in creative
The old separation of blocks/items in creative may or may not continue to exist, but one could be able to make from a three to four sided window, first with model (block ID actually), second with texture, third with color, and fourth with miscellaneous data value and otherwise tags aspects.
Command-accessible only
Or we can leave it to the command savvy, simply doing /give %p 'big cyan obsidian boat' (Link Removed)
Extra customizable ressource pack
So you want a pink-stained golden door? But how does it look?
The program will look first for a file in the ressource pack called "pink.gold.door.png", if absent then "gold.door.png" adding to it a pink tint, and if absent then take the oak door, add gold texture, then pink tint.
You have orange brick stairs? Same thing, if there is an orange brick texture, it will choose it first, otherwise it will tint the existing texture.
Beyond blocks
A similar potential can be done with entities from which the number would never go beyond a relatively small number, thus allowing more modulability to each ones like villagers with strange item exchanges, bigger creepers which could drop a TNT block, friendly spiders... And what about a swamp in which water is poisonous, or a mountain with loads of ore but water-filled caves? the limits are really far
The system for entities and biomes would be a quite different different though, and instead of having 4 bits per additional 1 in front of the first zero, it would have 8:
Human Writable Names for ID and data value
Follow the discussion here
Be aware
- It's going to be arduous change yet when it's done it's done for good.
- It may break many mods in their current form yet it will simplify mod making afterwards.
- By separating texture and data value, slabs and stairs for example will have unused bits yet it can be used to have side way stairs or slabs (the latter useful for thinner walls).
- Also, there will be block ID and texture overlapping, so the code is not fully efficient but at least enables future addition of blocks.
By the way, this, if well made, will not screw up existing world, only update it. Of course it's good to make a copy of your world before opening it like after any update.
Show your support
Copy the code below the image into your signature if you like!
Link RemovedImage RemovedImage Removed
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
I do believe it can make cause less lag than the current form.
It's quite space to me as well as when something is not existing already, it's hard to describe.
For example. Think of the letter A.
 can be considered either a new letter altogether, or A with ^.
The first being how computers originally worked, the second being how it has been for a while now.
Some alphabets like vietnamese can have quite a fair bit of diacritics and accents, making a as ặ.
Is it a new letter altogether, or the letter a with accents?
Now think about this. Is chiseled sandstone a new block altogether, or sandstone chiseled?
Minecraft does that with states and color already, but although it works well for the moment, it's an unclear distinction that does not allow for great customization - polished andesite stairs, as of now, only exist in the hope of the Minecraftan nation.
I think I get you, yes. Anything can get specific aspects this way after all, and in the most efficient way. Biomes. Blocks. Mobs. Items. Maps. Worlds. Sub-biomes like Mesa M are customized mesa, written for convenience as adjectives ("accents"/sub-biome/etc) + noun ("letter"/biome/block/mob).
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Actually, Unicode prefers having  as a separate character rather than A + ^. Also, the string ID system effectively renders this obsolete.
Putting the CENDENT back in transcendent!
But I do not want to copy the system from Unicode either, simply the principle of varying byte width with a certain kept logic.
We have colour. We have orientation. We have position. We have type.
If there is a way to keep all this information easy to get and at the same time allowing a lot of freedom, and be able to apply the same system to more than one aspect of coding, then full on customization as well as hopefully less lag are the end goals.
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
To sum things up, data value would be embedded in block id but separated in model, colour and state in order to give much more customizability of blocks while still being file efficient.
As for the current minecraft:filled_map string id, sure, it works somehow, but wouldn't it be great to not have to remember the exact name of blocks, and be able to write "black brick slab" and be understood?
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
FULL SUPPORT.
Thanks for your support! But can you explain more in details what you think I am suggesting? This way we have changes of being on more common ground
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Anyway, so you're saying that you want the programming to handle the "specs" of objects separately, instead of being bound to object types?
Like, for example, instead of having a code that ties a characteristic, like for example the stairs and slab "shapes", only to blocks like stone and wood, change it to a more "free" coding, making it able to handle blocks and characteristics, like shapes, colors, and whatso,separately from the blocks, in a way that could make them be appliable universally to any sorts of blocks. Be it wools, pumpkins, or even gravel.
No worries thanks for answering!
In fact yes, that is the reason for the "Model" component. 16 different shapes for block types. Here is 7 already off the bat and there could (and will) be more overtime:
But as you point out, pumpkin and gravel are a different deal. But in fact, due to the quantity of gravel in the world, it is kept in the program as one byte only along with 128 other blocks.
Let's remember not every block should have all shapes, but the principle allows simplicity and quick computing on that matter.
What I'm looking for is standardisation of block id allowing for easy customizability.
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
I actually disagree with you there. ...I mean, in Vanilla and regular gaming I agree 100%.
but for map-makers and modders I DO think ALL BLOCKS should be able to render in ALL SHAPES in Vanilla itself.
It allows for even greater possibilities of creativity and much more variety in buildings and/or creative use of the game's bugs/glitches (like for example when people make use of the fact that stairs don't block light to make hidden light sources.) and it also opens doors for those that simply can't, for one reason or another, handle modding Minecraft (Or even just don't want to, since some just wanna stick to Vanilla, but without losing freedom of choice.)
Other than that, great to know I got it right. And you have my Full and undying support! ^^
Great, le me le happy
But I agree with you that they could, but normally can't. Hell, an andesite door would be awesome! But what these thing should not be, is craftable.
They in fact could be /given as "andesite stone door" (or hell square, even "trapped cracked stone door" ^^)
2^46+2^31+2^26+2^21+2^16+2^11+2^7=70,370,960,935,040 possibilities is what you can call almost limitless.
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Can you add a spoiler with text for dumb dumbs.
I have a million imported redstone things in my world, will your idea destroy this?
I need help!
Want new mobs in vanilla minecraft? Can't be bothered with mods? To long a wait for the next update?
click here to get more stuff in vanilla
Link RemovedImage RemovedLink RemovedImage Removed
I tried to make a few changes, tell me if it's better, what specifically you have difficulty with?
Link RemovedImage RemovedLink RemovedImage Removed
Image Removed When you support an idea!
Yes I understand a litttle, so bassicly, it makes all that data tag junk easier to understand?
color model state=
/give @p red_wool_slab
I need help!
Want new mobs in vanilla minecraft? Can't be bothered with mods? To long a wait for the next update?
click here to get more stuff in vanilla
Link RemovedImage RemovedLink RemovedImage Removed