ChampionAsh5357

That is within 'src/main/resources'. I was saying for generated files it wouldn't be counted as they are saved to 'src/generated/resources' as specified in your code above which is not within 'main/resources'.

Yes, that's because it doesn't recognize any existing files with that name. If you want to iterate through the existing files, you will need to add a '--existing' arg pointing to your 'src/main/resources'. Note that this will only cover files in that specific location.

There's not really a reasonable way to do it. The bigger the water size, the more checks needed and the greater amount of lag on the system. There's no real optimization in something like this other than caching block positions which are water. Probably in a tile entity of some sort since you require some kind of timing feature. Less of a challenge and more of falling into bad habits looking at very problematic code. Hence why we suggest not starting it that way as it only detriments your learning.

Apologies then. You should probably try refreshing your gradle workspace, regenning your runs, and then select runData.

Because you're not following it. I don't see a parameter named modid anywhere in here.

Do java first, then come back and try to do modding. Learning both at the same time is a terrible way to start programming. Highly ambitious and also problematic. Unloaded areas will be affected and it will be editing a wide range of blocks like a multipart. Since it's also not in a standard shape, it becomes even more of an issue. There are a few way I can think of though, but that's regardless of any lag. World#setBlockState or World#destroyBlock should do nicely.

IForgeItem#isEnderMask must return true.

Isn't compile the old method of doing it? I thought it was implementation now. Also, you probably need to extend the configuration of the api to include your mod compile. Something like this in Example 1.

Not being rude, but that's never good. How much do you understand about what you're doing? Please give us a link to the repository so that we may see what you already have done or copied from someone else.

Makes sense as the blockstates folder is one directory too high. Should be in your modid folder.

And I quote from the EventBusSubscriber javadocs for the modid parameter 'only necessary if this annotation is not on the same class that has a @Mod annotation.' You should always use existing model. The parent is for your block model, not the block state. Which reminds me, you don't ever show what you want your block model to look like.

Ah ok, that makes more sense. My knowledge of how the jigsaw manager is limited so I try to eliminate the main issues first. My assumption is having to do with the AbstractVillagePiece and it expecting something different; however, this is a guess as my experience with world generation predates the existence of the jigsaw system.

If a line of code never gets caught by a breakpoint, it means that it's either never called from either no entries or not registering the event. Yes. You can give a model a parent that it will borrow a structure from. Most blocks parent block/block if anything. Fair enough. Here's a list of every method documented in states/models. That's what you need to do. The block state provider gives you the ability to create a state parser, block model, and item model from the class. Otherwise, it will most likely throw an error if you make a separate item model provider.

Problematic Code 11

Pick one, not both. Also, you never attach the feature nor the structure to a biome. You can do that on common setup or load complete, either works.

1.14.4 is no longer supported on this forum. Please update to at least LTS 1.15.2 to receive support.

Yes, protection is an instance. So you need to supply an instance. Take some time to learn functional programming.

This code looks problematic for a number of reasons: For one, I don't see how the event will run. Two, do you have the build.gradle setup? Three, you're using unchecked model files meaning you don't have anything really set up correctly. Four, don't iterate through an entire block list if you're just looking for a specific case. Five, I think you need to review how the builder works. Six, there's already a simple block state provider that will generate the required block. Seven, you never generate an item for the block.

You removed the super calls from the read and write methods.

BiomeLoadingEvent, getting the BiomeGenerationSettingsBuilder, and then calling withFeature.

3 I would say is correct. As for the other two, they might be already handled in the BlockItem implementation you'll probably need to extend. I think there's already some tall block placements used for that, but I forget the class name.

Nope, just understand toml and comments. No forge modding understanding required. Although I have been programming in Forge correctly for a while now, it still is not necessary. However, your issue more relies on reading the gradle documentation. The forge docs was only to add the dependency block that says "hey, i require this to load". That's exactly what you're supposed to do.

Well looking at gradle docs and the forge docs is always a good start. That's fine, still need to know java though to get it working. This part makes it sound like less like an actual mod and more like just modifying a vanilla loot table. So, you're probably going overkill making a mod when all that's needed is probably a datapack.

Ok, can you show the entire code block for the event then? Because with what I see now, I think it might be a different place that is causing the infinite check.