Draco18s

TileEntities already have packet communication built into them. @Override public Packet getDescriptionPacket() { NBTTagCompound nbtTag = new NBTTagCompound(); writeToNBT(nbtTag); return new S35PacketUpdateTileEntity(xCoord, yCoord, zCoord, 1, nbtTag); } @Override public void onDataPacket(NetworkManager net, S35PacketUpdateTileEntity packet) { readFromNBT(packet.func_148857_g()); }

Code?

You should really ask on their forums or IRC channel. IC2, by the way, has an API that is very easy to find and use.

That returns the list of IRecipe objects (which he already figured out), not their ingredients.

Multiply their grayscale texture by the color black? 0 times anything is 0.

new ItemStack(ModItems.Riptide = OreDicitionary.WILDCARD_VALUE) You have no idea WTF you're doing, do you.

It appears to make the search function search either forwards or backwards.

I also supplied one up-thread that you can steal.

GUI probably. But if it is a tile entity, you need to implement the description packet functions.

Client prints 0, server prints 10000.

Might have something to do with calling code on the server, which does not have a Minecraft class. But I don't know. You didn't bother including the crash.

IRecipe tmpRecipe = /*whatever*/; if (tmpRecipe instanceof ShapedRecipes) { ShapedRecipes recipe = (ShapedRecipes)tmpRecipe; ItemStack[] ingredients = recipe.recipeItems } else if (tmpRecipe instanceof ShapelessRecipes) { ShapelessRecipes recipe = (ShapelessRecipes)tmpRecipe; List ingredients = recipe.recipeItems; } There's a few other recipe types, as well. And mods can add their own. You'll also have to look at SmeltingRecipes for the furnace, and some mods add their own machines that do conversions as well (like IC2's macerator) which might not be accessible except through that mod's API (if at all).

Jesus christ. The client only knows what the values are, it can't change them!

No

[me=Draco18s]salute[/me]

Kind of why I was hoping to be able to "precompute" the icons so the alpha multiplication step can be skipped. Oh well.

You can pull it off. You just have to decide which battles are worth fighting. Planks and Logs have their own classes (BlockWood and BlockOldLog/BlockLog) as does dirt, stone, grass. Cobblestone does not. I completely replaced stone and made it drop my own cobblestone block (circumventing the need to ASM cobblestone) and left everything else alone (trees aren't constructed in a manner that is easy to run support rules for, and planks are primarily a player construction block and I was mostly dealing with the "dig out a room" aspect). What blocks are either too expensive or too weird for the player to decide to build the house out of it? What's too hard to modify and is an allowable loss in realism? Even at partial support, you'll find people who go "this is awesome" and won't subvert the rules too much because they like the mechanic and getting around it feels like cheating ("pfft, roof of furnaces, lol"). This class will also help in your endeavors: https://github.com/shieldbug1/S1Library/blob/master/src/main/java/com/shieldbug1/lib/asm/ASMHelper.java

ASM carefully. Use new blocks whenever possible (you can use the various worldgen events to examine and replace blocks as needed as well as remove and replace crafting recipes). Write a static class with helper functions, taking world, blockpos, and any relevant properties so that the code only has to be written once and all support-required blocks use it (support distance can be passed as a paramter based on the block, so if you ASM the call into Blocks.stone, it passes 5, whereas Blocks.wood_plans passes 3, and so on). You will have to figure out how non-same blocks support each other. Can jungle planks support oak? Can smooth stone support cobble? Can monster egg support smooth stone? And the biggest hint: You will need to always check that support exists 1 layer below. If cobblestone only checks that it's north neighbor is cobble, then two floating cobble will support each other. This last block needs to merely have a solid top surface (as it is supporting the block above, and the block above is supporting the adjacent block). Lastly: You'll need to take shortcuts somewhere. I'll leave you to figure out which shortcuts you should take, so that you understand them. But at some point you will have to sacrifice better physics for better performance or ease of coding. And oh yeah: Avoid try...catch in any code called from onUpdate / updateTick. You can cheat the compiler by letting the ASM-inserted function throw exceptions. The compiler never sees that it's being called and so never enforces the try...catch, and as long as the code cannot throw the exception, it can't crash. That is: "throws" does not exist as part of a function signature. (I had to do this in one spot, because I had to Reflect in a class definition. But the try...catch around the reflection code slowed the game down massively, but as I had defined the class and its constructor, it could never cause an exception, so I told the class I was ASMing into to handle it....except that it doesn't and the compiler doesn't give a damn). This video is kind of bunk, but it shows off what I did.

Which means my first code block is also wrong. replace "{@modVersion}" "1.2.3" should be replace "{@modVersion}", "1.2.3" (note the comma). Thanks much.

I think the notation for multiple replacements is off. replace "key": "val", "key2", "val2" The first key/value pair is separated by a colon, the second by a comma. And is the minecraft{...} portion required, eg. minecraft { version = "1.7.10-10.13.2.1291" runDir = "eclipse" assetDir = "eclipse/assets" minecraft { replace "key": "val", "key2", "val2" } } Or is it referring to the already-existent minecraft{...} block?

Awesome. I've been looking for just that. I'd figured out how to specify variables in the build script (which handled the mcmod.info file) but not how to get it to fiddle the source. Might be time for another Version Refactoring (e.g. aligning my version numbers to a(n even more) sensible format).

Your second set of randoms, inside the for-loop, can cause (almost certainly will cause) the "I am generating in this chunk" to decide "nope, I'm generating in the next chunk." Drop the +random(16) from the definition of startX and startZ and instead put them in place of the rand(8 ) - rand(8 ) Secondly, your maximum number of tries shouldn't be random if you're just going to discard 98% of the valid positions (and a countless number of invalid ones). To boot, you're trying "at most one time."

So, if I understand that correctly... minecraft { version = "1.7.10-10.13.2.1291" runDir = "eclipse" assetDir = "eclipse/assets" replace "{@modVersion}" "1.2.3" } Would search my source files for "{@modVersion}" (which it would find in my @Mod annotation) and replace it with "1.2.3" ?

Because for the most part they are vanilla GUI objects. That is, taking the existing pieces and re-purposing them. In fact, I made a wooden hopper recently, and aside from having to use my own container/guicontainer code (due to slot stack limits) it's 100% vanilla. The texture used, the text printed, the inventory slot definition...all vanilla. I just had to specify it as my own GUI so I could override the mergeItemstackIntoInventory function so that shift-clicking respected slot stack limits (the wooden hopper being dirt cheap has a slot limit of 16...along with only being able to send items downwards...yeah, it's a dumb chute). If you have a more specific question, just ask. "How to build an arbitrary GUI" is not a question that can be answered without knowing what the GUI is for and what operations it has.

I meant that if I wanted to use that code to change the pixel data, would it cache?