Paint_Ninja

I think the events you're looking at are based on client-side information. Depending on where the mod is being run (client-side or server-side) the events may produce different results. You could use networking to communicate server events to the client. What Forge version are you using? By the way, try asking on the Discord in future, it's more active for dev support than the forums these days.

Way back in the Forge 1.17 days, work started for adding JPMS (Java Platform Module Support) to ModLauncher and ForgeModLoader. This has been used internally by Forge and some libraries for a while now, but mods (those with mods.toml specifically) have not been able to take advantage of it. As of Forge 1.21.1 and 1.21.3, this is now possible! What is JPMS and what does it mean for modders? JPMS is the Java Platform Module System, introduced in Java 9. It allows you to define modules, which are collections of packages and resources that can be exported or hidden from other modules. This allows for much more fine-tuned control over visibility, cleaner syntax for service declarations and support for sealed types across packages. For example, you might have a mod with a module called `com.example.mod` that exports `com.example.mod.api` and `com.example.mod.impl` to other mods, but hides `com.example.mod.internal` from them. This would allow you to have a clean API for other mods to use, while keeping your internal implementation details hidden from IDE hints, helping prevent accidental usage of internals that might break without prior notice. This is particularly useful if you'd like to use public records with module-private constructors or partially module-private record components, as you can create a sealed interface that only your record implements, having the interface be exported and the record hidden. It's also nice for declaring and using services, as you'll get compile-time errors from the Java compiler for typos and the like, rather than deferring to runtime errors. In more advanced cases, you can also have public methods that are only accessible to specific other modules -- handy if you want internal interactions between multiple of your own mods. How do I bypass it? We understand there may be drama in implementing a system that prevents mods from accessing each other's internals when necessary (like when a mod is abandoned or you need to fix a compat issue) -- after all, we are already modding a game that doesn't have explicit support for Java mods yet. We have already thought of this and are offering APIs from day one to selectively bypass module restrictions. Let me be clear: Forge mods are not required to use JPMS. If you don't want to use it, you don't have to. The default behaviour is to have fully open, fully exported automatic modules. In Java, you can use the `Add-Opens` and `Add-Exports` manifest attributes to selectively bypass module restrictions of other mods at launch time, and we've added explicit support for these when loading your Forge mods. At compile-time, you can use existing solutions such as the extra-java-module-info Gradle plugin to deal with non-modular dependencies and add extra opens and exports to other modules. Here's an example on how to make the internal package `com.example.examplemod.internal` open to your mod in your build.gradle: tasks.named('jar', Jar) { manifest { attributes([ 'Add-Opens' : 'com.example.examplemod/com.example.examplemod.internal' 'Specification-Title' : mod_id, 'Specification-Vendor' : mod_authors // (...) ]) } } With the above in your mod's jar manifest, you can now reflectively access the classes inside that internal package. Multiple entries are separated with a space, as per Java's official spec. You can also use Add-Exports to directly call without reflection, however you'd need to use the Gradle plugin mentioned earlier to be able to compile. The syntax for Add-Exports is the same as Add-Opens, and instructions for the compile-time step with the Gradle plugin are detailed later in this post. Remember to prefer the opens and exports keywords inside module-info.java for sources you control. The Add-Opens/Add-Exports attributes are only intended for forcing open other mods. What else is new with module support? Previously, the runtime module name was always forced to the first mod ID in your `mods.toml` file and all packages were forced fully open and exported. Module names are now distinguished from mod IDs, meaning the module name in your module-info.java can be different from the mod ID in your `mods.toml`. This allows you to have a more descriptive module name that doesn't have to be the same as your mod ID, however we strongly recommend including your mod ID as part of your module name to aid troubleshooting. The `Automatic-Module-Name` manifest attribute is now also honoured, allowing you to specify a module name for your mod without needing to create a `module-info.java` file. This is particularly useful for mods that don't care about JPMS features but want to have a more descriptive module name and easier integration with other mods that do use JPMS. How do I use it? The first step is to create a `module-info.java` file in your mod's source directory. This file should be in the same package as your main mod class, and should look something like this: open module com.example.examplemod { requires net.minecraftforge.eventbus; requires net.minecraftforge.fmlcore; requires net.minecraftforge.forge; requires net.minecraftforge.javafmlmod; requires net.minecraftforge.mergetool.api; requires org.slf4j; requires logging; } For now, we're leaving the whole module open to reflection, which is a good starting point. When we know we want to close something off, we can remove the open modifier from the module and open or export individual packages instead. Remember that you need to be open to Forge (module name net.minecraftforge.forge), otherwise it can't call your mod's constructor. Next is fixing modules in Gradle. While Forge and Java support modules properly, Gradle does not put automatic modules on the module path by default, meaning that the logging module (from com.mojang:logging) is not found. To fix this, add the Gradle plugin and add a compile-time module definition for that Mojang library: plugins { // (...) id 'org.gradlex.extra-java-module-info' version "1.9" } // (...) extraJavaModuleInfo { failOnMissingModuleInfo = false automaticModule("com.mojang:logging", "logging") } The automatic module override specified in your build.gradle should match the runtime one to avoid errors. You can do the same for any library or mod dependency that is missing either a module-info or explicit Automatic-Module-Name, however be aware that you may need to update your mod once said library adds one. That's all you need to get started with module support in your mods. You can learn more about modules and how to use them at dev.java.

Forge version: 53.0.0 Minecraft version: 1.21.3 Downloads: Downloads page Note that 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, as the first ever build of Forge for any MC version is usually buggy. Intro: The first build for Forge 1.21.3 has been released! It is based on 52.0.22 for 1.21.1, however we'll still be releasing new builds for both 1.21.1 and older Minecraft versions, of course. We skipped 1.21.2 because it had some known bugs that were fixed shortly after release in 1.21.3 - similar to the 1.20.3 and 1.20.4 situation. If you find any issues, please let us know on the Discord.

It's a long time coming, but it's finally here -- as of Forge 1.21.1, we've now implemented the de-facto common tags! With the introduction of the de-facto common tags in Forge, there are now numerous tags that are shared across all major mod loaders. This means greater compatibility between mods across different loaders and a huge selection of new tags now bundled with Forge that are available for use in mods. It also means that datapack authors are less likely to need duplicate data or even separate datapacks for different loaders. We wanted to make it worth the wait, so we've gone above and beyond to ensure that the implementation of the common tags in Forge is as comprehensive and seamless as possible. Not only have we implemented all the tags -- including accounting for the many changes and additions made overtime -- we've also written tools that dump tags between the different loaders to identify differences, have comprehensive documentation on how to migrate to the new tags, bouncer fields to automatically make some old code use the new tags, avoided breaking changes entirely and adopted a stricter policy that clearly distinguishes between loader-specific and common tags. If you see a `c:` tag definition in Forge for a given version, you can be confident that it'll always work on all loaders that support the common tags. Many Neo-specific/Fabric-specific `c:` tags have also been added to Forge, under the `forge:` namespace, but we'll actively migrate them to `c:` as soon as they're adopted by the other loaders and provide a graceful deprecation period for the old tags. Overtime, we'll be working with other loaders to help further improve parity and keep things more in sync across versions moving forward, as well as updating Forge as new tags are added to other loaders, of course. We hope it has been worth the wait! Developers can find more information on Forge's implementation, including the common tags dumper and migration guides, in the description of pull request 9955. Background As for that wait, why did it take so long to implement in Forge after the other loaders? Shouldn't it have been a simple copy-and-paste job? Well... there were many hurdles to overcome that made implementing this feature in Forge difficult. A lot of work went into this, and I'd like to share just some of the many challenges faced. First of which was documentation and ease of migration: Early experiments of implementing this on Forge involved a simple copy-and-paste from Neo, however it quickly came apparent that this was not a good fit for Forge. There were many deliberate breaking changes that were initially undocumented, with various `forge:` namespaced tags being removed with no `c:` equivalents, around a hundred Neo-specific `c:` tags that were not available on Fabric despite having a dedicated `neoforge:` namespace for loader-specific tags and a "tag convention warning" system that would recommend migrating to the wrong tags as well as containing migration definitions from non-existent tags to `c:` equivalents and vice-versa. The discussions as to why certain tags were added, renamed, added, changed or removed were done across multiple PRs, Discord servers and channels. I'm aware of many different Discord channels where the tags were discussed, spanning multiple servers and thousands of messages, not to mention over 40 separate PRs made to the two loaders after the initial PRs and their associated filed issues, some of which contained further breaking changes. With no centralised discussion or documentation, combined with both loaders having differing goals that led to loader-specific `c:` tags on both sides, as well as bugs in the automated warning systems, it was very challenging to find the correct mappings and understand the reasoning behind them. Second was the approach taken by the other loaders: My understanding is that there were multiple attempts to create a central repo containing the code for common tags that the loaders could pull from so that it would be easy to update the tags in one place and have them propagate to all loaders, with clear indicators of what tags are available for a given version as well as well-documented parity across loaders, which is exactly what Forge was asking for in the past. However, all these attempts fell through over disagreements on management and permissions. As a last-ditch effort, the main person organising these discussions ended up directly creating PRs to the two loaders, but excluded Forge. These two initial big PRs were done accounting for loader-specific requests and with the intent of getting at least something done, rather than throwing away all the work that had been done so far. Bizarrely, the start of the description of both PRs implies that Forge was not interested in supporting the new tags, despite multiple Forge team members publicly expressing the opposite. Other loaders had the luxury of having the PRs made for them, which they could then review and merge, while Forge was left out of the loop. To make matters worse, said main person also refused to review my work in progress implementation to ensure consistency across loaders, stating that he doesn't use Forge anymore. I was essentially left to figure out the whole thing single-handedly, cross-referencing thousands of comments across multiple places, accounting for loader-specific differences and trying to get it up to Forge's standards. While working on Forge's implementation, people expressed frustration over this approach, as it looked like a deliberate attempt to make it hard for Forge to adopt the new tags. Even without considering the possibility of malice, it would've been easier to keep track of changes and loader-specific differences if a centralised document was maintained after loaders accept changes (that way the document would not require agreement from loaders). In my opinion, the manual approach of PRs to both sides and manually implementing parity improvements as they were requested without keeping track anywhere is more error-prone and labour-intensive. The following day I received an stern DM accusing me of spreading conspiracies about him making it hard for Forge to implement the new tags, along with a brief explanation of why the centralised repo didn't happen which further shaped my understanding explained here. I took the opportunity to thank him for reaching out with an explanation and provided more context on the frustrations people had with the approach taken, highlighting things such as the spread out nature of discussions, the lack of clear documentation and his refusal to review my implementation. I offered to work with him to fix some of the bugs I found on other loaders and we came to an understanding. This turned out to be pretty beneficial as I was able to directly ask him about the tags, get updates on new follow-up PRs made to other loaders and made him aware of some bugs and mistakes with the warning system and tags. I'm thankful for his willingness to reach out and help. Third is the sheer amount of tags and the moving target: Due to the approach taken by other loaders as explained earlier, there is no versioning for the de-facto spec. This has its own benefits and drawbacks. The main drawback being that the tags are out of sync across Minecraft versions -- you may see some tags on both loaders for the latest version, but only on one loader when going back an MC version. This is due to the differences in approach between the two loaders, where one is more focused on the latest version while the other supports multiple versions. This isn't entirely without its benefits though, as it allows Neo to deliver new tags faster by not needing to worry about older versions. There are many tags added, across many categories. Some existing Forge tags gained new contents, too. This is the biggest collaborative tag update the Minecraft modding community has ever seen, with a wide-reaching impact in terms of tags, which is a big win for interoperability and closely aligns with Forge's goal of being a compatibility layer for mods. Since the first big two PRs were made and Forge started working on its implementation, I've been keeping track of many amendment PRs made, cross-referencing them with each loader and Forge itself to ensure parity. A lot of new things have been further added and parity has been improving, but this does mean it's a moving target. Catching up with something that's continuously evolving means you need to be quick but thorough, which is a difficult balance to strike. While I've mostly been doing this single-handedly, I'd like to thank the people who have helped me along the way, such as Jonathan, Lex, TelepathicGrunt and others who have worked with me to overcome all of these hurdles and finally deliver Forge's implementation of the de-facto common tags. Conclusion I hope this document has provided some insight into some of the challenges faced when implementing the de-facto common tags in Forge, as well as the benefits it brings to the wider MC modding community. Now that all major mod loaders have adopted the common tags, I'm looking forward to seeing players, datapack authors and mod devs alike benefit from the compatibility benefits it brings to the whole MC modding ecosystem, no matter which loader you use.

Please share a link to your crash report on https://paste.ee, as explained in the FAQ

This is the Forge forums, we do not support Fabric here. Read the FAQ

You allocated too much RAM to the game, so the OS, drivers and other things are fighting for resources. Close as many things as you can when playing, allocate 3GB or 3.5GB max, do not set a min. In task manager go to the startup tab and disable things you don’t need to start and have always running when you turn on your PC, but ignore the AMD ones in the list (they’re needed). Use Java 21 instead of Java 17. Consider removing Alex’s Mobs. Update your Radeon drivers (see the FAQ). Consider buying more physical RAM for your PC

Please share a link to your crash report on https://paste.ee, as explained in the FAQ

Forge version: 52.0.0 Minecraft version: 1.21.1 Downloads: Downloads page Note that 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, as the first ever build of Forge for any MC version is usually buggy. Intro: The first build for Forge 1.21.1 has been released! It is based on 51.0.33 for 1.21.0. We expect most existing 1.21.0 mods to work on 1.21.1 without needing any changes, as the only notable differences from Vanilla 1.21.0 -> 1.21.1 are a couple of new languages and a bugfix for an exploit that could be used to crash servers... as such, we strongly encourage all 1.21.0 players and mod developers to move to 1.21.1. From a mod dev perspective, BlockEntities now validate their block during construction - as long as that's fine you should be good to go. 1.21.0 has been moved to our minimal support tier, as explained in our tiered support policy - use 1.21.1 instead. If you find any issues, please let us know on the Discord. Sidenote: I'm sorry for not making these release posts for Forge betas of the past few MC versions. While I forgot to make some posts, we still released Forge builds for newer MC. When in doubt, check the sidebar on the files site. Same-day ports of Forge to new MC versions are common.

First, the solution: use the mdk and don't touch anything in it before checking that it works. You seemed to have changed something that broke it. You're also targeting 1.20.0 - *don't use this!* - it is a known buggy and abandoned version that people dropped in favour of 1.20.1 which came out shortly after. Next, a couple of things about your post: 1) you tagged it with "broken mod", which is commonly used to indicate that your issue has been solved and that the problem was that one of the mod's you installed was broken 2) please use code embeds. It's hard to interpret an arrow pointing to the issue in your error when the arrow doesn't line up properly

