SanAndreaP

I solved it. So basically the fix for IntelliJ 14, where you put output.resourcesDir = output.classesDir into sourceSets -> main fucks with my deobf jar, causing it to duplicate my mcmod.info file and all my other classes. Why this doesn't happen with my manager pack, I have no clue whatsoever...

Don't use EntityRegistry.registerGlobalEntityID registerModEntity is more than enough

I can't get this to work for the life of me First of: Forge 1.7.10-10.13.2.1286 IntelliJ IDEA 13 So I want to make an add-on for a mod of mine. I've set up a local maven repo for the dependant mod and it's dependency. When building the dependand mod's dependency, it works. When I build the dependant mod, it works as well. As soon as I declare the dependant mod as dependency in my add-ons build.gradle, I get greeded with following error: java.lang.IllegalArgumentException: Multiple entries with same key: varietychests=FMLMod:varietychests{1.2.0} and varietychests=FMLMod:varietychests{1.2.0} (full crash report here) So basically FML loads it twice for some reason I'm unaware of... The dependency chain is as follows (with their build.gradle linked to each of them): SAPManagerPack > dependency of > Variety Chests > dependency of > VarietyChests EBXL AddOn Dependencies which don't have other dependencies work fine, but as soon as I have one of those which do have one, it messes up. I dunno if there's something wrong with my maven setup or if gradle just bugs out... And I've also tried to run gradlew runClient to exclude a faulty IDE, but that crashes with the same error. If someone has any solution, I would be very thankful. EDIT - SOLVED! So basically I've looked into the deobf.jar file again and noticed that it had 2 mcmod.info files in there, causing the duplication problem. The cause of this was actually a "fix" for IntelliJ 14, where you set output.resourcesDir = output.classesDir , which in turn fucks with my deobf jar.

Depends on the mod you want. Some ship a dev jar, some have a maven repo. Regardless, you need to specify the dependency inside the build.gradle.

You need CodeChickenCore for NEI, you just have CodeChickenLib.

Sounds like the Teamextreme launcher...

Yes, if you need to check if a block is a specific one, you need to check if the instances are the same. Same for items. Ok, so to tell the TileEntity should I use NBT? Sorry for all the confusion. To tell the TileEntity, just add a boolean field like "connectedOnNorth" which is false if it isn't connected to another block on that side. In your onNeighborBlockChange method grab the TileEntity instance on those coords with world.getBlockTileEntity(x, y, z) , cast it to your custom TileEntity class to set the boolean fields for each side. In your renderer, read the value of the side fields and render the model accordingly.

Block north; Block east; Block south; Block west; north = world.getBlock(x, y, z - 1); east = world.getBlock(x + 1, y, z); south = world.getBlock(x, y, z + 1); west = world.getBlock(x - 1, y, z); eeew... Do declaration and assignation in one line. if (north.getUnlocalizedName().equals(this.getUnlocalizedName())) eeeeeeww... use instance == this, there's only one instance of a block class per game (there are exceptions, but they have a variable telling them apart, like the furnace which has a boolean defining its state), Also use brackets. Always. It reduces thought errors made by wrong intendation. Where is the model variable? I suspect inside your block class!? So if one block in the world tells it to render your part, another block can override that. Put the model inside your renderer class, tell the TileEntity the block neighbor changed and set the flag, which gets grabbed by the renderer, which renders the Model. Also models are client-only, so your code crashes on a dedicated server.

So it works when it is placed by other means, but it only doesn't work if used in provideChunk within your own ChunkProvider? Can we see your ChunkProvider then?

[*]Do not use registerGlobalEntityId ! It has a globally limited amount of possible entities, where some of them are already occupied by vanilla. Use registerModEntity instead. [*]Make proxies. Either try to do it right, or don't even bother. A tutorial on proxies can be found here: http://www.minecraftforge.net/wiki/Proxies [*]Learn how to organize your classes using sub-packages, your current setup is just a mess. [*]And please, don't put everything of your workspace in your repo. The only files that belong there are your src and gradle (not the one prefixed with the dot) folders as well as your readme, build.gradle, gitignore and the gradlew files. Possibly also some other files (like photoshop image files etc.). Here an example of a correct setup: https://github.com/diesieben07/SevenCommons

Which launcher are you using?

You need to actually break the block with block#tryHarvestBlock(x, y, z) , which has the advantage that you don't need to call any ForgeHooks stuff, since it's already in there.

Read the Javadoc of the event, it clearly states that: so register it there. To get the sapling type? Just get the block instance from the coords and if it's a sapling, check through its metadata which type it is.

With Cauldron I assume you're SOL. You just can go to the latest one. Downloads can be found on the navbar above under "Files"

Just to clarify stuff: //The PushMatrix tells the renderer to "start" doing something. No it doesn't. It "adds" a new Matrix layer (child) to the one you're currently rendering in (parent), meaning every transformation from the parent layer gets applied in your new child layer, but anything transformed inside your layer does not get applied to further rendering within the parent layer. //[...]And for some reason you DO need PushMatrix again! No you don't! You only do a PushMatrix again if you want another child layer inside your child layer. You can safely remove it. //Tell it to stop rendering for both the PushMatrix's It does not "stop rendering", it just closes your child layers, bringing you back to the parent layer. If you've removed the 2nd PushMatrix, you need to remove one of the PopMatrix as well By the way: Matrices only encapsulate transformations (rotation, translation, scaling), whereas other stuff like colorization, enabling blend mode etc. WILL apply to the parent layers as well!

Update Forge. I can't reporduce this issue (Forge build 1286)

Where do you call fillChests()? Depending on where it's called, you either have a World object or something which holds one (entity, tileentity, chunk, world generator etc.).

This is not the full log. Please upload the content of your /logs/fml-server-latest.log in a pastebin site like http://gist.github.com and post the link.

You need to scale it after translation, or you'll scale the translation as well.

There's no need to use a DataWatcher, applyEntityAttributes() is called on both sides. @OP: Add @Override to all of your methods you intend to override, it will tell you something is wrong. You missed the s at the end of your applyEntityAttributes() method.

Or, use Guava: http://www.minecraftforge.net/forum/index.php/topic,17455.msg88353.html#msg88353

Lower your view distance.

Use registerModEntity instead of registerGlobalEntityId : https://github.com/SanAndreasP/EnderStuffPlus/blob/master/java/de/sanandrew/mods/enderstuffp/util/CommonProxy.java#L52

If you want consistent tick rates, you should use a TileEntity.

You need to do this: scaleHeight = maxScaleHeight - (currFlux / (float) maxFlux * maxScaleHeight ) Here's an example of my generator GUI: https://github.com/SanAndreasP/EnderStuffPlus/blob/master/java/de/sanandrew/mods/enderstuffp/client/gui/GuiOreGenerator.java#L57