Daeruin

I'm aware. There are lots of ways for items to end up in a given slot. It's all stuff I handled in 1.12, just struggling to figure out how to do the same thing in 1.18. If I could modify the vanilla inventories or slots to override what items they allow, it would be much easier. Like if there were an event that hooked into Slot#mayPlace, I would be ecstatic. I think I actually figured it out just now. Apparently there's a MouseReleasedEvent now, and I had to use that instead. I guess it's the release of the button that actually triggers the item going into the slot.

I'm trying to prevent my block from being placed in certain vanilla inventories. I'm using MouseClickedEvent.Pre. By canceling the event, I can prevent items from being picked up by the mouse cursor, but for some reason canceling the event doesn't prevent items from being placed into a slot. If there's a better way other than listening for mouse clicks, I'm all ears. Here's my code - the full logic isn't in place, I'm just trying to successfully prevent the block from being placed in any inventory to start off with.

I don't see an event like that in 1.18.2. Looks like I'm stuck with the RenderTooltipEvents. Thanks!

I have a custom block, and I'd like to add an image into its tooltip. I have created a class that implements ClientToolTipComponent and TooltipComponent so I can draw the image. I have overridden appendHoverText on my custom block, but there doesn't appear to be any way to add my custom component or any image that I can see. It looks like I can only add text-based components. Do I have to use the GatherComponents tooltip event?

Well, I figured out the problem. Basically I was being a doofus and I had two copies of the inventory in my capability provider—one inside a LazyOptional, like I should have, and a second one not inside a LazyOptional. The second one was old code from before I understood how to use the LazyOptional. The second inventory was always empty for obvious reasons but I was still using it to serialize/deserialize. So it's now working solely with a capability, and I'm not using BlockEntity#saveToItem at all. I'm writing the BlockEntity's capability data to the ItemStack in playerWillDestroy when the block is broken, and writing the ItemStack's capability data back to the BlockEntity in setPlacedBy when the block is placed.

I lied, the capability is not persisting. If I use the vanilla BlockEntity#saveToItem, then the inventory persists from breaking the block to placing it back down again. It's basically how the shulker box does it. But the capability disappears at some point after spawning the ItemEntity and picking it up in my inventory. It's baffling to me because I'm basically doing everything I used to do in 1.12.

The shulker box does it in playerWillDestroy. I just looked it up. Anyway that's kinda beside the point. As I mentioned in my previous post, I'm successfully saving the capability on the ItemStack when the block is broken (during playerWillDestroy), and it gets restored when I place the block again. I just can't find it when I'm holding the ItemStack and need to view the inventory.

It tried this, but by the time spawnAfterBreak occurs, the BlockEntity has already been deleted, so I can't get the inventory from it. So I tried it in playerWillDestroy, and it appears as though the inventory is being saved to the ItemStack that's part of the ItemEntity that I'm spawning. Yet when the BlockItem's use method occurs, the item no longer seems to have a capability attached to it. I am supplying my capability provider during initCapabilities. If I use BlockEntity#saveToItem during playerWillDestroy, the inventory data gets saved to a BlockEntityTag NBT, which persists all the way through breaking the block, picking it up, and placing it back down. Block#playerWillDestroy: BlockItem#initCapabilities: BlockItem#use:

I'm converting my old mod from 1.12 to 1.18. It's basically a backpack mod except it's wicker baskets. You can place them as a block or hold them as an item and view the inventory while holding it. I have most everything working except the inventory doesn't sync between the block and the item. If I put something in the block inventory, then break the block, pick it up, and try to view the inventory from my hand, the basket is empty. And vice versa - if I put something in the basket inventory while holding it as an item, then place it as a block, the block inventory is empty. It seems the way I used to do it in 1.12 doesn't work anymore and I can't figure out what to do. I couldn't find any other backpack mods for 1.18 that actually use capabilities. Help would be much appreciated. Full repo is here. Or some direct links: Basket Block Basket Block Entity Basket Block Item Capability Provider ItemStackHandler implementation Basket Menu

Sigh. I was being silly. I was using IntelliJ 2017. Once I opened my project in IntelliJ 2022, it worked fine.

I was able to reproduce the error using the gradle buildscript provided by the Forge MDK, version 1.18.2-40.1.0. I think this something wrong with my environment or IntelliJ settings. Here's the full error:

After a few months off, I'm trying to hurry and finish upgrading my mod to 1.18 before 1.20 comes out. I fired up IntelliJ and got this error: Unable to load class 'org.gradle.api.internal.plugins.DefaultConvention'. The only thing that's changed since last time I worked on my mod was updating to macOS Monterey. A little research seems to indicate the problem is with something trying to reference a class that's not available in the version of Gradle I'm using. My `gradle-wrapper.properties` is set to: distributionUrl=https\://services.gradle.org/distributions/gradle-7.4-bin.zip My project is set up to use the default Gradle wrapper and Java 17. I can see Gradle 7.4 in my /Users/<me>/.gradle folder. I also tried starting up a brand new mod project with the 1.18 Forge MDK and got the same error. Any idea what is going on here?

