superminerJG

Yep. If you're wondering about the functional interfaces, I use them to keep code clean. Blocks are registered in ModBlocks, and suppliers and functions are created using the Suppliers class. When does this happen, and why? Logs: https://gist.github.com/superminerJG/de17f22335b40f7edcf3fa36c3116a0a Mod repo: https://github.com/superminerJG/Vanilla-Automation EDIT: using the registry object as a supplier solved it.

Which method on the player returns their UUID? I can only find PlayerEntity#getDisplayNameAndUUID, which returns an ITextComponent.

What I wanted to say was the player should have a value between 0-399 inclusive stored on them, representing what Wold#getGameTime() % 400 was when the player acquired mercury. That way, it seems less predictable.

For reference, here's a link to my repo. I am adding "mercury poisoning" to the game. Starting from when the player grabs an item under the tag "vanauto:contains_mercury", every 20 seconds, they have a chance of receiving the poison effect for 10 seconds. I plan on doing this by storing an NBT tag on the player: "LastHgAcquisition", which is then used to calculated whether to tick the player or not. The problem is, I'm not sure if this is good practice, since NBT is usually managed by capabilities, and adding an entire capability like "CanHgPoisonCapability" seems kinda clunky. Is there a simpler way to track these sorts of things? Note: stackable items need to stay stackable.

Title explains it. https://github.com/JGgithub2018/Vanilla-Automation How does this sort of thing happen? What can I do to fix it?

I'm adding cinnabar (and later, other mercury-related things) and I wanted to add some kind of "mercury poisoning" to these items. The idea is that every 20 seconds, a player holding cinnabar has a 10% chance to receive Poison II for 10 seconds. I've been looking at Extra Utilities' Unstable Ingot, which causes the player holding it to explode 10 seconds after it's been taken out of the crafting grid. However, RWTema hasn't updated it to 1.15.2, so I'm not sure how it might work now. Any ideas?

Do you not see a search bar? *sigh* it's to the right of "Merch". *heavy sigh*

Reasons Forge isn't coming to Bedrock: Bedrock is written in C++, which is much harder to decompile than Java Bedrock runs on Xbox 1, PS4, and Switch. Inserting Forge's code onto a console is even harder (Console makers hate homebrew) Furthermore, the decompiled code is nearly impossible to make sense of (or deobfuscate) so modders won't know what they're doing Well there you go. Unless Mojang makes Minecraft open-source, Bedrock modding is very, very, very, very hard to do.

You need to build it using Gradle.

An ExceptionInInitializerError basically says an exception occured when assigning a static variable. Make sure the static variables' initializers don't produce exceptions.

There is a 1.15.2 preview, try that.

class Ticker extends ITickable{ static int timer = 0; static boolean pressed = false; static boolean doublePressed = false; static void tick() { if (Minecraft.getInstance().gameSettings.keyBindLeft.isKeyDown()) { if (!pressed) { if (timer < 8) { doublePressed = true; } timer = 10; pressed = true; } if (doublePressed) { //do stuff } } else { pressed = false; if (doublePressed) { doublePressed = false; timer = 0; } } timer--; } } I honestly don't know if this will work, but this is how I think it should work. Obviously you can improve on this, but the idea is to make sure that the second press doesn't happen too soon.

I believe you'll need to subclass net.minecraft.item.crafting.SpecialRecipe to create a special crafting recipe (look at ArmorDyeRecipe) Then you need to register a recipe serializer for said SpecialRecipe.

Would you mind putting your mod's source code on GitHub?

The reason this happens is if you hold the key for long enough, it starts to send repeated keydown inputs. So that's why the boolean is necessary. like if i held down k for long it does this: kkkkkkkkkkkkkkkkkkkkkkkkk