V0idWa1k3r

This will never be true because ticks is a local variable assigned to 0: World#getEntitiesWithinAABB is the perfect way to get all entities of a given type in a box around some point. The only thing I could advice is to use EntityCreature as the base class instead of EntityLiving since you are already checking if the entity is an EntityCreature, put the other conditions into the predicate of World#getEntitiesWithinAABB and invoke the method when this condition is satisfied: Otherwise you are just doing extra work that is not necessary.

Where on earth did you get that idea from? Did you read the thread that I linked? Absolutely nowhere does it say anything about threads, much less multithreading. And even if you attempted to you would just crash horribly because the game isn't thread safe at all. And even if it was it wouldn't eliminate the issue at all since it comes from your worldgen loading chunks that were not generated yet and thus causing them to generate. A direct quote from the thread: This is all you need to do. Unless your worldgen is bigger than a single chunk. In that case you would need to split it into pieces and generate those pieces separately.

This is not an argument. 1.8.9 is 4 years old and is no longer supported on this forum. We simply can't offer you help with this version because there were too many changes and nobody wants to remember how to work with the outdated methods anymore.

A concept of a common proxy makes no sense. Proxies exist to separate sided only code. If your code is "common" then it goes into your mod class, not into your proxy. serverSide = Reference.COMMON_PROXY_CLASS This makes even less sense. Server proxy either hosts noop methods that are only applicable for the client or server-side only methods. Your common proxy can't be your server proxy. ItemBase is an antipattern. You do not need it. public static final Item RUBY = new ItemBase("ruby", CreativeTabs.MATERIALS); Don't ever use static initializers. Instantinate your stuff in the appropriate registry event. IHasModel is stupid. All items need models, no exception and there is nothing about an item model that requires access to private/protected things. Register your models directly in the ModelRegistryEvent, not in your item classes. What is up with your ruby.json model? Why are there so many transforms specified? Why is it's parent a item/handheld? Main.proxy.registerItemRenderer(this, 0, "invetory"); invetory != inventory. Actually also related and the cause of your issue: public class CommonProxy{ public void registerItemRenderer(Item item, int meta, String id) {} } public class ClientProxy extends CommonProxy{ public void regsterItemRenderer(Item item, int meta, String id) { ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(item.getRegistryName(), id)); } } regsterItemRenderer != registerItemRenderer. This is why you a) Never use a CommonProxy but instead an interface. b) Never manually override methods and use the override feature of your IDE c) Always annotate methods that are intended to be overridden with @Override As an unrelated sidenote: Any particular reason you've hosted your code on mediafire of all places? You can just create a free github repository, you know?

Ugh, another crappy youtube tutorial. I've watched a total of 10 seconds of it and I immediately saw the CommonProxy, IHasModel, static initializers and ItemBase. No, thanks. In general youtube tutorials are pretty bad, don't rely on them. I have yet to see at least an okay modding tutorial on youtube. They teach you all the things not to do so I am not surprized you are encountering issues. As for your issue - I see no errors in the log which likely means that you've not registered a model for your items in the first place but I can't tell for sure since you've shown zero code. So could you please provide some of your code so we can inspect it for issues?

Is this your mod? If it isn't complain to the author. If it is you need to read this:

Uh, the naming of the last parameter is wrong. It's partialTicks, not ticks. There is a huge difference. if(timer >= 0) { timer--; if (this.fade < 1.0F) { this.fade += 0.03F; } } else { this.mc.displayGuiScreen(new ArsenalMainMenu()); } You can't do this in the drawScreen method because it happens each frame, not each tick. If you want your animation to stay consistent with the framerate you need to use GuiScreen#updateScreen to update your counters, that happens each tick, not each frame. Why are you passing y as partialTicks? All resources must be lower-case(as far as I am aware anyway, feel free to correct me). Same with the line directly after. And what does this method do? Or rather what is the code of this method? There is no need to push/pop matrix here as you are not changing the matrix at all. Do you have any idea what this does? What does 3042 magic number mean? Please don't just blindly copy deobfuscated code and call it good, actually understand what's going on. Also don't use GL11, use GlStateManager. And if you are enabling blend you need to specify the blend function too since you don't know what it was specified to beforehand(3042 is GL_BLEND in case you were wondering) You just enabled it. 3 lines above in fact. Oh and while I am at it if you are changing the GL state take care to restore it after you are done your drawing. Don't just leak GL state. Apart from all these glaring issues I immediately see - yeah, what @diesieben07 said. You need to clarify your issue a bit more and show a bit more code.

