gokiburi

That does it. It was not immediately obvious to me what needed to be copied or what was being used from the original forge setup folder. I coped the build folder over and it built immediately without error. Thanks GotoLink. I'll update my main post with the solution.

Solution: What I WAS doing: Creating new project folders with my src and resources folders along with build.gradle, gradlew, gradlew.bat and the gradle folder. What I WASN'T doing: Copying the build folder from the original forge setup as well. This is important because it contained the natives that need to exist for the mod to reference to successfully build. Once I put the build folder into the project folder the build worked immediately. Shoutouts to GotoLink for the solution. Original Post: I managed to update one of my basic 1.6.2 mods to 1.7.2 using the new forge gradle build system, but I'm running into issues updating the rest of them for this reason: error: package org.lwjgl.opengl does not exist import org.lwjgl.opengl.GL11; used mainly in Block rendering functions to push, pop, rotate, scale etc. Should I not be using org.lwjgl.opengl.GL11 functions? What should I be using if not? Example GL11 usage: GL11.glPushMatrix(); GL11.glScalef(1.0F, -1.0F, -1.0F); GL11.glRotatef(-90, 0.0F, 1.0F, 0.0F); GL11.glTranslatef(-0.5F, -0.5F, -0.5F); Am I missing a classpath or compile line in my gradle build file? I don't have a reference anywhere to org.lwjgl as the other mod I updated didn't need one. My build.gradle: buildscript { repositories { mavenCentral() maven { name = "forge" url = "http://files.minecraftforge.net/maven" } maven { name = "sonatype" url = "https://oss.sonatype.org/content/repositories/snapshots/" } } dependencies { classpath 'net.minecraftforge.gradle:ForgeGradle:1.1-SNAPSHOT' } } apply plugin: 'forge' minecraft{version = "1.7.2-10.12.0.1034"} version = "1.7.2-1.0" archivesBaseName = project.projectDir.name sourceSets.main{ java{ srcDirs 'src' } resources{ srcDirs 'resources' } } processResources { from(sourceSets.main.resources.srcDirs) { include 'mcmod.info' expand 'version':project.version, 'mcversion':project.minecraft.version } from(sourceSets.main.resources.srcDirs) { exclude 'mcmod.info' } } I'm not really sure where to go from here; I can update all my mods to 1.7.2 and they'll run from eclipse, but I can't get gradle to build them.

Is there a hook or some workaround method for calling a function when an EntityXpOrb is picked up? Need access to the EntityPlayer that did the pickup and the EntityXpOrb itself.

I return the ItemStack and don't proceed with the use call. The item itself isn't consumed; other items in the players inventory are supposed to be. I could access the ItemStack to change it around, but what's actually going on is that the recursive function tells the players inventory to decrease the stack size of the itemID with metadata if it exists and end recursion if it doesn't. Server side their items are decreased, client side they're still lingering and I don't know how to force the client to pick up on those changes without user interaction. I could send a packet but I feel that's the wrong answer. The other problem I have is that my raytrace returns the proper co-ordinates when par2World.isRemote is false but the block directly under the player when it's true, meaning I still have to figure out how to fix that before the function works properly. I figured I'd put that in another thread though.

I must have been doing something else wrong before. Your solution above mostly works now, after moving things around. There are two separate problems now, but I'll make another thread for one of them. The solution was to use par2World.getPlayerEntityByUsername(par3EntityPlayer.username) instead of MinecraftServer.getServer.worldServers[0].getPlayerEntityByUsername(par3EntityPlayer) while !par2World.isRemote. Now the players items get consumed server side but not client side. I may just have to split up portions of the code to run onItemUse for if it's the client or server or add code to simply remove from client side as well.

Here's a list of outcomes. par3EntityPlayer.worldObj.setBlock + par3EntityPlayer.inventory.consumeItem: onItemUse with par3EntityPlayer.worldObj.isRemote - Blocks placed, items consumed, changes do not persist. onItemUse with !par3EntityPlayer.worldObj.isRemote - No blocks placed, no items consumed. onItemUse with par3EntityPlayer.worldObj.isRemote and !player.worldObj.isRemote - Shows the blocks being placed and consumes the items, but after saving and reloading the changes have not persisted. This has the same effect as above. If I use MinecraftServer.getServer().worldServers[0].getPlayerEntityByUsername(par3EntityPlayer.username) it actually returns a "server" player and everything works exactly as expected, but that seems like an erroneous, not very proper way to get the current players multiplayer world.

Remote or not, the changes don't persist unless I get the world from the worldServers array.

Solution: Something else was causing the issue. Using !world.isRemote was the correct thing to do. With an onItemUse I consume an item from the players inventory. This command is run when world.isRemote. The server does not register these items as consumed if I pass in the player from onItemUse, but does consume the items if I pass in the player from MinecraftServer.getServer().worldServers[0].getPlayerEntityByUsername(player.username). Why?

