sequituri

Your slot indexes are all messed up. You keep repeating the same ones. In your loop you reused index 0-20 because your loop does not increment the slot indexes properly. Try this: int slot = 0; this.addSlotToContainer(new Slot(tileentityInputFurnace, slot++, 98, 34)); this.addSlotToContainer(new Slot(tileentityInputFurnace, slot++, 8, 62)); for (int i = 0; i < 3; i++) { for (int k = 0; k < 9; k++) { this.addSlotToContainer(new Slot(inventoryplayer, slot++, 8 + k * 18, 84 + i * 18)); } } for (int j = 0; j < 9; j++) { this.addSlotToContainer(new Slot(inventoryplayer, slot++, 8 + j * 18, 142)); } if(tileentity.upgradeScreenOpened){ this.addSlotToContainer(new Slot(tileentityInputFurnace, slot++, 179, 5)); this.addSlotToContainer(new Slot(tileentityInputFurnace, slot++, 179, 23)); this.addSlotToContainer(new Slot(tileentityInputFurnace, slot++, 179, 41)); this.addSlotToContainer(new Slot(tileentityInputFurnace, slot++, 179, 59)); } ...

Unlocalized name is only used in the IDE. You want the registered name of the Block or Item. The one you used when you called GameData.register{Block|Item}()

You are setting your Block's metadata in two different places with two different methods. One is obviously messing up the other.

I'm writing my networking packet test setup for my mod. I'm using typical code I've seen several places. Here is the code that gives me headaches: This code seems perfectly nice and works flawlessly in the eclipse IDE. Problem is this; if I remove the try/catch eclipse refused to compile without error and tells me I have to include or declare throws on my method. But, when compiled with gradlew build, I get this compile error. :\Users\master\Projects\mc1stmod>gradle -q build --stacktrace warning: [options] bootstrap class path not set in conjunction with -source 1.6 C:\Users\master\Projects\mc1stmod\build\sources\java\us\sequitur\metalmod\network\MetalTestPacket.java:43: error: exception IOException is never thrown in body of corresponding try statement } catch (IOException e) { ^ So, is this a code disagreement between deobfuscated code (in eclipse) and normal code (outside eclipse)? I'm using Forge 10.12.0.1030 as my build. In the IDE I can see that PacketBuffer$writeStringToBuffer is declared as throwing IOException and it has code in it's body to do just that. I'm stumped.

Draco18s, Rather than wait for complete deobfuscation, I've taken the task upon myself to go through every cpw, minecraft, and minecraftforge class... reading, understanding, and even rewriting the class after refactoring all of the names - to sensible ones. Then when I want to invoke a method, I look at my version of the code, pick the name I want, and then use the comment on my code to get the real (obfuscated name). Also, since the arguments in my code are all nice names, it makes it easier to figure out what the argument is expecting. Lots of work, indeed. But, I like java and I'm learning how minecraft works in the deal.

The Plants normally check and decide it it's time to grow or full-grown in UpdateTick. You did nothing (except for checking to see if the plant can stay), so your plant will not "grow". Check out the BlockSapling class for some ideas.

Saplings are subclasses of BlockBush not BlockFlower from looking at 1,7.2 code. However, trying to get a sapling to be plantable, is not a simple matter of deriving a class from grass, dirt, or farmland. protected boolean canPlaceBlockOn(Block p_149854_1_) { return p_149854_1_ == Blocks.grass || p_149854_1_ == Blocks.dirt || p_149854_1_ == Blocks.farmland; } The above code hard-wires the check for a specific block, not just a suitably derived type of block. The code should have been written more like to make growing on other blocks readily possible. protected boolean canPlaceBlockOn(Block p_149854_1_) { return BlockGrass.class.isInstance(p_149854_1_) || BlockDirt.class.isInstance(p_149854_1_) || BlockFarmland.class.isInstance(p_149854_1_); } I'm not sure (other than a coremod) how to make such things work.

The system sends the events to the instance of your mod class, so static event handlers will not work. As said, you cannot use a static method, but you can delegate the work to a static method, if you need to do so. Just call your static method from the instance's event handler.

I may have misunderstood this, but I believe these options would require me to obtain the source of the mod and modify it and then maintain my own version. If this is a coding issue with the mod, I can relay the information to the developer, but if it's just a workaround, I'd rather not make my own version of the mod. You have misunderstood. System properties are set on the java command line. "-Dsystempoerty.to.set=value" The other is a call that the client can make in their code. There may even be another way to allow missing blocks to just be ignored. But, normally this is the dev's responsibility.

If you Subscribe to the event: FMLMissingMappingsEvent, you might be able to override the mappings or ignore them. Or: System property: fml.missingBlockAction="FAIL" (the default for servers) Override in server startup??? On the client: FMLClientHandler.INSTANCE.setDefaultMissingAction(action) I have not tried either of these, but the code is there. Look at them if you want. FMLServerHandler * FMLClientHandler