My bad, I misread this As "this breaks textures". Now when I've looked at your blockstates I see that you are good on variants. I am actually unable to reproduce the issue described in my local copy of your repository. After adding this @Override public IBlockState getActualState(IBlockState state, IBlockAccess worldIn, BlockPos pos) { return super.getActualState(state, worldIn, pos).withProperty(BLOCK_STATE, ((LogicTileEntity)worldIn.getTileEntity(pos)).getClickCount()); } To the LogicBlock class I am able to both click the block and see the texture changes as well as relog into the world and see the correct textures(and by proxy the correct state)

Popular != good. A lot of popular mods are actually quite badly written with a lot of bad practices in place and a ton of cargo-cult programming in place. I can recommend some trustworthy repositories for learning:

First of all your actual issue - you've never actually registered your gui handler. You have the method that registered it correctly... in an another method that is never called from anywhere. BlockBase/ItemBase is an antipattern. Composition over inheritance. IHasModel is stupid. All items need models, no exceptions. And nothing about item model registration requires access to private/protected stuff. Register your models in the ModelRegistryEvent directly. @SubscribeEvent public static void registerBlock(RegistryEvent.Register<Block> event) { event.getRegistry().registerAll(ModBlocks.BLOCKS.toArray(new Block[0])); TileEntityHandler.registerTileEntities(); ClientRegistry.bindTileEntitySpecialRenderer(TileEntityCopperChest.class, new RenderCopperChest()); } You can't do this. Registering a renderer for a TE is a client-side only operation, while RegistryEvents are common code. This will crash the server. public static final Block COPPER_BLOCK = new BlockBase("copper_block", Material.IRON); public static final Block COPPER_CHEST = new BlockCopperChest("copper_chest"); public static final Block LOG_STRIPPER = new BlockLogStripper("log_stripper"); Never ever use static initializers. Instantinate your stuff in the registry event directly, not in static final fields. compound.setInteger("BurnTime", (short)this.burnTime); compound.setInteger("CookTime", (short)this.cookTime); compound.setInteger("CookTimeTotal", (short)this.totalCookTime); Any particular reason you are replicating a vanilla bug of casting things to a short but saving them as ints? public static int getItemBurnTime(ItemStack fuel) *Sigh*. This is like the tenth time I see this method in custom TEs that have a fuel unedited and blindly copied from TileEntityFurnace. You are not changing the implementation of this method. It is static. And public. Just invoke it from TileEntityFurnace, there is absolutely zero need to mindlessly copy-paste it from TileEntityFurnace, this is not how programming works. You are not using IInventory, why are you copying this abomination of a method from it? Just reference your fields directly, you do not need this. @Override public void tick() public void update() So, you've blindly copied TileEntityFurnace and yet it never occured to you that it is a little bit strange that the TileEntityFurnace has no tick method at all yet you are for some reason required to override it, and when you put @Override over the update method you get an error? No, no concern at all? Again - you need to understand what is actually going on, not blindly copy classes and then hope everything works out. If you ever want to learn you need to start understanding. Also, auto-fix in eclipe isn't a magical "fix all my issues" button. Instead of using it here you need to try and understand why do you need to implement tick here. I am kinda going on a tangent here, and I am sorry if I sound rude or something, but I am trying to help you. The issue in this case is simple - you've implemented the wrong ITickable but if you actually stopped and thought about the issue for a minute instead of blindly applying auto-fix of eclipse then you woundn't have this issue in the first place. This applies to your other TileEntity too, the copper chest one. public Table<ItemStack, ItemStack, ItemStack> getDualSmeltingList() Again, this is not the first time I am seeing this. Why are you using a Table exactly? There is no reason to use Table here, this is not it's use case. Use a Triple<ItemStack, ItemStack, ItemStack> instead. Why do you have 2 of the same class LogStripperRecipes in 2 different packages? They are identical after all. Your TileEntityCopperChest implements IInventory. Not directly, through inheritance but still. Never do that. IInventory is a horrible artifact of the past and nobody should be ever using it. Use capabilities instead, like you are doing in your furnace TE. CommonProxy makes no sense. Proxies are to separate sided only code. If the code is common it goes into your main class. Do not use a CommonProxy, use an interface instead. Your NBTHandler methods are kinda broken. First of all when saving an ItemStack you also need to save it's NBT and capability data, not just it's registry name and count. And second of all ItemStack already implements the methods for (de)serializing it into NBT, there is no need for duplicate functionality. public interface IStructure { public static final WorldServer worldServer = FMLCommonHandler.instance().getMinecraftServerInstance().getWorld(0); public static final PlacementSettings settings = (new PlacementSettings()).setChunk(null).setIgnoreEntities(false).setIgnoreStructureBlock(false).setMirror(Mirror.NONE).setRotation(Rotation.NONE); } You really can't do this. This is not how anything works at all. These are static final fields meaning they get instantinated when the class is loaded. A lot of the things you are referencing here will be null by then. This makes even less sense than a CommonProxy. A server proxy is NOT your CommonProxy, it's a collection of methods that either provide a noop implementation for client-only stuff or reference server-only things. A server proxy can't and musn't be a CommonProxy. This is not how proxies work and they are not meant to be used like this.

