They switched to names instead of numerical IDs because it's a lot easier to remap if an update comes out. Otherwise you have issues like dirt blocks being replaced with something widely different like pumpkins.
Plus, not everyone can remember ID 1 being grass or dirt.
They switched to names instead of numerical IDs because it's a lot easier to remap if an update comes out. Otherwise you have issues like dirt blocks being replaced with something widely different like pumpkins.
Plus, not everyone can remember ID 1 being grass or dirt.
Yes, not everyone can remember ID 123 is redstone lamp (for instance). They could provide in-game dumps for that problem or get rid of them, they chose to get rid of numerical IDs in 17w47a. Now all numerical IDs are random and there is no fixed int <-> string mapping.
Rollback Post to RevisionRollBack
My mod with manually registered ItemBlocks of technical blocks:
If this is a reply to my comments on this thread I very well know that 1.8+ can handle numerical IDs; else, how could you upgrade a world from older versions? I was referring to 1.8 changing item IDs to strings in the save format, causing issues with older versions and map editors which expect numerical IDs; i.e. casting NBTTagString to NBTTagShort, and this being a possible reason why MCEdit2 doesn't support older versions, i.e. it always handles item IDs as strings, which will cause them to crash with a class cast exception, and/or delete chunks with erroring items (block data was still numerical until at least 1.12, and even 1.13+ uses a "palette" to translate section-local numerical IDs to global blockstates):
(I've never used it but I notice that MCEdit2 only claims to support 1.7-1.12, though nothing actually changed in the save format in 1.7; 1.8 changed item IDs from numerical to strings. [note - in the save format, as I proved by showing an MCEdit analysis of a 1.8+ world with items being "minecraft:stone", etc]
In fact, here is a comment I made 8 years ago about how 1.8 appeared to be constantly translating to and from numerical IDs within the code, in part explaining why it is so much slower and more complicated than older versions (in particular, this refers to initial terrain generation, which fills an array with numerical IDs based on a terrain heightmap/3D noise, then it runs the cave generator on it, then it initializes a chunk with the final terrain data; unlike 1.6.4, which simply directly reads reads and writes from the array, 1.8 must translate the IDs to a "blockstate" object, then read the block it represents, and vice-versa, which adds a huge amount of overhead to performance-critical code (I even eliminated the need to reference block objects to check IDs, e.g. "if (id == Block.stone.blockID)", by adding constants corresponding to their IDs, which are inlined at compile time, e.g. "if (id == 1)"):
(just because I've never actually played on a version since 1.6.4 doesn't mean I know nothing about them - in fact, I made mods for versions as recent as 1.13, and various GitHubs have the source code for versions as recent as 1.12)
If this is a reply to my comments on this thread I very well know that 1.8+ can handle numerical IDs; else, how could you upgrade a world from older versions? I was referring to 1.8 changing item IDs to strings in the save format, causing issues with older versions and map editors which expect numerical IDs; i.e. casting NBTTagString to NBTTagShort, and this being a possible reason why MCEdit2 doesn't support older versions, i.e. it always handles item IDs as strings, which will cause them to crash with a class cast exception, and/or delete chunks with erroring items (block data was still numerical until at least 1.12, and even 1.13+ uses a "palette" to translate section-local numerical IDs to global blockstates):
In fact, here is a comment I made 8 years ago about how 1.8 appeared to be constantly translating to and from numerical IDs within the code, in part explaining why it is so much slower and more complicated than older versions (in particular, this refers to initial terrain generation, which fills an array with numerical IDs based on a terrain heightmap/3D noise, then it runs the cave generator on it, then it initializes a chunk with the final terrain data; unlike 1.6.4, which simply directly reads reads and writes from the array, 1.8 must translate the IDs to a "blockstate" object, then read the block it represents, and vice-versa, which adds a huge amount of overhead to performance-critical code (I even eliminated the need to reference block objects to check IDs, e.g. "if (id == Block.stone.blockID)", by adding constants corresponding to their IDs, which are inlined at compile time, e.g. "if (id == 1)"):
(just because I've never actually played on a version since 1.6.4 doesn't mean I know nothing about them - in fact, I made mods for versions as recent as 1.13, and various GitHubs have the source code for versions as recent as 1.12)
That is another reason to stick in 1.7.10 and 1.6.4 for modification development. There are no such things that makes the mod development difficult:
If this is a reply to my comments on this thread I very well know that 1.8+ can handle numerical IDs; else, how could you upgrade a world from older versions? I was referring to 1.8 changing item IDs to strings in the save format, causing issues with older versions and map editors which expect numerical IDs; i.e. casting NBTTagString to NBTTagShort, and this being a possible reason why MCEdit2 doesn't support older versions, i.e. it always handles item IDs as strings, which will cause them to crash with a class cast exception, and/or delete chunks with erroring items (block data was still numerical until at least 1.12, and even 1.13+ uses a "palette" to translate section-local numerical IDs to global blockstates):
In fact, here is a comment I made 8 years ago about how 1.8 appeared to be constantly translating to and from numerical IDs within the code, in part explaining why it is so much slower and more complicated than older versions (in particular, this refers to initial terrain generation, which fills an array with numerical IDs based on a terrain heightmap/3D noise, then it runs the cave generator on it, then it initializes a chunk with the final terrain data; unlike 1.6.4, which simply directly reads reads and writes from the array, 1.8 must translate the IDs to a "blockstate" object, then read the block it represents, and vice-versa, which adds a huge amount of overhead to performance-critical code (I even eliminated the need to reference block objects to check IDs, e.g. "if (id == Block.stone.blockID)", by adding constants corresponding to their IDs, which are inlined at compile time, e.g. "if (id == 1)"):
(just because I've never actually played on a version since 1.6.4 doesn't mean I know nothing about them - in fact, I made mods for versions as recent as 1.13, and various GitHubs have the source code for versions as recent as 1.12)
This thread is not a reply to your post I just showed a fact to everyone
String ids has been come into existence in 13w37a. That is another reason why I play in 1.7.10, I can use both numerical (Integer) and alphabetical (String) IDs, that makes some stuff easier (obtaining items, placing blocks). But 1.7.10 is not perfect, because:
- 1.7.10 (also 1.6.4) is barely represented and mostly unsupported in modding community
- 1.7.10 does not support alphabetical IDs for status effects
- Vanilla 1.7.10 hass less content than latest version //That does not really matter, many people uses Forge
Although 1.7.10 has that disadvantages, these are not enough to stop me! The game is progressively getting ruined with new up(!)dates, and I stick to 1.7.10 for not being affected by these up(!)dates.
It sounds crazy but all versions up to 17w47a can read numerical IDs. Steps to try:
-Open NBTExplorer
-Find a Minecraft world in versions from 1.8 to 1.12.2 (inclusive)
-Find "Inventory" entry list
-Delete all entries in the "Inventory"
-Create a "Compound" tag
-Create four tags under that compound: Count (byte) | Damage (short) | id (int) | Slot (byte)
-Set "Count" to any number between 1 and 127.
-Set "Damage" to 0
-Set "id" to an item or non-technical block ID (for instance 1, 2, 256 etc)
-Set "Slot" to 0
-Save all stuff
-Open Minecraft and load the world
An item (or ItemBlock) should appear in your inventory.
If you choose to not to delete the inventory contents, set the slot to an empty slot (Slots are defined as x-1, x is the appeared slot)
My mod with manually registered ItemBlocks of technical blocks:
[mod]obtain-blocks-mod[/mod
That's how it works internally.
They switched to names instead of numerical IDs because it's a lot easier to remap if an update comes out. Otherwise you have issues like dirt blocks being replaced with something widely different like pumpkins.
Plus, not everyone can remember ID 1 being grass or dirt.
Yes, not everyone can remember ID 123 is redstone lamp (for instance). They could provide in-game dumps for that problem or get rid of them, they chose to get rid of numerical IDs in 17w47a. Now all numerical IDs are random and there is no fixed int <-> string mapping.
My mod with manually registered ItemBlocks of technical blocks:
[mod]obtain-blocks-mod[/mod
If this is a reply to my comments on this thread I very well know that 1.8+ can handle numerical IDs; else, how could you upgrade a world from older versions? I was referring to 1.8 changing item IDs to strings in the save format, causing issues with older versions and map editors which expect numerical IDs; i.e. casting NBTTagString to NBTTagShort, and this being a possible reason why MCEdit2 doesn't support older versions, i.e. it always handles item IDs as strings, which will cause them to crash with a class cast exception, and/or delete chunks with erroring items (block data was still numerical until at least 1.12, and even 1.13+ uses a "palette" to translate section-local numerical IDs to global blockstates):
In fact, here is a comment I made 8 years ago about how 1.8 appeared to be constantly translating to and from numerical IDs within the code, in part explaining why it is so much slower and more complicated than older versions (in particular, this refers to initial terrain generation, which fills an array with numerical IDs based on a terrain heightmap/3D noise, then it runs the cave generator on it, then it initializes a chunk with the final terrain data; unlike 1.6.4, which simply directly reads reads and writes from the array, 1.8 must translate the IDs to a "blockstate" object, then read the block it represents, and vice-versa, which adds a huge amount of overhead to performance-critical code (I even eliminated the need to reference block objects to check IDs, e.g. "if (id == Block.stone.blockID)", by adding constants corresponding to their IDs, which are inlined at compile time, e.g. "if (id == 1)"):
https://www.minecraftforum.net/forums/minecraft-java-edition/recent-updates-and-snapshots/2202539-is-1-8-lagging-for-you-poll-lets-settle-this-issue?comment=672
(just because I've never actually played on a version since 1.6.4 doesn't mean I know nothing about them - in fact, I made mods for versions as recent as 1.13, and various GitHubs have the source code for versions as recent as 1.12)
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?
That is another reason to stick in 1.7.10 and 1.6.4 for modification development. There are no such things that makes the mod development difficult:
- Block states
- JSON models
My mod with manually registered ItemBlocks of technical blocks:
[mod]obtain-blocks-mod[/mod
This thread is not a reply to your post I just showed a fact to everyone
String ids has been come into existence in 13w37a. That is another reason why I play in 1.7.10, I can use both numerical (Integer) and alphabetical (String) IDs, that makes some stuff easier (obtaining items, placing blocks). But 1.7.10 is not perfect, because:
- 1.7.10 (also 1.6.4) is barely represented and mostly unsupported in modding community
- 1.7.10 does not support alphabetical IDs for status effects
- Vanilla 1.7.10 hass less content than latest version //That does not really matter, many people uses Forge
Although 1.7.10 has that disadvantages, these are not enough to stop me! The game is progressively getting ruined with new up(!)dates, and I stick to 1.7.10 for not being affected by these up(!)dates.
My mod with manually registered ItemBlocks of technical blocks:
[mod]obtain-blocks-mod[/mod