Thank you, that worked!. It took me a minute to figure out how to use an ExistingModelFile. For future readers, you can get one through models().getExistingFile and passing in the resource location of the block model.

I'm trying to use data generation to create blockstates and block models. I'm a little stuck on generating my block's item model. I'm trying to make it inherit from the block model, but the data generator seems to be assuming it should instead inherit from an item model. This essentially results in the item model inheriting from itself instead of from the corresponding block model. Here's my BlockStateProvider and the resulting item model. What am I missing?

I said it in my initial post. I'm trying to generate loot modifiers for a bunch of items. All of the items have the same tag. It seemed like I should be able to just grab the tag, iterate over the items, and generate the loot modifier for each one that way.

Hmmm, iterating over all the blocks and items and checking their tags showed that nothing seems to have tags during data generation of global loot modifiers.

Both of these produced an empty list during data generation. Seems like it should have worked, though. That is a great way to check if an individual block or item has the tag. It does not let me find all blocks or items that have the tag. I guess I could iterate over every block/item and use that method to find which ones have the tag. I was hoping for something a little more efficient. I am using the LootItemBlockStatePropertyCondition as part of my loot modifiers, and it takes Blocks as input.

Is there a handy way to get all the blocks that belong to a tag and then iterate over them? For example, I'm generating global loot modifiers and would like to iterate over all the leaf blocks to create loot modifiers for them. From my searching, it seems there was a method for that in 1.16, but it no longer exists in 1.18. Back in 1.12 I used the HarvestDropsEvent and just checked if the block was an instance of BlockLeaves. Much more efficient.

Yeah, something like you suggested would work. I just thought that maybe I could use some existing methods from Forge's existing config code instead of making a manual map. I poked around for a while, couldn't figure out anything elegant, and finally figured I'd ask for ideas. Eventually I figured it out. My ICondition class takes a ForgeConfigSpec.Boolean parameter, so I can pass in a config option and save it as a field in ICondition. I can then reference it directly in the ICondition#test method. In my Serializer, I write that to JSON by using ConfigValue#getPath and turning the resulting list into a period separated string. I deserialize the period separated string using ForgeConfigSpec#getValues#get which returns the same ForgeConfigSpec.Boolean. The thing I like about this solution is that I can now use data generation to make any recipe conditional on my config without manually updating some map. So my instinct was right, I just got frustrated too early and posted here hoping someone had already solved this kind of issue. I guess with datapacks people aren't doing as much of this kind of thing anymore.

You may need to (re)read my original post to see more about what I'm trying to do. I have the process working for a single "module" but would like to make it more generic so I don't have to create a whole bunch of IConditions for all the modules. With how conditions work in data generation, I'm not sure how to achieve that.

Well, I think it's easier for users to type "false" into a config file than create a datapack. But also my mod is modular. If the user doesn't want to use a certain part of my mod, they can disable it, and it affects multiple things. I need to stop certain items from dropping when blocks are broken in addition to disabling various recipes. It doesn't make sense to me to make the user create a datapack to fully disable this part of my mod.

I am trying to add conditions to my recipes based on values from my config file. I have gotten it to work for a single config value. I set the value to false, and the condition disables the recipe. I have a lot of recipes I'd like to handle this way, so I'd like to make my ICondition implementation more generic now, so I could pass in something that would tell it which config option to check. But I can't figure out how. Something roughly like this, I think: Each config option is a ForgeConfigSpec, and I found a function to look up the config options path, but I haven't found a way to do the reverse - given a path, get the value or maybe grab the corresponding ForgeConfigSpec so I can do ForgeConfigSpec#get. Another idea I found is to create a manual Map or maybe an enum to associate a String with each relevant config option. Then I could pass in the String to look up the appropriate config option. But that just feels like a lot of extra work and manual maintenance

I'm trying to write some tutorial/advice articles for Minecraft modding for 1.16. I'm a technical writer and have a few of my own mods under my belt. I've seen some older tutorials that tell you to add the path of your Java JDK installation to your environment variables. I don't recall having to do that when I started modding, and my general understanding is that the environment variables are mostly a convenience so you don't have to use the full path of an exe on the command line. So I was wondering if you really need to do anything with environment variables for modding and if so what situations it might be needed. Does it depend on your OS, JDK version, IDE, or what? TIA.

Become very proficient with Java. Unfortunately, the state of Forge documentation and lack of up to date tutorials means that you must become very good at reading and understanding other people's code in order to figure things out. You might try looking up TheGreyGhost's Minecraft by Example or Cadiboo's tutorials. They at least go up to 1.15. I haven't been plugged into the modding world for a while, so there may be others I'm not aware of.