Draco18s

What are you trying to do? Describe the gameplay effect you want from the player's point of view, not your attempt to code it.

It is the ENERGY capability attached to itemstack. As evidenced by the code, itemstack.getCapability(ENERGY) method call. If that stack represents a battery, then its the battery. Presumably your TE has item slots, using an ItemHandler capability, so your TE just needs to look into its inventory and go "hey, batteries!" Your TE also has an energy storage capability it does the same thing, only on its own capability (there's no need to call getCapability inside your own TE, all that does is return a field the TE already has, wrapped in a LazyOptional, so you may as well just access the field). You ... don't? I don't know of any, but the process here is the same as it would be for items, just a different capability that returns a different data type. You call ifPresent, do some operations on that data, and it's automatically saved. Because that's what happens when you operate directly on the stored data. ItemStackHandler is the ITEM capability equivalent to EVERGY's EnergyStorage. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L39 The lazy optional wrapper: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L42 Accessing the field data directly: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L109 The TE's getCapability, returning the wrapper https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L164-L166

I don't know what you expect us to be able to do. We help people write mods using the Minecraft Forge API. We don't support Optifine.

Its on my ever growing list of TODOs. But at the moment it isn't broken, and other things are, so its low priority. There really isn't a point to doing so. You can put "solved" in the title if you want, but locking a thread is a moderator tool. Its a forum, threads are to remain open by default.

I'm not using the energy capability, but rather items, but the same features apply. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/block/MillstoneBlock.java#L61 I'm also using orElse(null), but I wrote the code before figuring out ifPresent. cap = getCap(CapType).orElse(null) if(cap != null) { //code here } directly converts to getCap(CapType).ifPresent(cap -> { //code here }

You're trying to register a ContainerType, and to do that you need to specify your TE's constructor that takes no paremeters.

My code dates before DeferredRegister, so I haven't gotten a chance to mess around with it. But here's where I do the needful: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L165 The method call to EasyRegistry there just shoves the value passed into a list and waits for the RegistryEvent.Register<T> for some the appropriate T and then registers the value. It looks complicated, but only because I've got a thousand helpers that do various things to make my life easier in my actual mods,* but here's the relevant helper and event: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/EasyRegistry.java#L113-L136 https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/EasyRegistry.java#L195-L200 Mod Data Fixers do exist now, but as I said, I haven't really worked on things in a while. That should all still be the same sorts of stuff you need to do. *I definitely do not recommend doing things like this any more. My way is based on my own personal preferences for liking a clean-looking mod class and have shoved all the wonky aspects off into my EasyRegistry where I don't need to look at them. DeferredRegister has probably cleaned this up, I just haven't played with it.

My guess would be that when you go into generate a new world, the values are being set by something else, overwriting your change. Go look at the field, what sets its value, and what calls the code that sets its value.

ICustomContainer is my own interface. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/api/interfaces/ICustomContainer.java Its not even all that relevant here.

Well, your code (if it worked at all) will only work in the development environment. Because that string is not the actual name of the compiled vanilla class (any reason you aren't using Class GenClass = GenerationSettings.class?) or the field name when compiled. There's a reason Forge supplies an ObfuscationReflectionHelper class. As for why its not changing, I don't know. When and where are you calling that code?

Yes. This might help. https://github.com/Slyrae/MineExpansion/blob/1.12.2/src/main/java/net/slyrae/mineexpansion/init/ItemInit.java#L159

Correct. BlockContainer from vanilla sets up a bunch of defaults that you do not want or need. One of the most common was setting the model render type to invisible (because vanilla would have special case renderers for its containers, like the chest) and people would post a question every week about why their custom chest won't render. So yes. Extend block and override only the methods you need to override, namely has- and getTileEntity() https://github.com/GenElectrovise/MagiksMostEvile/blob/1.15.2/src/main/java/genelectrovise/magiksmostevile/common/tileentity/altar/AltarTileEntity.java#L29 You do not need to implement ICapabilityProvider here, TileEntity already implements it. You aren't even overriding getCapability(). https://github.com/GenElectrovise/MagiksMostEvile/blob/1.15.2/src/main/java/genelectrovise/magiksmostevile/common/tileentity/altar/AltarTileEntity.java#L31-L32 This does nothing useful for you. You want this: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L39 This: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L42 And this: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L145-L172

It has. OreDictionary no longer exists, we use Tags now.

Get a block position. Get the block state at that position. Call tick() on it.

This code is awful. Do not compare things to strings. entity.getItem().getItem() == Items.DIAMOND. The event is only fired on the server side. When you connect to a dedicated server, that server is the logical server, but also the physical server. Because it is physically elsewhere. However when you play single player, the physical client runs its own integrated server locally on a separate thread, this is the logical server located at the physical client. When you do something on the logical server that accesses something on the logical client, that's known as "reaching across sides." It works only because the two threads are running in the same JVM. But because they are different process threads you'll sometimes get random and unexpected crashes.

You're reaching across logical sides. You can't do this.

Not completely. There are some things that have changed, see https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a Most of what you'll run into is that names changed (so instead of ItemFood its now FoodItem) as well as a new registration process (DeferredRegister). But worlgen has been overhauled and 1.12 info is useless. There's also been some changes in rendering.

Yes

DeferredRegister is a wrapper around the RegistryEvent system to allow people to create their blocks and items in a static block without breaking everything. Uh, you still are. What do you think this code does? Sure, its a loop, and you aren't individually specifying things. Except you've done it in a way that forces all of your blocks to use the base implementation of BlockItem. Any block you want to be different you have to go fuck around with this code to make it not generate an item. Technical blocks that don't have items, blocks that use a custom item, a block that you want to belong to a creative tab group other than "misc" (which, frankly, should be most of them: such as decoration, building blocks, or redstone).

Why are you using both a deferred register and a RegistryEvent handler? You only need one. Second, BlockBase is an antipattern. Do not use it. There is already a base block class, its called Block.

Virtually zero. One hundred classes that each listen for one of one hundred separate events has the (nearly) the same impact as one class with one hundred listeners in it. The difference is all start-up time when Forge has to do discovery and some bytecode magic to create the hooks, but runtime is going to be the same.

Ah, actually I know what the problem is. This AABB is zero-volume and cannot contain any entities. Look at how vanilla entities like the hopper define their collection volume.

If the mod is not present, the value will be left null. Be sure to perform a null-check before doing anything with the value. And of course, if the other mod is present it won't function (but it won't crash).

Use breakpoints and debug mode to see what's going on.

To override you need to place the file in the same domain and path as the data file you want to override (how else will the game know what block it applies to? That's what resource locations ARE FOR). Additionally, your folders are backwards, should be data, then your mod ID. That means, src/main/assets/data/minecraft/loot_tables/