Matryoshika

Think you got it a bit off. Haven't touched containers since 1.7.10, but I do remember what hell I had with 'em. (They are the bane of my existence). Any slots "outside" the texture? Hover the mouse just outside the outer slots, and see if anything highlights like the slots. Quick look shows ContainerChest uses: for (int j = 0; j < this.numRows; ++j) { for (int k = 0; k < 9; ++k) { this.addSlotToContainer(new Slot(chestInventory, k + j * 9, 8 + k * 18, 18 + j * 18)); } } Or rather, more dynamically: for (int y = 0; y < maxRows; ++y) { for (int x = 0; x < maxSlotsPerLine; ++x) { //Index xpos ypos this.addSlotToContainer(new Slot(tile, x + y * maxSlotsPerLine, 8 + x * 18, 18 + y * 18)); } } You seem to be using x+y*maxRows rather than x+y*maxSlotsPerLine. Do you have a github or similar repository with your current code? I'd like to see the whole container-class as well as the Gui-class.

Where and when do you call your rendering-registration? Main, proxy, preInit, init, postInit? Also, do not use Minecraft.getMinecraft().getRenderItem().getItemModelMesher(), use ModelLoader.setCustomModelResourceLocation instead, and be sure to call that in preInit. Example would be, (by passing block) ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));

Open your texture in any program that can set alpha-levels of layers. Gimp, Photoshop, Krita etc "Behind" your normal textures, make a full-size background layer, with the colour you want. Now the image should be what you want the "fast" texture to be. Set the alpha-level of the background layer, to 0. Now the image should look just like it did before. Export the whole image, in png, and keep alpha-levels. The image should be good to go for what you want.

You have an instance of a block. Let's call it BLOCK. You set the registry-name of BLOCK to NAME. You do not register BLOCK by passing NAME, but by passing BLOCK itself. It should be done like this: public static Block BLOCK = new Block----().setRegistryName(NAME); public static void GameRegistry() { GameRegistry.register(BLOCK); } Switch out BLOCK for whatever you call that instance, replace Block---- with whatever the class of the block is called, and replace NAME with the string you want. In your code, you are telling the registry to register something, of which it only has the name of. It's kind of like asking someone to read a book to you, now, but only stating the books name.

Ah, completely forgot,, it spawn with (as good as) initial velocity. Take a look here: https://github.com/Matryoshika/Saligia/blob/master/src/main/java/Matryoshika/mods/saligia/tile/TileRitualCOTH.java If you depend on outdated mods, try to find other up-to-date mods, or create your own.

Once again: Your GitHub repo is frankenstein'd. It shows classes calling methods that don't exist anywhere, so I have absolutely no clue on how your BlocksInit.registerRenderer looks fully. ModelLoader rendering has to be initialized in preInit. You are doing your registration in postInit, way too late. Haven't touched the ModelLoader#setCustomStateMapper at all, so cannot help you much there sadly, but do switch your call to proxy#registerRenderer from postInit to preInit. If anything, that should solve at least one issue here.

1.7.10 is no longer maintained by Forge. Please update. Items cannot be inside solid blocks, which here happens as it's spawns in slightly clipped into the block it's supposed to be on Spawn it slightly higher up, about 1.2 instead of 1.0

