Alpvax

What version are you using? Could you not use block tags instead of config values?

There are currently stats for block mined, and ("custom") interaction stats for the vanilla crafting blocks. All of these are manually implemented. Further there are item use stats, which are manually implemented for clicking on air, but in `ItemStack#onItemUse(context, callback)` (called when clicking a block with an item) the item use stats are incremented if the click is successful. Would people be interested in having a similar system for blocks used (as in interacted with in world)? We could hook into `PlayerInteractionManager#func_219441_a` (the same method `ForgeHooks::onRightClickBlock` is called from) to determine whether stats should be added. The reason why I was looking for something like this is because I was looking to see how easy it would be to determine how many times a player has harvested crops, but I know that right clicking crops to harvest them is quite popular, which presumably doesn't actually add the block mined stat. Also, just basing off block mined would be inaccurate, as it would count non-fully grown blocks. I could always go down the events route, but ideally I would like to be able to retroactively use the stat (i.e. before the mod was installed).

Use the `@ObjectHolder` annotation on I believe a static final field initialised to null (if you have a look at some mods on GitHub you will see it).

Try looking into elytra, sleeping and death. All of those involve the entity "lying down"

These forums only support the latest 2 versions of Minecraft (i.e. 1.14 and 1.13 currently, although due to a special case 1.12 is also still supported currently). RE Your issue, are you using the WILDCARD_VALUE for metadata, because at least at some point in the past that was the value it had. Unfortunately you aren't going to get much more support than that here, sorry. I would STRONGLY suggest updating.

Please stop spamming, you are only going to annoy people, meaning that you won't ever get an answer.

This is the code that drops all the items when the block is broken. You need to change it so that it doesn't call `jar.removeItem();` but you need to save the counter value to the itemstack NBT (Try following the super call back to where items are dropped, see which method it is and override that one instead). Try looking at banners, they save their pattern etc to the NBT of the stack in an easy to follow way.

Some of the issues with your mod is that you are trying to register everything incorrectly: You are only registering them on the client You are registering them in init, not using the Register<Item> event You are only registering the textures, not the blocks themselves on the client Why, why, WHY are you using proxies just to call methods in other classes? Your project is a mess, just calling 1 method which simply calls another and another... Your Main class does nothing except call methods inside the proxies, which in turn mostly do nothing (you have the proxy do something on pre-init on the client, init on both and nothing else)! This makes everything almost unreadable. LEARN JAVA. Then, come back and start from scratch, follow the example of other (well written) mods, and ask for help with forge modding issues when you need it. One of the most important things to learn is how to understand your errors, learn to read and understand the stack trace, you shouldn't need to ask others what the problem is (Although in this case, as Choonster pointed out, you can't see the stacktrace for the actual error without setting a breakpoint).

Where are you calling this from? I imagine it is bundled in with other stuff (probably in the datawatcher). Look through the existing code, look for where the `isSneaking` is declared and see if there is a `setSneaking` method. I'm sorry but I do not currently have access to the source.

You need to set it on the server as well as the client.

Your counter variable is static, so all tileentities will have the same number of items in

Oh I see now. The issue is that Draco's recipes wouldn't be enabled if other mods registered OreDict entries too late. Again, if that issue is discovered by users and reported correctly, the offending mods would be inclined to update. Is it worth suggesting an oreDict version of the item_exists condition for inclusion in forge? (Although it wouldn't solve the problem, it would prevent the need for multiple modders to create their own.)

So this is actually just a case of the reported issue. Other than that it all works correctly? These two statements seem contradictory, I'm not sure what I'm missing here.

Fortunately (ish) those mods who register OreDict entries in init will find that their items cannot be used in other mod's recipes, so will be encouraged to move the registration.

Code? Crash log? We aren't psychic.

Is it your mod? If it is then I suggest you start by looking at the forge documentation on how to set up a modding environment.

Note the word ALL Yes, the file extension is part of the file name.

Forge policy is always to target the latest stable build (currently 1.12 - 14.21.1.2387). Otherwise we get another situation like we had with 1.7.10, where no-one wanted to update.

Why not just subscribe to the player tick event on the server instead of sending a packet every tick?

And as long as people keep making mods for 1.8.x, that will never change. As soon as people make mods for the newer versions, people will migrate across.

You need to import everything. In eclipse you can fix imports with Ctrl+Shift+O.

Your assets folder should be in resources, not in java. Also it appears that your texture is called "photo.png", but you are looking for "hackerNotify.png". Asset path names should also be entirely lowercase.

I doubt you will find much support for not using forge when you are asking on the forge forums. I suggest that you ask elsewhere if you are that desperate to avoid forge. Why don't you want to use forge though? It makes life much easier for everyone.

How do I do that? That doesn't look like you know java, and people don't want to waste their time teaching people basic java concepts, so please try to explain exactly what you are struggling with, rather than just complaining that people are judging you. The more information you give, the more we can help.

Yes, otherwise how will they know what packet to encode/decode? The sender needs to have the packet registered in order to send it to the reciever, and the reciever needs to have it registered in order for it to be decoded back into the data you then handle.