Similar to what is done in the Item.java file you make some public static variables you can access. They're already public static variables; public static Block denseStone; public static Block denseCobblestone; public static Item denseStoneShard; public static Item antiMatter; Which I declared like this: denseStone = new BlockStoneDense(1500, 0).setBlockName("DenseStone").setStepSound(Block.soundStoneFootstep).setHardness(7F).setResistance(10F); denseCobblestone = new BlockDenseCobble(1501, 1).setBlockName("DenseCobblestone").setStepSound(Block.soundStoneFootstep).setHardness(9F).setResistance(10F); denseStoneShard = new ItemStoneShardDense(1400).setItemName("DenseStoneShard").setIconIndex(1); antiMatter = new ItemNonMatter(1401).setItemName("AntiMatter").setIconIndex(2); So when you need to access those blocks in the current file, you should be able to use: denseStone denseCobblestone denseStoneShard antiMatter And when you need to access those blocks in another file, you should be able to use the below if the file is in the same package as your "experiment.java" file: experiment.denseStone experiment.denseCobblestone experiment.denseStoneShard experiment.antiMatter If you're accessing it from a different package, you need to import your experiment file, then you can use them the same way. It might also help to change your experiment file name or package name to something else. darkdestry.experiment.experiment.* is confusing. To make an item texture sheet, you need a 256x256 png file that you load in your ClientRegistry.java; public void registerRenderers() { MinecraftForgeClient.preloadTexture("path/to/the/texture/file.png"); } Then to set the item to use that texture, add this function to the Item's class: public String getTextureFile () { return "path/to/the/texture/file.png"; } The tutorial I used to figure this out was the basic tutorial found here.

