Draco18s

I'll also point out that that one parameter you're passing is the variable you're using to hold the tool item, which at that point, it is null.

I just went to try and download a version of Forge for 1.8 or 1.8.8 (don't care which, as I'll be using it in dev to poke at something that was added in a 1.8 snapshot) and every single file from the change log, to the installer, to the MDK for every single version of Forge was 404. Like this one: http://files.minecraftforge.net/maven/net/minecraftforge/forge/11.15.0.1655/forge-1.8.8-11.15.0.1655-mdk.zip Did something break somewhere?

Could you please explain what you mean by that? Minecraft.getMinecraft().thePlayer is the client side local player. If the bot tries to access this it will simply access itself. If the code is running on a server, it will simply crash. That's it, server's 404. Game over man, game over.

The hell are you trying to do?

More accurately: Minecraft.getMinecraft().thePlayer is the bot, not the other person.

That's where the jar file lives, you can extract assets (textures) from it. I don't think the .java files exist anywhere, I think its just the compiled .class files and attached javadoc.

C:\Users\[username]\.gradle\caches\minecraft\net\minecraft\minecraft\1.7.10

Hesus Frakking Christiana. I want the block class, that's the model json. This, I want this: BlockTest

Yep. You could also pass CardboardBoxSpaceShip as long as it also implements IVehicle.

You'd have to post your block code.

Interfaces exist to allow multiple objects with different inheritance hierarchies to be treated as "the same" due to the contract granted by the interface.

Ok, so I poked around. You are using it correctly, however, the texture name is not "plank_oak" its "planks_oak"

That's his main class, not his block class.

That suggests that "plank_oak" is not the correct texture string. The standard texture alas would throw one of those "texture not found: minecraft:plank_oak" messages, but in creating a custom loader, that error handling got lost. I'll take a look at the strings I pass. It might need to be "minecraft:plank_oak"

I think I'm the only one who has used the custom sprite loader, so I'm the only one that knows how it works, and even that knowledge is questionable. It is so much easier to just render the block twice and accept the crappy break particles.

AFAICT something in the texture atlas load method is borked. This is an incredibly difficult error to solve, as the point at which the program discovers that there's a problem is long after our code has run, or deep in the call stack. I don't see the problem off hand. I'll have to get you my block later, I'm not home.

http://www.minecraftforge.net/forum/index.php?action=profile;u=5 And don't bug him unless you have to. He does not maintain the content of the wiki pages, so there's no point in complaining directly to him, he will tell you "it is a wiki, if the information is wrong or missing, fix it." The page says to "view the page source to see a1.8 proxy" just above the section you quoted. I don't know why the "Proxy Classes" section is commented out, but you can view it if you click on one of the edit buttons.

Pretty sure that the 4 armor slots do not have inventory slot numbers. Or at least, in this context they don't appear to. I see 37: 1-9 (hotbar), 10-36 (inventory), 37 (your backpack).

Why not create a getMaxWeight() method to ItemBackpack, get the item, cast it, then ask the backpack what it's max weight is.

You missed an important line: icons[o] = map.getTextureExtry(regname); You need to get the IIcon back out and save it to a field in the block, which is then returned via getIcon(...)

Here's a custom TextureAtlasSprite that does pretty much what you're looking for. It takes in two textures and combines them. You'll have to modify it to combine them in the way you want, however. http://www.minecraftforge.net/forum/index.php/topic,35760.0.html

I do not know. You may have to write your own ISimpleBlockRenderingHandler. Its pretty straight forward.

AH HAHAHAHA HEHEHE Ha ha ha heeee..... oooh boy. This is going to be tough as balls as it has to be done client side and anything done client side has to be assumed to be inherently insecure. That is: someone clever enough can decompile your mod, strip out the checking code (or make it always return, "Yep! No X-Ray!") and recompile it and you would never know. That said, the only way I know how to get access to the pixel data of a given texture would be the method I talk about over here. You'd just have to rewrite some of the functions and then do Dirty Tricks as part of the processing (that is: violate the implied agreement that the texture loading code is there to load textures and not cause side effects, though no one will ever check to see that that is true). You'd still have to register a new texture icon to get the code to execute, but it could report back to Somewhere Else its findings.

Because the input to the getRotation method is the rotation axis, that is, the bit that doesn't move.