Matryoshika

1) What are you even doing here? Just use i.getRegistryName. 2) Do not use Minecraft.getMinecraft().getRenderItem().getItemModelMesher(), use ModelLoader.setCustomModelResourceLocation instead. Does the exact same thing, hell of a lot less issues than getItemModelMesher. Needs to be called in preInit rather than init. 3) Tool models have the parent "item/handheld". Be sure to have that as well, and not "item/generated"

Yeah, issue was a logical one =_= HashMap was getting an instance of the tile, but that same instance would then be used when the block was placed. I replaced the RitualRegistry parameters to make use of the class directly, and then invoking a new instance when the block is placed. It works now I'm using my own API, as each ritual makes use of the same block, which changes the placed tile based to what RitualName is set to when it gets registered. I have at least 16 tiles planned, which will all be connected to the same block. API is there to allow anyone else who wants to easily add their own ritual (multiblock based tile) to my mod. Simply returning a new TileRitual.... would have fixed that issue, yes, but would have left the whole point of a central block used by all tiles, including other's, pointless.

Both of those are done in the SaligiaBaseMultiblocks.class which is called from the CommonProxy postInit. https://github.com/Matryoshika/Saligia/blob/master/src/main/java/se/Matryoshika/Saligia/Utils/SaligiaBaseMultiblocks.java

I've been updating my first ever minecraft project from 1.7.10 to 1.10.2, and been confronted with a quite bizarre issue. If I'm in a completely new map, and in a fresh instance of minecraft, my tile works perfectly. If I as much as even touch or cause the block to update, the tile just dies. No matter if I place a new one, the block will not issue what is inside of it's update() method which is inherited from ITickable. The issue follows through new maps & games, unless I create a new map in a new game. Where it works fine once again, till anything happens to it. The block does contain the tile, that is sure. My debugger item outprints "contains tile: se.Matryoshika.Saligia.Content.Tiles.TileRitualCOTH@..." when used on the block. Not even just a simple System.out.println("Update") works in it's update() method. Anyone able to see what the heck is wrong with this specific tile? TileEntity Code: https://github.com/Matryoshika/Saligia/blob/master/src/main/java/se/Matryoshika/Saligia/Content/Tiles/TileRitualCOTH.java

Don't use BlockContainer, simply override createTileEntity and hasTileEntity from the Block class. If you look into the BlockContainer class, you'll see it does a lot with the rendering, and is simply a pain in the proverbial behind.

Sounds need to be converted to the .ogg format, last I checked. In assets/modid/sounds, add the .ogg files. In assets/modid, add a sounds.json In that, you would add something like this, if you have a file called testSound.ogg { "testSound": { "category": "block", "sounds": ["modid:testSound"], "subtitle": "modid.subtitle.testSound" } } You will have to look up the various categories inside SoundCategory. Subtitle is the unlocalized string presented to those that have subtitles enable. You then need to create a SoundHandler, that registers the sounds. Vazkii's Psi has one you can look at: https://github.com/Vazkii/Psi/blob/98d44ba9e7852739e11515d53f6c0f21cef418d1/src/main/java/vazkii/psi/common/core/handler/PsiSoundHandler.java Then in the various world#sound.... methods, you'd just call your SoundHandler#SoundYouWant along with the other variables (x,y,z, category, pitch, volume etc )

