The Apocalypse that is 1.7

gardenapple

Well-Known Member
Mod Developer
Jan 14, 2014
176
265
93
I like to play my own modpacks and while I play Minecraft, I usually keep my launcher open. I see tons of messages that say:
Client> 2014-01-18 16:31:41 [SEVERE] [ForgeModLoader] Found anonymous item of class "item name" owned by mod "mod name", this item will NOT survive a 1.7 upgrade!
Explanation anyone?
 

Tristam Izumi

New Member
Jul 29, 2019
1,460
0
0
It means that 1.7 is the beginning of the end for relying on block/item IDs, and mods that don't define their blocks/items as modname.itemname will need to do so to transition into modded 1.7. Supposedly there is still some legacy block/item ID support still in 1.7, but it's also supposed to disappear in 1.8.

Examples would be like the following (not sure if these are what are actually used, but are a good thought experiment):

mystcraft.inkmixer
bop.mudblock
forestry.copperore
te3.copperore

Note that two items with the same name can exist in the namespace because they belong to different mods. This is at least my understanding of how the change is occurring.
 
  • Like
Reactions: jokermatt999

portablejim

New Member
Jul 29, 2019
267
0
1
It means that the mod author did not have the line
Code:
GameRegistry.registerItem(item, "ModName:ItemName");
in the startup code for their mod
 

portablejim

New Member
Jul 29, 2019
267
0
1
It means that 1.7 is the beginning of the end for relying on block/item IDs, and mods that don't define their blocks/items as modname.itemname will need to do so to transition into modded 1.7. Supposedly there is still some legacy block/item ID support still in 1.7, but it's also supposed to disappear in 1.8.

Examples would be like the following (not sure if these are what are actually used, but are a good thought experiment):

mystcraft.inkmixer
bop.mudblock
forestry.copperore
te3.copperore

Note that two items with the same name can exist in the namespace because they belong to different mods. This is at least my understanding of how the change is occurring.
The correct way is actually "Modname:ItemName".

Supposedly there is still some legacy block/item ID support still in 1.7, but it's also supposed to disappear in 1.8.
Actually, IDs are 'gone' in 1.7 (as far as almost all modders are concerned, or at least should be concerned) and it is all referenced based on names instead. I highly doubt they will go anywhere, apart from disappearing from view where they still currently announce themselves *cough*flat worlds presets*cough*

IDs still exist, but at a lower level (before you press F3+H in 1.7 and exclaim "There is still IDs"). The IDs are determined when creating a world. It takes the list of names and just adds ids based on its list of items and its list of blocks. One exception is the vanilla blocks with have a preset id. Once the world is created, the mapping is stored with the world, so when you come back to it you know what mapping you had and can use that one. If you join a server, the server sends you the ID mappings to use while connected to the server. This method of mapping strings to IDs allows the world file to still use IDs (to be efficient with space) while the rest of the game doesn't have to worry about IDs or conflicting IDs.
 

PsionicArchon

New Member
Jul 29, 2019
147
0
0
It only took four years for the developers to figure out that having to map literally thousands of ids manually was a bad idea. Then there are those crazy folk that insist that Forge will auto-map ids who should take a big fat look at my three thousand block/item long list of mapped ids.

Good bye, good riddance, sayonara, au Wiedersehen, you shan't be missed. It isn't even that difficult to adapt the current method to the new method (Why wasn't this done ages ago!?).

It will no longer take half a week to prep a mod pack for each new version of Minecraft. If anyone's going to worry about anything in 1.7, let it be useful mods vanishing.
 

portablejim

New Member
Jul 29, 2019
267
0
1
It only took four years for the developers to figure out that having to map literally thousands of ids manually was a bad idea. Then there are those crazy folk that insist that Forge will auto-map ids who should take a big fat look at my three thousand block/item long list of mapped ids.

...Why wasn't this done ages ago!?
Well, in vanilla minecraft IDs were quite fine to have predefined as they were. It is only as you start to look to adding lots of additional blocks to minecraft (i.e. modding/plugin API) that you need it. Forge would not do it itself as it would be too much work rewriting vanilla.

As for the timing, I expect they were doing other improvements while they were getting the id changes ready, as well as actually thinking up the current system and making sure it worked.
 

gardenapple

Well-Known Member
Mod Developer
Jan 14, 2014
176
265
93
My friend said that some stuff about how chests work in vanilla 1.7 and that id values greater than 16384 will not be supported. However, i've seen messages pop up complaining about ids ~300-400. Most of them were >17000, though. Is that really the case?