maximum id range exceeded - even with uninstalled mods

[jermangarc]

Hello everyone. This is my first post, so be gentle, lol. Anyhow, I have come up with an issue I can't figure out. It's with a current map I've been using on my private clan server for over a year now. Now the issue DOES NOT happen on a brand new map, which is why I'm submitting this support topic. Without having to type out thee whole problem all over again, please reference this https://github.com/jakimfett/Minechem/issues/614 issue that first came up a few weeks ago for context.

 

At this point I can't even update my map to the current version of BuildCraft Additions 2.0 because of this. Any help or ideas are appreciated. Thanks again!

[Sigma]

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.

[LexManos]

provide logs

The mod packs {both before and after the issue}

And your world.

FML blocks certain IDs when loading the world to prevent crashes. You may need to go in and manually kill things if you try to do to many changes at once.

Last person I looked at that had similar issue was using a broken mod that was registering the items in a stupid way and changing the registration every update.

 

So provide me what I request and I might be able to debug.

[Sigma]

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.

[Sigma]

[jermangarc]

  On 2/18/2015 at 1:13 AM, LexManos said:

provide logs

The mod packs {both before and after the issue}

And your world.

FML blocks certain IDs when loading the world to prevent crashes. You may need to go in and manually kill things if you try to do to many changes at once.

Last person I looked at that had similar issue was using a broken mod that was registering the items in a stupid way and changing the registration every update.

 

So provide me what I request and I might be able to debug.

 

Hello Lex and thanks for replying. Here are the resources that you've requested. Below is the original support request with the mod I was trying to get installed into my pack a few weeks ago. Like I mentioned the problem has re-introduced itself just trying to UPDATE BC Additions.

 

"Hello jakimfett. Well, after some more testing in my existing world regarding item and block id allocation, I've found that there MIGHT be a problem with how Minechem goes about this process. Let me explain.

 

I've attached the startup log as well as an excel spreadsheet containing item and block ID dumps that I exported in-game; organized the ID's to show totals between a new world and my existing world; found that the startup log error is a bit confusing on line 99549 - "java.lang.RuntimeException: Invalid id 11105 - maximum id range exceeded". Looking up this error I found that modders all agree that "too many mods installed". This is why I'm very confused.

 

If this is true, then my excel spreadsheet tells me otherwise. In my existing map, I have a total of 11104 ID's used up, which coincides with the RuntimeExeption error of 11105, I GET that. But if you look at the Existing world with New Galacticraft install, the ID's go well over this number to total 11183!? What gives? Do you see my problem? or am I missing something? Any thoughts?

 

Sorry if I'm being a pain, you don't have to bother if you don't want to, but I'd really love to get this mod on our server. Thanks for any help you provide.

 

Oops! Almost forgot to include the crash log after I installed Minechem-1.7.10-5.0.5.379.jar. The log file and crash log ARE from same session.

 

Crash Log: http://pastebin.com/Qu42L6rz

Log file: https://dl.dropboxusercontent.com/u/72156241/Item-ID-mismatch.txt

Spreedsheet: https://dl.dropboxusercontent.com/u/72156241/item.xlsx

"

WORLD SAVE FILE: https://dl.dropboxusercontent.com/u/72156241/Minecraftia.zip

MODPACK FILES: https://www.dropbox.com/sh/6686fdq2g8u7u9s/AABOFfiW7PNoScL0VkLQdC6Da?dl=0

 

Since this reply to Jakimfett, I've actually uninstalled Bibliowoods Forestry Edition, RedLogic and OresPlus (these were redundant and using up over 1,500 ID slots). So I'm currently trying to see if this will work since so many slots have been made "available".

[jermangarc]

Well bad news, after uninstalling all those three mods and saving the world in that state, I tried updating RFTools, an existing mod in my pack and I got the "maximum ID range" error again. Here is the latest log for that. For some reason all those ID's are not being released.

 

https://dl.dropboxusercontent.com/u/72156241/fml-client-latest.log

[LexManos]

Let me explain this.

IDs are NOT freed when you remove a mod from a world. They are preserved for when you re-add the mod.

Somehow your world is setting a block to 11,000

The max block ID is is 4096.

You have a lot of ID mismatches in your world.

You may need to find a way to manually fix the world, it looks like it's fubared.

How long has this world existed? Are you trying to update from 1.6.4->1.7.10 directly? You should go through 1.7.2 first.

[jermangarc]

Yes, the world started in 1.6.4, without mods though. I started adding mods in 1.7.2 and subsequently when I updated to 1.7.10. I don't mind updating the ID's, but how do you do that? In 1.6.4, I've read that there were configs to do that, but in 1.7.10 it's all automated.

 

