Warren Tode

I believe the format for that is supposed to look something like this: dependencies { implementation(group: 'com.google.code.gson', name: 'gson', version: '[2.0,3.0)') { jarJar.pin(it, "2.8.0") } }

That totally makes sense to me. I've been hanging back in 1.19.2 for this reason as well. I'm not ready to jump right into 1.19.3 just yet. I only jumped into 1.19 when I did because I really liked some of the changes they had made to datapacks at the time and it didn't feel that hard for me to make the leap, but now that I'm tinkering around with Forge I feel like I have my hands full so I'm more than willing to just take my time for now to figure things out. I'm really glad you got it all sorted out.

This tutorial might be helpful to you: https://misode.github.io/guides/adding-custom-structures/ As for saving the NBT file for the structure itself, you can just use the structure blocks in game to save your structure in the generated folder of your world map.

I understand. Sorry it didn't work out the way you wanted.

Try removing the Curios mod and any mods that depend on it. Add them back in one at a time, test launching each time.

I also learned that you can add new disk features - up to a point. I put back the disk_clay, disk_gravel, and disk_sand and named my disk feature for 1.18.2 disk_concrete. All this worked just fine. When I tried to add disk_concrete_1, disk_concrete_2 to that list, 1 & 2 didn't show up. Not sure if it's due to the way I named them or if there is a limit as to how many disk features you can add to a biome. I think you should be able to get your custom feature working just fine with the adjustments mentioned above, and if you don't want to completely replace the clay block, you could just rename your disk feature to something different so that the vanilla clay disks can be placed as well.

Okay, so I got it working for both 1.18.2 and 1.19.2 - in the process I learned that for 1.18.2 the configured feature file format only allows for you to place a single block, and it's in 1.19 that you're able to use weighted lists or noise providers for block placement in the disk feature. Meaning, that I was initially incorrect altogether about how the format works regarding block placement. For this I'm sorry. So in 1.18.2 the configured feature placement looks like this: However in 1.19.2, the format can look something like this: I hope this helps and I apologize for getting things mixed up earlier. Edit: I've put both test datapacks in GitHub for anyone to look at. 1.18.2 Test Datapack https://github.com/toadie-odie/TestDatapack-1.18.2 1.19.2 Test Datapack https://github.com/toadie-odie/TestDatapack-1.19.2

I've tried making my own test datapack in 1.18.2 with a custom river biome. The river generates just fine, but I'm running into the same problem as you are with the custom disk feature. I went so far as to remove all of the other disk features from my biome to be sure and it doesn't seem to matter what order I place the block replacing the clay (in my case, magenta concrete) my custom disk doesn't generate. I'm not sure what the problem is. Starting to wonder if there's another file we need.

That is so weird, I don't know why the image link thing isn't working for you. And I will try to make my own river with a custom clay disk to see what gives. I'm wondering if I misunderstood the format or something. Give me a bit and I'll see what I can figure out if anything.

Bottom right of the forum's comment box is a button that says, "Insert image from URL" copy the direct link of your image from Imagur to paste it in there. As far as why your blocks aren't showing up, I don't know yet. And, yeah, I've noticed that the info is all over the place for datapacks. It's actually been easier for me to find stuff for Forge since I started modding - which I didn't expect. But, maybe this is because Forge has been around longer than the datapack feature so the community has had more time to do stuff with Forge in contrast with datapacks? As far as devs not documenting stuff? Well, you guys are busy so I get it. Honestly, I'm surprised he shared as much as he did for as long as he did.

slicedlime also has a YouTube channel and it looks like this is the only video he has on feature placements for 1.18. Not sure how helpful it will be to you though for what you want to do.

Okay, so I'm pretty sure the zip folder you want from slicedlime is this one: https://github.com/slicedlime/examples/tree/d766a7028865fc210bef3ddcffb54886cdaf4860 This should give you all the vanilla worldgen files and folders to look at as templates as well as how to place them in your own namespace. I will admit that mostly what I've done with datapacks is make compatibility packs to make mods and datapacks more friendly with each other, or to make custom NPC villages for my sons. I've only dabbled in custom biomes a few times (tried to make a biome with spider spawners in the trees, but that didn't go well - the spawners still only spawn pigs), but I will help with whatever I can. The way I learn things is through exploration and experimentation, so I promise I'm not trying to confuse or mess anyone up. All I can do with certainty is share the information I've come across. Whether I understand it correctly or not is another matter. There isn't a lot of documentation or tutorials for making datapacks. They exist, but basically be willing to experiment quite a bit until you get what you're aiming for. I never shared anything I made, but if it ends up being useful to you or relevant to what you're trying to do here, I'll put it up to look at in my GitHub. All of this is something I find very interesting, so I don't mind learning it with you.

