GotoLink

Given that your chest inventory size is 6: //merges the item into player inventory since its in the tileEntity if (slot < 6) { if (!this.mergeItemStack(stackInSlot, 9, 45, true)) {//should be 6 and 42 return null; } } //places it into the tileEntity is possible since its in the player inventory else if (!this.mergeItemStack(stackInSlot, 0, 9, false)) {//should be 6 instead of 9 return null; }

You are probably only changing things on client side with your gui. Use packets to change things on server side.

public void onEntityCollidedWithBlock(EntityPlayerMP par1entityplayer) I doubt this method exist. Try the real onEntityCollidedWithBlock method.

I explained a bit how to change the project structure here.

All this is because they didn't abstract enough. A generic pipe for me is only a means of transportation. Object to be transported should simply be wrapped with their transportation method, which should be called as the pipe comes into contact. Example: public class GenericPipe extends TileEntity{ Vec3 vec3; List<Transportable> transports = new ArrayList(); List<ContactHandler> lookers = new ArrayList(); public GenericPipe(){ vec3 = Vec3.createVectorHelper(this.posX,this.posY,this.posZ); } public void addTransportFor(Transportable object, ContactHandler handler){ transports.add(object); lookers.add(handler); } public boolean isInContactWith(Transportable object){ for(ContactHandler handler:lookers){ if(handler.canTouch(object, this) return true; } } public void send(Direction dir, Speed speed){ for(Transportable object:transports){ if(isInContactWith(object)){ object.transportTo(dir, speed, this.vec3, this.worldObj); } } } } So, let say we are in this case: TileEntity tileEntity = world.getTileEntity(x,y,z);//some random code to get a TileEntity instance Object obj = tileEntity.getBehavior(SomeBehavior.class, Side.WTV);//you call that method you suggested obj. //? now what ? And compare it with the current situation: TileEntity tileEntity = world.getTileEntity(x,y,z);//some random code to get a TileEntity instance if(tileEntity instanceof SomeBehavior){ ((SomeBehavior)tileEntity).doSomething(Side.WTV); } I don't see any improvement from your suggestion...

You need to override the power methods in Block. Though if you want to power non-adjacent blocks, that is going to be trickier.

OpenGl is a native for Minecraft, you should see them in the build/natives folder. If you don't, run gradlew setupDevWorkspace --refresh-dependencies

I'd recommend Configuration.getBlock as it searchs for a free block id. Also, it is unecessary to make the id as fields, since you already have the blocks themselves, and they keep the info through block.blockID. Same goes for items.

GameRegistry.findItem("whatever-name-is-given-to-the-item-in-the-first-place")

Ho, right, you can publish to maven local repo like so: gradle publishToMavenLocal http://www.gradle.org/docs/current/userguide/publishing_maven.html

It is at the same place as in 1.6.4. It is a Forge client event, by the way.

Using RenderWorldLastEvent and mc.thePlayer.isInsideOfMaterial(datFluidMaterial) ?

The whole point of getBlock is to return a block no matter what. It can't be null, at worst it would already crash while trying to get the block. It defaults to Blocks.air in most cases. By the way, you have World#isAirBlock.

The ModAPITransformer should do the job. I don't see why it wouldn't ?

If you don't want to learn bytecode, just write the changes in an external class and read it with the plugin.

The EventSound is not needed in 1.7. You should use a sounds.json file.

If you plan to reuse a "core", cache it with Gradle (give it a group in its build.gradle) and add it in the "dependencies" part of the build.gradle from the sub-mods.

Well, i guess it would help a lot of people to understand, so, here is a full description. Optional has three annotations, Optional.@InterfaceList, Optional.@Interface, Optional.@Method. The first two use @Target(ElementType.TYPE), meaning you put them above the class declaration. (like @Mod) The latter has @Target(ElementType.METHOD) is obviously supposed to be put above a method. (like @Mod.EventHandler) Optional.@InterfaceList accepts only a array of @Interface, while @Method only accepts a string, the modid. Example time ! @Interface(iface="mods.battlegear2.api.IDyable", modid="battlegear2", striprefs = true)//Will strip IDyable interface from Battlegear2 API if it isn't loaded public class ItemGun extends Item implements ISheathed, IDyable{ //imagine some working code here @Method(modid="battlegear2")//Will strip that specific method if Battlegear2 isn't loaded public boolean sheatheOnBack(ItemStack item){ return false; } } @InterfaceList(@Interface(iface="class.path.Interface1", modid="examplemod1"), @Interface(iface="class.path.Interface2", modid="examplemod2")) public class AwesomeImplementation implements Interface1, Interface2{

Had to add my answer here, since i work on Battlegear2. The @Optional from fml can "remove" interfaces depending on a mod being installed or not. This is one case where bytecode manipulation is more interesting than reflection, since it allows to hide the code that would crash/throw exception otherwise. The best part being that you don't need to understand asm to use @Optional.

Dude, resource packs. That simple.

Confirmed to be fixed in later Forge. Thanks Lex

The mod FMLMod:PiffM{1.0} is attempting to register a block whilst it it being constructed. com/ibm/icu/text/ArabicShapingException That is an interesting Exception. Do you use arabic text ?

Item.getItemFromBlock(Blocks.chest)

In your sounds.json, you should be able to set the sound as a stream.

No, the answer to most of those questions is to use events. You can change vanilla things behaviour dynamically without conflicts with other mods. That is why replacing blocks is not recommended.