If not, then you're right then. I somehow knew forge wasn't freeing up those ID's, which makes sense now. This seems to be a huge limitation, especially for server owners. Too bad it can't be configurable to free up ID's as an option to players. Going to have to break the bad news to my player base. Thanks for all your help Lex.

[Sigma]

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.

[LexManos]

If you loaded from 1.7.2+ things should all work just fine as long as mods handle their names correctly.

Your world is downloading now so I can try and take a look.

However, something in your blocks is setting the ID to 11,000 which is not possible for Forge to do as the max ID is 4096.

[jermangarc]

Agreed, I understand that now. Makes perfect sense. I'm actually updating the modpack right now, to reflect the changes to the world you're downloading. Thanks again Lex!

[Sigma]

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.

[LexManos]

You can manually edit the id values in the level.dat

But its breaknig shit.

And as stated ids are not freed because they still exist in the world.

Without converting the ENTIRE world and support EVERY TE we can't force remove all the old items/blocks.

 

Now what happens if you delete a mod

and then re-add it later. Rather then have corrupted items in your world it automatically re-maps them and your world loads fine.

 

I'll look into it more later.

Fuck worst you can do is delete the ID map in level.dat and HOPE it works.

If that fixes it for you then fine, but SOMETHING other then Forge has caused your world to corrupt, There should be no possible way for a BLOCK to get a ID over 4,000 in a Forge controlled environment.

[jermangarc]

I figured. I've got the level.dat file open right now. Over 12,000 entries in the ID section. DAMN!!! Don;t know if I'm ready to do all that work, lol. If I figure something out, I'll post it here. Thanks again Lex!

[Sigma]

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.

[LexManos]

Think of it this way...

Game Starts

World META Loaded

Old IDs 'freed' and new ids assigned in those slots.

Then SOME world chunks start the load, this is the part that uses the IDs.

 

The problem is the SOME part.

We do not load the ENTIRE world and force everything to free the ids.

So you have old chunks that still have references to the 'unused' ids.

If those IDs are reassigned then the chunk doesn't know and just loads them like normal.

 

Think of it this way. You're running around and there comes a mod that adds a nice cool volcano to world gen.

Fly around see a bunch of volcanoes and decide you don't want that mod anymore.

So you remove it, and add a new mod that adds a new type of log.

If that volcano block ID is freed, the log would instantly take it.

You load the world up and go back to where you saw those volcanos.

Those volcanoes are now made out of logs!

 

When it comes to the chunks themselves, ALL they know is the integer ID numbers. They don't care that the old ID #32 was basalt, but the new #32 is logs. It just knows that it has #32 and loads it.

 

Now that doesn't seem like a big deal, but what happens when blocks rely on tile enties and IDs switch around. Suddently the world is crashing because the block THINKs it has a TE there but doesn't.

Or if things get shuffled and you get those 'TileEntityChest cant be cast to TileEntityKite' type errors.

[jermangarc]

Got it! So the problem lies in the unloaded chunks. So if you have a world that's made up of hundreds of chunks, then you would have to visit every chunk in existence before installing any new mod; if ID's were to be "freed" and "re-assigned". That could be feasible depending on the size of the world.

 

In essence you've installed a fail-safe.

[Sigma]

"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?

[jermangarc]

Basically if Forge DID let go of block ID's and make them "available" upon uninstalling a mod, any unloaded chunks in a world would still retain their block ID's until you go back and visit those chunks and reload them, remember Lex's example of the volcano basalt blocks rendering as logs, that would not be good. This is why Forge does not release the ID's. I still think there should be an OVERRIDE option in Forge's config to let the player decide this though. It would be much more flexible, especially for older worlds. I'm always deleting unused chunks using MCEdit to keep the world borders fresh, so in my case (and I'm sure for many other's) it would be great if Forge allowed me to override the reserved ID's.

[LexManos]

There is nothing stopping you from using a NBT editor on your world and freeing the IDs yourself.

One idea that would be nice is someone creating a world ID management tool that actually takes advantage of Forge's ID table.

It's just not very user friendly right now.

[jermangarc]

Yeah, I might be that person. I've been thinking about taking up modding, but on the server admin side of things. There are very few mods out there doing these roles and we sorely need more. Thanks for the suggestions though. I've actually figured out how to do it and I'm back on track installing and updating the mods I needed in the world. Thanks again man!

[Sigma]

  On 2/21/2015 at 10:47 AM, jermangarc said:

Yeah, I might be that person. I've been thinking about taking up modding, but on the server admin side of things. There are very few mods out there doing these roles and we sorely need more. Thanks for the suggestions though. I've actually figured out how to do it and I'm back on track installing and updating the mods I needed in the world. Thanks again man!

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