SanAndreaP

No, don't check if it's the server in your Render class. This is purely client-side. What I meant is when you spawn the entity, (through an item most likely), there you have to check if it's server-sided. (worldObj.isRemote == false)

I just like to seperate stuff. It's just a difference in coding style, not a functional one. BTW: the registerPackets method in my proxies are deprecated. I didn't come around to remove them, so you can ignore those.

[19:35:24] [main/INFO] [FML/]: Java is Java HotSpot(TM) 64-Bit Server VM, version 1.8.0_20-ea, running on Windows 8:amd64:6.2, installed at C:\Program Files\Java\jre8 I see you have Java 8 installed. Try Java 7 and see if it works. As I've heard, there are still some problems with Java 8.

Just convenience, also every (at least AFAIK) vanilla entity only overrides the entity one. It doesn't mess anything up if you use the other one. Just make sure on both you call the super method. Just more readable and convenience. You can put it anywhere in the method, but make sure it gets called every time.

Do you check if it's the server world you're spawning the entity (worldObj.isRemote == false)? If not, that's the problem. You spawn a ghost entity on the client which does nothing.

// Call Parent super.writeToNBT(tag); // Call Parent super.readEntityFromNBT(tag); so, I see 2 problems here: in your readFromNBT method, you call super.writeToNBT and readEntityFromNBT. The first writes the position to the NBT, which in this state is still 0,0,0. Also readEntityFromNBT doesn't read the position AFAIK, and if it does, it would read the 0,0,0 you've wrote in your previous call. I suggest not to override readFromNBT/writeToNBT methods in entities but rather use the readEntityFromNBT/writeEntityToNBT, an the first call in this method is the super call to the same method.

I like this one. It also seems pretty straight forward and actually takes a similar approach to what I was trying to do. Since you're a much more expert coder than I, I assume that this already works in multiplayer as well? Yes, works flawless for me. There's an example packet class in the link. To send / receive packets, use something like this: IPacket packet = new PacketChangeBCGUI(3, this.teBiomeChanger.xCoord, this.teBiomeChanger.yCoord, this.teBiomeChanger.zCoord); ESPModRegistry.channelHandler.sendToServer(packet); First instantiate the new Packet class with the parameters you wanna send, then just send it with your channelHandler. 1. I had some problems when I initialized directly on declaration, so you might wanna use the preInit for that. You can also use the modConstruction event like I did, it's fired also for normal mods. 5. I think this is a problem with MC directly, idk.

Caused by: java.lang.NullPointerException at org.objectweb.asm.ClassReader.<init>(Unknown Source) at invtweaks.forge.asm.ContainerTransformer.transform(ContainerTransformer.java:112) at net.minecraft.launchwrapper.LaunchClassLoader.runTransformers(LaunchClassLoader.java:276) at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:174) well, I suspect Inventory Tweaks. Remove it and see what happens.

If you wanna try a different approach on packet handling, look at this code: https://github.com/SanAndreasP/SAPManagerPack/tree/master/java/de/sanandrew/core/manpack/mod/packet https://github.com/SanAndreasP/SAPManagerPack/blob/master/java/de/sanandrew/core/manpack/mod/ModCntManPack.java And simultaneously this tutorial I've based it off (I recode some stuff, since it was a bit messy IMO) http://www.minecraftforge.net/wiki/Netty_Packet_Handling

Go to the forum thread then. This is a forum for Forge problems, and this is clearly not one of them.

There's a method you can override in your block class called getLightValue(IBlockAccess world, int x, int y, int z)

AFAIK, you either need the mod's source directly, or use CodeChickenCore (put it into the mods folder)

Add a new instance of DefaultArtifactVersion

To get the world's save directory (the folder where the level.dat is in), use this: worldObj.getSaveHandler().getWorldDirectory() It returns a File instance. Append the dimension folder name upon that. To get the name of the dimension (if you're uncertain what the name is, if you wanna delete a dimension from a mod or whatever), use this: this.worldObj.provider.getSaveFolder() Please note that this can return null, when it's the Overworld. Also I strongly recommend to check if a player is in the dimension, and only delete it if it's not the case.

I don't fully understand the issue here, is it that you get a "ghost" entity?

Again, remove the damage field in your class! It's not referenced anywhere and unlike methods, fields cannot be "overridden"! Also do your calculations before the super method call, and only on the local variable. Also a tip, you can also do damage *= 3.0D , which basically says "re-assign the variable with itself multiplied by 3.0D". You can also use this on any numerical type with any mathematical or bitwise operator. But what you can also do is to do the calculation within the parameter assignment like method(variable * [value])

You don't reference the damage field you've declared. Actually you don't even need to. I recommend just to override setDamage and call the super method with the given parameter multiplied by the value, meaning it has x times more damage than a vanilla arrow would've. Also remove the getDamage method and the damage field

Can we see your build.gradle file?

In your renderInventoryBlock, use the tess.setBrightness(240) before rendering In your renderWorldBlock use tess.setBrightness(block.getMixedBrightnessForBlock(world, x, y, z)) before drawing. For that light-shining-through issue, use block.setLightOpacity(255) when you construct your block.

I don't reccomend using the unlocalized name for the GameRegistry.registerItem/Block methods. Your problem seems to be that it has a prefix ("prefix:name") and judging from your code, you add the References.RESOURCESPREFIX in the getUnlocalizedName methods.

run this: gradlew clean gradlew cleanCache gradlew setupDecompWorkspace --refresh-dependencies gradlew eclipse and see if it works

Try to use knockBack instead of addVelocity.

DO NOT set mc.currentscreen directly! Use mc.displayGuiScreen for that, since it initializes the GUI (and not just sets a variable)

Use the BonemealEvent. In there check if the event's block is your sapling, check if the world.isRemote == false and then call your sapling grow method (I called it markOrGrowMarked) and also set the result of the event to Result.ALLOW In 1.7, you could also implement IGrowable in your block, but note that the method names aren't readable yet!

Crash log? can we also see your main mod file (where you initialize your custom creative tabs)