Draco18s

Oh I get why it's done, Lex. Minecraft has its limitations because of the decompile and deobf process. All I meant was that I, as a coder, wouldn't have chosen those names for my own functions.

That only makes me think of How to Write Unmaintainable Code

https://github.com/Excaliburns/ModPractice/blob/master/src/main/java/items/HuskItem.java#L52 If (not client) then...

Well....let's see here... matches returns....if what's in the crafting grid matches the recipe getCraftingResult returns....the result of the recipe getRecipeOutput returns....the output item of the recipe (this will be the basic item with no knowledge of the grid, but you need to return something) getRemainingItems returns....the items remaining in the crafting grid after the result is taken canFit returns....if the recipe fits within a given grid (2x2, 3x3, etc) Look at some existing implementations to snaggle most of those methods already implemented. All you'd have to do is fluff up the getRecipeOutput method to grab the metadata you want from the items in the grid.

(On the single player integrated server, anyway)

https://github.com/Excaliburns/ModPractice/blob/master/src/main/java/network/tutmodMessage.java#L43 When the packet is being reconstructed from the byte array...what is the value (and therefore its size) of itemsList? I'll give you a hint, it's specified in the zero-argument constructor.

You would have to look at the player's ToString method and find out.

The player isn't null. The object's ToString() method encountered a NPE while executing.

You aren't using the methods without parameters so of course they're not deprecated.

(or you can set each stack's stacksize to double: virtually all drops are done via 1-size stacks, even in the case of dropping 3 or 5 items)

Because string comparison is awful. You will have to either: a) make a recipe for each variant b) create a new IRecipe implementation that gets the metadata of the dye and applies it to the recipe output.

BTW, it'll take a while to get accepted and you'll probably feel like you're being abused with needing to make changes. Its not personal.

if(entity instanceof EntityParrot) { ... }

You need to encode the information you want to send. ByteBufUtils will help.

https://github.com/Excaliburns/ModPractice/blob/master/src/main/java/network/tutmodMessage.java#L35-L43 And what, pray tell, did you expect to happen?

You should be fine, it's just that if you wanted to override a behavior (e.g. making water buckets do something different) you'd have to remove the existing behavior.

I think so. You're also removing any existing behavior for items you're adding behaviors for, yes? (If applicable) (Aside from the default "toss").

The dispenser does not fire any event, of any kind, when it dispenses items. The BlockEvent class (and its subclasses) are for events like crops growing, blocks being placed, blocks being broken, etc. They are very specific (I do not believe that BlockEvent is used in any context except via its subclasses). Also, if you look at BlockDispenser and the dispense method, you'll see that no events are posted. If you want to change how the dispenser dispenses items, you can do that by adding and removing entries to the DISPENSE_BEHAVIOR_REGISTRY

Packets.

Snrk. Hardly. File a bug report. Better yet, make a Pull Request fixing the problem. https://github.com/MinecraftForge/MinecraftForge

Custom IRecipe implementation should be able to do this.

That is NOT how you post code. You've made it bold for some inane reason and not used a code block (the button with <> on it).

Because you're using the base ItemBlock class which returns 0 in getMetadata()...

Learn how to read the log: Caused by: java.io.FileNotFoundException: multic:blockstates/colored_plank.json

I do not have an answer.