sequituri

I'm not seeing your FMLPreinitialization event handler where you should do most of your work, like creating and registering your blocks and items. That might break things.

The error log indicates that you have tried to downcast a vanilla furnace into your own class. Downcasting is not allowed unless you are holding an instance of the proper class or of its subclasses. In this case the TileEntityFurnace is the vanilla one and it cannot be cast into a subclass (your own class). You If you are wrapping a vanilla class, you have to construct your class and pass that as the instance to place instead of the vanilla one.

Gradle projects expect the sources for your project in the folder hierarchy rooted at [PROJECT_HOME]/src/main/java and the assets and assets and resources at [PROJECT_HOME]/src/make/resources.; It puts the final jar final in [PROJECT_HOME]/build/libs As long as that is where you stuff is, you're okay. Otherwise, you might need to learn some Gradle and Groovy to modify the sourceSets and such. Easier to use the premade method.

Look, OP. Doing it that way creates a huge chunk of memory in the dynamic heap (space in your RAM mamory) for every single 'new XYZ(...)' unless that class is trivial, which Block is not. About to time to fill one chunk of space with mushroom block, you have eaten up 16*16*(sizeof HugeMushRoomBlock) * height of blocks... Yeah, a couple chunks and you are done! So, like everyone says, "Don't do that." Learn to code the minecraft way.

Completely separate project, should probably get its own board. Just saying...

If they are all universal, then you should not have a problem. But, there may be client only mods anyways. Did you check each one? BTW, Rei's minimap was abandoned at MC v1.6.2 - since you are running 1.6.4, you are on your own with a fix.

BuildCraft 5.0.0 is not the latest build. And, just in case you're not SpaceToad or one of the devs, you should really post in the BC forums for help on this error.

Yeah, no. Wuppy is not using dynamic blocks, he is assigning the blocks to static fields in his mod class, and notice he is registering each of them. You need to study his code better.

Two things: 1. This probably is the wrong forum for a crash report of this type. It has something to do with mod creation? 2. One of more of your libraries is/are not installed properly.

I'd modify (make a new) explosion method - so it can allow subscribers to all explosions. Then the event sent to subscriber would include the source and target of the blast, and be cancellable. You just have to make sure your explosion method gets called instead of the original.

As to whether overriding methods have to return same type as parent, the answer is no, a more specific type is allowed here as well. See http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.5 However, I think the real problem for the OP is that the Deobjuscating remapper cannot figure out his class hierarchy and went into a recursive loop tracing parents. Obviously then, somewhere the code has a superclass recursion. I just do not see it. The first thing I would do is rename all those fields in ModBlocks (so they don't resemble class names) and make them standard case - start with lower case!

The new launcher uses profiles for each particular game - some with forge, some without, some with 1.7.2 some with another version. Each one allows you to specify the game folder so each mod folder runs with the version of minecraft you pick. Check the button [edit profile] and look for yourself.

Have your tried EnumHelper.addArmorMaterial()?

I'm pretty sure scala compiles right into JVM code.

If your build was successful, then you have a libs folder in the build folder. Otherwise, you might want to post the output of "gradle[w] build", so we can see what went wrong.

Well, obviously, some part of everything you did not do. Why not clean it all up (delete and start over) and follow a tutorial. Then indicate what actual steps you performed, and what error messages you got.

You said, So, i am not following your reasoning on how this can be a Forge error. Care to elucidate, how does it not occur on these other exact same forge servers?

goldRod = new Item().setUnlocalizedName("goldRod").setCreativeTab(CreativeTabs.tabMaterials).setTextureName("pplus:goldRod").setMaxStackSize(64); Rather than try to use the base class Item, why not create your own Item class derived from Item. Also, register your new Item class.

For the love of all that is good, do not break all the standards of good java coding practice. Package names do not contains uppercase letters: package KitchenCraft.MainClass.CounterProperties; Try to follow that conventions already established. e.g. "youruniqueclassifier.modnameorid.subpackage" And if you have any internet domain you own, that makes a perfect uniqueclassifier. Manifest constants are all uppercase: MODID Classes are capitalized: MyClass methods and fields are camel-cased: theInteractor, or theFloat, or myWitdh

Well, movement with WASD only allows forward, backward, and strafe left and right. Turning and looking up/down/right/left requires a captive mouse, so you cannot have both at the same time. At least without a major rework of the movement code. If you want to get into that, I can't help. But, I'd advise against it because users may become very disoriented.

I'm thinking the OP might be talking about an active HUD... I could be wrong. It would allow clicks and such? Perhaps the problem of the cursor always being centered in the visual field might render such a HUD useless (at least for Mouse clicks). If you can't use mouse lick in the "GUI" then in what way would the player interact with it while still being able to move about?

Check out your mods. Dalek Mod in particular. All of the mods have to be for the proper version of minecraft and forge to keep from crashing. You cannot put a 1.6.4 mod in 1.7.2 minecraft and expect goodness.

After looking through the source for net.minecraft.world.storage.WorldInfo class, I can say for certain that this function player.worldObj.getWorldInfo().getNBTTagCompound(); creates and returns a new NBT compound object (loaded with current world info, and the {player: NBTCompound} added), if does not in any way modify the worldInfo object no matter what is done to it, nor is it saved at any point. However, any changes made to the original playerTag should be saved in the course of world saves.

From your pastbin: It seems that heap space is a problem for quite a few people, as far as I can see. I think there was another topic or two where this specific issue is discussed and possibly resolved. I think it had to do with giving gradle more heap space - On a 32-bit machine, I dunno how much is possible - for the decompile.

It looks like you are trying to manipulate a locked cache through gradle. A locked cache should only be possible if another application opened it and crashed??? Or another application is still using it. I'd consider it a gradle bug, but it might just be user error. Have you tried deleting your .gradle folder and rerunning the command?