Alex_hawks

Thank you for that clarification. Is there any way to include the Project1 and Project2 outlined in the code block? Development Forge the stuff normally in the forge dir src Project1 Project1 Stuff Project2 Project2 Stuff

just wondering, are the Project1 and Project 2 folders in the Forge folder, or the folder that the Forge folder is in?

by adding the natives jars to you build path as well

No, wrong section for that... I think he means method to call on the server to send a message to all players on the server.

add a launch parameter in your IDE to your run configuration. the parameter is "--username <name>"

try using the following Psuedocode @Override public void tickEnd(EnumSet<TickType> type, Object... tickData) { if (type.contains(TickType.WORLD)) { onWorldTick(new Random()); } }

*laughs* Red Power 2 source code, available? *laughs a lot more* But seriously, I'm not guaranteeing the code quality, but Mekanism is an Open Source mod that has blocks that do what you want. Look at Energy cubes in here. But that is for 1.5.1... If you really want 1.4.7, just backtrack through the commits...

Just make it render in both passes, and have a completely empty Icon for the pass in which it shouldn't render. NOTE: UNTESTED! It's only an idea...

But the person with the file open in a text editor, configuring the mods they have installed usually doesn't see it that way...

Some mods already do; Forestry has one for the farms, named [Forestry] Buildcraft has one for the quarry, et al, named [buildcraft] Red Power 2 has one for its block placers/breakers, and IIRC, it's named [Redpower] Forge already has hooks for this, but it isn't compulsory to use them, yet...

The damage value wildcard for ItemStacks has changed, but I can't remember what it changed to... I think it changed to Integer.MIN_VALUE but I'm not certain...

Update forge?

Because of the unified code that forge has implemented (Which IMHO is a very good thing). If you just used ModLoader you would have to maintain to separate code-bases, but wouldn't run into this issue.

It's being run on both the server and the client... That if (par1World.isRemote) { return true; }else{ //Code goes here } is checking if it is on the client, and if it is, return true. If it isn't, it is actually doing stuff...

check before you cast

in updateIcons() register both Icons, and return the icon that you want based on the input into getIcon(ItemStack itemstack)

I thought about each of them, but getRenderBlockPass in block doesn't have an overload with metadata, as you described, long and tedious, and the render pass is still in the block's class. 3 sounds the most logical...

Correct, I'm using Mojang's default Block renderer. All I need to do is change what one of the getTexture overloads returns, and mark the block for a render update... The block in question is the Hidden Wires from Electric Expansion. With 1.5 and the new way of handling textures, I thought it would be easy to add blocks that can use another blocks texture, with support for Mod Blocks that aren't my own... One of the very few bugs left in the MC1.5 update is the Hidden Wires not rendering properly.

What I'm doing is storing it as an ItemStack in a TE, and using IBlockAccess to get the ItemStack, but the method getRenderBlockPass() in Block doesn't have any parameters... But thanks for that link, I'll go check it out...

getRenderBlockPass in Block doesn't have any parameters, and you have one instance of a Block / Item, so I can't store it there... I have no way to access where I'm storing my data... Amending the first post, I would have to use 2 Block IDs to accomplish it in the way I proposed...

I have been making a block that can take the texture of other blocks, and have run into the issue of which render pass the block needs to render in. If I set it to 0, then I have the same issue as MFFS had with ice and water a while back, and if I set it to 1, then I have dodgy rendering when the block are next to each other with different textures, particularly textures of blocks that should be rendered in pass 0. One way that I can think of to fix it is to use twice as much metadata, but I would like to retain future compatibility and would prefer to avoid using metadata for this. I also looked at MFFS source code to see how ThunderDark dealt with it, and found out that he hard-coded for water and ice... Is there any solution without hard-coding, or doubling my footprint?

If you do everything the same, except you run the *.sh scripts instead of the *.bat or *.cmd scripts...

The default Minecraft render engine for blocks (render type 0) can only handle metadata < 16. Custom renderers don't suffer this same restriction...

Metadata only goes up to 15 when using a default Block renderer...

The @Mod is where I put all of the @ForgeSubscribe methods