Draco18s

This is what I believe happens as well. Each chunk may (or may not!) be on its own thread, so you can't reach out too far. I think/hope/assume that the +X/+Z chunks are accessible, due to how vanilla has always handled generation across chunk boundaries before, but I haven't had the time to actually find out. Its possible that there's some precompute (eg. structures) with the structure part bounding boxes and vanilla goes "ok, cool, you want to generate in this volume, that'd be this list of chunks...pooling chunks together...spawning thread...here you go, do what you need."

Utility classes can often help reduce the amount of code you need to write. For example, back on 1.12 (when we no longer had the Game Registry and had to register item models ourselves) I wrote this class: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/EasyRegistry.java That's the 1.14 version, but the switch was pretty straight forward. It meant I could have my "1.7-like" register-a-block one or two line clean system: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L119-L131 Instead of this utter nonsense people were doing where they'd create a block, set its registry name, set its translation key, add it to a BLOCKS list, then add the blocks list to the registry, then over in the item event loop over their entire BLOCKS list, create an item (set its registry and translation keys), set a creative tab, and add it to an ITEMS list. And then realize "herp a derp, I created this giant loop that does all my blocks, how does I do more than one creative tab where some blocks are in one and others are in another? What if my block has variants that need different items?" and then end up needing nine lines per block (plus a couple lines for registering a model in the client proxy!). The deferred registry system is what I'll be using on 1.16 because it solves the problem I was solving.

https://github.com/Draco18s/ReasonableRealism/ (and its older predecessor https://github.com/Draco18s/HarderStuff) https://github.com/Draco18s/Redstone https://github.com/Draco18s/Decaying-World https://github.com/Draco18s/Artifacts And a bunch of others that never got on github (Crossed out ones are already covered or not mods) Sure. No experience. You're not wrong. It could happen, but I'd still call that a malicious mod. I don't see any legitimate need for a mod to uninstall itself without being malicious. It could still happen, but its like you say, just because you've seen someone die from eating an apple, there's no reason to avoid eating apples. Its rare, its dumb, you don't worry about it.

Documentation is in the code as Javadoc comments. Force src is here (including test mods): https://github.com/MinecraftForge/MinecraftForge/

This is wholly the wrong way to go about this. Try looking at how the hopper picks up items.

Not really no. Because there are other ways to damage an item and all of them are ignored in creative. It happens here, in ItemStack#damageItem: if (!entityIn.world.isRemote && (!(entityIn instanceof PlayerEntity) || !((PlayerEntity)entityIn).abilities.isCreativeMode)) { If the player is in creative, the interior block (which actually applies the damage) is not run.

Showing what you tried involves showing your code to us. So we can read it. We're not telepathic.

Don't use a full cube voxel shape.

As I said, no non-malicious mod would delete itself. That would be dumb.

https://www.jetbrains.com/help/decompiler/Navigation_and_Search__Go_to_Declaration.html#c654 Among other ways. Use Google to ask questions like "how do I view source for this?"

All Forge javadoc is inside the class on each method. All you have to do is open up the file in your IDE. https://github.com/MinecraftForge/MinecraftForge/blob/638d1d31deabd8a83cf4b84496549703bc527ab4/src/main/java/net/minecraftforge/fml/common/ObfuscationReflectionHelper.java#L67-L83

If only there was some documentation in the ObfuscationReflectionHelper class

They're java code, the jar file is just a zip file containing the compiled code. No. Yours. It runs on YOUR computer. Software isn't magic. Any mod that isn't malicious is likely not tracked by the creator. No one cares. If its malicious, you have other, bigger problems than "does the creator know I'm using it!?!?!?" A mod should not be able to delete itself. Doesn't mean it can't, but that'd be Kind Of Weird.

Cool. I did this in a week. https://draco18s.itch.io/time-slicing-sword

The type is Consumer<T>, that is a function that accepts a single parameter of type T (in this case, LivingEntity) that is to be run when the item is broken. This is what handles the player's hand animation when their tool breaks, among other things. Look for existing calls to this method to see what they pass.

I guess you should find some other hobby then. Because programming is work.

You have multiple issues originating from multiple mods, AFAICT.

GASP. WHO'D HAVE GUESSED. Yes, yes it does. That's literally why they are there. Json resources aren't magic. Conditions are automatically deserialized. Not the rest of it. Conditions are JUST this part: ...yes You have custom data. So read your custom data.

Your json file does not match your deserialization method. You need to make your deserialize (the read method) match your json structure. No, do not do this. Actually implement the method. It should mirror your deserialization method, so that your json file is generated by it and properly deserializes.

https://forums.minecraftforge.net/search/?q=recipe condition&type=forums_topic&updated_after=any&sortby=relevancy&search_and_or=and

Your cauldron handle does not need a voxel boundary. Its basically irrelevant.

GOSH MAYBE THERE'S A METHOD CALLED "getPrivateValue" IN THE CLASS. HAVE YOU TRIED READING THE AVAILABLE METHODS?

Call its methods? They're intelligently named.

You do it the same way you use the Math class to get the value of Pi.