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