Jonathing

Not sure if the wall of text is helpful. It looks like a Mixin from Iris is failing. Try loading without that and see if that helps.

crazy

Hey, sorry about this. There was an oversight with my fix so I've made a pull request to have it resolved. When LexManos or Paint_Ninja are available, it'll be merged. For now, please continue to use 60.0.5. Thanks for letting me know of the issue again. 🙏

I've fixed this in Forge 60.0.7. Please update. Thank you!

In the future I do plan on adding optional OAuth to the new launcher in ForgeGradle 7. But yes, using --username and offline mode is a good workaround to not using accounts in the development environment, especially considering that the server is on LAN.

GistForge 59.0 Minecraft 1.21.9Forge 59.0 Minecraft 1.21.9. GitHub Gist: instantly share code, notes, and snippets.

GistForge 58.1 Minecraft 1.21.8Forge 58.1 Minecraft 1.21.8. GitHub Gist: instantly share code, notes, and snippets.

a

You can add mob spawns using Forge's Biome Modifiers feature. I won't go into details on how to use a data generator for them, but here's a simple example: { "type": "forge:add_spawns", // Required "biomes": "#namespace:biome_tag", // Accepts a biome id, [list of biome ids], or #namespace:biome_tag "spawners": { "type": "namespace:entity_type", // Type of mob to spawn "weight": 100, // int, spawn weighting "minCount": 1, // int, minimum pack size "maxCount": 4 // int, maximum pack size } }This JSON file would go somewhere like this: data/modid/forge/biome_modifier/your_biome_modifier.json

Try replacing implementation with minecraftLibrary. Dependencies in the minecraftLibrary configuration are added to your compile and runtime classpaths in ForgeGradle 6.

This forum is for Forge, not NeoForge. Please go to them for support.

Forge version: 55.0.0 Minecraft version: 1.21.5 Downloads: As this is the start of a new version, it is recommended that you check the downloads page and use the latest version to receive any bug fixes. Downloads page Intro: Good evening! Today, we have released our initial build of Forge 55.0 for Minecraft 1.21.5. 1.21.5 is the newest member of the 1.21 family of versions, which was released yesterday on March 25, 2025. As a reminder, the first minor (X.0) of a Forge version is a beta. Forge betas are marked as such on the bottom left of the title screen and are candidates for any breaking changes. Additionally, there are a couple of important things to note about this update, which I've made sure to mention in this post as well. Feel free to chat with us about bugs or these implementation changes on GitHub and in our Discord server. As always, we will continue to keep all versions of 1.21 and 1.20 in active support as covered by our tiered support policy. Cheers, happy modding, and good luck porting! Rendering Refactor For those who tuned in to Minecraft Live on March 22, 2025, you may already know that Mojang have announced their intention to bring their new Vibrant Visuals overhaul to Java in the future. They've taken the first steps toward this by refactoring how rendering pipelines and render types are handled internally. This has, in turn, made many of Forge's rendering APIs that have existed for years obsolete, as they (for the most part) can be done directly in vanilla. If there was a rendering API that was provided by Forge which you believe should be re-implemented, we're happy to discuss on GitHub through an issue or a pull request. Deprecation of weapon-like ToolActions In 1.21.5, Minecraft added new data components for defining the characteristics of weapons in data. This includes attack speed, block tags which define efficient blocks, and more. As such, we will begin marking our ToolActions solution for this as deprecated. ToolActions were originally added to address the problem of creating modded tools that needed to perform the same actions as vanilla tools. There are still a few tool actions that will continue to be used, such as the shears tool action for example. There are some existing Forge tool actions that are currently obsolete and have no effect given the way the new data components are implemented. We will continue to work on these deprecations and invite you to chat with us on GitHub or Discord if you have any questions.

As long as the packets you are sending aren't lost, there's nothing wrong with what you're currently doing. Although, this sounds like something that would benefit from you making your own datapack registry instead of trying to arbitrarily sync static maps. Check out `DataPackRegistryEvent.NewRegistry`.

Make a workspace for the mod's Minecraft version. Just download the MDK of whatever that version is. Then, add it as a dependency. So, if it's on CurseForge, you can do something like this: dependencies { implementation fg.deobf("curse.maven:PROJECT_ID:VERSION_ID") } Then you can take the mapped jar from Gradle's caches (in IntelliJ this is right click > Open in > Explorer) and run it through your favorite decompiler (FernFlower, VineFlower, etc).