Please share a link to your crash report on https://paste.ee, as explained in the FAQ. Dumping it directly into the thread often triggers the anti-spam and makes it hard to read due to word wrapping

This is the Forge forums. We do not support NeoForge here - use Forge instead if you want help.

They were intended to be used on tutorial posts so that people could easily find tutorials based on their skill level, but instead the tags were abused for unrelated things that made the original intent useless... for example, people often posted crash reports with the "beginner" tag, so instead of finding tutorials for beginners, you got crash reports showing up in searches.

You can't mix mods for different MC versions.

Spark definitely has downloads available for Forge 1.20.1 on the CurseForge website. 47.0.35 is a very old beta version of Forge. You should be running 47.3.0

Please share your crash report or log, as explained in the FAQ

Forge version: 43.4.0 Minecraft version: 1.19.2 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Downloads page Intro: This fourth recommended build for 1.19.2 offers improved performance, a couple of bugfixes and a boatload of backports from newer MC versions. As a reminder, the release policy for recommended builds has changed - we now aim to release new recommended builds for fully supported MC versions more frequently - as long as there's a reasonable amount of changes since last recommended build. This week, we've released new RBs for 5 different MC versions, proving a renewed, serious commitment for long-term support. New: Improve mod loading error message for errors inside mod constructors, backport of #9751 (#9709) No longer shows a vague error if the error happens inside a constructor - Forge now tells you the actual error Optimise path filter in mod loading, backport of #9710 (#9712) Add a CrashReportAnalyser that tries to identify the mod that crashed the game This feature scans your crash report as it is being generated and lists suspected mods that could be the cause of the crash, accounting for coremodding as well. This makes it easier to find the culprit as it is often listed clearly in the crash report itself (e.g. "Suspected mods: buggymod") Improve mod description formatting in mods screen (#9771) Update to FG6 and Gradle 8, backport 1.20.1's MDK (#9754) Optimise ForgeConfigSpec and make Range public, backport of #9810 (#9827) Make common DisplayTest registration tasks easier, backport of #9822 (#9838) Before: ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class, () -> new IExtensionPoint.DisplayTest(() -> "ANY", (remote, isServer) -> true)); After: ModLoadingContext.get().registerDisplayTest(IExtensionPoint.DisplayTest.IGNORE_ALL_VERSION); The old method still works for backwards-compatibility. The new method has also been backported to 1.20.1, 1.19.4 and 1.18.2. Add support for running with Java 22 and 23 Make common config screen registration tasks easier, backport of #9884 (#9914) Before: ModLoadingContext.get().registerExtensionPoint(ConfigScreenHandler.ConfigScreenFactory.class, () -> new ConfigScreenHandler.ConfigScreenFactory((mc, modsScreen) -> new MyConfigScreen(modsScreen)); After: MinecraftForge.registerConfigScreen(modsScreen -> new MyConfigScreen(modsScreen)); The old method still works for backwards-compatibility. The new method has also been backported to 1.20.1, 1.19.4 and 1.18.2. Optimise capabilities, backport of #9886 (#9918) Fixed: Fix TagsProvider not honouring replace attribute (#9865) Fix NPE when acceptableValues in defineInList() does not allow nulls, fixes #9300, backport of #9903 (#9909)

