V0idWa1k3r

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.

You do not need to find a name of a method. The method you used is client-only which crashes the game, reflection isn't going to magically recreate a method for you, and the other one is public anyway. You need to modify the the FoodStats.foodSaturationLevel field. Also field_71147_cj is EntityPlayerMP.wasHungry. It makes no sense for a method to be named field_xxxxx

An example of what? Overriding a method? Adding things to a list? Invoking List#sort? This is all basic java.

Alternatively don't let the base implementation take care of the list for you and populate it manually in that method with your desired items in your desired order.

Define "organize". Do you mean change the order of things in the tab? By default they are arranged in their registry order. You can use custom sorters by overriding CreativeTabs#displayAllRelevantItems and performing sorting on the list you get as a parameter. Obviously only do that once the list is populated with items(after the super invocation)

Create a new field that will hold the reference to the foodSaturationLevel field, instantinate it as ReflectionHelper.findField and then use that field just as you would with normal java reflection. public static final Field foodStats_foodSaturationLevel = ReflectionHelper.findField(FoodStats.class, "MCPNAME", "SRGNAME"); You can learn the field's SRG name with MCPBot or locally on your computer in %user_home%/.gradle/caches/minecraft/de/oceanlabs/mcp/mcp_snapshot/%snapshot_date%/fields.csv.

Well you could read forge's official docs. They are not exactly a tutorial though. Apart from that not really, I haven't seen any good tutorial. Even praised modders like McJty make numerous mistakes in their tutorials and enforce cargo-cult programming. I guess the best way to learn is to consult forge docs, look at some open-source mods that are trustworthy, look at vanilla and ask on these forums. I could recommend some repositories I've looked at and they look fine to me - here, here, here, here is mine. Anyone is also welcome to cotribute their repositories if they want to and they feel confident enough in them. Yeah, this just screams instantinating at wrong time & place. Also it likely calls client-side only code in a common environment which will crash the server. Yeah, this is the outdated way to register your entities. Entities are now registered with EntityEntry which is a IForgeRegistryEntry itself so it has a propper registry event fired for it. Basically subscribe to RegistryEvent.Register<EntityEntry> and use EntityEntryBuilder to register your entities in that event directly. Like this: @SubscribeEvent public static void onEntityRegistry(RegistryEvent.Register<EntityEntry> event) { event.getRegistry().register(EntityEntryBuilder.create().entity(YourEntity.class).id(new ResourceLocation(MODID, NAME), NETWORK_ID).name(NAME).tracker(RANGE, FREQUENCY, SEND_VELOCITY).spawn(EnumCreatureType.WANTED_TYPE, WEIGHT, MIN, MAX, BIOMES).egg(COLOR_FORE, COLOR_BACK).build()); }

This is true and this is exactly why you provide 2 names for the field/method you are looking up. One is a MCP name, that works in your dev environment. The other is an SRG name for the normal "obfuscated"-ish environment. It doesn't prevent you from using reflection, just makes you do an extra lookup. Or a check for the environment.

The version doesn't matter. Reflection always worked just fine. You always had to supply 2 names to it and it would always work. There is no "magic" in minecraft that makes it somehow not work with basics of the language it is written it. Minecraft is just as valid of a java application as any other one and as such is completely compatible with java's API. I have no idea what MDC is or who UpcraftLP is but they are not telling you the truth.

When registering(or rather creating EntityEntry for your entity but if you are doing things correctly you are doing both on the same line of code anyway) your entities use the EntityEntryBuilder#spawn to add your entity entry to biomes listed in order for your entity to spawn in them. ...Although I suspect that whatever tutorial you are watching is telling you to use EntityRegistry. Which is an outdated way of registering entities and you should not be using it. Am I correct? As a side note I would also recommend not using tutorials on youtube at all. They are created by people who also just started modding, picked up all the wrong ideas and practices but are eager to share their discoveries with the world. I have yet to see a modern, good tutorial on youtube.

There isn't even such a class in all the libraries forge uses including forge itself. This is absolute and total bollocks. I have no idea where you got that impression from but regular reflections work absolutely fine. The only catch is that you have to search 2 methods/fields at the same time - the one with the DEV name and the one with the SRG name. Forge has a utility class ReflectionHelper that allows you to pass multiple names for a field/method when getting it.

Do you need a tutorial on java's reflections? What is your question here?

I do not think this is possible because you don't have a reference to the entity which initiates the pathing check whatsoever. I suppose you might be able to replace the basic EntityMoveHelper with your wrapper that does the check for your specific block but this might cause incompatibilities with mods that attempt to do the same.