Draco18s

You need to write your own recipe handler to check for stack sizes. Furnace recipes don't care how big the stack is. So you'll need a way to check that a recipe is valid (ignoring stack size) and then get how big the input stack size is for the recipe and check that the slot has at least that many items and then remove that many items when it completes. This is how I handled it. It's likely not the best way, but I was working off of the vanilla furnace's handling.

Haven't the faintest.

They custom built their animator. public class DragonAnimator { ... }

player.worldObj.provider.dimensionId

Yeah, I'd given it a shot after I'd seen a lot of praise on these forums, but it turns out no one uses it for animation. Surprise, surprise.

Quick and easy? Not that I know of.

That would be a problem.

Some people swear by it, but as I wanted to have an animation only play when my mob was walking, I did what looked like the only way to play and stop animations, which caused Concurrent Modification Exceptions. Which no one was able to help me figure out. So. Yeah. Don't use MCAnimator. Good news, the model it creates is very easy to turn into a ModelBase. You need to refactor some function names and work out the euler rotations from the quaternions (but as you created the model using eulers...) but it's pretty much a 1:1 port.

I had massive, massive problems with MCAnimator and animations. And not just in the "animate when" situation, but in a "does bad bad things and will crash the game" kind of way. I was never able to fix it and instead rebuilt things using a standard quadruped.

May have to live with it, then.

Include the Teleporter .

You're still only opening the GUI on the client. The server is not aware that you've opened the gui, and will ignore any commands sent because you're not interacting with the container.

Mojang has done a lot of things to make modder's lives easier, with some benefit to themselves, but from a "just Mojang" perspective the cost:benefit analysis comes out in favor of not-doing them. For instance, removing block IDs and making things referenced by string. A lot of work on their part with a pretty small benefit for their continued development, but which makes leaps and bounds improvements for modders. Then on other things they go "can't reproduce it with just vanilla, not a bug, closed." Say...maps only working in dimension IDs less than 128 (because the dimension ID is an integer, but maps use unsigned shorts!). Actually, it is a bug, you're using an int in one place and a short in the other, that will be a problem eventually and with access to the source code I can prove it. It just doesn't have any visible effect until a mod is introduced.

I've not ever seen someone with code that works for addSubstitutionAlias , so I don't know how it's supposed to work or be used (etc. etc.) and only seen non-working code, one way or another. So that said, my first question is: What happens if you only call addSubstitutionAlias once, either for the Type.Block or Type.Item? (rather than calling both) Second question: Does your ModStone call setCreativeTab ? What happens if you comment that out? I imagine that something breaks, but that'd be my first experiment: figure out which line(s) are adding the extra addition to the creative menus, why, and what breaks as a result.

Rather than copying files, get a program like Beyond Compare. It'll let you select two folder locations and do a recursive scan, looking for changed files (a quick scan just looks at last-modified, takes a fraction of a second, and is usually good enough). That way you are always making sure to merge in the right direction: red files overwrite black files.

Cough. @Override public boolean canCommandSenderUseCommand(ICommandSender sender) { return true; } A || !A will always be true

Just TileEntity. There's no reason to extend something else. As well as implementing ISidedInventory, of course.

There's a difference between "you don't have to do it that way, this way is cleaner" and "STOP THAT!" For instance, should I be yelled at for: HashTable<int, string> myHash = new HashTable<int, string>(); instead of HashTable<int, string> myHash = new HashTable<>(); ? Or maybe I should be yelled at because I put my open braces on the same line, instead of a new one... if(a == b) { instead of if(a == b){

As discussed in many other threads, one as recently as yesterday, varargs compiles to the exact same bytecode as new Object[] {...} and while the syntactic sugar is very nice and all, please don't yell at people for using one over the other, Lex.

Even if your mod has absolutely zero meaningful functionality in SSP (e.g. an economy with private chests, wallets, coins, and shops) it's still way easier to create as a single, universal, mod. It's also way easier to test.

What I did for my millstone was give each "dummy" block their own inventory (as they were the same block as the operant block, using the same TE, what they did with their inventory was based on metadata). I was only allowing insertions from these, not extractions, but it basically worked like this. When a "dummy" block had an item inserted into it via ISidedInventory, it would hold onto it and then attempt to insert it into the main block (if there was room and so on). So yes, a whole bunch of items could be inserted into each dummy block and the dummy wouldn't be able to do anything with them because the main block was full, but that was sufficient for my purposes. For you, what you could do is when the dummy is asked if a slot is accessible, it can locate the main TE (it knows its own coordinates and should be able to calculate the offsets and thereby position of the main) and pass the request on. Likewise for the item insertion, item extraction, and request for slot contents. e.g. public boolean canInsertItem(int slot, ItemStack stack, int par) {//'par' here is which side. 0 = bottom, 1 = top, etc. ISidedInventory main = (ISidedInventory)world.getTileEntity(xCoord + xOffset, yCoord + yOffset, zCoord + zOffset); if(main == null) { return false; } return main.canInsertItem(slot, stack, par);}

Likely you need a lang file in your assets.

I would have to agree with coolAlias.

Using registerModEntity, you can't spawn them with spawn eggs. IIRC, you need to create your own spawn egg item.

Reminds me of how many "API packages" I've downloaded that straight up didn't work. I downloaded one one time (I forget what mod) and the API made references back to the mod's core package. Which made the API worthless, because it wasn't self contained. I've also had to badger Reika as his Extractor API (which I requested on account of having an ore block I could not oreDict under a standard name) would crash when called (NPE). I think it works now, but I alone made him go through four revisions, if not more.