Draco18s

It's called a Race Condition. If you change the block hardness, that effects ALL players. What the hardness is would depend on the last player to start mining the block.

Yes. Use a bitflag (as metadata) to save its powered/unpowered state. All you should need to do is check for power in the onNeighborBlockChanged function, if it has it, set its powered flag (if not, clear it) then schedule an updateTick (which is where the code you have should be already)

I need a better idea of what the goal you have in mind is, first.

Ah ha! Fantastic. I knew something like that was floating around somewhere, but I had no idea where to look or what to look for (I don't typically deal with OGL).

https://github.com/Draco18s/Artifacts

Ah, the magic of Static.

NameOfClassWhereIntegerLives.IncreaseThatThing(); function int IncreaseThatThing() { NameOfStaticInteger += 1; setDirty(); return NameOfStaticInteger; }

.... if(Block.blocksList[world.getBlockId(x, y, z)] instanceof BlockPipes) { } Now you don't need the variable, or the try/catch (which is SLOW).

Uh. You know there's only one instance of each block class, yes? This is not how you store per-block information.

public void render(int left, int top, int width, int height) { Tessellator tessellator = Tessellator.instance; TextureManager renderEngine = FMLClientHandler.instance().getClient().getTextureManager(); renderEngine.bindTexture(renderEngine.getDynamicTextureLocation("link", bufferedimage)); GL11.glEnable(GL11.GL_BLEND); tessellator.startDrawingQuads(); tessellator.addVertexWithUV((double)(left), (double)(128+top), 0.0D, 0.0D, 1.0D); tessellator.addVertexWithUV((double)(128 + left), (double)(128+top), 0.0D, 1.0D, 1.0D); tessellator.addVertexWithUV((double)(128 + left), (double)(top), 0.0D, 1.0D, 0.0D); tessellator.addVertexWithUV((double)(left), (double)(top), 0.0D, 0.0D, 0.0D); tessellator.draw(); GL11.glDisable(GL11.GL_BLEND); } This works with one slight issue: Any pixels in the bufferedimage with an alpha value lower than 26 (0x1A) aren't drawn at all. Other values are drawn as expected with the appropriate amount of transparency. How do I fix it?

If you can't figure it out, give XCompWiz a poke. He's gotten Mystcraft to have dynamic sky colors (including rainbow hue shifts over time). Mystcraft isn't open source, but XCW is pretty helpful about getting specific features working the way (generic) you want them to for your mod.

EntityPlayerMP (and it's relatives, like EntityPlayerClientMP) only exist either Server side or Client side, not both. You should check for if(world.isRemote) or if(!world.isRemote) (e.entity.worldObject being an appropriate stand-in if you don't have a world object already) After you've determine you are on the client (or server, as appropriate) can you check for typecasting.

...You might want to actually get the various xray cheats and check....

Not that I am aware of. Probably possible, but I haven't looked into it.

Well first off....item right clicks are handled client side... So you'd need a packet handler... But to answer the question: NameOfClassWhereIntegerLives.NameOfStaticInteger += 1

Silk Touch would get you "natural" stone, but there's no ability to "cheat" resources there, as once its broken by not-silk-touch it drops the resource and not the stone. So it's still one-for-one.

And where are your textures when you zip things up?

Zaa! http://www.minecraftforge.net/wiki/Mob_Spawners And for an example: https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/worldgen/StructureMasterTower.java (all the way at the bottom)

No and Yes. If you do it as an IWorldGenerator, yes, but only at chunk generation. If you make new blocks and shove them into the blocksList at the old block's ID (essentially getting around the conflicting ID problem) you can cheat, but keep in mind that this may cause compatibility issues with other mods.* But you won't have any extra chunk generation lag. *As an example I used Block.furnaceIdle to get the furnace texture to use on one of my blocks, but someone paired my mod with a mod that replaced the vanilla furnace in the above manner, leaving the vanilla furnace to never register its textures, thus making a null pointer error in my mod.

Just checking. In any case, I've not directly used the onCreated method, so all I can offer is: Use debug statements and break points to figure out if onCreated is getting called or not. I based my reply on the Javadocs that said that's when the function is called.

Get started with 1.6.4, get the hang of how things work, do small mods, put a hold on your Big Plans (you'll have to anyway, but you might as well get started learning now, yah?) Forge isn't going to be ready for 1.7 for a while yet, as MCP needs to be updated; lots of changes making all previous deobfuscation translations unhelpful. (Side note: http://mcp.ocean-labs.de/news.php?extend.10.1 )

Also, to better explain how I arrived at the 3-block solution: 1) You want a block to spread: ok, block replaces its neighbors with itself. 2) You want it to spread in a range: ok, so there's something special about the central block (think redstone torch vs. redstone wire). 3) You want the "center" to actually be a line from bedrock to world ceiling: ok, so now we need two types of central block: the one that starts everything and the 'infinite' vertical line blocks. These can be the same block if it's a permanent effect, but in either case it's fundamentally different than the actual spreading block, as it provides the "power source" as it were. 4) You also want to spread through air in some manner in order to effect blocks in the sky. This will likely end up being duplicating each of the block types that covers the former 3, but with a different material, collision hull, etc. etc. (normally you'd do this with metadata, but Material can't be altered, and if you want other mod blocks to treat these blocks as if they are air, then you'd need a separate block class). That would leave you with 6 different blocks. Now that we've split the effect down into specific block concepts we can work on each one individually. Under the assumption that we don't want the effect to occur instantly, we should use the onUpdate() function, so that when an update occurs, spread advances 1 block. The exception is our central axis that is not the origin anchor point: due to the fact that we can't use metadata to infer connection back to the anchor, we need to add all of them at once. We can either do this when the anchor is placed (and just loop through all blocks at that XZ location) or use an "instant spread" of when each of these "pillar" blocks is added to the world. That puts us in a position where we have a Finite State Machine for all of our blocks, where the state only changes in the onUpdate as defined by that function, based only on the block's surroundings and its current state. And that's easy, provided that the number of states is less than our metadata limitation (16). We can also get tricky, if we need 17-32 states, we can just use a second block, with the same texture, and switch from Block1(state 16) to Block2(state 1) and back (or any other state-to-state), as needed. This gets complicated though, so for most effects, try to stick within the 16-state limitation.

Uh huh. But you didn't tell me how you're acquiring the item.

Vanilla doesn't care for most blocks, except leaves, which use metadata to determine if they were natural or player-placed. So without rewriting a huge chunk of vanilla (as either base class edits or through Reflections/ASM) you probably won't ever be able to tell.

No, I don't, I know that. I do, however, like being able to run Eclipse and have it already in the workspace I want to use. But I'm not worried about saving 2-400 MB of hard drive space on a 500 GB 1 TB drive.* I've set myself up in a way that is convenient for me. *Literally 0.03%. Not worth the time lost by using a single install and the File->Switch Workspace option.