Draco18s

I'm sorry for your lack of reading comprehension.

Ah ha. Thanks. I definitely don't need it per dimension, just per save.

Pretty much this. There's about four functions involved that you'd need to duplicate, but name differently. isProvidingWeakPower canProvidePower isProvidingStrongPower and possibly canConnectRedstone

Alright, I'm trying to figure out how to handle data storage for information that needs to be accessible from the world. It's essentially information about a player entity, but needs to be accessible from a tile entity while the player is offline, hence I can't use extended player data, I need to save it to either its own NBT file or to the main world data file. Having trouble implementing this. I found one solution that extends WorldSavedData, but there were a few errors (such as no providing a proper constructor) that I am not sure how to solve. Eg. the constructor used was one that takes no parameters, but WorldSavedData doesn't have a matching constructor, as its only constructor takes a string paramter, but I am not sure what I should be passing. I also am not sure if I should be instancing this class once for my entire mod and storing each player's info in it, or if I should be using one instance per player (and what the differences in construction would be; that is not the read and write NBT parts). Help?

You need a packet handler that implements IPacketHandler

0 is bottom 1 is top (check any block that has a different face for the top, side == 0 -> bottom, side == 1 -> top)

That's only blocks and items.

Remove the # symbol. Hex values are specified with 0x[the value] not 0x#[the value].

They use 2-5 because that's the face they're attached to.

Or !world.isRemote for server side.

Here's my Eclipse set up with working textures without jar editing. This is the ninth time I've posted this.

To expand on this: You should override the registerIcons(...) function and specify a mod-name: This will prevent multiple mods from specifying the same texture files (so modA and mobB both wanting to use "new_wood.png" won't conflict). public void registerIcons(IconRegister iconRegister) { blockIcon = iconRegister.registerIcon("MYMOD:BLOCK"); } AND DO NOT JAR EDIT FOR YOUR TEXTURES mcp>src>mods>MYMOD>textures>blocks>BLOCK.png (or items for items, armor for armor, etc.)

Having recently had a similar issue: All I can say is that GUIs are a right pain in the ass and there are about four things that can happen that'll cause the error. I'll try and find my particular issue when I get home, as it was a little more obscure.

And in either case, you shouldn't be storing your textures inside the eclipse folder.

Hooray a wiki! It even has a link to a nice tutorial.

Of course, not the only way. Minecraft is my first experience with Java, but my...5th language? (C++, AS2, AS3, Javascript....yeah, 5th language I've used extensively) So I'm pretty much at the point where I only need to learn syntax and the IDE. Fortunately Eclipse is a fuckign awesome IDE. Next project in Unity I do I'm going to see if I can set up Eclipse as my code editor. Sooo much nicer than MonoDevelop. <3

Gah, use the code tag please. It makes examples a lot easier to read. >..X

Annotations are little more than comments that induce extra error checking. They don't actually get compiled. (There may be some exceptions, such as @Mod and @NetworkMod) My guess is that you never registered onServerStarted as an event handler.

Try hovering your mouse over...well, just about anything. Hovering it over an error tells you what the error is (and can offer most solutions). Hovering it over a function call, variable, or type will show you information about that object and clicking on the icon/bolded text will jump your view to where that object is defined.

Java Documentation. It's all the nice helpful info popups in Eclipse that you're probably ignoring.

Essentially what you need to do is make some Interface classes that your actual mod implements (each function in the Interface being one that other mods can call), then provide an access class (basically the main API class) that holds null references to your actual blocks (type of these variables is each Interface class). Package all those up and release it as the API. Finally in the Init function of your mod you access your base API class and turn those null references into actual block/item references. The best way to learn how to do this kind of stuff is to take a look at an existing API. I'd suggest Mystcraft's because it's set up in a fairly simple manner, but it's not freely available.

new WaterStoneblock(506) does not match public WaterStoneblock(int part1, Material par2Material) Your passing an int to a function that wants an int AND a Material. (function a(b, c) is not the same function as function a(b))

And you didn't indicate what version of Forge you're working with. Because my code works too. So clearly they renamed things, which plays havoc on our ability to support each other.

Every block being its own instance would be a MASSIVE drain on system resources. He's wrong. This is easily noticable when using setBlockBoundsBasedOnState (and not specifying block bounds for inventory rendering). What's likely happening is that he's getting back the right data values by accident.

Uh. 1.5.1 I opened up my environment with Forge 639, there is no "getIcon" method.