Draco18s

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.

No. 1.5.2 is so far different than 1.6.4 that you will not be able to effectively create mods for 1.5.2 You can set up separate workspaces for a single installation of Eclipse, though the one time I tried to do it, it blew up in my face. Eclipse is so small I don't mind keeping four or five copies for each different version of Minecraft I'm working with, with repositories of the mod code kept on Dropbox (just copy back and forth when I switch mods).

Which is option B. Problem is I don't know if that's what he actually wants to happen because it would mean that ALL players on the server would be modifying the SAME value.

Ok look: If you have an item that is modifying a counter, either: A) the counter is ON the item B) ALL INSTANCES OF THAT ITEM will modify the SAME counter

This is the first time you've mentioned that you want a counter ON an item. For that, just use the NBT tags already accessible on the item stack.

That is not how you should be saving this info.

Block metadata is just a second value in addition to block ID. It's passed to almost every block function.

Here's my client proxy: render = new SpikesRenderer(); ClientRegistry.bindTileEntitySpecialRenderer(EntitySpikes.class, render); MinecraftForgeClient.registerItemRenderer(BlockSpikes.instance.blockID, new ItemRenderPedestal(render, new EntitySpikes()));

Do it the other way around. Store the data in the tile entity, then when the render function is called, check the TE (which is accessible) for the value and render as appropriate.

This is a tad tricky. But I think it can be done. Step 1: the block that acts as the anchor is going to be a unique block. One per effected zone. Step 2: the anchor pillar. These blocks will act like the anchor, but will only spread up/down as required. Might need a second one that has Material.air. Might be able to use the first block, but with metadata to get the effect, but sometimes its easier to just use a new block ID Step 3: the infected blocks. These will be ever block in the infected area, we will use metadata to figure out how far away from the anchors they are. If we need to infect through air, we'd need a separate block unless your radius is <= 8 All blocks will receive random updates. Step 4: Anchor block replaces the block above it and the block below it with Pillar blocks, depending on material type. You've got this happening already, sort of. Next replace all four horizonally adjacent blocks with Infected blocks, set metadata to maximum radius value. It should do this on blockAddedToWorld. Step 5: Pillar blocks will perform the above step as well, be sure to check that you're not replacing other Pillar or Anchor blocks! Step 6: Infected blocks will check all adjacent blocks for self, and find hightest metadata. It will then set itself to that value -1 and replace all not-self blocks with itself, at another -1 metadata. If you want the anchor to be broken and let things heal back to "normal" then: Step 6 is important, as if the Infected block's metadata is 0, then it should replace itself with stone/air. For the anchor pillars, if during an update it is not adjacent to either a pillar or a anchor on BOTH top and bottom, replace itself with stone/air. You'll probably have to experiment with stuff one step at a time until its behaving properly.

onCreated is only called when the item is crafted.

Don't pass new TileEntity(), pass a new YourTileEntityClass()

I don't think you're going to be doing that through the mob class. You're probably going to have to go higher.

I had that problem too. That's honestly the best way to give you everything. It's a lot of cross referencing. The primary class needed is a IItemRenderer: public class ItemRenderSpikes implements IItemRenderer { TileEntitySpecialRenderer render; private TileEntity dummytile; public ItemRenderSpikes(TileEntitySpecialRenderer render, TileEntity dummy) { this.render = render; this.dummytile = dummy; } @Override public boolean handleRenderType(ItemStack item, ItemRenderType type) { return true; } @Override public boolean shouldUseRenderHelper(ItemRenderType type, ItemStack item, ItemRendererHelper helper) { return true; } @Override public void renderItem(ItemRenderType type, ItemStack item, Object... data) { if (type == IItemRenderer.ItemRenderType.ENTITY) GL11.glTranslatef(-0.5F, 0.0F, -0.5F); this.render.renderTileEntityAt(this.dummytile, 0.0D, 0.0D, 0.0D, 0.0F); } }

I'd just like to point the flaw in this statement: "I am trying to make a mob move faster than the maximum speed." It's called a maximum for a reason.

You will also need an item renderer. Check out my classes here: https://github.com/Draco18s/Artifacts/tree/master/draco18s/artifacts/client You'll be looking at the client proxy and the spikes.

Are you talking about the chunks that look like this? //this.moveSpeed = 0.28F; this.getEntityAttribute(SharedMonsterAttributes.movementSpeed).setAttribute(0.28D); //this.addPotionEffect(new PotionEffect(Potion.resistance.getId(), 10, 0)); Yep, those bits.

Sorry, I haven't done anything with animated textures. But I know that Minecraft does have some kind of internal mechanism to deal with animations. As for snagging the Fire block's texture: Block.fire.getIcon(0,0)

You may be interested in this: https://github.com/Draco18s/Decaying-World/blob/master/draco18s/decay/entities/EntityFooDog.java I have several speed modifiers for that entity.

Frame rate is taken care of for you. "box" and UV coordinates are handled by the tesselator* You'd be drawing single vertices at a time, so four to define one side of a flat plane. It's annoying to work with, but for four quads (there's no reason to do more than the X shaped bit in the middle, similar to flowers and wheat) it won't be too bad. Just do it one quad at a time and use Mojang's renderers as a reference. *tessellator.addVertexUV(x, y, z, U, V); //U and V are the texture coordinates 0 to 1 inclusive where 0,0 is the upper left and 1,1 is the bottom right (if I recall correctly). I may be missing a parameter (vector normal?), but I'm doing this offhand.

You would need an event handler to cancel damage dealt.