Draco18s

For everything.

We still have signatures, just that per-user-settings they are turned off by default.

Don't use the model mesher, use ModelLoader.setCustomModelResourceLocation

Debug it and find out. If that's the case, you're going to need to find a default value to supply.

ASM is not a Forge thing, it's a Java thing. Also, don't reopen locked topics.

Try disabling the loading screen as described in the EAQ

If you're not using Eclipse, google how to activate the debugger in your IDE.

No idea. Forge has moved on. You should update. As for a Null Pointer Exception, those are easy to fix. Find the thing that is null, figure out why it hasn't been assigned a value. Use your debugger.

Looks fine to me, I guess. I haven't messed with IRecipes much. I did one. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/recipes/RecipeToolMold.java Which was based on regular recipes (I forget what I used as a base).

1.7.10 isn't supported here any more, but I'm going to ask this anyway: On these lines here: https://gist.github.com/DrPiggy/c9a21adbc9f879a983ff41bea5e2d21a#file-commoneventhandler-java-L78-L82 Why do you get the item in the slot s, check that it's not null, and then instead of using the local variable that is the item in slot s, do you get the item in slot s again?

Don't make a coremod. Alternative options, to be used in order: - Use APIs - Use Events - Use Reflection - Ask on the forums, you probably missed how to do one of the above - Make a Forge Pull Request on GitHub - Still don't make a coremod

How do you call any other method? You get an instance of an object and press the . key and type the method name...

You never set ironballitem to anything.

I suppose if you want to save the index you could, but I'd do it like this: if the index is a valid number (e.g. not -1 and within the array bounds), check the grid location at that spot. If it's a staff, awesome, you found it, good job. IF NOT, then iterate over the whole grid. You save some CPU by caching an index, but have a fallback if the staff isn't there or the index is bad.

Where?

Same way you register anything else. ItemBlock itemBl = new ItemBlock(yourBlock).setRegistryName(yourBlock.getRegistryName()); GameRegistry.Register(itemBl); Or via the registry events.

The later half of 1.10.2, at least. I don't recall when it was first introduced.

No. They share data through packets.

It spawns once on the server thread and once on the client thread. What's so hard about understanding that? If the threads are running on different machines (cough, dedicated server, cough) what did you expect to happen?

Items using NBT can display multiple textures, I have an example here, the same could be done for your items without the need for NBT just using the world info. I can't really speak to your particular implementation, I can't run it and only have an idea of how to go about doing it. You shouldn't use the same two-string constructor I do, you're not using two textures -> one. You're doing something else. I assume. Just pass in whatever data you need in order to generate your textures. For me it was two resource locations. As for how many textures...no idea.

Size of the 2D array: https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/hardlib/client/TextureAtlasDynamic.java#L118 And the mips might be calculated for you by another class, I don't remember. I just know that my code doesn't do any downscaling (other than to make the two input textures the same size). Items/Blocks: no idea, probably both. Items you can do more easily another way, though. One class can handle a bunch of resource locations, or one, depending on what you're doing and how you're doing it. As you can see, a ResourceLocation is passed to the Load method, indicating what texture should be loaded (you'll also notice my code ignores it, and uses strings passed to the constructor). Well you're doing world-specific items and blocks, right? Which means that somewhere else in your code you're defining how many and what they are. Just give each a unique ID (this ID is shared between worlds and is just a reference to "this one is the first one, this one is the second one...") that acts as that item's resource location, so you can re-use spots in the texture sheet.

If you want it to turn slowly, you need to turn less (amount) over time (more than once). It's called LERPing.

Essentially. Mind, if you f*ck something up, Minecraft will crash deep in the texture sheet code and it's very hard to diagnose back to your custom TAS.

Should be obvious. The first one you want to return true and in the second one you want to take the item stack passed in, damage it, and return it.