Draco18s

The nether and end are easy to special case. You can either ignore their biomes (set HELL and SKY to have 0 delta or if dimID abort, although both biomes CAN show up in other dimensions when other mods--like Mystcraft--are installed) or give them their own facets. I let the nether be super dry and super hot.

It's a pain in the ass. Stop now. If you want to look at what I did in 1.7.10 (which involved heavy use of things that shant be talked about) you can have a look at my event handler class: https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/wildlife/WildlifeEventHandler.java Roughly: 1) store the original biome data, we need to keep records of what they are so we can calculate time offsets properly 2) modify the shit out of these numbers because some of them are garbage. We also need to calculate the variance delta (deserts have greater temperature variance than oceans because of water's thermal capacity) 3) get the current date, look up the seasonal sine waves, multiply by variance delta, add to the base value, apply back to the biome It's ugly and there's hacks all over the place. One of the most annoying was having to deal with ice. Ice doesn't melt on its own, but water will freeze. Have fun handling that.

1) why is your Init package not inside your M101 package? Who taught you this? I need to go punch them, you are the second new modder I've seen doing this. IT WILL CAUSE CONFLICTS WITH OTHER MODS DOING THIS. 2) do not use the ModelMesher, use ModelLoader.setCustomModelResourceLocation and your problem will magically go away 3) your git repo should include the build.gradle file and gradle.properties (if you have one)

Hhmmm... so in your code you did a thing. And it didn't work. And you want help. But didn't share your code. Hmmm...

Open the Eclipse marketplace and install the json editor plugin.

@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.