Jump to content

[1.8.9] Bizarre Block Substitution After Upgrade


jeffryfisher

Recommended Posts

I'm trying to move forward from 1.8 (Forge build 1450) to 1.8.9 (recommended Forge build 1722). Updating my mods was straightforward (fix a few srg names with new deob names). My trouble started when I used a 1722 client to open a test world created by build 1450.

 

While vanilla block types all appeared to be where I remembered them, my mods' block types had all been scrambled. Walls had been replaced by sensors, the sensors had been replaced by solid blocks from another mod, a custom pressure plate had turned into a wall, and at least one block type had simply vanished.

 

Comparing the logs between my last load of 1450 versus loading 1722, the block IDs all appear to be unchanged, at least at the moment of registration (and my mods don't use IDs anyway except to print those registration messages). Except for an unknown biome being treated as ocean, there are no errors to show, and no hints at substitutions.

 

I tried running in Eclipse's debugger (with one mod and its test world), and the behavior was different: The mods' blocks retained their identities, but each was displaced to a new blockpos, each block type moving a different distance and direction. Ironically, the one tile entity instantiated at its correct coords, which meant that its corresponding block no longer functioned.

 

I'm unsure at what level the problem arises. Is it Minecraft 1.8.9? Forge build 1722? Or, is there some secret sauce that mods use to stabilize their blocks? Should I cap my 1.8 worlds at some other Forge build for 1.8 or 1.8.8? Is there some way to log more information?

 

If the "recommended" build (1722) is not a good one to use, then which build would be safest to try?

 

EDIT:

 

I used old build 1450 to open the "scrambled" world saved by build 1722, and my blocks were unscrambled! Some metadata has changed (like where a wall had been interpreted as a moon-phase sensor, when it became a wall again, its texture matched what the phase of the moon had been instead of what the original wall had been).  All that was missing was tile entities that had deleted themselves during the scramble because the blocks at their positions had invalidated them.

 

As interesting as all that is, I am still wondering whether I should freeze my world at 1450, try to upgrade to the last 1.8, upgrade to the last 1.8.8, or try a different build for 1.8.9. If anyone has any experience with upgrading saved worlds, you could save me a lot of work by sharing what you've learned.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

Well, I've tried a few ways to ask about how to safely transition a modded world to 1.8.9 from an earlier version of 1.8. The fact that nobody has chimed in with any experience doing so is in itself information: Apparently I am trying to do something that nobody else in their right mind would try. It is finally dawning on me that a mod may be ported from version to version, but new worlds should be created at each level. I guess modded worlds with added block types just don't travel well.

 

Still, I am curious. If anybody has ever attempted to open a modded world in 1.8.9 that was created in 1.8, please tell us how it went. If you had block types being scrambled in translation, did you find any clues to how and where the scrambling took place?

 

For me, 1.8.9 was just a stepping stone toward 1.9, so I will probably not bother creating a new server world to run my updated mods. I am instead stepping back to 1.8 to find the best Forge build to use as a "final" version on which to run my client and 1.8 server.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

The same thing has happened to me. Opened an old world with updated mods that create new blocks and the blocks are all scrambled. I suspect that the updated mod with blocks is using different block IDs or something. Occasionally Minecraft adds blocks to the game and that may have something to do with the block IDs changing. I have a mod that has a metal ladder and that was consistently replaced with an iron trapdoor. Another mod block was replaced with slime blocks.

The fact that you can open the old world with the correct version of forge and everything reverts makes me think the block ID is the issue. I don't really know though.

Link to comment
Share on other sites

I saw the slime blocks when I used 1.8 to open a 1.7.10 world. That was indeed a case of vanilla mc claiming IDs that Forge had used for blocks registered by my mods.

 

The latest scrambling is something different. Having learned my lesson (some lesson) the last time around, I put an output statement in my registration helper method so every block and item in every mod reports its ID. As I reported in my OP, all of my registration IDs were the same in 1.8.9 (build 1722) as in 1.8 (build 1450). However, identities got rotated all around.

 

And they're swapped predictably, which means something systematic is happening, but circular: Walls became sensors or the blower, sensors became either walls or nethergem blocks, and the invention became the iron gate from my walls mod. It's not like each block is shifting down in one direction. It's a crazy remapping that I don't understand and don't want. Why didn't the registration IDs stick? How do I make it stop?

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

  • 1 month later...

I got the same problem. Most (but not all) of my blocks are scrambled. I updated from forge-1.8-11.14.0.1281-1.8-src to forge-1.8.9-11.15.1.1722-mdk (Mod development) and Forge 11.14.3.1450 to Forge 11.15.1.1722 (Forge version used while playing)

It seems it scrambles only because I've got more than one mod running. If I create a new world in 1.8 with only one of my mods the blocks seem perfectly ok in 1.8.9. This gives me a feeling of scrambled mod-IDs?

 

Is this the same problem as this one? http://www.minecraftforge.net/forum/index.php/topic,36733.0.html

Because it was asked on the other thred here are my mods and worlds, both 1.8 and 1.8.9:

1.8 and 1.8.9 Mods and World (I also use Optifine but that shouldn't be a problem, should it?)

Link to comment
Share on other sites

If the mod IDs are being scrambled, then it's happening sometime after registration (or it's happening to a different set of IDs than what I've been looking at).

 

My reg calls all log their resulting IDs so I can check for that very phenomenon, and my 1.8.9 IDs matched my 1.8 IDs.

 

I've decided that (for now) modded worlds with custom blocks are version-locked. I'll just create a new one from time to time.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.