Draco18s

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.

Don't bother trying to render an actual block of fire. Just grab its texture and render it onto some quads yourself. The main reason to do this is because Fire renders differently based on the surrounding blocks.

You mean quotes. ( is a parenthesis. http://en.wikipedia.org/wiki/Parenthesis#Parentheses_.28_.29

I figured it out yesterday, pure guess. The rendered YAW is based on entity.rotationYawHead.

speedModifier = 60D !? You realize that values greater than about 2 will cause the mob to effectively teleport, right?

There's also Item#itemInteractionForEntity