This came from slicedlime's download links. Last I knew, the guy works for Mojang. So yes, I assume it's somewhere in the vanilla jar, but probably obfuscated. I say this because you can pull any jar for a version of Minecraft you've played right from the game's folders, but when you look into the data folder of the jar, the worldgen folder isn't there until you hit 1.19.3. This is probably why he stopped posting them at that point. So to find the jar on a PC it's AppData/Roaming/.minecraft/versions/ and in there will be folders for every version you've ever played. In each of those folders is a matching jar. This means that you'll probably be able to find it all in the external libraries of your workspace as well.

Not sure if this is what you're looking for, but this webpage explains the keys/values for the custom biome json file. https://minecraft.fandom.com/wiki/Custom_biome And this link is to slicedlime's GitHub where he posts the vanilla worldgen template files. He's kept it up to date until they started working on 1.19.3. This will give you pretty much everything you need for a worldgen datapack. https://github.com/slicedlime/examples/commits/master But, I will admit that I'm not sure I entirely understand what you mean by block provider. This is what the file for the disk_clay feature, in the configure_feature folder, looks like in vanilla: { "type": "minecraft:disk", "config": { "half_height": 1, "radius": { "type": "minecraft:uniform", "value": { "max_inclusive": 3, "min_inclusive": 2 } }, "state_provider": { "fallback": { "type": "minecraft:simple_state_provider", "state": { "Name": "minecraft:clay" } }, "rules": [] }, "target": { "type": "minecraft:matching_blocks", "blocks": [ "minecraft:dirt", "minecraft:clay" ] } } } So the clay disk has two blocks in it actually, dirt and clay. I don't think it would be a problem to add a third block to the list. There is a file for disk_sand and disk_gravel as well.

I think the old saying is, "The devil is in the details." Far too often I find this to be the case. The "group" defined in the json file deals with the recipe book and how crafts show up in there. I think maybe the best way to explain this is with a couple of screenshots. So you see the wool and how it says "right click for more" when you hover over it? This is because I have more than one dye along with the stack of wool to craft with here. If I just sit there, it will toggle through the other colors I have available in my inventory. When you right click on it, you get this: It gives you a collection of similar recipes. This is what a "group" does. It works for vanilla and modded. You don't need to bother with it if you don't want to, but some people like it since it declutters the book so to speak. I hope this helps.

You need a method that checks how much damage your item has taken, and when that damage equals the item's max durability, it gets removed from the item slot.

If you used the vanilla recipe types, meaning that in the "type" part of your recipe's Json file is "smelting", "shaped_recipe", "shapeless_recipe", etc. then the only thing you need to do is put it in the recipe folder. It's the recipe types that get registered. So your recipes using vanilla types don't need anything extra once the Json file is made. Registering for recipes come in when say you want to make a recipe "type" called maybe, I don't know, "spacium_smelting" for example. There you would tell Forge what recipe format it uses, which block entity type uses it, and how to read it, etc. Edit: Oh, wait, I meant to also say that the vanilla "smelting" type is tied to the furnace for example while the vanilla "shaped_recipe" and "shapeless_recipe" are tied to the crafting table. So if you want these vanilla types to also be connected to your custom block entity, then you will to make a custom recipe type with a different name that uses the same format. You'd make them the same way as their serializer, but just replace the name of it with your custom name where ever it pops up and then register this custom type. After that, when you make recipes for it, you just plug in your recipe type's name in the json file and stick the file into your recipe folder. I really hope I'm making sense here.

Ah, I get it. Personally, I find reading easier than listening to be honest, especially when there's a lot to process and absorb. And that guy does go fast from what I've seen. At least with a video you can pause it to compare notes and text when you need to. I'm sorry if I insulted you in any way, it wasn't my intention.

Okay, if you're having trouble with kaupenjoe's tutorials it's because he assumes you already have a solid understanding of Java, so he skips over explaining that aspect of what he's doing - which is a lot, since it's all in Java. This website should be very helpful in understanding whatever methods or parts he uses in his videos. https://www.w3schools.com/java/ Just click the GitHub link he provides with his tutorials, and look up on that site whatever you don't understand. Don't be afraid to take your time with this. Same goes for anything else you run into that you don't understand since this site covers many other programming languages, not just Java. In fact, if you click on their tutorials tab you'll find JSON under the Javascript heading in there too.

Oh I'm sorry, I thought it would be helpful but I'm glad you got something figured it out.

If you're looking to create recipes for vanilla recipe types, this is pretty much all you need: https://misode.github.io/recipe/ If you need to add a custom recipe type as well, then a quick search on Forge Modding Recipe Types should get you what you need.

That doesn't make sense. If that was the case, the vanilla game wouldn't be able to read tags in the recipe Json files either, but it does even in 1.18.2.

Not sure, but you might be able to build something using the SimpleCookingRecipe Serializer as a base in order to use the count parameter?

Yes, you can. People have made datapacks for cutting wood planks into stairs, etc. Just make your Json recipe files formatting exactly the same way the files are done for the Stone Cutter recipes.

Never mind, I think finally found the list of Forge tags in the extended libraries of my workspace. I should be all set with that now.