As you probably know, prior to 1.13 Mojang was concerned about running out of block IDs - but this is in part their own fault since many blocks that have been recently added used more block IDs than necessary, as well as not fully implementing support for 4096 block IDs (instead of just 256), which has been unlocked by mods ever since it was added in 1.2. For example, fences - they added 5 new blocks instead of taking advantage of data values, which enables as many as 16 types of fences per block ID (or up to 10 more types of wood over what we already have). I've also confirmed that there was nothing within the code that prevented fences from using data values because I recently added more types of fences to my 1.6.4 mod (mainly so mineshafts could use different types of wood depending on the biome):
As you can see, they all have the same block ID but different data values, and as it happens, this is also exactly what they did when they added them to Pocket Edition (which is developed by another team):
So why did Mojang not do this? This applies even moreso to some other blocks, particularly Shulker boxes - which could have used a single ID; they are already tile entities so they could have easily used tile entity data to store their color; stacking different colors is not an issue since they are already unstackable, nor can you stack items with different NBT data.
By taking advantage of data values in my mod I've been able to add dozens of blocks using far fewer new block IDs - you could store as many as 4096 different blocks in just 256 IDs if every single data value were used, as many as 65536 with a simple patch to enable all 4096 block IDs to be used (the simplest way is to shift item IDs up to start at 4096 instead of 256, which I've successfully tested but not implemented. This does waste 4096 item IDs but they could be shifted down by 4096 when accessing the item array and use an unsigned short to allow for over 60000 IDs):
Granite (1:1)
Polished Granite (1:2)
Diorite (1:3)
Polished Diorite (1:4)
Andesite (1:5)
Polished Andesite (1:6)
Coarse Dirt (3:1)
Podzol (3:2)
Quartz Sand (12:1)
Rose Bush (37:1)
Peony (37:2)
Lilac (37:3)
Allium (37:4)
Blue Orchid (37:5)
Oxeye Daisy (37:6)
Paeonia (37:7)
Poppy (37:8)
Red Tulip (37:9)
Pink Tulip (37:10)
Orange Tulip (37:11)
Yellow Tulip (37:12)
White Tulip (37:13)
Cyan Rose (37:14)
Azure Bluet (37:15)
Amethyst Ore (49:1)
Block of Amethyst (49:2)
Reinforced Quartz Sandstone (49:3)
Spruce Fence (85:1)
Birch Fence (85:2)
Jungle Fence (85:3)
Mossy Stone Brick Monster Egg (97:3)
Cracked Stone Brick Monster Egg (97:4)
Chiseled Stone Brick Monster Egg (97:5)
Granite Monster Egg (97:6)
Diorite Monster Egg (97:6)
Andesite Monster Egg (97:6)
Quartz Sandstone (160:0)
Chiseled Quartz Sandstone (160:1)
Smooth Quartz Sandstone (160:2)
Full Smooth Quartz Sandstone (160:3)
Quartz Sandstone Stairs (161)
Magma Block (162)
Packed Ice (174)
Tallgrass (175:0 + 175:1)
Large Fern (175:2 + 175:3)
Large Rose Bush (175:4 + 175:5)
Sunflower (175:6 + 175:7)
Large Peony (175:8 + 175:9)
Large Lilac (175:10 + 175:11)
Large Blue Orchid (175:12 + 175:13)
Diamond Ender Chest (176)
Cobweb Block (177)
Empty Monster Spawner (unlit) (178)
Empty Monster Spawner (lit) (179)
Bone Block (180)
Ruby Ore (181)
Ruby Block (182)
Rail Block (183)
That is 58 new blocks for only 13 more IDs used and this doesn't include variants of blocks like bone blocks (3 different directions) or the two blocks that make up each double tall plant (each one counted as one block since they can never exist by themselves), or blocks which technically already existed within the game, such as bark logs and smooth double stone slabs (the latter act like their own blocks instead of slabs now). Some blocks, like empty monster spawners, use more IDs than would appear to be necessary since the light level is an intrinsic property which applies to all variants of a block, so unlit and lit blocks are needed, and I could have made quartz sandstone a variant of sandstone but wanted it to render as a separate block in MCMap (I could modify MCMap to add them but want others to be able to use a simple colors.txt file to get the right colors), but in many cases this is not an issue and helps group together blocks with similar properties; for example, torches use the following code to see if they can be placed on top of a block which does not have a solid top surface:
If I had added new types of fences using new block IDs I'd have had to modify every single instance like this (a lot) in order to check for every type of fence block but this way they are all grouped together into a single block; this includes the rendering code, where adding a bunch of additional checks could slow things down (I could use "instanceof BlockFence", which would also include Nether brick fences, but then it would break Optifine compatibility as I'd have to modify a class it modifies).
Also, if you are wondering, this is (mostly) all I had to do to add new types of fences; I just extended the existing BlockFence class and made it point to the textures used by planks (instead of just oak planks); I did have to implement a hack to get items to render properly due to the rendering code not passing in data values when rendering a fence item (fixing this the proper way would break Optifine compatibility; as with MCMap I could patch Optifine myself but then nobody else could use it or it they would always render as oak fences). As a bonus, it also fixes that annoying bug when you try to eat (etc) and you instead try to "punch" a fence (they added a right-click function to fences in 1.6 so leads would work but it doesn't check for whether you are holding one, always returning true for the client):
package net.minecraft.src;
import java.util.List;
public class BlockWoodFence extends BlockFence
{
// Set by ItemRenderer when rendering fences so they use the proper texture (hack to avoid modifying
// RenderBlocks as Optifine modifies it). Note that value must be reset to 0 after rendering or fences
// will not render properly.
public static int renderItemMeta;
public BlockWoodFence(int par1)
{
super(par1, "planks", Material.wood);
this.setCreativeTab(CreativeTabs.tabDecorations);
}
public Icon getIcon(int par1, int par2)
{
return Block.planks.getIcon(0, renderItemMeta | par2);
}
public Icon getBlockTexture(IBlockAccess par1IBlockAccess, int par2, int par3, int par4, int par5)
{
return Block.planks.getIcon(0, par1IBlockAccess.getBlockMetadata(par2, par3, par4));
}
public int damageDropped(int par1)
{
return par1;
}
public void getSubBlocks(int par1, CreativeTabs par2CreativeTabs, List par3List)
{
for (int i = 0; i < 4; ++i)
{
par3List.add(new ItemStack(par1, 1, i));
}
}
// No icons are actually registered; uses icons for wood planks instead
public void registerIcons(IconRegister par1IconRegister) {}
public boolean onBlockActivated(World par1World, int par2, int par3, int par4, EntityPlayer par5EntityPlayer, int par6, float par7, float par8, float par9)
{
if (par1World.isRemote)
{
// Only returns true if player is holding a lead so they don't try to "punch" fences
ItemStack item = par5EntityPlayer.getCurrentEquippedItem();
return (item != null && item.getItem() == Item.leash);
}
else
{
return ItemLeash.func_135066_a(par5EntityPlayer, par1World, par2, par3, par4);
}
}
}
According to the Minecraft wiki page on fences, it appears that they use the data value for the connection direction (1 bit each for N/S/E/W), so they had to use separate blocks for the fence material types.
Personally, I think it was a mistake for Mojang to not bump the data bits up from 4 to 8 during one of their major world format organizations (such as when they implemented the McRegion format).
Having 8 data/damage value bits would have consolidated lots of blocks that have both a material type and other requirements for the data bits.
It's called "creative workaround", it's a practice among all developers (but particularly among game developers) that figures out unintended or unplanned ways to use the tools they have available to push out a feature on a sooner rather than later basis. All kinds of relatively impressive speed improvements were implemented in this fashion, wringing out even more use from the very tight 64k byte limit that existed in the days of DOS; nowadays, with far more wiggle room to waste with bloated implementation of bad code, it's more about dealing with new or unplanned-for extensions to an overall idea in ways the code was not intended to be used. This inserts small problems (bugs, design flaws, etc) that grow bigger and bigger until the developer simply has to stop and deal with it all at once.
This is basically the whole concept around the 1.13 Minecraft update, which is pretty much just invisible bugfixes and optimizations that the player is never going to see.
According to the Minecraft wiki page on fences, it appears that they use the data value for the connection direction (1 bit each for N/S/E/W), so they had to use separate blocks for the fence material types.
This is not true though; MCEdit shows the data value of fences as 0 regardless of orientation (this is true not only for 1.6.4 but for 1.12.2, so the change to blockstates in 1.8 did not change the underlying data), and their appearance is solely determined during render time; when rendering a fence the game uses the blocks surrounding it to determine how they should be rendered and this data is not stored anywhere. I did not have to change anything other than making the texture depend on the data value when I added more variants, and if the game internally used it for other purposes they wouldn't render correctly, plus the number of data values needed exceeds the number possible (in order to have 4 variants of fence you'd need 6 bits since there is one "virtual" bit used for each direction a fence may connect in, 4 total, then you need 2 more bits for the variant).
The only issue I ran into had to do with the way the game rendered fences as items; it treats them separately (different render function) and the render function used to render a fence as an item ignores the data value (which is passed into the main render function), and since I did not want to modify code that Optifine modifies I added in a field to my BlockWoodFence class and set it to the appropriate value before rendering the item (it must be set back to 0 afterwards or blocks will have the wrong textures).
1) If it was known internally that the block ID limit [BIL] was slated to be removed in the near future moving to one_block; one_ID could make sense.
[That would seem more likely with the addition of Glazed_Terracotta (1.12) rather than with the addition to the fences (1.8), however,.]
2) Mnemonics: yellow_glazed_terracotta will be easier to remember than stained_glass 4.
[Again, this would make sense only if the removal of the BIL was anticipated.]
3) There may have been a faction within the development group that pushed to hit the BIL because the then necessary expansion would facilitate other changes (e.g. the reworking of the command structure).
[Pure speculation, but the effect of intramural corporate politics can not be ruled out.
Somethings that may lend credence to this being at least partly responsible:
the kindest explanation for how 1.14 is implementing new fence/slab/etc behavior (ie. breaking builds relying on the current blocks) would be that – the removal of the BIL having served its pupose – it is now being ignored.
sunperp's point RE the missed opportunity to increase the size of the data word can also be seen as pointing to less than the greatest of care and forethought being given to these changes.]
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
Here's a dumb question - how is it that they're running out?
Yeah, I get it, wasted block IDs, but why is there a limit in the first place? Such a limit seems so arbitrary and unnecessary, but shedding some light on why it exists would make me feel differently.
Rollback Post to RevisionRollBack
I'm gonna buy a cheap bouquet before it dies on the display.
Here's a dumb question - how is it that they're running out? [1]
Yeah, I get it, wasted block IDs, but why is there a limit in the first place? Such a limit seems so arbitrary and unnecessary, but shedding some light on why it exists would make me feel differently. [2]
[1] This is no longer an issue: the block ID limit [BIL] is slated to be removed as of 1.13
[2] I see this as likely similar to the 640kB limit in IBM pcs: at the time they were created this appeared to be soooo much memory that there would never be an issue… [This sort of failure of foresight wasn't limited to the x86 world either, q.v. the Fat Mac.]
Rollback Post to RevisionRollBack
"Why does everything have to be so stoopid?" Harvey Pekar (from American Splendor)
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
Here's a dumb question - how is it that they're running out?
Yeah, I get it, wasted block IDs, but why is there a limit in the first place? Such a limit seems so arbitrary and unnecessary, but shedding some light on why it exists would make me feel differently.
Chunks are split into 16x16x16 segments. Each segment contains various arrays of byte data about that segment, with each index in the array corresponding to a physical location in the segment (so index 0 might indicate the bottom-most left block, 1 is one block over, etc). We only care about two of these arrays, the "Block" array and the "Add" array. Now the "Block" array contains 4096 bytes (16x16x16=4096=1 byte per block), where the "Add" array contains 2048 bytes (16x16x16=4096/2=2048=1 byte per 2 blocks=4 bits per block).
Numerical ID's for blocks are expressed as 12 bits, which is where the 4096 block ID limit for modded comes from. The first 8 bits are stored in the "Block" array, and the last 4 bits are stored in the "Add" array. When the game reads a given position in the segment, it reads the first 8 bits from the "Block" array, then reads the last 4 bits from the "Add" array, and shifts the 4 bits over to the left by 8 positions. Then it adds the two values together to get the final, full ID. Now the problem is, in vanilla, the "Add" array is somehow disabled. Mods activate it, but Mojang has yet to. So Mojang is still only using 8 bits to store the ID, which results in the 256 block ID limit the game has currently.
They could activate the "Add" array, which would raise the block ID limit to 4096 in vanilla, but 4096 is still pretty low: I ran out of block ID's with 280 or so mods in 1.7.10, when I could easily run 300+ mods on my system. So they're coming up with a new way of storing ID's, that keeps this current system in place, but extends off of it such that each individual ID is unique to the segment it's stored in. Under 1.13's system, chunk segments will also store a thing called an "ID palette", which maps textual ID's ("minecraft:stone") to numerical ID's (3). Because the palette is local to the chunk segment, it moves the 4096 block ID limit from the game itself to each individual chunk segment, which coincidentally each chunk segment can store at maximum 4096 unique blocks (16x16x16=4096), so it's impossible for a single chunk segment to run out of ID's. And that's where the whole "infinite ID" thing is coming from, under 1.13 the limit will be however many block instances an array in Java can store, which at minimum is around 2 billion or so, assuming arrays use signed 32-bit integers.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
As you probably know, prior to 1.13 Mojang was concerned about running out of block IDs - but this is in part their own fault since many blocks that have been recently added used more block IDs than necessary, as well as not fully implementing support for 4096 block IDs (instead of just 256), which has been unlocked by mods ever since it was added in 1.2. For example, fences - they added 5 new blocks instead of taking advantage of data values, which enables as many as 16 types of fences per block ID (or up to 10 more types of wood over what we already have). I've also confirmed that there was nothing within the code that prevented fences from using data values because I recently added more types of fences to my 1.6.4 mod (mainly so mineshafts could use different types of wood depending on the biome):
As you can see, they all have the same block ID but different data values, and as it happens, this is also exactly what they did when they added them to Pocket Edition (which is developed by another team):
So why did Mojang not do this? This applies even moreso to some other blocks, particularly Shulker boxes - which could have used a single ID; they are already tile entities so they could have easily used tile entity data to store their color; stacking different colors is not an issue since they are already unstackable, nor can you stack items with different NBT data.
By taking advantage of data values in my mod I've been able to add dozens of blocks using far fewer new block IDs - you could store as many as 4096 different blocks in just 256 IDs if every single data value were used, as many as 65536 with a simple patch to enable all 4096 block IDs to be used (the simplest way is to shift item IDs up to start at 4096 instead of 256, which I've successfully tested but not implemented. This does waste 4096 item IDs but they could be shifted down by 4096 when accessing the item array and use an unsigned short to allow for over 60000 IDs):
Polished Granite (1:2)
Diorite (1:3)
Polished Diorite (1:4)
Andesite (1:5)
Polished Andesite (1:6)
Coarse Dirt (3:1)
Podzol (3:2)
Quartz Sand (12:1)
Rose Bush (37:1)
Peony (37:2)
Lilac (37:3)
Allium (37:4)
Blue Orchid (37:5)
Oxeye Daisy (37:6)
Paeonia (37:7)
Poppy (37:8)
Red Tulip (37:9)
Pink Tulip (37:10)
Orange Tulip (37:11)
Yellow Tulip (37:12)
White Tulip (37:13)
Cyan Rose (37:14)
Azure Bluet (37:15)
Amethyst Ore (49:1)
Block of Amethyst (49:2)
Reinforced Quartz Sandstone (49:3)
Spruce Fence (85:1)
Birch Fence (85:2)
Jungle Fence (85:3)
Mossy Stone Brick Monster Egg (97:3)
Cracked Stone Brick Monster Egg (97:4)
Chiseled Stone Brick Monster Egg (97:5)
Granite Monster Egg (97:6)
Diorite Monster Egg (97:6)
Andesite Monster Egg (97:6)
Quartz Sandstone (160:0)
Chiseled Quartz Sandstone (160:1)
Smooth Quartz Sandstone (160:2)
Full Smooth Quartz Sandstone (160:3)
Quartz Sandstone Stairs (161)
Magma Block (162)
Packed Ice (174)
Tallgrass (175:0 + 175:1)
Large Fern (175:2 + 175:3)
Large Rose Bush (175:4 + 175:5)
Sunflower (175:6 + 175:7)
Large Peony (175:8 + 175:9)
Large Lilac (175:10 + 175:11)
Large Blue Orchid (175:12 + 175:13)
Diamond Ender Chest (176)
Cobweb Block (177)
Empty Monster Spawner (unlit) (178)
Empty Monster Spawner (lit) (179)
Bone Block (180)
Ruby Ore (181)
Ruby Block (182)
Rail Block (183)
That is 58 new blocks for only 13 more IDs used and this doesn't include variants of blocks like bone blocks (3 different directions) or the two blocks that make up each double tall plant (each one counted as one block since they can never exist by themselves), or blocks which technically already existed within the game, such as bark logs and smooth double stone slabs (the latter act like their own blocks instead of slabs now). Some blocks, like empty monster spawners, use more IDs than would appear to be necessary since the light level is an intrinsic property which applies to all variants of a block, so unlit and lit blocks are needed, and I could have made quartz sandstone a variant of sandstone but wanted it to render as a separate block in MCMap (I could modify MCMap to add them but want others to be able to use a simple colors.txt file to get the right colors), but in many cases this is not an issue and helps group together blocks with similar properties; for example, torches use the following code to see if they can be placed on top of a block which does not have a solid top surface:
If I had added new types of fences using new block IDs I'd have had to modify every single instance like this (a lot) in order to check for every type of fence block but this way they are all grouped together into a single block; this includes the rendering code, where adding a bunch of additional checks could slow things down (I could use "instanceof BlockFence", which would also include Nether brick fences, but then it would break Optifine compatibility as I'd have to modify a class it modifies).
Also, if you are wondering, this is (mostly) all I had to do to add new types of fences; I just extended the existing BlockFence class and made it point to the textures used by planks (instead of just oak planks); I did have to implement a hack to get items to render properly due to the rendering code not passing in data values when rendering a fence item (fixing this the proper way would break Optifine compatibility; as with MCMap I could patch Optifine myself but then nobody else could use it or it they would always render as oak fences). As a bonus, it also fixes that annoying bug when you try to eat (etc) and you instead try to "punch" a fence (they added a right-click function to fences in 1.6 so leads would work but it doesn't check for whether you are holding one, always returning true for the client):
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?
According to the Minecraft wiki page on fences, it appears that they use the data value for the connection direction (1 bit each for N/S/E/W), so they had to use separate blocks for the fence material types.
Personally, I think it was a mistake for Mojang to not bump the data bits up from 4 to 8 during one of their major world format organizations (such as when they implemented the McRegion format).
Having 8 data/damage value bits would have consolidated lots of blocks that have both a material type and other requirements for the data bits.
- sunperp
It's called "creative workaround", it's a practice among all developers (but particularly among game developers) that figures out unintended or unplanned ways to use the tools they have available to push out a feature on a sooner rather than later basis. All kinds of relatively impressive speed improvements were implemented in this fashion, wringing out even more use from the very tight 64k byte limit that existed in the days of DOS; nowadays, with far more wiggle room to waste with bloated implementation of bad code, it's more about dealing with new or unplanned-for extensions to an overall idea in ways the code was not intended to be used. This inserts small problems (bugs, design flaws, etc) that grow bigger and bigger until the developer simply has to stop and deal with it all at once.
This is basically the whole concept around the 1.13 Minecraft update, which is pretty much just invisible bugfixes and optimizations that the player is never going to see.
This is not true though; MCEdit shows the data value of fences as 0 regardless of orientation (this is true not only for 1.6.4 but for 1.12.2, so the change to blockstates in 1.8 did not change the underlying data), and their appearance is solely determined during render time; when rendering a fence the game uses the blocks surrounding it to determine how they should be rendered and this data is not stored anywhere. I did not have to change anything other than making the texture depend on the data value when I added more variants, and if the game internally used it for other purposes they wouldn't render correctly, plus the number of data values needed exceeds the number possible (in order to have 4 variants of fence you'd need 6 bits since there is one "virtual" bit used for each direction a fence may connect in, 4 total, then you need 2 more bits for the variant).
The only issue I ran into had to do with the way the game rendered fences as items; it treats them separately (different render function) and the render function used to render a fence as an item ignores the data value (which is passed into the main render function), and since I did not want to modify code that Optifine modifies I added in a field to my BlockWoodFence class and set it to the appropriate value before rendering the item (it must be set back to 0 afterwards or blocks will have the wrong textures).
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?
In repsonse to the title query:
I can see multiple potential reasons:
1) If it was known internally that the block ID limit [BIL] was slated to be removed in the near future moving to one_block; one_ID could make sense.
[That would seem more likely with the addition of Glazed_Terracotta (1.12) rather than with the addition to the fences (1.8), however,.]
2) Mnemonics: yellow_glazed_terracotta will be easier to remember than stained_glass 4.
[Again, this would make sense only if the removal of the BIL was anticipated.]
3) There may have been a faction within the development group that pushed to hit the BIL because the then necessary expansion would facilitate other changes (e.g. the reworking of the command structure).
[Pure speculation, but the effect of intramural corporate politics can not be ruled out.
Somethings that may lend credence to this being at least partly responsible:
Maybe They wanted to make Minecraft More Interesting Ah Realistic Maybe ??!!
Here's a dumb question - how is it that they're running out?
Yeah, I get it, wasted block IDs, but why is there a limit in the first place? Such a limit seems so arbitrary and unnecessary, but shedding some light on why it exists would make me feel differently.
quote=Daib
Here's a dumb question - how is it that they're running out? [1]
Yeah, I get it, wasted block IDs, but why is there a limit in the first place? Such a limit seems so arbitrary and unnecessary, but shedding some light on why it exists would make me feel differently. [2]
[1] This is no longer an issue: the block ID limit [BIL] is slated to be removed as of 1.13
[2] I see this as likely similar to the 640kB limit in IBM pcs: at the time they were created this appeared to be soooo much memory that there would never be an issue… [This sort of failure of foresight wasn't limited to the x86 world either, q.v. the Fat Mac.]
Because of how they saved the ID's on your storage. Here is the source for all this.
Chunks are split into 16x16x16 segments. Each segment contains various arrays of byte data about that segment, with each index in the array corresponding to a physical location in the segment (so index 0 might indicate the bottom-most left block, 1 is one block over, etc). We only care about two of these arrays, the "Block" array and the "Add" array. Now the "Block" array contains 4096 bytes (16x16x16=4096=1 byte per block), where the "Add" array contains 2048 bytes (16x16x16=4096/2=2048=1 byte per 2 blocks=4 bits per block).
Numerical ID's for blocks are expressed as 12 bits, which is where the 4096 block ID limit for modded comes from. The first 8 bits are stored in the "Block" array, and the last 4 bits are stored in the "Add" array. When the game reads a given position in the segment, it reads the first 8 bits from the "Block" array, then reads the last 4 bits from the "Add" array, and shifts the 4 bits over to the left by 8 positions. Then it adds the two values together to get the final, full ID. Now the problem is, in vanilla, the "Add" array is somehow disabled. Mods activate it, but Mojang has yet to. So Mojang is still only using 8 bits to store the ID, which results in the 256 block ID limit the game has currently.
They could activate the "Add" array, which would raise the block ID limit to 4096 in vanilla, but 4096 is still pretty low: I ran out of block ID's with 280 or so mods in 1.7.10, when I could easily run 300+ mods on my system. So they're coming up with a new way of storing ID's, that keeps this current system in place, but extends off of it such that each individual ID is unique to the segment it's stored in. Under 1.13's system, chunk segments will also store a thing called an "ID palette", which maps textual ID's ("minecraft:stone") to numerical ID's (3). Because the palette is local to the chunk segment, it moves the 4096 block ID limit from the game itself to each individual chunk segment, which coincidentally each chunk segment can store at maximum 4096 unique blocks (16x16x16=4096), so it's impossible for a single chunk segment to run out of ID's. And that's where the whole "infinite ID" thing is coming from, under 1.13 the limit will be however many block instances an array in Java can store, which at minimum is around 2 billion or so, assuming arrays use signed 32-bit integers.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!