To register an event, you need to register it to a bus. You should use the basic EVENT_BUS here. Create a private final instance of your EventHandler class. For example, using my eventhandler from one of my mods, called UnderworldMapEventHandler.class, I would use private final UnderworldMapEventHandler ANY_NAME_YOU_LIKE = new UnderworldMapEventHandler(); Then in your proxy, register it simply with: MinecraftForge.EVENTBUS.register(ANY_NAME_YOU_LIKE); (For those you who sees the issue with event->bus here, don't worry, my own eventhandler uses the TERRAIN_GEN_BUS)

Hmm? ClientTickEvent already gives you the EntityPlayer (and through it, the world as EntityPlayer#worldObj) Minecraft is already Client-Side, so simply use "Minecraft minecraft = Minecraft.getMinecraft()". Try this instead: @SubscribeEvent public void onClientTick(TickEvent.PlayerTickEvent event){ final Minecraft minecraft = Minecraft.getMinecraft(); final EntityPlayer player = event.player; final World world = player.worldObj; } Also, have you registered the event-handler to any bus? If it's not registered, it's not going to do anything. To get the biome, as this topic is about, you need to get the player's position, then use world#getBiomeForCoordsBody(BlockPos)

Please actually post your crash-log. Without that, we have no clue what's actually happening.

Alternatively, to not rely on the other mod at all: If you know the EntityName, you can simply check if the mod is loaded, like Leviathan states, and then use the EntityList#NAME_TO_CLASS to get access to its class directly.

You are trying to set the registryName twice. You can only do it once. Remove the .setRegistryName(prefixName+suffixName) if you are doing it somewhere else.

What exactly is your crash? Are you ever setting the registryName in each block? Has to be done in the blocks constructor, or while registering the block instance

Here, have a look on one of my registries. https://github.com/Matryoshika/Underworld/blob/master/src/main/java/se/Matryoshika/Underworld/Content/ContentRegistry.java And for rendering: https://github.com/Matryoshika/Underworld/blob/master/src/main/java/se/Matryoshika/Underworld/Content/Rendering/BlockRenderRegister.java ContentRegistry: Fired in CommonProxy; preInit. BlockRenderRegistry: Fired in Client-Proxy; preinit.

For the collision-box, override getCollisionBoundingBox(IBlockState blockState, World worldIn, BlockPos pos) to return the bb you want. For the meta issue, if I understand this correctly(When mined, the block given has a meta of something you already have) If these are all instances of the same class, then I'd imagine you are using a for-loop to register them, no? In teh same for-loop, have it add each and every block to an Array. Add a new method, simply called setRegisteredNumber, which returns a block, the block itself. Have setRegisteredNumber set a public integer with the provided value. Then in your getPickBlock, return the corresponding block-instance in that array, depending on the registerednumber value.

Where are you firing your render-registry? Main, or proxy? When? preInit, init or postInit? Are you calling this before or after you register your block? Also: Do not use "Reference.MODID + ":" + prefixName". Simply use block.getRegistryName, after setting the registryName, either in your block's constructor, or while instantiating the block for registration. In a mod called "supermod", if I set the registryname of a block to "superblock", getRegistryName would return "supermod:superblock", it's all done for you.

ServerChatEvent: Fired when a chat message is about to be handled by the server. Uses the fields String message, String username, EntityPlayerMP player, ChatComponentTranslation component. You'd have to incorporate your own logic of who it is going to, as Minecraft only deals with where it is coming from.

Where are you calling your BlockRenderRegistry? It must be called client-side only, and after you initialize ModBlocks

Minecraft uses both standard OpenGL light, as well as a lightmap to control brightness. Try doing GL11.glPushMatrix(); GL11.glDisable(GL11.GL_LIGHTING); OpenGlHelper.setLightmapTextureCoords(OpenGlHelper.lightmapTexUnit, 240f, 240f); ---Render what you want--- GL11.glEnable(GL11.GL_LIGHTING); GL11.glPopMatrix(); Haven't done anything with OpenGL since 1.7.10, but all of these methods still exist in 1.10.2 at least, so they should get you going

Why do this only from the inventory? Why not just start it from the inventory, and handle everything in the item itself? When you put something in the container, make it turn a boolean in the held item from "empty" = true, to "empty" = false; There, that states if it has something in it. If you never made a custom slot, (not sure if this is still an issue in 1.10.2, only did this back in 1.7.10) you can put any item inside, which would be bad. (Remember to cast the item to your own item to get access to the boolean, from the container) So: you know how long the fuel lasts, and you know if the item has fuel or not. Every tick, countdown the lifetime left of the fuel, in the item's onUpdate, or a derivative method, and make it output energy. If it runs out of energy, or everything that can use the energy is full, make it stop in it's tracks, and be "frozen" until it is refilled, or can output again. (Unless you want it to keep going nevertheless)

Like Draco18s, I wonder what the heck you mean? You mean world#getBlockState(BlockPos)#getBlock()?

For-loops are your friend. Reference another method that returns a boolean. public boolean checkBlocks(World world, BlockPos playerPos){ //Check in x-axis for(int x = -2; x < 3; x++){ //Check in z-axis for(int z = -2; z < 3; z++){ //Only get the blocks that are 2 blocks out (For loop -can- be used here instead) if(x != -1 || x != 0 || x != 1 || z != -1 || z != 0 || z != 1){ //Create a new BlockPos based on our offsets BlockPos pos = new BlockPos(playerPos.getX()+x, playerPos.getY(), playerPos.getZ()+z); //If ANY block is not air, return false if(world.getBlockState(pos).getBlock != Blocks.AIR){ return false; } //If all blocks are air, return true return true; } } } return false; }

Ö.ö loads fine in hand, but not in world? Most get the issue other way around... Where are you registering the block? Main, proxy? When? preInit, init, postInit? If doing this from the proxy: Make sure that the proxy actually gets called. Blocks & Items should be registered in preInit, just like the renderer. Any errors in console after launching client?

Thats... kinda what I just said. Read the highlighted part of the quote

Ö.ö?? Also, Minecraft.getMinecraft().getRenderItem().getItemModelMesher() is prone to soooooooo many issues, that stating that it "works" 100% of the time cannot ever be true. Forge had to add it's own ModelLoader, just to fix the issues getItemModelMesher have! @AnZaNaMa ModelLoader has to be called in preInit. You are calling it in init.

To quote the Block#setRegistryName documentation: Same thing applies to, random strings. You are meant to use RegistryName here, but you imitate it using a string that does what RegistryName does. It's unlikely, but if ANY mod, literally any ever has a method that checks blocks, and uses Block#getRegistryName, on this block, guess what'll happen. Bam, nullpointerexception. Sorry if I sound harsh, but this is what you are meant to use! It's actually dangerous to do what you are doing now.