ChampionAsh5357

I'm pretty sure it has. That would be due to the placements. To make placements more versatile, they have been separated and allowed to chain on one another. This means that one placement might add more trees to generate, the other may spread them out, and another could change their height coordinate. Take a look at a tree ConfiguredFeature within Features to see what I'm talking about and replicate the chained placements. Note that their order does matter in how they decide to generate.

Why are you using a registry object if you just plan on grabbing the entry directly from the registry itself? For reference, the constructor only adds a handler to the object to populate the objects whenever they are frozen. However, since you are constructing after the snapshot occurs, they will never be populated. This can be circumvented by calling RegistryObject#updateReference, but there is simply no point as you can just grab the instance from the registry itself directly via ForgeRegistries.

You just ignored what I said. You're telling me an issue based on runtime testing and not on debugging. You can go all the way into Minecraft#clickMouse and put a breakpoint over the case where the RayTraceResult is an ENTITY and view what's getting called where and why. However, telling me the same problem without debugging the process like I mentioned above is just repetition and not solving the issue. So, follow the code from where the entity is clicked on all the way to it's final result. If you are in fact targeting an entity, it should be recognized by the resulting ray trace. You should even be able to verify that your mouse is hovering over the existing entity by simply opening the debug menu.

Well you have a block with six faces. Each face will connect to a different block on four sides. However, it will cover all six faces regardless. So, you will need a state per face (SixWayBlock has an example of this) to check what textures should be present. From there, the texture can be updated based on the corresponding states of the surrounding blocks. You should probably use a data generator for this.

First, this is taking in a registry object when it requires an entity type. Second, this looks like that the call in a parallel event will not be deferred, so defer it properly within a DeferredWorkQueue (assuming this is 1.15).

Yes, that is true. All entries have a registry key of some kind which can be obtained from the specific registry it's within. They are all singletons, so it doesn't particularly matter that the biome entry is referenced as a key. You can still parse the name of the biome into a registry key with some parent. The biome would still spawn. This is evident by their implementations across the versions. This can also be seen via Lex's comment on a post to reintroduce the BiomeManager. The only difference is that spawn biomes are specified in the spawn info of each biome itself instead in some list. So, this claim needs some base to be reviewed. Once again, read what I wrote above. You would need to create a json biome and probably attach the biome via it's registry key to the layer on server start and remove on server stop. A registry key is just a concatenation of the registry and the object registered. You can grab both of these.

You should probably put a breakpoint within your part class at attackEntityFrom and see whether it calls the statement as it looks like it should.

Yes, the console output is occurring only whenever you hit the parts. However, it will not cause any damage to the actual entity as that returns false. You need a better descriptor rather than 'it just doesn't work'.

The process doesn't change regarding Eclipse, IDEA, or VSCode. Any IDE can be used, some just require more work than others. You must import and run the gradle information and generate your runs. As for how to do this, you can probably google. Importing a gradle project into VSCode is within the internet, and then from there you would just need to generate the VSCode runs which is a provided task by Forge. Happy hunting!

All you need to do is register the config. The Load and Reloading events should be handled to setup any caching that might occur. Any server related config information that requires an instance of MinecraftServer can be handled initially within FMLServerAboutToStartEvent and then updated with some sort of invalidator. However, this information should be cleared whenever the server is stopping as it will not persist across worlds.

Look at how the end is generated. Then, replace the instances of end stone with obsidian and work from there.

Not true, no client synchronization nonsense is going on here. It's the same reason as it was last time when you replaced getSignMaterial within the TER. You are calling EditSignScreen which grabs the material via SignTileEntityRenderer::getMaterial which hardcodes to the vanilla asset library. So, create a custom screen that uses your entry instead of vanilla's.

Probably chain to your block properties Properties#notSolid or update your VoxelShape to the correct size via Block#getShape.

Code Style 6 That's called a capability that needs to be synchronized with the client.

People will respond when they can. Don't unnecessarily bump your thread. As for the answer, look into the IDE you use for hot swapping your current running instance. It's like you're trying to "debug" the process.

Nope, world generation is usually completely undocumented. Just look at the vanilla source for where they put dirt and/or farmland and you'll find what you need to change.

That's what a data generator is for. Instead of doing it all by hand, you just write an algorithm that makes it for you.

A data generator is a way to automate creating json files via providers. Current versions of the mdk have a base build.gradle set up so you do not need to edit anything. Then, I would suggest reading through the docs with their information and build off of there.

I'm going to guess the crash report says 'cannot cast ServerWorld to ClientWorld' or something like that. You need to check if you are on the correct side. Otherwise, it's a blind cast and will throw errors.

You need to make a custom feature for trees as they will always check if there is dirt or farmland beneath them before spawning.

Split it into multiple files. There should almost never be a reason to change different items using the same JSON file unless your item has dynamic storage that changes it's outlook. This would most likely be done via some kind of ItemOverrideList if you were to ignore my recommendation.

You never register your DeferredRegister to the mod event bus. Also, pick one method to register your objects and not two.

My guess is that you called a registry object instance before it was loaded, probably COPPER_ORE.get() within some sort of method handling without deferring the instance such that it only gets called when the TE type is registered and not when the static final variable is defined. Please show the repository where this code is linked to.

That would probably be the result of a carver of some kind. I believe the class you should look at is CanyonWorldCarver. Other than that, it should be the same as creating any other biome.

https://mcforge.readthedocs.io/en/latest/forgedev/prguidelines/