[Resolved] Blocks changing into other blocks

[altorac12]

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.

[rj22497]

Could you post your code so we can look through it and find the issues?

[altorac12]

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

[TheGreyGhost]

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

[altorac12]

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.

[TheGreyGhost]

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

 

 

[altorac12]

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.

[altorac12]

I updated to 10.12.2.1121 (latest recommended) and I can't reproduce the issue anymore.  I guess it was just an issue that got resolved and didn't make it into the changelogs.