Please share the full log or join our Discord server for help

Please share your Spark report. Instructions for troubleshooting lag and how to use Spark are in the FAQ

Try giving the game more ram in the launcher settings

The "essential" mod is broken. Try updating Forge or removing the mod

Forge version: 45.3.0 Minecraft version: 1.19.4 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Downloads page Intro: This third recommended build for MC 1.19.4 offers improved performance, bugfixes, new features and various backports from newer versions such as 1.20.1, 1.20.2, 1.20.4 and 1.20.6. As a reminder, the release policy for recommended builds has changed - we now aim to release new recommended builds for fully supported MC versions more frequently - as long as there's a reasonable amount of changes since last recommended build. New: Improve mod loading error message for errors inside mod constructors, backport of #9751 (#9708) No longer shows a vague error if the error happens inside a constructor - Forge now tells you the actual error Optimise path filter in mod loading (#9711) Update to FG6 and Gradle 8, backport 1.20.1's MDK (#9753) Improve mod description formatting in mods screen (#9770) Add a CrashReportAnalyser that tries to identify the mod that crashed the game This feature scans your crash report as it is being generated and lists suspected mods that could be the cause of the crash, accounting for coremodding as well. This makes it easier to find the culprit as it is often listed clearly in the crash report itself (e.g. "Suspected mods: buggymod") Optimise ForgeConfigSpec and make Range public, backport of #9810 (#9826) Make common DisplayTest registration tasks easier, backport of #9822 (#9837) Before: ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class, () -> new IExtensionPoint.DisplayTest(() -> "ANY", (remote, isServer) -> true)); After: ModLoadingContext.get().registerDisplayTest(IExtensionPoint.DisplayTest.IGNORE_ALL_VERSION); The old method still works for backwards-compatibility. The new method has also been backported to 1.20.1, 1.19.2 and 1.18.2. Add support for running with Java 22 and 23 Make common config screen registration tasks easier, backport of #9884 (#9913) Before: ModLoadingContext.get().registerExtensionPoint(ConfigScreenHandler.ConfigScreenFactory.class, () -> new ConfigScreenHandler.ConfigScreenFactory((mc, modsScreen) -> new MyConfigScreen(modsScreen)); After: MinecraftForge.registerConfigScreen(modsScreen -> new MyConfigScreen(modsScreen)); The old method still works for backwards-compatibility. The new method has also been backported to 1.20.1, 1.19.2 and 1.18.2. Optimise capabilities, backport of #9886 (#9917) Fixed: Fix Melon/Pumpkin stems having wrong plant type causing them to remain after trampling farmland. Fix NPE when acceptableValues in defineInList() does not allow nulls, backport of #9903 (#9908)

Please share a link to your crash report on https://paste.ee, as explained in the FAQ

Forge version: 50.1.0 Minecraft version: 1.20.6 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Downloads page Intro: Continuing the strong cadence of solid improvements on 1.20.x versions, we focused especially on the developer experience for 1.20.6. We've delivered a new decompiler, unified official MojMap mappings everywhere, cleaned up more patches and worked with devs to make our networking APIs better support multiplatform mods and Vanilla's latest features. The new decompiler has improved formatting and much better support for newer Java features. This took weeks worth of effort from multiple team members to redo all the patches to support this (albeit, we still did this much faster than the competition), but we believe it was worth it in the end. Additionally, by having the same official MojMap mappings everywhere, mod devs have less required steps to build their mods and troubleshooting crash reports in production is easier. Setting 1.20.6 aside for a moment, we haven't forgotten about older versions! We continue to actively backport new features and make fixes for older versions where possible - meaning you can adopt some breaking changes incrementally instead of being forced to deal with all of them lumped in with an MC port, and you don't need to chase the latest MC or go out of your way to manually backport things yourself to take advantage of some of the things we're doing on newer versions. More than ever, Forge remains an excellent choice for devs who want to focus on their mods. New: New decompiler Supports newer Java features and has improved formatting Runtime official mappings Better troubleshooting experience as logs and crash reports now have human-readable names in production No need to reobf your mod as a developer. Mixin refmaps are also unnecessary. New AccessTransformers Much simpler implementation, no longer relies on ANTLR Significant performance improvements Add ModelLayers patch back (#9962) Update SimpleChannel to make StreamCodecs easier (#9959) Rework networking so that RegistryFriendlyByteBuf is useable for modders Simple support for StreamCodec in SimpleChannel Codecify all Forge packets Make simpler builder pattern for SimpleChannel. Will eventually deprecate the old MessageBuilder as it's verbose and poorly written. Implement entity-aware armor model and texture hooks. Closes #9960 Remove ICustomPacket and add PayloadChannel. (#9972) New PayloadChannel that uses the vanilla payload Type for packet distinction Implement the minecraft:register/unregister channels using the new PayloadChannel New generic channel builder function allowing people to implement channels however they want. Add GatherComponentsEvent (#9944) Fixed: Fix custom payloads not being handled on the server in the game state. Closes #9948 Fix villagers not opening trade GUIs. Closes #9946 Fix MDK by bumping FG and disabling reobf tasks Fix LAN server IPs being duplicated Fix connecting to vanilla servers due to misapplied patch. Fix canApplyAtEnchantingTable null pointer. Closes #9956 Bump SecureModules for package info and multi-release jar fixes. Fix RenderTarget stencil patch location. Fixes #9965 Fix shields not working correctly. Fixes #9966 Filter paths discovered by ServiceProvider in ClasspathLocator. Closes #9899 Fix Melons/Pumpkins not growing correctly. Fix potion brewing having arguments reversed. Closes #9970 Fix canceling MobSpawnEvent.FinalizeSpawn causing a NPE. Closes #9971 Ignore jar files in the mods folder that are not Forge mods. Closes #9968 Make RegistryObject.getHolder lazy, should help cases where vanilla registries use holders from other vanilla registries. Closes #9961 Fix finalizeSpawn's return value not being used correctly. Closes #9964 Fix powered rails not propagating correctly. Fix screen layering and re-add the test. (#9978) Fix RenderHandEvent firing with incorrect hand and item for offhand items. (#9977) Fix NPE in HurtByTargetGoal when mods set targets to null. Closes #7853 Fix crash when reloading a world that uses custom placed features. Closes #9979 Add File.exists check to ConfigFileTypeHandler. Closes #9976 Make OpenContainer and SpawnEntity packets process on main game thread. Move Creative Inventory page count to fix issue with partially transparent tooltips. Closes #9983 Fix CustomizeGuiOverlayEvent.DebugText and CustomizeGuiOverlayEvent.Chat not being fired. (#9982) Removed: Remove deprecated compressLanIPv6Addresses config option (#9949) LAN IPv6 addresses are always compressed these days, so this config option is redundant Remove zombie chance config options (#9950)

Forge version: 49.1.0 Minecraft version: 1.20.4 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Downloads page Intro: We're pleased to announce the first recommended build for 1.20.4. Following the spirit of significant improvements from 1.20.2, we're continuing to iterate on improving performance, code quality, features and ease of use. 1.20.4 brings various enhancements, focused on improving user experience. Some highlights: We've brought back the option of executable server jar - just like the olden days. The run scripts remain an option for those who prefer it, and we've added Java version checks and a readme to make it easier to setup your own server. We also collaborated with various third-party server panels to ensure compatibility with our new setup. Client-side-only mods crashing dedicated servers and mod devs needing to employ special care to avoid such has been solved by the new clientSideOnly switch in the mods.toml file. This feature results in better performance and makes it easier for mod devs to write client-side mods. The config system has gotten some love, too. There's been a big clean-up to its internals, various optimisations and support for new data types - ByteValue, ShortValue and FloatValue. On the topic of clean-up and optimisation, the DisplayTest and ConfigScreen extension points now have simpler APIs and many parts of the mod loading process have seen optimisations along with improved error messages for non-Forge mods. New: Revive the option of executable jars for the dedicated server You're no longer forced to use the supplied run scripts! All existing JPMS features are preserved - you can have your cake and eat it too Add impl. of IModFileInfo#showAsDataPack (#9802) Add clientSideOnly feature to mods.toml (#9804) Setting this to true in the root of your mods.toml will tell Forge to skip loading your mod on dedicated servers and set an appropriate DisplayTest for you This is recommended for all client-side-only mods, as it is a trivial and performance way to prevent your mod from crashing servers or causing it to incorrectly show up as incompatible on the multiplayer server list Optimise ForgeConfigSpec and make Range public (#9810) Support pack overlay system. Closes #9818 Clean-up Explosion patch but keep bin compatibility by using asm hacks. Closes #9817 Make common DisplayTest registration tasks easier (#9822) Before: ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class, () -> new IExtensionPoint.DisplayTest(() -> "ANY", (remote, isServer) -> true)); After: ModLoadingContext.get().registerDisplayTest(IExtensionPoint.DisplayTest.IGNORE_ALL_VERSION); The old method still works for backwards-compatibility. The new method has also been backported to 1.20.1, 1.19.4, 1.19.2 and 1.18.2. Improve server panel compatibility (#9836) Criterion test mod + unit test (#9744) Show a more helpful error message when attempting to start the server with old Java Improve the UX of server setup and usage, add a readme with instructions, tips and advice Readded DatapackBuiltinEntriesProvider (#9848) Add CPU usage config option to early window, hide it by default (#9866) New cleaner look, slightly improved client mod loading performance Make common config screen registration tasks easier (#9884) Before: ModLoadingContext.get().registerExtensionPoint(ConfigScreenHandler.ConfigScreenFactory.class, () -> new ConfigScreenHandler.ConfigScreenFactory((mc, modsScreen) -> new MyConfigScreen(modsScreen)); After: MinecraftForge.registerConfigScreen(modsScreen -> new MyConfigScreen(modsScreen)); The old method still works for backwards-compatibility. The new method has also been backported to 1.20.1, 1.19.4, 1.19.2 and 1.18.2. Optimize capabilities (#9886) Add Leaves method to ModelProvider.java (#9887) Add ByteValue, ShortValue and FloatValue to ForgeConfigSpec, cleanup code (#9902) Add helper method to `OnDatapackSyncEvent` (#9901) Prevent registering null tiers (#9895) Makes it easier to identify broken mods, as it moves the crash to when the broken mod in question registers the tier, rather than when any mod tries getting the tier. Improve mod loading errors (#9870) Add ClientPauseChangeEvent (#9905) Add config option for optionally disabling non-Forge mods.toml detection (#9943) Fixed: Fix java version check in bootstrap shim Fix Server bundle Bump SecureModules to fix conflict between AccessTransformers and Mixins, Closes #9820 Only add sorted/deduplicated mods to the classpath. Fixes some mods causing the Forge error displays to break. Closes #9833 Bump JarJar and SecureModule to fix issue with jars containing [] in their name. Closes #9842 Fix launcher version name missing - between `forge` and the version. Closes #9843 Fixed Spelling error in credits.txt (#9694) Fix background music looping when it shouldn't Fix cases where LivingConversionEvents were not fired for vanilla conversions. Closes #9850 Add null check to DimensionDataStorage. Fixes #9859 Fix DNS SRV record lookup not working by hacking the module system. Closes #9846 Fix slightly offset mods screen link positioning (#9860) Fix DatapackBuiltinEntriesProvider issues with forge registries, Fixes #9874 Fix modlist size Fix level data not loading from existing worlds. Whole system needs a re-write. Fix NPE when acceptableValues in defineInList() does not allow nulls, fixes #9300 (#9903) Early display fixes/workarounds for buggy drivers (#9921) Fix edge-case regression with single-jar multiloader mods (#9931) Fix early window crash when parsing some forms of options.txt (#9933) Make non-Forge mods.toml detection more robust (#9935) Filter paths discovered by ServiceProvider in ClasspathLocator. Closes #9899 Removed: LibraryFinder