Sigma

Any chance you could share what you did to resolve this?

"We do not load the ENTIRE world and force everything to free the ids." This is the part that confuses me- if there are old blocks that would cease existing because a mod has been deleted, isn't that exactly what should be happening? Even if the process takes time for larger worlds, this seems like a better alternative as an optional feature to breaking old saves, surely?

Mind you, I know full well that I don't have intimate knowledge of the inner workings of forge or the ID system as it is right now, so I hope I don't sound terribly ignorant- but is having the world interpret unused block/item IDs in a running instance as empty air and resetting the associated IDs automatically out of the question for the purposes of fixing worlds like this? I tried deleting the "BlockedItemIds" section under FML in the level.dat using NBTExplorer and that finally got me somewhere as it seems the world is intact and I can update again, but I would never have gotten to this point without being told explicitly this is how IDs work, and I can imagine this might be a problem further down the line for older worlds as people migrate through updates to mods/minecraft/forge.

Is there a particular reason IDs don't get freed automatically when handled by Forge? Truthfully, I can't think of a way to handle fixing a world gone "fubar" in 1.7.10 if the client isn't able to handle it directly, so I don't know what my options are. In 1.6.4 I was able to manually edit config ID values, and it was a pain in the ass, but at least I knew I could do it if I had to in a scenario like this.

In my case, the world was started on 1.7.10 in the first place- is there no way to free up unused IDs using the client as a template? I'd like to repair the world rather than reset, but the fact that IDs aren't freed is a problem I'm not sure how to get around myself.

I'll make a more detailed post with logs/world file, but it's worth noting that this problem tends to manifest in a specific way for me, and makes me wonder whether there are more instances of the issue going undocumented as a result of crash logs being misleading. I get a crash-log with the message "java.lang.ClassCastException: X cannot be cast to Y" where "X" and "Y" are two mod's blocks that interact without problems until sticking a third, unrelated mod into the pack. Scouring through the logs at the time of the crash shows a message "Maximum ID range exceeded" when that third mod attempts to add new blocks/items, but things get weird at this point. A typical solution for this problem is to uninstall mods to fix the crash- but in this instance, the actual problem is not a lack of IDs because the client can produce a new map or world with 100% success and total functionality, only crashing when attempting to load an older map with the same exact client setup.

I made an account just to say I'm experiencing the same problem and am having trouble updating mods, even after having removed plenty to make double sure (on the scale of hundreds of blocks/items) to update mods that add a handful of new ids. Loading a new world works fine, which is why this is a definite cause for concern- accessing an old one is what results in a crash, always preceded by forge telling me my level.dat is being used.