example would be: if(OreDictionary.doesOreNameExist("ingotCopper")){ //Recipe code here }

You are getting the client-side only player-instance, when using Minecraft#getMinecraft#thePlayer. That instance, does not exist, for the server. You need to use EntityPlayer#getHealth, to be able to do anything server-side.

Please update your BlocksInit class. Your client-proxy calls BlocksInit#registerBlockRenderer, which in your repo atm, doesn't exist. Does your block not have any texture at all, or only when actually, placed, or only when in your hand? You must also call your proxy's registerRenderer in preInit not postInit, if your renderer uses ModelLoader, which I hope that you are using instead of the vanilla Minecraft#getMinecraft way.

OreDictionary#doesOreNameExist Boolean, returns true if the given string is registered in the OreDictionary.

I know. All that, was my first ever project for modding minecraft, with zero previous experience with Java, bar doing some C# (~80% Java) 2 years prior. It's a baaaaad project, I know, I won't deny that, but that is why it's on hold, so that I can learn everything I should.

Yeah, 1.7.10 is quite outdated, and projects for it should be discontinued or updated. However, I do still have this 1.7.10 project which I will be updating sometime to 1.10.2. Here, I've already checked for blocks implementing a specific interface, and then call this method, which then creates a HUD of it's name, akin to basic WAILA. https://github.com/Matryoshika/Saligia/blob/master/src/main/java/Matryoshika/mods/saligia/rendering/GUI/HUDRitual.java That's all I can do for ya'.

Ah, you're talking about FPS performance issues. Didn't specify FPS before. Well, constantly updating light-values, in a large-ish area (what is it, 7 blocks out in all directions?) will take its toll. It's a caveat with Minecraft's rendering. AtomicStryker, creator of the mod Dynamic Lights, had to turn it into a CoreMod (Actually editing source-code) to optimize, last I checked. You can see his works here: https://github.com/AtomicStryker/atomicstrykers-minecraft-mods/tree/1.10 On another note: I thought your issue stemmed more from TPS/freezing client initially, which is why I adviced you to do all of this in the item itself, instead of using an event.

Add your modid, "bot" before the strings representing the location of the textures, like this: "1": "bot:blocks/medium_chest_image"

I'd actually abandon the event-way fully, and place a custom, intangible block with light-level near/in the player. I have a Lantern that places a block with an associated tile, that keeps track if the block should exist or not, if the player holds the lantern or moves away. You can see my code here: https://github.com/Matryoshika/Underworld/blob/master/src/main/java/se/Matryoshika/Underworld/Content/Items/ItemLantern.java

Navigate to the referenced line that gets a nullpointer (at net.minecraft.world.Teleporter.placeInExistingPortal(Teleporter.java:134)) Place a breakpoint on that line, and test it. You should get all the information passed to that method, before the method itself is run, which should allow you to see exactly what being passed to it, is null. A guide for placing breakpoints in Eclipse: http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-add_line_breakpoints.htm If you are using any other IDE, you gotta lookup their breakpoint placement yourself.

Your tile needs to implement ITickable for it to get access to a method (onUpdate) that is scheduled every tick. Use your updateEntity code in that instead.

Question: Where did you initlialize the renderer? Your preInit in your main class? Client-Proxy? CommonProxy? Minecraft#getMinecraft is purely client-side. Running it on the server-side will always return nullpointer, because for the server, that method does not exist. I do apologize if you already know of this. You'd be surprised how many try to run Minecraft#getMinecraft server-side.

What is the cause of the crash? Nullpointer? What is your exact code for sending the player to the Nether?

Odd, this issue is the reverse of what most experience >_> Your models/item json file loads fine, as you say you see it when holding it. Do you have a models/block json file as well? Any errors in the console or the FML logs after launching the client?

I'm guessing that you are using a WorldProvider. Override WorldProvider#getSpawnPoint(), to return a suitable spawn-point. Checking if it is suitable, you'd best create another method that checks in blocks through x, y & z coords in for-loops. As far as I can see, the WorldProvider no longer provides anything like the getEntrancePortalLocation method, and the Teleporter#makePortal method checks for suitable locations directly. I'm forcing a spawn-point to an already cleared area here: https://github.com/Matryoshika/Underworld/blob/master/src/main/java/se/Matryoshika/Underworld/WorldGen/WorldProviderCaves.java#L41 Bit messy, but been meaning to clear it up since I managed to figure out how to force a spawn-point.

You still need an Item-Model for each block, in models/item

That "item", is an instance of Item. Of course it'll look for the model amongst the models/item. If you have your model in models/block, create a new .json file in models/items with { "parent": "modid:block/block-you-want" } If the Block is "flat" when in an inventory, be sure that your models/block .json has this just above "textures": "parent": "block/cube_all",