Draco18s

@DimensionsInTime: that doesn't do what the OP wants. That CONSUMES the pickaxe, they want to leave the pickaxe in the crafting grid. K4yfour: You can see an example of a custom recipe implementation here, this being the only method you need to modify: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/recipes/RecipeToolMold.java#L171 Note that my recipe looks for items with a very wide definition of "tool" and you are only interested in pickaxes (or even alternatively, an item passed to the recipe constructor: mine does not because the recipe declaration takes in iron tools as a template, but wooden tools can be used in game). The magic principle is the same, though.

Read values from the configuration, get the Item instances from those values. Store your own references to those instances and use those instead. Calling Item.getByNameOrId is slow.

Unarranged sticks? I don't think you'll be able to represent that well at all.

How to be got at texturing in a Minecraft style: 1) find an existing Minecraft texture that's similar to what you want. Like the hay bale 2) extract it from the Minecraft jar file 3) open in GIMP 4) use the hue saturation brightness tool to make it a different color (brown) 5) yer an artist now, Harry

A TileEntity is only needed if you need to store more information than metadata can provide. So no, it isn't. As for rendering, I can offer this: https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/hazards/client/HazardsClientEventHandler.java#L371 It's old 1.7 code, but it's updatable as long as you know what you're doing.

No, because those references are to instantiated objects. You have no way of passing a class to anything and get back that instance. You simply can't do it.

You need to check the stack metadata. Creating a stack, then decomposing it back to an item only checks the item.

World-stuff slid be done in getActualState. Extended state is for things like fluids, which need to control where each of the four corners are.

No, it uses RESULT.DENY to prevent the growth. It's effectively canceled, but it does not use event.setCanceled(true).

There are three events you need: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/FlowerEventHandler.java#L101-L118 One for reading the data, one for writing the data, and one from freeing the data from RAM.

setHarvestLevel("axe", 1);

What part of "ignore the fuck out of that enum and pretend it doesn't exist" isn't making sense to you? You can extend the vanilla classes left right and center and that enum can be ignored.

For the "block is hit by a laser" vanilla has no concept of lasers, so you would need to program some kind of interface or capability yourself.

That's what I have these for: https://github.com/Draco18s/ReasonableRealism/tree/master/src/main/java/com/draco18s/hardlib/api/internal Notice that they're in my API package, but inside another package called "internal." In some respects they do need to be exposed, but they shouldn't be utilized directly in most cases.

I wanted a single function that would handle the linkage between "an ore block" and "a flower block" so that the flowers could be used to indicate the presence of ore in the area. Which involves 3 different block states: the ore, the flower, and the desert flower. And two properties and their corresponding values (for the flower and desert flower respectively). It's the craziest method signature I've ever written.

No? You can't? How about I in-line that method. //copy 1, was registerBlock(townCentre); GameRegistry.register(townCentre); //COUGH #1 ItemBlock itemtowncentre = new ItemBlock(townCentre); itemtowncentre.setRegistryName(townCentre.getRegistryName()); GameRegistry.register(itemtowncentre); GameRegistry.register(house); ItemBlock itemhouse = new ItemBlock(townCentre); itemhouse.setRegistryName(townCentre.getRegistryName()); GameRegistry.register(itemhouse); //copy 2, was registerBlock(house); GameRegistry.register(townCentre); //COUGH #2 ItemBlock itemtowncentre = new ItemBlock(house); itemtowncentre.setRegistryName(house.getRegistryName()); GameRegistry.register(itemtowncentre); GameRegistry.register(house); ItemBlock itemhouse = new ItemBlock(house); itemhouse.setRegistryName(house.getRegistryName()); GameRegistry.register(itemhouse); Can you find where a block is being registered twice, now?

Your repository is terribly arranged. Why is the Init package not inside the com.xXJamie_Xx.myTweaks package? Also, do you own xXJamie_Xx.com? Now then, lets look at this method This method is called twice. Can you find the problem? I'll give you a hint. private static void registerBlock(Block block) { GameRegistry.register(townCentre); //COUGH, COUGH

January? Shit son, the ModelLoader.setCustomModelResourceLocation method has existed for over a year. That link links to the method in the blob commit that was made Jun 16, 2015, almost two years ago. The tutorial you found, even though recent, is shit. Please link it so I can go tell the author that it is shit and they need to change.

Step back from the "how do I make an api jar" and look at your mod. What is it that you've created that other people might want to use? Did you add a machine that has some sort of recipe? Did you add a machine that has some sort of recipe? Do you have some capability that could be exposed? Do you have some other mechanism that other mods might either want to know about, modify, supply data to, or get data from? Do you have block properties that aren't vanilla? First, create an API package separate form your mod. In there create interface that declares the action you want to expose. Second, implement that interface on the class that's already handling those actions. Third, store a reference to the instance in an API location (don't forget to instantiate it). Fourth, convert all existing references over to use the API instead. If you do things right, the game won't crash and your machine will still work. Congrats, you made an API. If you don't use your own API, you can't test it. And if you don't test it, you won't realize that something's wrong (it took Reika and I back and forth over 3 revisions of his API before I could add a recipe to the Rotary Craft Extractor). You can do the same thing for block properties, capabilities, and other things as well. However there's other things to keep in mind as well: Once you've declared the interface and released it, it's effectively permanent. You've signed an API contract that says that these methods exist and are guaranteed to exist. If you change the method signatures in the future, it won't be your mod that crashes, but the mod that tried to use your API. And users will complain to them even though it's your fault. Imagine how frustrated a player would be if that other mod author vanished from modding and you changed the API: users would be hammering a brick wall with no response, unable to use two of their favorite mods together. Instead, you should mark the methods in the interface as @deprecated (so that no one else starts using them) and in the implementation, make a best-guess conversion to the new method. If it can't be done at all, then just leave an empty method stub. The two mods won't integrate as they used to, but they'd still run. You can throw warnings and log messages and non-fatal errors all you'd like, but the JVM should never crash.

Generics are fucking awesome and it's the one tool in the toolbox I don't have when working in Unity that I miss (or at least, not to the same degree: there's typed lists and such, but everything needs to be strictly defined at compile time: no contravariance or covaraiance which means that I can't generically define delegate methods). Also, this method declaration is insane: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/OreFlowersBase.java#L204 It can technically be simplified, but not by a whole lot.

Looks fine to me. But I've never used those methods. Does it work?

You don't need to copy anything at all. The value is meaningless for you.

Armor already has a method that's called every tick when the armor is being worn. In that event, apply the potion effect if: a) the potion effect is not currently applied b) the duration is < 20 Then when the armor is taken off, the potion effect will persist for a second or two, and then go away on its own. In so doing, the blinky decay effect from Night Vision still happens when it wears off.

Ah, you're trying to set the item stack NBT data so the item has a custom name, same as if it was renamed in the Anvil? Try looking at the anvil code to see how it applies a name. See also: http://minecraft.gamepedia.com/Player.dat_format#Item_structure

Something something copy the existing code into your leaf class as an override and change the values?