Draco18s

Looked at the load order, for some reason I thought CommonSetup was called sooner. ERROR(null), VALIDATE(null), CONSTRUCT(null), CREATE_REGISTRIES(null), LOAD_REGISTRIES(null), COMMON_SETUP(()-> FMLCommonSetupEvent::new), SIDED_SETUP(SidedProvider.SIDED_SETUP_EVENT::get), ENQUEUE_IMC(()-> InterModEnqueueEvent::new), PROCESS_IMC(()-> InterModProcessEvent::new), COMPLETE(()-> FMLLoadCompleteEvent::new), DONE(null), GATHERDATA(ModLoader.get()::getDataGeneratorEvent);

The javadoc says: "Implement" and "Override" are specific keywords that have specific meanings in programming and if the intent was that mods should not listen for the event, then it would (or should) say "don't" use or "don't listen for" or be marked as deprecated. A search of both the git repo and the forums return no results of anyone of any authority saying anything about the event. I'm more than happy to be wrong, but my reading says nothing about not using the event.

I believe that CommonSetup is too early, use FMLLoadCompleteEvent .

You need to register an IBlockColor instance on (and only on) the client thread.

How does one find/acquire this plugin? Not that I use IntelliJ, but for the folks that do, just because "it exists" doesn't give enough information to find and use it.

Be aware that the csv files, while organized by class, don't tell you what class a given method is in, so if you have a field name that's rather common (say, "world") then you're going to have trouble. Find a different field in the same class that's more unique, then look for the one you actually want nearby.

The various enum classes have a create method.

No, that is overkill. What you probably want is a Capability that stores the buff information.

You post words. We read them at some undefined point in the future, then we post words. You at some undefined point later read those words and post new words. Eventually there are no more words to post and the thread stops being on the front page. All is well. No. Specifically. I am not sure that what you want to do is even possible, but it might be able to be done through a custom IRecipe implementation.

I misunderstood the problem. I am not sure, then.

I think you need a custom Teleporter class. Been a while since I looked into it, but I recall that if you don't have one, vanilla is like "oh you changed dimensions, lemme just build a nether portal for you..."

Because that's how commands work. @p and not supplying a target means that it affects the player typing the command. But what if you wanted to affect a different player?

Specifically, you should want to use the Global Loot Modifier system which is a direct comparable (if more involved) system to LivingDropsEvent.

Either you do, or Mekanism does.

Your method is not being called because it lacks @SubscribeEvent

https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/opes/tiles/GrinderTile.java#L79 You need to clone this stack or things will go very wrong indeed. https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/lib/inventory/outputStackHandler.java#L7 This class should start with a capital letter to follow naming convention https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/lib/inventory/outputStackHandler.java#L17 You do not need to override this method, you're not doing anything that the base implementation does not already do. https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/lib/inventory/ProcessingBlockItemHandler.java#L10 This comment is objectively wrong. The int passed there is how many slots the handler has, so this "won't be shown" stuff is bollocs. https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/opes/tiles/GrinderTile.java#L80 This line assumes that all outputs are size 1. This may or may not be true. And finally, you have no data assets which use your recipe type, but the above issues not withstanding, your grinder is compatible with any mod that has a recipe that matches your grinder recipe.

Because you never know when a static block will execute, and if it executes too early, Forge can't insure that it has full control over the object. (Forge does lots of lots of behind the scenes magic and dangerous sorcery that you, as a modder, don't need to worry about, but that if it isn't done in order, things break)

Unfortunately, Forge no longer supports old version, because they are old and we can't maintain every version in perpetuity.

Go look at the Slider class and figure out how it builds the text that is displayed in the render method.

What version of Minecraft?

In the constructor for the widget, get the current screen's position and size and calculate the top left corner, adding that value to the value you're already passing in. Vector math is fun.

That is precisely what that event is for. If you set the result the Pre event to DENY, then the plant won't advance to the next growth stage. You can find a (complicated) example here: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderfarming/EventHandlers.java#L103 That takes into account biome temperature, rainfall, and neighboring plants to determine whether or not to grow. The net result is that crops of the same type grow at approximately the same speed, and its influenced by the ambient conditions (and different crops have different ideal conditions).

Ha, whoops. 58:00 When I copied the link I thought I grabbed "at time" but apparently not!

There this wonderful magical thing called Capabilities that ItemStacks are allowed to have. https://mcforge.readthedocs.io/en/1.15.x/datastorage/capabilities/

Whole video is worth a watch, but that time stamp is the presenter going through and refactoring a complex method out of existence one line at a time.