I looked at your code and saw that your order of doing things was a little weird. It read like this; Register Recipe Register Recipe Register Smelting Register Smelting Define Item Define Item Define Item Define Item Register Block Register Block Register Item Name Register Item Name Register Item Name So I reordered things to read like this: Define Item Define Item Define Item Define Item Define ItemStack Define ItemStack Define ItemStack Define ItemStack Register Recipe Register Recipe Register Smelting Register Smelting Register Block Register Block Register Item Name Register Item Name Register Item Name This adheres to a more structured, easily readable order of operations, assuring that things you will be using in the code are properly defined and exist. I also simplified your recipes a tiny bit and added some ItemStack variables for legibility. I think the main issue was that when you were creating your recipes (first thing you did, smelting in particular) you were using Blocks that didn't have their info set yet. BlockIDs for one. I'm not 100% certain if that was the issue or not, but it's what I noticed first and foremost. Glad that everything ended up working out. You probably already noticed, but I also left out defining "AntiMatter" in the language registry. I wasn't sure what you wanted to do with that, but make sure you register that as well. (-;

I've subscribed to the Player.EntityInteractEvent so that when a Player clicks their tamed pet it stops it from attacking its target. Unfortunately, using all of the below, it still remembers its enemy/victim (mobs/neutrals) after telling it to stand up again. tameable.setTarget((Entity)null); tameable.setRevengeTarget((EntityLiving)null); tameable.setLastAttackingEntity((Entity)null); tameable.setPathToEntity((PathEntity)null); tameable.setAttackTarget((EntityLiving)null); Is there a working method to force an entity to completely forget about attacking something before it kills it to death?

I won't pretend that this will work or that I have tested it, because I haven't. I just rewrote and rearranged your main file to follow a top down flow of instantiation and use. Might need some changes before it would compile but you shouldn't be accessing things that haven't been instantiated with this, at least. package darkdestry.experiment; import net.minecraft.src.Block; import net.minecraft.src.Item; import net.minecraft.src.ItemStack; import cpw.mods.fml.common.Mod; import cpw.mods.fml.common.Mod.Init; import cpw.mods.fml.common.SidedProxy; import cpw.mods.fml.common.event.FMLInitializationEvent; import cpw.mods.fml.common.network.NetworkMod; import cpw.mods.fml.common.registry.GameRegistry; import cpw.mods.fml.common.registry.LanguageRegistry; import darkdestry.common.CommonProxydarkdestry; @Mod(modid = "DarkDestry_Experiment", name = "Experiment", version = "1.0.0") @NetworkMod(clientSideRequired = true, serverSideRequired = false) public class experiment { public static Block denseStone; public static Block denseCobblestone; public static Item denseStoneShard; public static Item antiMatter; // Block Texture render @SidedProxy(clientSide = "darkdestry.client.ClientProxydarkdestry", serverSide = "darkdestry.common.CommonProxydarkdestry") public static CommonProxydarkdestry proxy; // Main Chunk @Init public void load(FMLInitializationEvent event) { denseStone = new BlockStoneDense(1500, 0).setBlockName("DenseStone").setStepSound(Block.soundStoneFootstep).setHardness(7F).setResistance(10F); denseCobblestone = new BlockDenseCobble(1501, 1).setBlockName("DenseCobblestone").setStepSound(Block.soundStoneFootstep).setHardness(9F).setResistance(10F); denseStoneShard = new ItemStoneShardDense(1400).setItemName("DenseStoneShard").setIconIndex(1); antiMatter = new ItemNonMatter(1401).setItemName("AntiMatter").setIconIndex(2); ItemStack denseCobblestoneStack = new ItemStack(denseStone); ItemStack denseStoneStack = new ItemStack(denseCobblestone); ItemStack denseStoneShardStack = new ItemStack(denseStoneShard); ItemStack antiMatterStack = new ItemStack(antiMatter); GameRegistry.addRecipe(denseCobblestoneStack, "SSS", "SLS", "SSS", 'S', Block.stone, 'L', Item.bucketLava); GameRegistry.addRecipe(denseStoneStack, "SSS", "SSS", "SSS", 'S', denseStoneShardStack); GameRegistry.addSmelting(denseCobblestone.blockID, denseStoneShardStack, 0.2F); GameRegistry.addSmelting(denseStone.blockID, antiMatterStack, 0.5F); GameRegistry.registerBlock(denseStone); GameRegistry.registerBlock(denseCobblestone); LanguageRegistry.addName(denseStoneShard, "Dense Stoneshard"); LanguageRegistry.addName(denseCobblestone, "Dense Cobblestone"); LanguageRegistry.addName(denseStone, "Dense Stone"); } } I'm only guessing here.

Trace out the values of this, this.tileEntityRenderer and this.tileEntityRenderer.renderEngine right before the crash line. Look for which is null and make that variable not null. I'm only explaining why the error is thrown, not giving you alternatives. If you don't want to set the tileEntityRenderer on your TileEntitySpecialRenderer to something not null, you could rewrite the bindTextureByName function to not use a TileEntityRenderer. I can't tell you how to do that though. To answer your questions; If they were incompatible types, the TileEntitySpecialRenderer wouldn't be asking to set a TileEntityRenderer and the bindTextureByName function wouldn't be looking for one. You need to use one or make one alongside your TileEntitySpecialRenderer, I suppose. Secondly, if it isn't crashing when you load the world, then no, the error I'm describing wouldn't cause the world to crash on load, because I'm describing your error, which doesn't cause the world to crash on load.

Judging from your error log, it looks like you're not returning a gui instance. You'll need to set a GuiHandler up to return one and register it.

Sounds like a simple NPE. If this is the solution, you may want to look into basic programming tutorials. For now, I've gone through the steps one should take when they encounter a NPE. 1. 22:53:19 [sTDERR] java.lang.NullPointerException 2. 2012-10-19 22:53:19 [sTDERR] at net.minecraft.src.TileEntitySpecialRenderer.bindTextureByName(TileEntitySpecialRenderer.java:21) 3. 2012-10-19 22:53:19 [sTDERR] at jcm2606.te.client.tiles.TileEntityAnvilRenderer.renderAModelAt(TileEntityAnvilRenderer.java:49) 4. 2012-10-19 22:53:19 [sTDERR] at jcm2606.te.client.tiles.TileEntityAnvilRenderer.renderTileEntityAt(TileEntityAnvilRenderer.java:62) Your stack trace shows that your issue ends up in your class TileEntityAnvilRenderer. We know this thanks to lines 3 and 4. Following along the trace shows that the exception is actually thrown in the TileEntitySpecialRenderer.bindTextureByName function. It also shows the file and line number: TileEntitySpecialRenderer.java:21. Looking there, we find this section of code: ... 19. protected void bindTextureByName(String par1Str) 20. { 21. RenderEngine var2 = this.tileEntityRenderer.renderEngine; 22. 23. if (var2 != null) 24. { 25. var2.bindTexture(var2.getTexture(par1Str)); 26. } 27. } ... Line 21 shows that there are 3 possible null variables; this, this.tileEntityRenderer, and this.tileEntityRenderer.renderEngine. Looking at the TileEntitySpecialRenderer class we can see it does not set a tileEntityRenderer when created. ... 12. protected TileEntityRenderer tileEntityRenderer; ... There is a function to do so; ... 32. public void setTileEntityRenderer(TileEntityRenderer par1TileEntityRenderer) 33. { 34. this.tileEntityRenderer = par1TileEntityRenderer; 35. } ... We can also see that you never call this function in the code you provided. I can only assume that if you actually set the TileEntityRenderer and its renderEngine, the error would not be thrown.