Tyron

I get bellow exception every time. Whats the problem?

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?

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.

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

Thank you very much, TheGreyGhost. Sending the packet to the players individually helped with the crashes. Odd, I had the crash also under Forge Build 1450, but the changelog says its fixed from 1436 on.

I can't look up the source code right now, but what I remember mobs harming entities is done in their respective Entity AI Tasks. I'd Check EntityAIAttackOnCollide and EntityAINearestAttackableTarget

I'm getting some really strange crashes when I testplay my mod via Open-To-Lan. I'm using forge build 1412 The client connecting gets this crash after 0-3 seconds after joining: 09:31:18] [Netty Client IO #2/ERROR] [FML/]: SimpleChannelHandlerWrapper exception io.netty.handler.codec.DecoderException: java.lang.NullPointerException: Undefined message for discriminator 10 in channel vintagecraft - However my mod using the vintagecraft channel registers only Message with the discriminators 0,1,2,3,4,5,6,7! On the machine where i opened to lan I get this crash: Caused by: java.lang.IndexOutOfBoundsException: readerIndex(165) + length(1) exceeds writerIndex(165): UnpooledHeapByteBuf(ridx: 165, widx: 165, cap: 256) at io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1161) ~[AbstractByteBuf.class:4.0.15.Final] at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:563) ~[AbstractByteBuf.class:4.0.15.Final] at net.minecraft.network.PacketBuffer.readByte(SourceFile:609) ~[hd.class:?] at net.minecraftforge.fml.common.network.FMLIndexedMessageToMessageCodec.decode(FMLIndexedMessageToMessageCodec.java:73) ~[FMLIndexedMessageToMessageCodec.class:?] (full crash report) I checked the forge and minecraft source code. This crash apparently happens when Forge tries to read the package discriminator. My best guess which Packet is causing the crash is MechanicalNetworkNBTPacket.java Registered via: packetPipeline.registerMessage(MechanicalNetworkNBTPacket.ClientHandler.class, MechanicalNetworkNBTPacket.class, 4, Side.CLIENT); The packet send command: @SubscribeEvent public void onServerTick(TickEvent.WorldTickEvent event) { [....other code....] if (event.world.getWorldTime() % 40 == 0) { NBTTagCompound nbt = new NBTTagCompound(); writeToNBT(nbt); VintageCraft.packetPipeline.sendToDimension( new MechanicalNetworkNBTPacket(nbt, networkId), event.world.provider.getDimensionId() ); } } What am I doing wrong here?

Thank you for the reply TheGreyGhost, I now have a guess as to why this crash is happening. 1. I'm using EntityJoinWorldEvent to occasionally add another mob to a spawning mob 2. EntityJoinWorldEvent is also fired during chunk loading - which loops through the chunk entitylist -> probably gets modified due to my code adding another entity I'm going to switch over to LivingSpawnEvent, that should probably fix the problem!

My Linux server occassionally crashes with a ConcurrentModificationException. Details here: http://pastebin.com/KfvE7Vt3 I'm only using forge and my own mod on this Server and I have no idea whether this is a bug in forge or with my mod. [Edit:] Ok apparently it happens during server join. Here is the fml logs: http://pastebin.com/38JCw45L How can I debug this?

Ok, thank you very much for the clarification diesieben07. By the way, if you had anywhere a donate button, I'd totally donate a few bucks - you answered so many of my questions already... I'm in your debt.

Maybe I don't understand the concept right but shouldn't EntityRegistry.findGlobalUniqueEntityId() return a different number every time it's being called? Or at least once I used one of the returned id via EntityRegistry.registerModEntity()? I'm registering 2 entities in my mod and the packet handler is mixing up both of them because I registered them with the same number from 2 seperate calls on findGlobalUniqueEntityId() I'm using Forge Build 1412 for MC 1.8

Oh already available. Different than I imagined, but I can work with this. Thank you Forge Code God!

Currently interopability between mods is very limited as requires each mod to include some API code before compiling. I think many mods would require only a small amount of information to be transfered between them to become compatible with each other. As an example, the butterflies in my ButterflyMania mod would only need to know if a particular block is a certain plant, whether it is currently considered food for butterflies and how tall the plant is. It would save a lot of overhead coding, if I just had a simple messaging system or bus that can request such information from a block or item. Similar to existing forge buses or the microsoft windows message system. With such interface it would become very easy for any modder to add compatibility to other mods. It would be like the oredictionary, but for block/item properties instead of recipes. The cost of adding and maintining this code to forge should be comparatively low (= 4-5 new classes below 30 LoC and very few lines of code added to Block.class and Item.class) and the gain for modders pretty high. Example Implementation for blocks (untested pseudo code): // MessageEvent.java: class MessageEvent { public final Class sender; // Mod Instance public final String message; public final World world; public final BlockPos pos; public final Object []params; } // MessageResponse.java: class MessageResponse { public final Class responder; // Mod Instance public final Object []params; } // in Block.class, which each mod can individually override public MessageResponse handleMessage(MessageEvent evt) { return null; } // e.g. in my Butterfly Entity: double foodblockheight = 0D; MessageEvent evt = new MessageEvent(ButterflyMania.instance, "foodBlockHeight", worldObj, pos, null); MessageResponse response = world.getBlockState(pos).getBlock().handleMessage(evt); if (response != null && response.params.length == 1 && response.params[0] instanceof Double) { foodblockheight = (Double)response.params[0]; } I can try to make a pull request if this idea has a chance of getting accepted.

Thanks for the suggestion jabelar. I did some tweaking and think I just got it working now. I guess probably the culprit was the order in the IProperty Array in createBlockState(). I switched that out (amongst other stuff) and now it seems to work.

Thanks for the reply but I'm well aware of the metadata limits. My Anvil is using a tileentity to store the metal type. Only the facing is stored in metadata. You can see that in the coded I posted e.g. in getActualState() in BlockAnvil.java I meant 4 bits, not 4 bytes. It was a typo

It even seems to use the correct texture. Below code prints the textures I assigned to each metal correctly for both server and client. Hmmmmmmm.... There must be some other code in mc other than BlockRendererDispatcher.getModelFromBlockState() that determines the which model json to use @Override public boolean onBlockActivated(World world, BlockPos pos, IBlockState state, EntityPlayer playerIn, EnumFacing side, float hitX, float hitY, float hitZ) { BlockRendererDispatcher brd = Minecraft.getMinecraft().getBlockRendererDispatcher(); IBakedModel ibm = brd.getModelFromBlockState(world.getBlockState(pos), world, pos); System.out.println(ibm.getTexture().getIconName()); return true; }

A block can only hold 4 bytes bits when saved (=getMetaFromState), during runtime you can have as many blockstates as you like - you just cant save/load them together with the block. You have to infer the additional info via neighbouring blocks, store it in a tileentity, or some other custom solution.

I'm at my witts end here. I've been debugging this for 2-3 hours and I bet i'm just missing some comma or space somewhere My custom anvil block renders correctly in the inventory, which means it must have correctly loaded the model json. But when placed it completely ignores my PropertyEnum METALTYPE and just renders with the last item in my enum. Interestingly enough, the second property FACING is working just fine. So, there must be something wrong with either my blockstates json file or by the way it's being loaded I guess. Here is my custom anvil block with METALTYPE=iron once in my hotbar (active item) and then placed on the ground. This is the blockstates json: https://github.com/tyronx/vintagecraft/blob/master/src/main/resources/assets/vintagecraft/blockstates/anvilvc.json The model json files: https://github.com/tyronx/vintagecraft/tree/master/src/main/resources/assets/vintagecraft/models/block/anvil BlockAnvilVC.java, correctly setting up the block properties: https://github.com/tyronx/vintagecraft/blob/master/src/main/java/at/tyron/vintagecraft/block/Utility/BlockAnvilVC.java The enum is here: https://github.com/tyronx/vintagecraft/blob/master/src/main/java/at/tyron/vintagecraft/WorldProperties/EnumMetal.java Any anvil I place always renders with metaltype=bismuthbronze - If I rename the model json file "bismuthbronze.json" all the anvil blocks get the missing texture, so it is indeed using only bismuthbronze.json. - There are no errors logged to console - Client and Server blockstate is in sync as far as i could see This is really perplexing that in f3 mode it displays iron (or any other of the 15 metals) but renders as bismuthbronze. Is there any way I could debug this properly?

Im using the B3D Model loader to use a model created in blender. I'm able to load it but the texture is missing: I'm using the same code as: https://github.com/MinecraftForge/MinecraftForge/blob/master/src/test/java/net/minecraftforge/debug/ModelLoaderRegistryDebug.java The console doesn't show any errors. What could be the problem?

>The GradleStart class is cached so if you run setupDecompWorkspace again it will probably not be regenerated. I remade the dev env from scratch, so nothing could have been cached. > In eclipse you choose the JDK like this: Window > Preferences > Java > Installed JREs This worked! Thanks yet again, you're the real MVP!

Thanks for the reply, this still doesn't seem to help though. I've now set up forge completely anew and ran the following commands: C:\[...]\forge-1.8-11.14.1.1336-src-vintagecraft>set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_71 C:\[...]\forge-1.8-11.14.1.1336-src-vintagecraft>set PATH=C:\Program Files\Java\jdk1.7.0_71\bin C:\[...]\forge-1.8-11.14.1.1336-src-vintagecraft>java -version java version "1.7.0_71" Java SE Runtime Environment (build 1.7.0_71-b14) Java HotSpot 64-Bit Server VM (build 24.71-b01, mixed mode) C:\[...]\forge-1.8-11.14.1.1336-src-vintagecraft>gradlew setupDecompWorkspace --refresh-dependencies + Attachments and other options [....] BUILD SUCCESSFUL Total time: 5 mins 48.241 secs C:\[...]\forge-1.8-11.14.1.1336-src-vintagecraft>gradlew eclipse [....] BUILD SUCCESSFUL Total time: 14.087 secs C:\[...]\forge-1.8-11.14.1.1336-src-vintagecraft> Im starting Eclipse with this command: "C:\Program Files (x86)\eclipse\eclipse.exe" -vm "C:\Program Files\Java\jdk1.7.0_71\bin" Still getting the exact same error I chose JDK 1.7 because I can't see no options to choose JDK1.8 in Eclipse.

No Idea what I have done wrong but since yesterday whatever I do, when trying to launch my mod in Eclipse I get this error: Exception in thread "main" java.lang.UnsupportedClassVersionError: GradleStart : Unsupported major.minor version 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [....] Google suggests I'm using the wrong Java version. In my run configurations the Runtime JRE 1.7.0_71 is selected. What happened? Selecting (x) project specific settings + Java Compliance 1.7 in the Eclipse Compiler doesn't help either. The JRE System Library in the Project is also jdk1.7.0_71

For the last few weeks I have been on and off tyring to code a generic solution that allows me to register groups of blocks of any kind to overcomes the 16 metastates per-block limit. My first attempt was an enumeration that holds all the states, and my code would just register as many blocks as needed to hold all states. But Java Enum cannot be extended so this would be a massive copy&paste for each class of block. My second attempt to overcome the enum limits was to simulate extensible enums via abstract classes. But here I ran into the next limit - you can't extend from, or define abstract static methods. Before I redo it all again, has perhaps already someone solved this limitation in a generic way? Or is there perhaps a software pattern I could use here? What I more or less want to get to is to be able to define a list of blocktypes and the code manages the registering of blocks and setting the metadata for each type, but with the simplicity of java enums, where I could do a call like EnumFlower.Peonia.getBlockState() or EnumFlower.getStateFromMeta(block, meta)

Ugh right, thank you very much.

That happens when you generate stuff outside the chunk to be populated. If you do that, minecraft tries to load the chunk and/or generate another chunk if it does not exist, which in turn gets again populated by your flower gen which again creates new chunks..etc. = infinite loop You have to make sure that you are not generating outside the current chunk. I had the same problems when building my own terrain generator.. I ended up building my own checks on when to populate a chunk or not - vanilla mc does it weirdly.