command to clean /fml/registry/... entries of deinstalled mods?

[DanNetwalker 0]

There's this problem that people doesn't run into normally, that when you install a mod its blocks, objects, potions, etc are stored in the map registry, some data structure that links block name with the block ID used in the map.

 

This thing is great for a player that gets a modpack, goes to start a new map and boom! there it works, or migrating a map from a previous modpack version to the next (or players that join a server with blocks disabled? I may have not understood that use case). However, if a player (or modpack maker) has been adding and removing mods to test them for the modpack in a single map, or the mods have been changing over time while you keep playing the same map, the block registry will get filled with entries that are spending block IDs that could be used for real, working mods.

 

Could we please get a command that allows to remove the registry entries related to a mod, so that we can not only deinstall but "purge" it from a map?

[Ernio 600]

While I hate having junk data anywhere - locked IDs are actually not one.

 

If you remove mod that took up some IDs, those IDs must stay locked to point at "null" block (read: AIR).

Whenever chunk is loaded and it can't find block with matching ID in registry, it will replace it to null (AIR).

Not holding those locked IDs would result in chunks that are loaded after adding 2nd mod (so not "purged" between transition from 1st to 2nd), to start loading different blocks - and you really don't want that.

[DanNetwalker 0]

Oh, snap. So the problem it's not only cleaning the /FML registry, but also taking all the generated chunks, hunt for the blocks and change the block id for the air id. And with items it would be worse, it can be burrowed in the NBT data of other blocks... Then it may not be the kind of job for a forge command, but for an external tool or something that does the job during a server boot.

 

Any chance of something like this coming from the Forge team, anyway? If we had a nice command line nbt editor/manipulator I could mix that with mcedit and do it manually, but with the current tools I don't see how we can do that kind of "map repair", more like "map refresh".

[Ernio 600]

You do understand that there is literally no point in making such tool?

The moment ID becomes "nullified" game automatically assumes that given blocks are now AIR, they just stay in world data until you load it.

It's cleaning itself. The only viable approach to such things.

 

Only valid argument here would be lack of free IDs for new mods - which is ridiculous, I can't imagine any map having that much stuff.

 

 

Sure you can remove IDs, load tons of world data files (which is IO that takes time), then iterate over chunks and then blocks and then check agains every removed ID and then change data and save it back. Oh and did I mentiont TileEntities and Entities saved in world? How about Any other mechanism that every saved anything block-related? How about other mods? You can't even be sure you removed everything - and then BAM! Other mod suddenly loads different blocks from it's modded backpack items.

 

Not only pointless, but close to impossible.

 

Why bother?

[DanNetwalker 0]

Only valid argument here would be lack of free IDs for new mods - which is ridiculous, I can't imagine any map having that much stuff.

 

Ejem...

 

 

Not a normal use case, but possible when you install a mod that it's really badly made (a single block id per block in a "huge library of blocks". Missing pieces for example. A frozen world, as another example. Do this mistake too many times and you are forced to abandon your map. Or manually fix it by removing block id by block id with nbtexplorer, which it works fairly well if you clean the map from those blocks  with mcedit, which is a pita because you have to note down block ID by block ID what was added by the removed mod.

 

A mod is removed? Fine. Put it's blocks/items/etc in a black list registry. Then an external tool can turn all that blacklisted blocks into id 0 and clean the blacklist entries after looking at all the chunks. Am I missing something here? As I see it, it's a registry entry and an external tool that loops it, not rocket science... items would be harded, I know, except that most of block containers are fairly standard (chests and such). Only mod blocks would be a problem, and not an uncontrollable problem.

 

And the point of letting players keep using a map that they played in for months? Well... do I really have to explain that?

[LexManos 1596]

Then just delete that entry. There are no plans to write a garbage collector program for this literally one in several million chance that you run through several screwed up mod packs.

 

Someone else can but its so low priority that I doubt I'll ever get to it

[bmwalter68 0]

FWIW, my family has a world we've been playing on for several years.  As we've moved through versions of Forge and various mods it has filled up with a ton of legacy blocks, finally crossing the 4096 explosion point when adding a new mod.  After reading this thread I found World Utils for 1.12.2 which successfully removed 600+ unused blocks from the world.  The command you're looking for is:

 

/worldutils registry remove-missing-blocks 

 

Step by step, here's how I fixed my issues:

1. Back up the old map.  Make sure you don't /fml confirm when it it warns that you've exceeded 4096 blocks!
2. Load up MC running the mods I was interested in keeping
3. Started a clean flat world where I could execute the command
4. Copy the afflicted level.dat into the instances config/worldutils folder
5. Run: /worldutils registry remove-missing-blocks
6. Copy the fixed level.dat back into my old world directory

YMMV and you definitely need to work with a version of level.dat that hasn't been saved after the exceeded max blocks warning.

- B

[LexManos 1596]

3rd party utilities that mess with the world are not supported/endorsed as they have non-insignficant chances of breaking the world.

Beyond that update to 1.13+ to remove the 4096 limitation directly.