ChampionAsh5357

You simply add the required JSONs to 'data/modid/dimension' and 'data/modid/dimension_type'. For more explanation on the JSONs itself, the vanilla wiki breaks it down a bit.

Apologies for the off-topic conversation above. Would you mind providing the debug.log so that we can have a full context of the error? My guess is that you are calling the entity type object before the registry event have finished, most likely in an item constructor or even prior. A link to your repo would also be helpful as well. It could also be that you never registered the DeferredRegister.

Forge is still not a product. Also, there are ways to remap missing entries by changing their qualified modid using RegistryEvent$MissingMappings, so your point is mute. Why would what your mod does have anything to do with if your name is unique? Don't be rude and link a paste to your debug.log. If something is not working, then it's your problem as it will and does work for anyone else. First, your textures are under 'blocks' instead of 'block'. Second, you never show your blockstate JSON which leads me to believe there's something wrong there as only the block model is rendering incorrectly (which there definitely is as it references the model directly instead of its subdirectory 'modid:block/path').

Item#addInformation if you own the item or RenderTooltipEvent if its not. I'm assuming that this is present on the ItemStack itself.

You do realize that no one is obligated to help and that bumping a thread every day doesn't change the outcome. Also, presumptions about if he stole your code are pointless as yours is ARR. Now as for the actual problem, it's looking for 'pink_layer_1/2' as that is name supplied to the armor type, not 'netherite'.

That would make sense as 'windowTileEntityTileEntityType' seems to be null. Pass in your registry object instead.

So, yes and no. Chunk generation is handled asynchronously to reduce the strain on the main thread and avoid any major lag spike. A chunk on generation is a ChunkPrimer where it uses the players location to determine whether to resolve. Once resolved, that Chunk will never change from world generation. However, these chunks can be partially resolved when being loaded. This allows certain features or structures to be determined without actually resolving the chunk itself. I'm guessing that's what you mean by pre-generating non-visible chunks. The rendering and actual logic of chunks is handled separately. Logic will only happen within an 8 chunk square around the player while rendering can show any specified distance. Rendering iirc partially resolves the chunk and the logic on the server fully loads in once the player gets close enough. Since the game uses a seed which determines almost everything about world generation, it isn't hard to partially resolve a chunk on the client until it needs to be resolved on the server.

Well, a feature can generate in every chunk within a specific biome. As such, the feature is resolved every time a new chunk loads. Only existing chunks will not generate a feature as they are already resolved.

To get any potion item properly, you should use PotionUtils::addPotionToItemStack. You do not need to supply a count as that can be 1 by default. Also, move this to an actual loot table instead of overriding #getDrops.

First, do not use IInventory. Use capabilities via IItemHandler. Second, look into the methods you are using. The maximum index those methods can read is 255. So, whenever index 256 rolls around, the lowest eight bits are kept making index 256 act as index 0 when reloaded and repeats for every 256 values (this is also known as a narrowing primitive conversion as referenced by $5.1.3 of the JLS). This is not to mention the load method bitwise ANDs the resulting byte received making the limit even more guaranteed.

Then you are definitely missing something within your imports. Did you delete both the .gradle folder within your workspace and the one located within user/.gradle? Remember that your workspace should be closed while this is happening. Hopefully this will remove any cache associated with Forge which might fix the issue. If it still persists after all of this, then Gradle is just not on your side right now. Try again at a different time repeating the same steps maybe after a computer restart or two and it'll probably work because Gradle is like that sometimes.

Based on what you answered, that tells me everything works fine. From there, I will direct you to the forge docs on registries as that gives a general idea on how to construct a registry object using one of the two methods mentioned. If you have any issues with that, then create a different thread with that question. This thread is now resolved based on the mentioned topic.

Try going into the run configurations then, locating 'runClient', and where it says Main class, click Search... and find the LauchTesting class applicable to yours. Maybe that will fix the issue.

Then try closing the IDE, running 'gradlew --stop' and then 'gradlew clean', opening up the IDE, refresh and regen. If that doesn't work, you can always repeat except deleting the .gradle folder first in your directory and then in your application data.

Might be because you tried to load the ClientPlayerEntity on the server: https://github.com/Tavi007/ElementalCombat/blob/cbd2054ce35659d97fb9ff7a100e0b5f39df0ecd/src/main/java/Tavi007/ElementalCombat/network/PackageHandlerOnClient.java#L63 You should properly side off your client code within another class, not the packet handler itself. The handling can be with the message itself, you can then enqueue work and use DistExecutor to force it to run only on the physical client. This will guarantee that the physical client and server are isolated.

I assume you import as an existing gradle project to the directory where you extracted. If so, then find the 'Gradle Tasks' bar, click the dropdown arrow next to the project you are in, go within 'fg_runs', and then double click on 'genEclipseRuns'. This should generate the runs properly for use without the command prompt. After that succeeds (which you should be able to tell within 'Gradle Executions' as there will be no red exclamation marks showing), you can then 'runClient' within the run configurations. If you haven't changed anything and gradle does fizz out on you, you will be able to open an instance with three mods installed: Minecraft, Forge, and Example Mod.

You could either try rerunning the generate runs again or target a different version of Forge temporarily, refresh, and then regen. One of those two tricks tends to annoy gradle enough to build them correctly.

Yes, you can just use the BlockModelRenderer or whatever the class is called. Well, I suggest blockstates to allow the use of cached baked models when its not moving, which is much more efficient than a renderer every tick.

Well, you would be using a TileEntityRenderer to determine how the doors are rendered during moving and then different blockstates to use a cached static model when not moving.

Do not run the commands before entering eclipse. Get a clean MDK, open up a workspace, import as an existing gradle project, then once that's done run the command either through the IDE system (recommended) or in terminal.

So, a question for you. First, what's your experience level in Java and using Eclipse as an IDE? As for the second part, extract a clean version of the MDK to a location and open up a clean workspace in Eclipse. Do not run any commands. Note, you have to point to a different directory for the workspace when they ask.

You tried using the registry object before it was registered. I'm guessing you didn't supply the instance to the music disc item then?

This is not applicable for 1.16.2+ as the system was changed. First, you will need to register your Configured Feature within the associated WorldGenRegistries. I would suggest looking at how the Features class does the registering and borrow the method. Note that this should be deferred until FMLCommonSetupEvent. For reference, the register event is not thread-safe, so it should be wrapped using the synchronous work queue provided in the event (e.g. enqueueWork). From there, you can attach the feature to the biome(s) of your choice using BiomeLoadingEvent. You can grab the generation settings builder there and add a feature during a specific point in the generation process, in your case most likely UNDERGROUND_ORES.

You have to answer that question yourself. What are you attempting to do in a generic form? I see you trying to keep a specific item in the crafting table and not be used. Is that the only case or does this expand to any item for a specific recipe? These are questions that need to be answered.

Depends on the complexity of the recipe. If there is no requirement for dynamic manipulation, you can get away with making a custom recipe with serializer and building a json off of that. You haven't created the recipe serializer. Take a look at ShapedRecipe for that. Also, every method within IRecipe except for basically two (I'm not counting the getters) has documentation associated with it. The other two gets the items that are supposed to be left over in the inventory using container items while the other gets the recipe ingredients.