net.minecraftforge.common.Configuration should use one array, not two. about minecraftforge HOT 7 CLOSED

I still don't know why the item shift has not been updated to 4096, Can a Forge Dev enlighten me?

from minecraftforge.

Cause that would break all the existing worlds. It should have been done when the save changed to anvil.

from minecraftforge.

Until then Itemid on Blockid conflicts have to be treated the same way as Blockid on Blockid conflicts. Right now Itemid on Blockid is ignored and causes "interesting" interactions.

A more extensive solution would include two mod loading passes. The first pass would only load mods that have been loaded previously (have an existing config file) and the second pass would add new mods.

from minecraftforge.

is it now? last time I checked, the items are automatically shifted as necessary.. and are not allowed to have IDs that conflict with Items..

from minecraftforge.

The problem is @AbrarSyed, that items conflict with blocks. To fix this, always use item ids above 4096, and block ids below this. ALWAYS!

What you could do is write a small bit of code that would take two constants, one being 4096 and the other being 256, and shift your items in your own mod by 4096 ( MAX_BLOCK_ID ) minus 256 ( ITEM_SHIFT ), Then when/if ever Forge changes it's item shift to 4096, You change it in your mod and bang you're already compatible and your ids never changed!

from minecraftforge.

The dummy blocks in the block array matching any item which is not an item block prevent this being an issue...

from minecraftforge.

Forge will NOT shift items by 4096. not really wanting to repeat this all, but making old worlds explode is bad mmkay.
This isn't a forge issuse, though, I could optimize it to use a single array as you said, but this has nothing to do with items/blocks in the mods.

Buildcraft needs to get there items out of the 4096 range.

from minecraftforge.