[1.8] Changing order of block registration messes up old world saves

[Tyron]

How is it that when I add a new block via GameRegistry.registerBlock(), let's say before all my previously added blocks are being registered, that forge doesn't recogonize this and instead all block ids of an old world save messed up (probably shifted by one)?

 

Doesn't forge remember the unlocalized names of blocks on a per-world basis to counteract exactly this problem?

 

I'm not quite sure if this problem is also 100% reproducible. It seems to occur more likely outside the dev environment.

 

Example:

 

Tyrons Mod version 0.1

1. Register Leaves-Block

2. Register Stone-Block

3. Register Ore-Block

 

 

Tyrons Mod version 0.2

1. Register Leaves-Block

2. Register TNT-Block

3. Register Stone-Block

4. Register Ore-Block

 

 

When I then use version 0.2 load up a world saved with versions 0.1, the leaves blocks are okay, but the stone and ore blocks are replaced by another block - i assume they were shifted by that one new block id.

 

 

I would really like to prevent messing up old worlds with every new block added, without the need to always add them at the end of my initBlocks() method as it would prevent any cleanup attempts and complicate matters a lot

[TheGreyGhost]

Hi

 

I had this problem as well, it was caused by Forge doing some remapping of IDs from the save world but it wasn't 100% correctly implemented.  I wasted nearly half a day figuring out what was going wrong.  I thought it had been fixed, but perhaps not.  So far it's never been an issue because I make a new saved game every time I change/add items. That doesn't help much if you've already released the mod though

 

I would suggest you raise an issue at the forge github and provide links to your source and the saved game.  Or even better, it would raise your chances of a successful bugfix if you made a very simple test case and submitted that.  Or best of all, if you debug the source and pinpoint where the bug is (easier said than done)

 

-TGG

[Tyron]

Ok thank you for your help Sir TGG. I will make an example mod and report an issue on Forges GitHub issues page. I hope it is easy to reproduce the bug.

[Draco18s]

I had this problem as well, it was caused by Forge doing some remapping of IDs from the save world but it wasn't 100% correctly implemented.  I wasted nearly half a day figuring out what was going wrong.  I thought it had been fixed, but perhaps not.  So far it's never been an issue because I make a new saved game every time I change/add items. That doesn't help much if you've already released the mod though

 

The irony here is that this Forge bug is why Keybounce was banned from the forums permanently, because it had the potential to corrupt a world irrevocably and Lex told him "that's why it creates a .bak file."  But by the time the player logs in, the .bak files for the world info (containing the original mappings) have been overwritten three times.

[jeffryfisher]

I currently have a similar problem, but it happens when I simply add a second mod to a world that had blocks placed by a first mod. The first mod's saved blocks appear as versions of blocks from the 2nd mod (the 2nd mod is "stealing" block IDs that should still be in use by the 1st).

 

No

 

I have three theories to test:

 

1) Forge has a bug (unlikely)

 

2) I am registering my blocks too soon. Some change in Forge between 1.7.10 and 1.8 may have delayed the acquisition of saved-game data beyond the pre-init phase.

 

3) I did something in the interim to change block name(s) so that Forge did not recognize the saved blocks as belonging to the 1st mod.

 

I'm going to try to find where Forge attempts to reconcile saved blocks with incoming mods so I can see when it happens and by what means.

[Tyron]

I currently have a similar problem, but it happens when I simply add a second mod to a world that had blocks placed by a first mod. The first mod's saved blocks appear as versions of blocks from the 2nd mod (the 2nd mod is "stealing" block IDs that should still be in use by the 1st).

 

No

 

I have three theories to test:

 

1) Forge has a bug (unlikely)

 

2) I am registering my blocks too soon. Some change in Forge between 1.7.10 and 1.8 may have delayed the acquisition of saved-game data beyond the pre-init phase.

 

3) I did something in the interim to change block name(s) so that Forge did not recognize the saved blocks as belonging to the 1st mod.

 

I'm going to try to find where Forge attempts to reconcile saved blocks with incoming mods so I can see when it happens and by what means.

 

 

It is probably the same bug as I experienced: Block IDs get rearranged due to the different order in which they are registered.

I am only working with MC 1.8 so for me it was not during any switchover from 1.7 -> 1.8, but everytime I made larger additions to my mod.

 

I did make a minimal test mod as TheGreyGhost suggested but so far was unable to produce the bug there - a different order of block registration did not cause any remapping of block ids in a old world save.

 

Next time I work on this I will try it out again with my normal mod, there it happened several times. Perhaps it's caused when during a mod update a block is also renamed or removed?

[jeffryfisher]

I just did a strict test: Create a new SP world with my 1st mod, quit-save, then add my 2nd mod and restart the game (none of this in Eclipse). My custom ore generated in the 1st run was still itself after reloading, so we don't have a general bug (there would probably be much more discussion by others if we had).

 

I think that there are some finicky rules regarding edits that we need to nail down. I've been doing my best to religiously preserve block names from 1.7 so my modded world can be upgraded to 1.8. However, I may need to restore it from backup a couple times before I get it right. If I do, and if I find the grind spot in the code where identity can be messed up, I'll post here again with notes on pitfalls to be avoided.