Could you please setup your repository on github so I can debug it locally?

You still haven't answered most of my questions. It is not supposed to. Place a breakpoint in your IGuiHandler implementation when returning the GUI or the Container object to see if it is getting called. Place a breakpoint in your GUI/Container constructor to see if they are getting invoked.

This is an internal method for getting the blockstate from an internal ID. Never use anything that involves IDs ever. Construct the blockstate yourself with the properties you need. Blocks.STAINED_HARDENED_CLAY.getDefaultState().withProperty(BlockColored.COLOR, EnumDyeColor.WHITE)

The error is pretty obvious It means that your recipe is missing the "data" property for that ingredient. You need to specify the data property for items that have subtypes, like dirt which has 2 subtypes - normal dirt and coarse dirt.

BlockBase is an antipattern. You don't need it. @Override public Item getItemDropped(IBlockState state, Random rand, int fortune) { return Item.getItemFromBlock(ModBlocks.LOG_STRIPPER); } @Override public ItemStack getItem(World worldIn, BlockPos pos, IBlockState state) { return new ItemStack(ModBlocks.LOG_STRIPPER); } @Override public EnumBlockRenderType getRenderType(IBlockState state) { return EnumBlockRenderType.MODEL; } These are not needed at all. This is the default implementation of these methods. There is no reason to override them since you are not providing a different implementation. Don't set the blockstate in Block#onBlockPlaced and Block#onBlockPlacedBy. Return the blockstate you need in Block#getStateForPlacement. if(tileentity != null) { tileentity.validate(); worldIn.setTileEntity(pos, tileentity); } You do not need these TE manipulations. Just override TileEntity#shouldRefresh and return false if it is a simple blockstate property change. You have not provided enough code. Have you registered your IGuiHandler implementation at all? Does your container override Container#canInteractWith and if it does what does it return there? And if it references your TEs what do they return in their methods? What did the debugger told you? Are your IGuiHandler methods being invoked? Are your Container/GUI constructors getting invoked?

I might be blind here but I see absolutely nothing that would make the blockstate have the clicked property from your TE upon reloading the world. You are not referencing your TE in Block#getActualState, you don't even have that method and you are not serializing the property into metadata. What makes you think it would magically persist then? The TE saves the counter just fine, it's the blockstate that doesn't. As @supercat765 said you need to include the property in your Block#getActualState. That also means that you need to include the variants in your blockstate file for the model to work.

Well, yes. But forge for 1.13 isn't out yet.

https://github.com/MinecraftForge/MinecraftForge/issues/5056

I already told you. Iterate get the closest player and work from there.

Could you please clarify your question? What is your actual issue? What do you want to acheive? Take note that casts the fuel burn time to a short before saving it to the NBT, meaning that the max burn time you can have persist is 32767. As your number is greater than 32767 it will not persist, instead it will be saved as -21023. There is no fix to this issue as far as I am aware, that's a vanilla oversight.

These are completely different things. World.isRemote checks whether you are on a logical client or not. @SideOnly removes the method completely from the class on the physical side opposite to the one specified.

EntityPlayer can't be an instance of FoodStats. This operation is quite expensie. Do it in your class initializer.

I don't even know what you are trying to say. The code you've provided declares a valid method. There is nothing wrong about it. You might want to learn java before trying to create mods for the game otherwise it will be like assembling a rocket without any instructions.

Well obviously if you've deleted the method you can't keep a reference to it. This is basic java. Also make sure your event handler is actually registered. And it would probably help if you were to actually register the EntityEntry objects you are creating instead of putting them into an array and doing nothing with said array.

Override GuiContainer#drawGuiContainerForegroundLayer, check if the mouse coordinates are within the desired area and draw the tooltip you want with GuiScreen#drawHoveringText like I do here for example.