Draco18s

Did you register it?

All I can tell you is that treating those blocks as pathable (and diggable by mobs) is a non-trivial task. There's a 1.6.4 mod, Invasion Mod, that did have this, but they had to implement their own pathfinder, and so on. There's an incomplete update for 1.7 available here.

In b4 deisieben07 says, "stop using 1.6.4": Can't help you without error log.

Try swapping these two lines: GameRegistry.registerBlock(BlockLiquidCoffee, Names.LIQUID_COFFEE_BLOCK); FluidRegistry.registerFluid(LiquidCoffee);

Long story short: For some reason the tessellator doesn't work when called from a TESR. Same code copied into an ISimpleBlockRenderer renders just fine.

Thanks anyway Diesieben. Trying to poke at the values that make RenderBlock do its Thing, nothing is seeming to indicate a complete non-render. :\ Copying tessellator code now to do it my bloody self.

Hmm. It didn't crash, but it also didn't render the water. http://s27.postimg.org/kb12ndiar/2014_11_21_13_30_09.png[/img] Item Render is using an old model which is not being used in-world at all (commented sluice.render(...) so it would just draw the water). Not sure how to go about debugging that, as it would require adding statements inside vanilla code.

Ahh. I'll try that, thanks.

import net.minecraft.client.Minecraft; import net.minecraft.client.renderer.ItemRenderer; import net.minecraft.client.renderer.Tessellator; import net.minecraft.client.renderer.texture.TextureMap; None of these classes exist on the server, merely instantiating your class will cause the server to crash due to missing references. You will see this a lot with inter-mod compatibility. You must create a unique class for EACH mod API you want to use because if that mod is not present and you call a function in a class that merely contains the imports will cause Minecraft to crash, even if the code that uses the imported classes isn't called.

So here's what I'm trying to do, I have a model that I want to render a block of flowing water in the same space so that my model doesn't need to supply the faces and texture of flowing water itself for various reasons. public class TESRSluiceBottom extends TileEntitySpecialRenderer { private ModelSluice sluice = new ModelSluice(); @Override public void renderTileEntityAt(TileEntity tileentity, double d0, double d1, double d2, float f) { System.out.println("Rendering sluice at " + tileentity.xCoord + "," + tileentity.yCoord + "," + tileentity.zCoord); System.out.println("world: " + RenderBlocks.getInstance().blockAccess); if(RenderBlocks.getInstance().blockAccess != null) { RenderBlocks.getInstance().renderBlockAllFaces(Blocks.flowing_water, tileentity.xCoord, tileentity.yCoord, tileentity.zCoord); } sluice.render(tileentity, d0, d1, d2, 0, ((TileEntitySluiceBottom)tileentity).getRotationY()); } public void renderTileEntityInventory(TileEntity tileentity, double d0, double d1, double d2, float f) { sluice.render(tileentity, d0, d1, d2, 0, f); } } Problem is: RenderBlocks.getInstance().blockAccess is always null. Rendering sluice at -720,62,-447 world: null Rendering sluice at -720,62,-447 world: null Rendering sluice at -720,62,-447 world: null Rendering sluice at -720,62,-447 world: null Rendering sluice at -720,62,-447 world: null Rendering sluice at -720,62,-447 world: null Rendering sluice at -720,62,-447 world: null If that IBlockAccess field is null, then when it goes to attempt to render the water, it tries to get the biome color to use for the water, which requires a non-null world (i.e. it crashes). So clearly I'm doing something wrong somewhere. What do I need to change?

I don't know why, but Forge 965 uses MCP. Go get 964, which has Gradle.

You don't have to.

Also use @Override so that your IDE will yell at you when you aren't actually overriding something.

Just as an example of "something you can actually do" (with enough time, knowledge, and effort): Recreate the affects of Accel World's Brain Burst game which stops time. The rough bullet point method of doing this is as follows: 1) recreate the 2) copy region data to a new dimension when the player activates Brain Burst 3) teleport the player to this dimension (there's another mod that does something similar and has a "power cell" biome where no ticks happen) 4) add a blue-tone filter 5) add custom gameplay 6) teleport player back to the overworld when done 7) play out the resequence data, accelerating the updates of all objects not in the player's view fulcrum (if it enters, replay at normal speed until it leaves again). Voila, player-perspective time-stopping powers.

Also, just as an FYI: Your default case should treat the dimension "like the overworld" for compatibility with other mods, such as Mystcraft. If you don't add any code to determine what mod added the dimension and figure out if your ore should generate there or not (the Mystcraft API has an "is Mystcraft Age" method, for example) then just assume that it's "overworld-like" and attempt to generate.

I have both Indigo and Juno and both work fine.

what happens when... amt = 10 player.experience = 5 player.experienceLevel = 2 ..?

public ItemStack onItemRightClick(ItemStack itemStack, World world, EntityPlayer player) { itemStack = new ItemStack(...); } ?

The Tessellator is how vanilla draws black squares.

So use the NBT all entites have instead. I gave you two options and you don't know anything about one of them (and frankly, neither do I).

I think I hodge-poged my code together from looking at how other mods did it. And no, there's no registration in either the main mod class or the client registry (I just looked, and all of those classes are on git).

Look at the line above that one. GameRegistry.addRecipe(new ItemStack(itemWand), new Object[]{" B ", //something missing here, yo

Use the player's EntityNBT or IExtendedProperties.

That kind of data shouldn't be stored in your Shield class at all, it needs to be stored on the player. Because if Tom uses his shield, you should be rendering it around Tom and only Tom, not Steve, Jane, and Boris.

Well for starters, you should do player.experience >= amt Second the 1F/player.xpBarCap(); adjusts the bar...by 1 point of exp, you should use amt/player.xpBarCap(). Third, you'll have to similarly adjust the second block. Fourth, what if the player has less than that amount of exp and no levels?