That message you get (with @Override) tells you exactly what the problem was. When you subclass another class (like Item, Block, etc.) you normally override methods that you need to change. Your method signature (that is name, return type, and types of arguments) does not have a method to override. Check you spelling and if you still can't figure it out, reread the class your subclassing. By the way, if you copy the BlockBush class completely, then you obviously are not overriding the canPlaceBlockOn method; you are defining it. The class you copied works only with vanilla dirt. Of course a copy would do the same. Right? The problem is this code in Block class: if (plantable instanceof BlockBush && ((BlockBush)plantable).canPlaceBlockOn(this)) { return true; } Since you have copied the class and renamed it, your method will never be called. As was suggested, you need to subclass BlockBush and override necessary methods like the one you changed.

{ GameRegistry.addRecipe(new ItemStack(ARepo.ICobalt_door, 1), "_##", "_ ##", "_ ##", Character.valueOf('#'), CMStuff.cobaltwood); GameRegistry.addRecipe(new ItemStack(ARepo.ICobalt_door, 1), "##_", "##_", "##_ ", Character.valueOf('#'), CMStuff.cobaltwood); GameRegistry.addRecipe(new ItemStack(ARepo.IIronCobalt_door, 1), "_##", "_##", "_##", Character.valueOf('#'), CMStuff.cobaltingot); GameRegistry.addRecipe(new ItemStack(ARepo.IIronCobalt_door, 1),"##_", "##_", "##_", Character.valueOf('#'), CMStuff.cobaltingot); } Here is your problem. ^ The crafting grid is not correctly created in any of these recipes. a. Only spaces and items go in the grid. Spaces are for alignment and structure. Nothing else. b. You have underscores: They are not items and therefore do not belong in the grid. Nothing except spaces (for structure.) No underscores '_' allowed for this. c. Your first recipe has 4 character wide strings. This will not give you the recipe you expect. Make all strings the same length (length of string <= 3 and all match). d. You are registering recipes in 'preinit'. In 1.7.2, this should be done in 'init'. Fix those and the problem goes away.

Really, LexManos. Memory "Leaks" were the hallmark of C and C++ programming. As it's very easy to say alloc() or new() and then just reuse the point later for something else. Since the memory is not free nor is it accessible at any point with any option to reclaimed it, it has leaked. It the java world, memory cannot "leak" the same way. The memory is always accessible unless the user has dome something very unjava-like. Like create an object with a reference to itself. Although, there are garbage collectors that can even detect that and free the lot.

Okay, just curious. Carry on then.

So, let me see if I understand. a) You want these tamed beasts to despawn when the owner logs out? b) You want the creatures to become still and inert when the owner logs out? c) You want the creatures to revert to wild(untamed) vanilla status when the owner logs out? d) Something else entirely?

I'm not at all familiar with 1.6.2, but I'd look at the possible problem of sending packets before the server is properly started. It seems like a misplaced packet which, at the time of receiving, had no code set up to handle it. All mods seem to still be in Pre-init state.

This is not a bug/crash discussion forum. Maybe you should perhaps post it in the proper forum? This one is for general discussion.

java, since it has a reasonable garbage collector, normally doesn't suffer much from memory leaks. However, bugs in code that create circular reference dependencies most certain can create such problems. For example: when you do "new Thing1(new BigObject(args))," then normally, minecraft sees when the inner object goes out of scope and frees the memory. It is possible, though, to store the reference where it never goes out of scope, and keep doing it with more and more. That would gobble memory horribly. IT IS NOT A LEAK. It has simply never gone out of scope. The game still has references to this memory left laying around. If it happens with dimension travel, that might be a good place to nail it down to. A good place to check is the mojang bug tracker.

Post a full crashlog. See the banner at the top of this forum for information. The one you posted is abbreviated version.

I'd hazard a guess here. It looks kind of like your java runtime has a security issue and is not allowing connections on the loopback (127.0.0.1) interface. I don't know what to tell you at this point.

So you went back to square one, which you knew did not work. Now, you expect us to glean something more from those old crashlogs? I'm pretty sure that you've ignored all of our help, you won't get much more. Learn from what you've been told and try the results (with new logs and code) or fix it yourself.

For my normal eclipse setup and gradle configured arrangement, I found that it looks for such things here: <PROJECT_LOC>\src\main\resources\assets\<modid>\textures\blocks\<blocktexture>.png <PROJECT_LOC>\src\main\resources\assets\<modid>\textures\items\<itemtexture>.png As for other things, I haven't used them yet. So, I dunno.

Not to discourage you, little one, but their are many 30 year old java veterans who are struggling to write mods for Minecraft. And you think you can do it with no programming background or java experience whatsoever? You really should find a school class for programming unless you are a genius. Otherwise, your questions on the "basics" will just annoy people until you get booted. Think about it.

Why do people bring all of their Mojang launcher related questions to this forum? If you don't konw how to use the launcher, there are plenty of tutorials and howto's and videos for that.

Unless you post the new log with the new code, there is no way for us to surmise what problems remain. So, post the latest crash log with your code that causes it. Then you will get more help.