Jump to content

[Resolved] Blocks changing into other blocks


altorac12

Recommended Posts

I'm running into an issue while creating a new mod for 1.7.2.  I'm adding blocks then running the debug version of Minecraft in eclipse to place them to verify they are working properly and the textures are displaying as expected, and a couple of times now after a code change I've had blocks "shift" on me, where all of the block x's will turn into block y's, all the y's become z's and so on in the debug world.

 

I'm not changing the names of anything, and after the second time it happened I started playing around and figured out that if I changed the configuration file to remove a block, launched minecraft, then changed the configuration back I could get this sort of behavior.

 

I have quite a bit of programming/java experience but this is the first time I've tried to mod minecraft and I'm not sure what I could be doing to cause this, I'm hoping someone here might have some ideas.

 

I'm using Forge 10.12.1.1060.

Link to comment
Share on other sites

Here is my main code file, if you want to see some of the individual item/block files I can post those too but they're pretty straight forward subclasses of the standard minecraft versions of those blocks/items.  The general idea is to add birch/spruce/etc. versions of some of the standard oak only blocks.

 

https://gist.github.com/anonymous/dedb9ca7a4124178f0dd

 

Edit: fixed link

Link to comment
Share on other sites

Hi

 

My guess is that your ID allocation code (using i++) is getting out of step on save vs reload.  If you change your code, the numbers allocated to your blocks change, but of course they don't change in the saved world.

 

I'd suggest either changing to a more fixed ID allocation (at least - for debugging), or just regenerating your test world each time and don't worry about it.

 

-TGG

Link to comment
Share on other sites

I don't quite understand what you mean.  It was my impression that with 1.7 you didn't have to manually assign Block/Item IDs so I don't have "ID allocation code".  The i variable here is just keeping track of which wood I'm on and passing i+1 to some of the constructors is just so they know what texture to use (for items like fence/buttons that use the plank texture rather than having their own) and corresponds to the plank metadata value for the wood that item is made out of.  That is why it's only incremented at the end of the loop.

 

If this is for some reason something I'll only ever see in debug I don't have a problem with it, as you say I can regen the debug world each time and it's only a minor inconvenience.  However I'm concerned that if I publish version 1 of this mod, then make changes and release version 2 later then if I don't know what's causing this bug/how to avoid it it's going to end up scrambling all user's saved worlds which is obviously a huge problem.  So I would like to find some explanation so I can be sure a user isn't ever going to run into this issue when changing versions of my mod.

 

I can experiment with how to assign fixed Block IDs in 1.7 (I think I saw somewhere how this is possible) but it was my understanding that this wasn't necessary anymore and going forward the block IDs were eventually going to be removed outright so I'm not sure if that solution is going to work when porting to 1.8 and beyond.

Link to comment
Share on other sites

Hmmm ok.  I'd assumed your code was still for 1.6.4 (didn't read  your original post properly!), but you're right you shouldn't manually allocate IDs for 1.7.

 

I have heard rumours that the world load/save should automatically reassign IDs to the correct block names, although I don't know how that works.  Probably deep in the bowels of GameData.

 

Sorry, no ideas on how to fix it, and yes it does sound like a potential problem...

 

-TGG

 

 

Link to comment
Share on other sites

Well I don't know if I should be relieved that I didn't do something too boneheaded or disappointed that this doesn't sound like a quick fix... If forge should be handling this under the covers is it possible this is a forge bug?  If so I would think someone else would have run into the same thing by now but from what I can tell I seem to be the only one with this problem so I assume it's something in my code.

 

My debug console has several lines saying things like "Found item id mismatch altorac12_woodcompatibility:big_oak_fence : 209 214" after making code changes, but it happens even if there isn't an issue so I don't think it this is necessarily a problem.  It does appear that forge is doing some id remapping though, and most of the time it appears to be successful.

 

On times that I'm reproducing the issue I'm seeing things like the following:

 

[09:40:48] [server thread/ERROR] [FML]: There are unidentified mappings in this world - it cannot be loaded

java.lang.RuntimeException: Mod IDs are missing

at cpw.mods.fml.common.Loader.fireMissingMappingEvent(Loader.java:865)

        ...

 

Given that I took blocks out to reproduce the issue though I would expect the unidentified mappings and the missing mod IDs error, but it's the only thing out of the ordinary I see in the console output.

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.