neoforged/neoforge

Neo Modding API for Minecraft, based on Forge

NeoForge

NeoForge is a free, open-source, community-oriented modding API for Minecraft.

Version	Support
1.20.x	Active

• Download
• Discord
• Documentation

Installing NeoForge

Go to the Download page, select the Minecraft version and installer, and run it. The installer will attempt to install NeoForge into your vanilla launcher environment, where you can then create a new profile using that version and play the game!

For support and questions, visit the NeoForged Discord server.

Creating Mods

See the "Getting Started" section in the NeoForged Documentation.

Contribute to NeoForge

If you wish to actually inspect NeoForge, submit PRs or otherwise work with NeoForge itself, you're in the right place!

Check the contribution workflow for details.

Translations

Translations are done on Crowdin.

Pull requests

Please read the contributing guidelines found here before making a pull request.

Contributor License Agreement

We require all contributors to acknowledge the NeoForged Contributor License Agreement. Please ensure you have a valid email address associated with your GitHub account to do this. If you have previously signed it, you should be OK.

neoforge's Issues

Mod description shows line ending char

I’m at work so I can’t elaborate but something something mod descriptions showing line ending at end or something

Move to require usage of the step height attribute

This is more of a todo note to enforce usage of ForgeMod#STEP_HEIGHT_ADDITION over the Entity#maxUpStep field. This has the following benefits:

1. Consistency - Currently, the step height can be modified through either means, and neither is aware of eachother.
2. Traceability - Modifications done directly to the field cannot be tracked to their source.
3. Interoperability - Multiple modifications to the legacy field may conflict with eachother. Attribute modifiers solve this problem.

The following tasks need to be completed:

• Deprecate Entity#setMaxUpStep(float) in favor of the step height attribute. This method was added in 1.20 and has not yet been deprecated.
• Deprecate LivingEntity#maxUpStep() in favor of the attribute. Entity#maxUpStep() is already deprecated.
• Rename ForgeMod#STEP_HEIGHT_ADDITION to ForgeMod#STEP_HEIGHT to signify it is the primary means of dealing with step height, and not an auxiliary method.
• Disable the ability for entities to opt-out of having the STEP_HEIGHT attribute. Currently this is supported, but in an attribute-driven universe it will not be.
• Change IForgeEntity#getStepHeight to only check the attribute. Enforcing this for all entities would be difficult due to the maintenance burden of mapping the vanilla entities attribute value to their maxUpStep values. In practice there are only 13 entities that change their step height from the default value. At the very least, it should be enforced for players, since they have their step height modified most frequently.

PerWorld configs should create a "defaultConfig" config first

o/
I wasn't going to implement this myself but if configs get reworked as #32 was FINALLY found an seen as a "issue" and not just seen as "don't use notepad++".

here is another thing that modpack devs will kiss your feet for.
Server configs will only be created when you create a world.

Which is fine. I get that per instance configs make sense.
But while i am writing my own config system (will launch soon xD) i found something that forges configs could do a LOT better.
And thought of sharing the idea.

Instead of ONLY creating a server config upon world creation in 1 specific instance.
How about you create upon game load a server config in the "defaultConfigs" folder?
And when a world loads it first copies from the "defaultConfigs" folder if present?
And just append differences there.

This would allow modpack devs to provide global configs to their pack without having to install another mod.
Or is there a reason why forge creates the "defaultConfigs" folder in runtime?

Anyways.
That is something a TON of people would love to see.

Also and if people just want to refresh the "defaultconfigs" delete the file. It doesn't interfere with "existing copies" just "fresh one" would copy the new config entry.

[1.20.2+] The Registry Overhaul

The Registry Overhaul is the transition from the Forge Registry system to the vanilla Registry system. This issue serves as the general record of all changes under this umbrella, as well as their scope and future steps that have yet to be executed. It is also a work-in-progress. Discussion is also ongoing in the Registries Overhaul thread.

Importantly, this will be a gradual change. This system is huge and has a lot of pieces to it, and we hope to make the transition as seamless as possible.

Phase 1

The first step in this process is to phase out usages of the Forge Registry system. The goals of this phase are to reduce mod usage of the forge registry system and identify feature gaps between the two systems.

Identified Feature Gaps

• Registry Sync
• ID Map Serialization to Disk
• Aliasing
• Registry Replacement
  • This feature is being removed.

PR's under this umbrella include the following:

1. #35

Phase 2

The second step is to add feature parity to the vanilla Registry system, based on feature gaps identified in phase 1.

PR's under this umbrella include the following:

Phase 3

The final step is to remove the Forge Registry system in totality, after the vanilla Registry system has achieved parity.

PR's under this umbrella include the following:

In the interface where loaded mods are listed (more precisely, to choose how to sort the list), there seems to be one pixel more than expected

Can Neoforge reduce modifications to the Minecraft？

For example, no longer fixing existing bugs in Minecraft and restoring methods that have been removed

`PlayerSpawnPhantomsEvent` is just instantiated and not run on the event bus

Minecraft Version: 1.20.1

NeoForge Version: 47.1.56

Logs: Not really needed

Steps to Reproduce:

1. Subscribe a PlayerSpawnPhantomsEvent
2. Run the game and check that the event is never run

Example code
This makes Phantoms spawn in The End instead of the Overworld

@SubscribeEvent
public void onPhantomsSpawn(PlayerSpawnPhantomsEvent event) {
    if (event.getEntity().level().dimension() == Level.OVERWORLD)
        event.setResult(Event.Result.DENY);
    else if (event.getEntity().level().dimension() == Level.END)
        event.setResult(Event.Result.ALLOW);
}

Description of issue:
This happens because the event is never posted, only instantiated:

NeoForge/patches/minecraft/net/minecraft/world/level/levelgen/PhantomSpawner.java.patch

Line 10 in 3323a2f

+ var event = new net.minecraftforge.event.entity.player.PlayerSpawnPhantomsEvent(serverplayer, 1 + randomsource.m_188503_(difficultyinstance.m_19048_().m_19028_() + 1));

PackRepository patch fails to retain order

The patch in PackRepository to make the sources field mutable replaces the original ImmutableSet.copyOf call with a new HashSet(...). ImmutableSet.copyOf has a rough order guarantee: Returns an immutable set containing each of elements, minus duplicates, in the order each appears first in the source array. HashSet does not have such guarantee. I suggest replacing the current patch with a LinkedHashSet or fastutil equivalent.

What has happened to Forge?

Sorry to bother you. I'm a player of Minecraft from China. Early today,I noticed that Forge was rebranded to NeoForge.Why was Forge rebranded?I use Forge to play mods on Minecraft every day, so I'm wondering if this is going to make any difference to the game.If possible, could you please tell me what has happened to Forge? I am looking forward to your reply.Thanks!

Here is the news about Forge in China player groups.

[1.18.1~ Latest] Forge is not compatible with Openj9 17

Minecraft Version: 1.18.1~Latest

Forge Version: 39.1.1~Latest :(

Steps to reproduce:

Start from openj9 17 because 1.18 onwards is java17 start
Crash
Problem description: You are trying to run with an unsupported Java Virtual Machine: Eclipse OpenJ9 VM.
Please visit https://adoptopenjdk.net and install the HotSpot variant.
OpenJ9 is not compatible with several of the conversion behaviors we rely on to run.

I don't know if OpenJ9 is supported by NeoForge, but it's very likely that it's not.

Here's some player feedback that was previously dismissed MinecraftForge/MinecraftForge#9408

Solutions for other loaders: e.g. fabric FabricMC/fabric#1019

CaffeineMC/lithium-fabric#111

Finally, I don't want NeoForge to make the same mistake, please support openj9, thanks to all the developers!

Mod transformers are applied inconsistently if loading fails

If early mod loading fails (e.g. due to a missing dependency), mod access transformers are not applied (since only the ATs from system mods are loaded) but their mixins are still applied. If the mod mixes into a class that is used within the code path to display the dependency error screen, and that mixin references a field in a manner that requires the mod's access transformer to also have been applied, the game will crash.

To see this in the wild, install Rubidium 0.6.5 and Sophisticated Backpacks 3.18.56.890 on Forge 47.1.0. Be sure not to install Sophisticated Core. Rather than displaying the missing dependency screen, the game will crash with an IllegalAccessError, as Rubidium includes a mixin that depends on its access transformer.

In my opinion this design is confusing and inconsistent. It also creates misleading crash reports for users that show the IllegalAccessError instead of the actual problem (which is that a a dependency is installed). Both access transformers and mixins are modifying core game code, so it seems prudent to either not apply mod mixins in this scenario, or also apply mod ATs. This current design works in the case that the mod uses only ATs and Forge events (as its event handlers are skipped) but does not work in a Mixin world.

It's possible to work around the issue by checking ModLoader.isLoadingStateValid() (after constructors fire) or LoadingModList.get().getErrors().isEmpty() (before constructors fire) in critical mixins, but I don't think modders should have to do this.

lwjgl failure on running client on mdk

I am trying to setup the work space for 1.20.1 with the base mdk without any new code in it. my operating system is windows 11, only one display adapter (nvidia 1080ti) and in the nvidia panel I set the opengl rendering gpu to use this display adapter. I installed openjdk using adoptium for version 17 and the settings and project structure in intelliJ is already set.
When I try to use RunClient task using intelliJ, it crashes with this log in the consol :

`
[08:48:25.244] [main/INFO] [Launcher/MODLAUNCHER]: ModLauncher running: args [--launchTarget, forgeclientuserdev, --version, MOD_DEV, --assetIndex, 5, --assetsDir, E:.gradle\caches\forge_gradle\assets, --gameDir, ., --fml.forgeVersion, 47.1.25, --fml.fmlVersion, 47.1.40, --fml.mcVersion, 1.20.1, --fml.mcpVersion, 20230612.114412]
[08:48:25.257] [main/INFO] [Launcher/MODLAUNCHER]: ModLauncher 10.0.10+10.0.10+main.22f00f84 starting: java version 17.0.8 by Eclipse Adoptium; OS Windows 11 arch amd64 version 10.0
[08:48:25.669] [main/INFO] [loading.ImmediateWindowHandler/]: Loading ImmediateWindowProvider fmlearlywindow
[08:48:26.126] [main/INFO] [EARLYDISPLAY/]: Trying GL version 4.6
[08:48:26.367] [main/INFO] [EARLYDISPLAY/]: Requested GL version 4.6 got version 4.6
[08:48:26.911] [main/INFO] [mixin/]: SpongePowered MIXIN Subsystem Version=0.8.5 Source=union:/E:/.gradle/caches/modules-2/files-2.1/org.spongepowered/mixin/0.8.5/9d1c0c3a304ae6697ecd477218fa61b850bf57fc/mixin-0.8.5.jar%23128!/ Service=ModLauncher Env=CLIENT
FATAL ERROR in native method: Thread[pool-2-thread-1,5,main]: No context is current or a function that is not available in the current context was called. The JVM will abort execution.
at org.lwjgl.opengl.GL11C.nglGetString([email protected]+7/Native Method)
at org.lwjgl.opengl.GL11C.glGetString([email protected]+7/GL11C.java:978)
at net.minecraftforge.fml.earlydisplay.DisplayWindow.initRender([email protected]/DisplayWindow.java:206)
at net.minecraftforge.fml.earlydisplay.DisplayWindow.lambda$start$9([email protected]/DisplayWindow.java:290)
at net.minecraftforge.fml.earlydisplay.DisplayWindow$$Lambda$453/0x000002c8e422eff0.run([email protected]/Unknown Source)
at java.util.concurrent.Executors$RunnableAdapter.call([email protected]/Executors.java:539)
at java.util.concurrent.FutureTask.run([email protected]/FutureTask.java:264)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run([email protected]/ScheduledThreadPoolExecutor.java:304)
at java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.java:1136)
at java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.java:635)
at java.lang.Thread.run([email protected]/Thread.java:833)

Process finished with exit code 1
`

I tried to ask for help in discord channel, only response I got was people telling me that the display adapter is not letting open gl to work! they assumed I had onboard display adapter that was interfering and it's not the case, I had no other choice but to ask for help here.
Here is what I know, I use atlauncher for vanilla game, when I set the params to use windows opengl stuff, it won't work, but when I uncheck the setting and let the launcher use the gl stuff from minecraft, the game comes up and works. so I know somehow the graphic card is letting the gl library to run and also, my nvidia driver is up to date (checked before posting this issue), so lack of updates is not an issue there.
Please help, if this error is not solved, my only option will be to build the mod, manually replace it in an instance of atlauncher, run the game there, and back to modding. That would be a hell.

PlayerDestroyItemEvent doesn't trigger for Fishing Rods

Minecraft Version: 1.20.1

Forge Version: 47.1.0

Logs: None

Steps to Reproduce:

1. Subscribe to PlayerDestroyItemEvent
2. /give @p fishing_rod{Damage:200}
3. Use and retrieve the bobber
4. The event is not triggered

Description of issue:
As the title says, PlayerDestroyItemEvent is not triggered for Fishing Rods.

Issue cloned from MinecraftForge

Comment from ChampionAsh5357:

The event mentions it should be triggered on ServerPlayerGameMode#useItem; however, it isn't. While the event is called on the client, as the fishing rod is only removed on the server, it has no understanding that the item has changed. It looks like the change was never implemented server side, so I'm not sure why this was mentioned.

Regardless, it can be fixed by implementing the event within ServerPlayerGameMode#useItem, probably within the ItemStack#isEmpty check.

Confirmed by MCStreetguy that the issue applies to 1.20.1 too

[Suggestion] Add one-liner way to register builtin resourcepacks for mods

A while ago, I wanted to add an optional builtin resourcepack for my mod that users can enable on their own like how Minecraft has a programmer art builtin resourcepack. I was then shown this is how that is done:
https://github.com/MinecraftForge/MinecraftForge/blob/1.19.x/src/test/java/net/minecraftforge/debug/AddPackFinderEventTest.java

My thought is I feel like this could be simplified to a one liner registration for modders. Here’s the idea of such a system:

• Modders creates a folder called resourcepacks in their mod’s resources folder.
• Then the modder puts the resourcepack they want to use into that resourcepacks folder.
• Now the modder calls a single line while giving it a resourcelocation where the namespace is the modid of the mod’s resourcepacks folder to look under and the path is the name of resource pack itself to load as a built-in resourcepack.

Something like:
event.registerResourcePack(new ResourceLocation(“modid”, “packfilename”), PackActivationType.DISABLED_DEFAULT, Component.literal(“Display Name Of Resourcepack”));

This may be easier for people to find and use as the current code to make builtin resourcepacks looks tricky to figure out on our own without asking in the Neoforged discord. I had asked in another discord earlier and two people gave me incorrect/even more complex solutions which seems to show that this system is not well known. A simpler API may go a long way

Resolving Tag Errors do not include the Tag Identifier but double prints the unresolved entries

Minecraft Version: 1.19-1.20.1

Forge Version: 41.0.1 and Up

Description of issue:
Error output for unresolved entries within tags are doubled printed due to the patch adjusting the first parameter of the log message to not be the Tag's ResourceLocation within the TagLoader.java.patch: Link

Server Failure to Start - Duplicate key

Minecraft Version: 1.20.1

Neo Forge Version: forge-1.20.1-47.1.28-installer

Logs: Installer log: https://gist.github.com/AzureDoom/fd41749aca4121c446f18056dcb90c6c

Steps to Reproduce:

1. Run installer
2. Extract server files to new folder
3. Try and Start server

Description of issue:
Trying to launch server files (run.bat ) gives:

Exception in thread "main" java.lang.IllegalStateException: Duplicate key C:\Users\AzureZhen\Desktop\New folder\libraries\net\neoforged\fancymodloader\loader\47.1.41\loader-47.1.41.jar (attempted merging values EmbeddedFileSystemMetadata[path=C:\Users\AzureZhen\Desktop\New folder\libraries\net\neoforged\fancymodloader\loader\47.1.41\loader-47.1.41.jar, fs=C:\Users\AzureZhen\Desktop\New folder\libraries\net\neoforged\fancymodloader\loader\47.1.41\loader-47.1.41.jar, fsCh=sun.nio.ch.FileChannelImpl@38bc8ab5] and EmbeddedFileSystemMetadata[path=C:\Users\AzureZhen\Desktop\New folder\libraries\net\neoforged\fancymodloader\loader\47.1.41\loader-47.1.41.jar, fs=C:\Users\AzureZhen\Desktop\New folder\libraries\net\neoforged\fancymodloader\loader\47.1.41\loader-47.1.41.jar, fsCh=sun.nio.ch.FileChannelImpl@687080dc])
        at java.base/java.util.stream.Collectors.duplicateKeyException(Collectors.java:135)
        at java.base/java.util.stream.Collectors.lambda$uniqKeysMapAccumulator$1(Collectors.java:182)
        at java.base/java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
        at java.base/java.util.stream.Streams$StreamBuilderImpl.forEachRemaining(Streams.java:411)
        at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
        at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:276)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
        at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
        at java.base/java.util.AbstractList$RandomAccessSpliterator.forEachRemaining(AbstractList.java:720)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
        at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
        at cpw.mods.securejarhandler/cpw.mods.niofs.union.UnionFileSystem.<init>(UnionFileSystem.java:131)
        at cpw.mods.securejarhandler/cpw.mods.niofs.union.UnionFileSystemProvider.newFileSystemInternal(UnionFileSystemProvider.java:115)
        at cpw.mods.securejarhandler/cpw.mods.niofs.union.UnionFileSystemProvider.newFileSystem(UnionFileSystemProvider.java:105)
        at cpw.mods.securejarhandler/cpw.mods.jarhandling.impl.Jar.<init>(Jar.java:84)
        at cpw.mods.securejarhandler/cpw.mods.jarhandling.SecureJar.from(SecureJar.java:70)
        at cpw.mods.securejarhandler/cpw.mods.jarhandling.SecureJar.from(SecureJar.java:62)
        at cpw.mods.securejarhandler/cpw.mods.jarhandling.SecureJar.from(SecureJar.java:54)
        at [email protected]/cpw.mods.bootstraplauncher.BootstrapLauncher.lambda$main$6(BootstrapLauncher.java:99)
        at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
        at java.base/java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:357)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:510)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
        at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
        at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
        at [email protected]/cpw.mods.bootstraplauncher.BootstrapLauncher.main(BootstrapLauncher.java:93)

[Feature Req] add yarn/ fabric compatibility

as simple as that. i want to see both fabric and neoforge to stop barking at each other.. now that the project is under new (hopefully) Non monopolized management.

Removing Mods or Datapacks with Custom Dimensions Makes Worlds Unusable

Minecraft Version: 1.20.1

Forge Version: 47.0.35 (Forge, not NeoForge)

Steps to Reproduce:

1. Add a mod that adds a new custom dimension, such as my mod Dimensional Dungeons.
2. Enter an existing world or create a new one. (Single player.)
3. Save and quit.
4. Navigate to /mods and remove the mod jar.
5. Attempt to enter the same world as step 2.

Description of issue:
Attempting the load the world causes an error message to appear, The player is then given the choice to use Safe Mode instead, but this fails and the player is returned to the title screen. The only fix is to reinstall the mod.

Other notes:
According to the Mojira bugtracker this issue has regressed in 1.19.3 for vanilla datapacks. Additionally I found a closed ticket on the Forge tracker which seems to prove that this very issue was fixed in 1.19 and also backported to 1.18.2. However it seems like something has changed more recently to undo that fix and cause the issue to regress.

[1.19-1.20.x] Submitted chat event incompatible with jarInJar

Minecraft Version: 1.19 and 1.20

Forge Version: 43.2.20

Description of issue:
I noticed that the chat decorator works in ForkJoinPool, instead of using own ExecutorService. As an example, you can see the chat filtering that works in Util.ioPool() (IO Worker) The reason why I created this Issue is that I use the chat event processing, which is processed in ForkJoinPool. In addition, I have JarInJar dependencies that fall into the ForkJoinPool and hence causing the ClassNotFoundException error. Most likely, this will not solve the context problem for my mod, but it will help avoid other problems with ForkJoinPool overflow and in general it will meet the requirements of Java.

ModLauncher bootstrap is very slow in large packs

The ModLauncher bootstrap process seems to be very slow in large packs (e.g. ATM8), taking ~20 seconds on my machine before control is finally handed over to actually setting up mixins and launching the game. Most of this time appears to be getting spent in the SecureJar/module code. I am not sure if gains are possible here or if there are limitations in the JVM itself.

I've attached an NPS profile of this stage of the launch for further analysis. It should be possible to open this in VisualVM or YourKit.

43_2_13_early.nps.zip

Some notes:

• java.lang.module.Configuration.resolveAndBind seems to be taking a long time, accounting for 7.5 seconds out of the total 26.
• The package walking done in cpw.mods.jarhandling.Jar.getPackages is very slow, accounting for 8.5 seconds out of the total 26.

This profiling was done on a Linux system so slow Windows IO isn't the culprit here.

IllegalStateException: Failed to find system mod: minecraft

Minecraft Version: 1.20.1

Forge Version: 47.1.8

Logs:

[17:27:09.656] [main/INFO] [Launcher/MODLAUNCHER]: ModLauncher running: args [--username, Color_yr, --version, 1.20.1, --gameDir, E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft\instances\game\.minecraft, --assetsDir, E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/assets, --assetIndex, 5, --uuid, b4ed2f52c80e320aa6711a195fecb8a6, --accessToken, ????????, --clientId, ${clientid}, --xuid, ${auth_xuid}, --userType, legacy, --versionType, ColorMC, --launchTarget, forgeclient, --fml.forgeVersion, 47.1.8, --fml.fmlVersion, 47.1.37, --fml.mcVersion, 1.20.1, --fml.mcpVersion, 20230612.114412, --width, 1280, --height, 720] 
[17:27:09.661] [main/INFO] [Launcher/MODLAUNCHER]: ModLauncher 10.0.9+10.0.9+main.dcd20f30 starting: java version 17.0.3.1 by Oracle Corporation; OS Windows 11 arch amd64 version 10.0 
[17:27:09.842] [main/INFO] [loading.ImmediateWindowHandler/]: Loading ImmediateWindowProvider fmlearlywindow 
[17:27:09.990] [main/INFO] [EARLYDISPLAY/]: Trying GL version 4.6 
[17:27:10.268] [main/INFO] [EARLYDISPLAY/]: Requested GL version 4.6 got version 4.6 
[17:27:10.407] [main/INFO] [mixin/]: SpongePowered MIXIN Subsystem Version=0.8.5 Source=union:/E:/code/ColorMC/src/ColorMC.Launcher/bin/Debug/net7.0/minecraft/libraries/org/spongepowered/mixin/0.8.5/mixin-0.8.5.jar%23154!/ Service=ModLauncher Env=CLIENT 
[17:27:10.496] [pool-2-thread-1/INFO] [EARLYDISPLAY/]: GL info: NVIDIA GeForce RTX 3070 Laptop GPU/PCIe/SSE2 GL version 4.6.0 NVIDIA 531.79, NVIDIA Corporation 
[17:27:10.792] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "client-1.20.1-20230612.114412-srg.jar" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4647881c 
[17:27:10.793] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "forge-1.20.1-47.1.8-universal.jar" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4647881c 
[17:27:10.803] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "events-47.1.37.jar" of type GAMELIBRARY with provider net.minecraftforge.fml.loading.moddiscovery.BuiltinGameLibraryLocator@1fcf9739 
[17:27:10.852] [main/INFO] [loading.moddiscovery.JarInJarDependencyLocator/]: No dependencies to load found. Skipping! 
[17:27:10.919] [main/ERROR] [loading.LanguageLoadingProvider/LOADING]: Missing language minecraft version 1 wanted by client-1.20.1-20230612.114412-srg.jar 
[17:27:10.920] [main/ERROR] [loading.LanguageLoadingProvider/LOADING]: Missing language javafml version [24,] wanted by forge-1.20.1-47.1.8-universal.jar 
Exception in thread "main" java.lang.IllegalStateException: Failed to find system mod: minecraft
	at MC-BOOTSTRAP/[email protected]/net.minecraftforge.fml.loading.ModSorter.detectSystemMods(ModSorter.java:181)
	at MC-BOOTSTRAP/[email protected]/net.minecraftforge.fml.loading.ModSorter.buildUniqueList(ModSorter.java:145)
	at MC-BOOTSTRAP/[email protected]/net.minecraftforge.fml.loading.ModSorter.sort(ModSorter.java:53)
	at MC-BOOTSTRAP/[email protected]/net.minecraftforge.fml.loading.moddiscovery.ModValidator.stage2Validation(ModValidator.java:98)
	at MC-BOOTSTRAP/[email protected]/net.minecraftforge.fml.loading.FMLLoader.completeScan(FMLLoader.java:172)
	at MC-BOOTSTRAP/[email protected]/net.minecraftforge.fml.loading.FMLServiceProvider.completeScan(FMLServiceProvider.java:91)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.TransformationServiceDecorator.onCompleteScan(TransformationServiceDecorator.java:174)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.TransformationServicesHandler.lambda$triggerScanCompletion$24(TransformationServicesHandler.java:145)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1779)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
	at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.TransformationServicesHandler.triggerScanCompletion(TransformationServicesHandler.java:147)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.Launcher.run(Launcher.java:95)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.Launcher.main(Launcher.java:78)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:26)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:23)
	at [email protected]/cpw.mods.bootstraplauncher.BootstrapLauncher.main(BootstrapLauncher.java:141)

Command line

-XX:+UseG1GC
-Xms512m
-Xmx4096m
-Dforgewrapper.librariesDir=E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries
-Dforgewrapper.installer=E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/neoforged/forge/1.20.1-47.1.8/forge-1.20.1-47.1.8-installer.jar
-Dforgewrapper.minecraft=E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft\libraries\net\minecraft\client\1.20.1\client-1.20.1.jar
-XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump
-Djava.library.path=E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/native-windows-x64/1.20.1
-Djna.tmpdir=E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/native-windows-x64/1.20.1
-Dorg.lwjgl.system.SharedLibraryExtractPath=E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/native-windows-x64/1.20.1
-Dio.netty.native.workdir=E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/native-windows-x64/1.20.1
-Dminecraft.launcher.brand=ColorMC
-Dminecraft.launcher.version=A19.1.20230709
-cp
E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.3.1/lwjgl-tinyfd-3.3.1-natives-windows.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/io/netty/netty-transport/4.1.82.Final/netty-transport-4.1.82.Final.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-glfw/3.3.1/lwjgl-glfw-3.3.1-natives-windows.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-stb/3.3.1/lwjgl-stb-3.3.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-opengl/3.3.1/lwjgl-opengl-3.3.1-natives-windows-x86.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/mojang/logging/1.1.1/logging-1.1.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl/3.3.1/lwjgl-3.3.1-natives-windows.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl/3.3.1/lwjgl-3.3.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-opengl/3.3.1/lwjgl-opengl-3.3.1-natives-windows-arm64.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-opengl/3.3.1/lwjgl-opengl-3.3.1-natives-windows.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-openal/3.3.1/lwjgl-openal-3.3.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.3.1/lwjgl-jemalloc-3.3.1-natives-windows-x86.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.3.1/lwjgl-jemalloc-3.3.1-natives-windows-arm64.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-glfw/3.3.1/lwjgl-glfw-3.3.1-natives-windows-x86.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-glfw/3.3.1/lwjgl-glfw-3.3.1-natives-windows-arm64.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/ibm/icu/icu4j/71.1/icu4j-71.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/slf4j/slf4j-api/2.0.1/slf4j-api-2.0.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl/3.3.1/lwjgl-3.3.1-natives-windows-x86.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl/3.3.1/lwjgl-3.3.1-natives-windows-arm64.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.3.1/lwjgl-tinyfd-3.3.1-natives-windows-x86.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.3.1/lwjgl-tinyfd-3.3.1-natives-windows-arm64.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.3.1/lwjgl-tinyfd-3.3.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-stb/3.3.1/lwjgl-stb-3.3.1-natives-windows-x86.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-stb/3.3.1/lwjgl-stb-3.3.1-natives-windows-arm64.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-stb/3.3.1/lwjgl-stb-3.3.1-natives-windows.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-opengl/3.3.1/lwjgl-opengl-3.3.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-openal/3.3.1/lwjgl-openal-3.3.1-natives-windows-x86.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-openal/3.3.1/lwjgl-openal-3.3.1-natives-windows-arm64.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-openal/3.3.1/lwjgl-openal-3.3.1-natives-windows.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.3.1/lwjgl-jemalloc-3.3.1-natives-windows.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.3.1/lwjgl-jemalloc-3.3.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/lwjgl/lwjgl-glfw/3.3.1/lwjgl-glfw-3.3.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/joml/joml/1.10.5/joml-1.10.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/apache/logging/log4j/log4j-slf4j2-impl/2.19.0/log4j-slf4j2-impl-2.19.0.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/apache/logging/log4j/log4j-core/2.19.0/log4j-core-2.19.0.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/apache/logging/log4j/log4j-api/2.19.0/log4j-api-2.19.0.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/apache/httpcomponents/httpcore/4.4.15/httpcore-4.4.15.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/apache/httpcomponents/httpclient/4.5.13/httpclient-4.5.13.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/apache/commons/commons-compress/1.21/commons-compress-1.21.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/sf/jopt-simple/jopt-simple/5.0.4/jopt-simple-5.0.4.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/java/dev/jna/jna/5.12.1/jna-5.12.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/java/dev/jna/jna-platform/5.12.1/jna-platform-5.12.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/it/unimi/dsi/fastutil/8.5.9/fastutil-8.5.9.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/io/netty/netty-transport-native-unix-common/4.1.82.Final/netty-transport-native-unix-common-4.1.82.Final.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/io/netty/netty-transport-classes-epoll/4.1.82.Final/netty-transport-classes-epoll-4.1.82.Final.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/io/netty/netty-resolver/4.1.82.Final/netty-resolver-4.1.82.Final.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/io/netty/netty-handler/4.1.82.Final/netty-handler-4.1.82.Final.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/io/netty/netty-common/4.1.82.Final/netty-common-4.1.82.Final.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/io/netty/netty-codec/4.1.82.Final/netty-codec-4.1.82.Final.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/io/netty/netty-buffer/4.1.82.Final/netty-buffer-4.1.82.Final.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/commons-logging/commons-logging/1.2/commons-logging-1.2.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/commons-codec/commons-codec/1.15/commons-codec-1.15.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/mojang/text2speech/1.17.9/text2speech-1.17.9.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/mojang/patchy/2.2.10/patchy-2.2.10.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/mojang/datafixerupper/6.0.8/datafixerupper-6.0.8.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/mojang/brigadier/1.1.8/brigadier-1.1.8.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/mojang/blocklist/1.0.10/blocklist-1.0.10.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/mojang/authlib/4.0.43/authlib-4.0.43.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/google/code/gson/gson/2.10/gson-2.10.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/github/oshi/oshi-core/6.2.2/oshi-core-6.2.2.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/neoforged/forge/1.20.1-47.1.8/forge-1.20.1-47.1.8-universal.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/neoforged/fancymodloader/loader/47.1.37/loader-47.1.37.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/neoforged/fancymodloader/earlydisplay/47.1.37/earlydisplay-47.1.37.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/cpw/mods/securejarhandler/2.1.10/securejarhandler-2.1.10.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm/9.5/asm-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm-commons/9.5/asm-commons-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm-tree/9.5/asm-tree-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm-util/9.5/asm-util-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm-analysis/9.5/asm-analysis-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/accesstransformers/8.0.4/accesstransformers-8.0.4.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/antlr/antlr4-runtime/4.9.1/antlr4-runtime-4.9.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/eventbus/6.0.5/eventbus-6.0.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/forgespi/7.0.1/forgespi-7.0.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/coremods/5.0.1/coremods-5.0.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/cpw/mods/modlauncher/10.0.9/modlauncher-10.0.9.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/unsafe/0.2.0/unsafe-0.2.0.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/mergetool/1.1.5/mergetool-1.1.5-api.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/electronwill/night-config/core/3.6.4/core-3.6.4.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/com/electronwill/night-config/toml/3.6.4/toml-3.6.4.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/apache/maven/maven-artifact/3.8.5/maven-artifact-3.8.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/jodah/typetools/0.6.3/typetools-0.6.3.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecrell/terminalconsoleappender/1.2.0/terminalconsoleappender-1.2.0.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/jline/jline-reader/3.12.1/jline-reader-3.12.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/jline/jline-terminal/3.12.1/jline-terminal-3.12.1.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/spongepowered/mixin/0.8.5/mixin-0.8.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/openjdk/nashorn/nashorn-core/15.3/nashorn-core-15.3.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/JarJarSelector/0.3.19/JarJarSelector-0.3.19.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/JarJarMetadata/0.3.19/JarJarMetadata-0.3.19.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/cpw/mods/bootstraplauncher/1.1.2/bootstraplauncher-1.1.2.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/JarJarFileSystems/0.3.19/JarJarFileSystems-0.3.19.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/neoforged/fancymodloader/events/47.1.37/events-47.1.37.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/neoforged/fancymodloader/core/47.1.37/core-47.1.37.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/neoforged/fancymodloader/language-java/47.1.37/language-java-47.1.37.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/neoforged/fancymodloader/language-lowcode/47.1.37/language-lowcode-47.1.37.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/neoforged/fancymodloader/language-minecraft/47.1.37/language-minecraft-47.1.37.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/io/github/zekerzhayard/ForgeWrapper/mmc3/ForgeWrapper-mmc3.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft\libraries\net\minecraft\client\1.20.1\client-1.20.1.jar
-Djava.net.preferIPv6Addresses=system
-DignoreList=bootstraplauncher,securejarhandler,asm-commons,asm-util,asm-analysis,asm-tree,asm,JarJarFileSystems,events-47.1.37.jar,core-47.1.37.jar,language-java,language-lowcode,language-minecraft,client-extra,forge-,1.20.1.jar
-DmergeModules=jna-5.10.0.jar,jna-platform-5.10.0.jar
-Dfml.pluginLayerLibraries=core-47.1.37.jar;language-java-47.1.37.jar;language-lowcode-47.1.37.jar;language-minecraft-47.1.37.jar
-Dfml.gameLayerLibraries=events-47.1.37.jar
-DlibraryDirectory=E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries
-p
E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/cpw/mods/bootstraplauncher/1.1.2/bootstraplauncher-1.1.2.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/cpw/mods/securejarhandler/2.1.10/securejarhandler-2.1.10.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm-commons/9.5/asm-commons-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm-util/9.5/asm-util-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm-analysis/9.5/asm-analysis-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm-tree/9.5/asm-tree-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/org/ow2/asm/asm/9.5/asm-9.5.jar;E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/libraries/net/minecraftforge/JarJarFileSystems/0.3.19/JarJarFileSystems-0.3.19.jar
--add-modules
ALL-MODULE-PATH
--add-opens
java.base/java.util.jar=cpw.mods.securejarhandler
--add-opens
java.base/java.lang.invoke=cpw.mods.securejarhandler
--add-exports
java.base/sun.security.util=cpw.mods.securejarhandler
--add-exports
jdk.naming.dns/com.sun.jndi.dns=java.naming
cpw.mods.bootstraplauncher.BootstrapLauncher
--username
test
--version
1.20.1
--gameDir
E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft\instances\game\.minecraft
--assetsDir
E:\code\ColorMC\src\ColorMC.Launcher\bin\Debug\net7.0\minecraft/assets
--assetIndex
5
--uuid
****************
--accessToken
****************
--clientId
${clientid}
--xuid
${auth_xuid}
--userType
legacy
--versionType
ColorMC
--launchTarget
forgeclient
--fml.forgeVersion
47.1.8
--fml.fmlVersion
47.1.37
--fml.mcVersion
1.20.1
--fml.mcpVersion
20230612.114412
--width
1280
--height
720

Steps to Reproduce:

1. Install NeoForge
2. Run game

Description of issue:

Addition of MINABLE_WITH_SHEARS blocks tag

Hello,

I would like to request the inclusion of a MINEABLE_WITH_SHEARS block tag to be included officially with baseline Forge (or NeoForge as it's now known). Currently, the only way to reliably add a block that the shears can mine is by adding it to either BlockTags.LEAVES or to BlockTags.WOOL (or some cursed Mixin you get the idea). This of course has the downside of adding blocks to those tags and potentially giving them unwanted behavior, especially with crafting and world interaction. As all the other tools have such a tag, it makes sense that the shears would have its own mining tag too. I would be willing to implement the feature and pull it if needed.

[1.20.x] RegistryDataLoader conditions patch is in the wrong location

JsonElement jsonelement = JsonParser.parseReader(reader);
DataResult<E> dataresult = pDecoder.parse(registryops, jsonelement);
   if (!net.minecraftforge.common.crafting.conditions.ICondition.shouldRegisterEntry(jsonelement)) continue;

This placement causes the object to still be deserialized, which can create Holders as a side effect, which then crash as they will not be filled out. It should be one line up.

Update/promotions URL does not exist

Minecraft Version: 1.20.1

NeoForge Version: upstream

Steps to Reproduce:

1. Start Minecraft
2. Look at the log

Description of issue:
The update URL is set to "https://maven.neoforged.net/releases/net/neoforged/forge/promotions_slim.json", which is correct I guess, but the file doesn't exist at the moment. Because of that, there's a stacktrace each start of the game.

I know, other things have priority. Just wanted to report that, so it won't be forgotten :)

ForgeConfigSpec worldRestart is unused

Minecraft Version: 1.20.1

Forge Version: 47.1.8

Steps to Reproduce:

1. View uses of ForgeConfigSpec.ValueSpec#needsWorldRestart
2. See that there are none and that the value isn't even passed/accessible via ConfigValue

Description of issue:

The concept of certain config values needing a world restart in order for the config value changes to be updated/synced never got hooked back up again post 1.12. Given the fact that at some point support for config value caching got added it would make sense to only invalidate the cached values for entries that need a world restart when the config unloads (server is closed aka world restarts).

Error log enhancements.

In the logs error logs for when a mod is incompatible it would be nice either at the end of the log or beginning it would tell you what went wrong if there are dependencies missing or what is incompatible.

Plan for optional tag functionality

This issue documents the resolution to the problem of using tags for game logic where vanilla does not.
Relevant discussion thread: https://discord.com/channels/313125603924639766/1134501578548715632

Problem

Using tags for game logic that does not normally use tags may cause desyncs between forge and vanilla in the following scenarios:

1. Forge Client to Vanilla Server
   a. Desyncs may occur when forge introduces new tags that are not supplied by the vanilla server.
   b. Desyncs may occur when a vanilla datapack updates vanilla tags the forge client uses for extended functionality.
2. Vanilla Client to Forge Server
   a. Desyncs may occur when a vanilla datapack updates vanilla tags that are being used for extended functionality.
   b. Desyncs may occur when a forge datapack updates forge tags that are being used for extended functionality.

Solution

Fallback Tags

The solution to problem (1a) is to utilize Fallback Tags, which are tags loaded on the client whenever a tag is not supplied by the server.
These are currently implemented in a limited fashion - fallback tags consist of a hardcoded object list which is injected after tag load.

A proper solution would be to load specific tags (those marked as requiring a fallback, defaulting to any tag outside of the minecraft namespace) from client mod datapacks if not supplied by the server. Such functionality would also mean that fallback tags could reference other tags instead of only a static object list, and would be available for dynamic objects (like biomes).

Strict Vanilla Compatibility Mode

The solution to problems (1b), (2a), and (2b) is to introduce a strict vanilla compatibility mode. This would be used to guard checking extended functionality, though the following pattern:

    protected boolean mayPlaceOn(BlockState pState, BlockGetter pLevel, BlockPos pPos)
    {
-       return pState.is(BlockTags.DIRT) || pState.is(Blocks.FARMLAND);
+       bool ret = pState.is(BlockTags.DIRT) || pState.is(Blocks.FARMLAND);
+       return net.minecraftforge.common.VanillaCompat.isStrict() ? ret : pState.is(net.minecraftforge.common.Tags.Blocks.PLAINS_SOILS);
    }

The default state of VanillaCompat.isStrict would be true, but can be changed in the following manners:

1. Server Config - A Forge Server may opt to disable strict vanilla compat for any reason.
2. Mod Installation - A mod may forcibly disable strict vanilla compat. The server bears the risk of installing such mods.
3. Registry Checks - Installing any content mod that adds content which would prevent vanilla connections would disable strict mode.

This field would be controlled by the server - forge clients would utilize the same mechanism in singleplayer, but would always have strict mode enabled when connected to a vanilla server.

Face Data is only currently data genned per face rather than also per element

Minecraft Version: 1.20.1

Forge Version: 47.1.3

Steps to Reproduce:

1. Create a block model for data gen.
2. Add something like .color(0xFFFF2233) to set the color for the element (not the face)
3. Set a break point in ModelBuilder where it returns the root json (should be ~L356).
4. Inspect the result. Currently there is no should be no color set despite one being set above.

Description of issue:
Basically the forge data is read in (or least indicates it in the documentation to be read in) per element as well as per face. However, despite having a data gen methods for setting the values per element, no where does it encode it to the JSON output. It only does so for the face. There probably need to be some checks against the default.

In the linked data gen model builder, there should be a reference to part.getFaceData().

NeoForge/src/main/java/net/minecraftforge/client/model/generators/ModelBuilder.java

Lines 293 to 343 in c3b3b66

	JsonArray elements = new JsonArray();
	this.elements.stream().map(ElementBuilder::build).forEach(part -> {
	JsonObject partObj = new JsonObject();
	partObj.add("from", serializeVector3f(part.from));
	partObj.add("to", serializeVector3f(part.to));
	if (part.rotation != null) {
	JsonObject rotation = new JsonObject();
	rotation.add("origin", serializeVector3f(part.rotation.origin()));
	rotation.addProperty("axis", part.rotation.axis().getSerializedName());
	rotation.addProperty("angle", part.rotation.angle());
	if (part.rotation.rescale()) {
	rotation.addProperty("rescale", part.rotation.rescale());
	}
	partObj.add("rotation", rotation);
	}
	if (!part.shade) {
	partObj.addProperty("shade", part.shade);
	}
	JsonObject faces = new JsonObject();
	for (Direction dir : Direction.values()) {
	BlockElementFace face = part.faces.get(dir);
	if (face == null) continue;
	JsonObject faceObj = new JsonObject();
	faceObj.addProperty("texture", serializeLocOrKey(face.texture));
	if (!Arrays.equals(face.uv.uvs, part.uvsByFace(dir))) {
	faceObj.add("uv", new Gson().toJsonTree(face.uv.uvs));
	}
	if (face.cullForDirection != null) {
	faceObj.addProperty("cullface", face.cullForDirection.getSerializedName());
	}
	if (face.uv.rotation != 0) {
	faceObj.addProperty("rotation", face.uv.rotation);
	}
	if (face.tintIndex != -1) {
	faceObj.addProperty("tintindex", face.tintIndex);
	}
	if (!face.getFaceData().equals(ForgeFaceData.DEFAULT)) {
	faceObj.add("forge_data", ForgeFaceData.CODEC.encodeStart(JsonOps.INSTANCE, face.getFaceData()).result().get());
	}
	faces.add(dir.getSerializedName(), faceObj);
	}
	if (!part.faces.isEmpty()) {
	partObj.add("faces", faces);
	}
	elements.add(partObj);
	});
	root.add("elements", elements);

I would assume something like the following at say line 309 might be along the correct lines, but I am uncertain.

  if (!part.getFaceData().equals(ForgeFaceData.DEFAULT)) { 
             partObj.add("forge_data", ForgeFaceData.CODEC.encodeStart(JsonOps.INSTANCE, part.getFaceData()).result().get()); 
         } 

Forge rebuilds blockstate cache on every registry bake

Forge (and by extension NeoForge) currently rebuilds all blockstates' shape caches inside the block registry's onBake callback:

NeoForge/src/main/java/net/minecraftforge/registries/GameData.java

Lines 492 to 496 in ed6d3e5

	for (BlockState state : block.getStateDefinition().getPossibleStates())
	{
	blockstateMap.add(state);
	state.initCache();
	}

The issue is that baking can occur multiple times during the launch process, which leads to a lot of unnecessary work during startup as this cache is rebuilt multiple times over.

An attempt was previously made to solve this in MinecraftForge/MinecraftForge#7496, but was shot down due to compatibility concerns. It is not really clear to me what mods that change would break though, as most if not all methods in the BlockState classes are designed to work without the cache being initialized, and the cache would be built by the time the server/client begin ticking anyway.

As a side note, the Mojang approach of building ALL shape caches at once is very inefficient and does not scale well to mods (since not all blocks are seen in the world right away). In ModernFix the current solution I've used to solve the issue is to simply implement dynamic cache building where the cache for a blockstate is only computed the first time it's accessed. The call to initCache is then replaced by setting an invalidation flag that triggers the cache to be rebuilt on next access. This has worked reliably with no reported issues, and completely eliminates the launch delay of building the cache up front.

`ForgeRegistry.add` slows down with more entries

Modern versions of Forge appear to call ForgeRegistry.add with an ID of -1 in most, if not all scenarios during block/item registration. This triggers a scan of the availabilityMap to find the first available ID:

NeoForge/src/main/java/net/minecraftforge/registries/ForgeRegistry.java

Line 404 in 5bfbe71

idToUse = availabilityMap.nextClearBit(min);

The problem is that the scan is always started from the minimum valid ID. In most cases (many registrations being done at once, without any removal of entries) this results in repeatedly scanning over every previously registered ID, which means each addition effectively runs in O(n) time, where n is the number of previously registered entries. When profiling large quantities of block/item registration I saw the call to nextClearBit as the main dominator.

The fix I used for the issue is to cache the previously returned bit and start the scan from there instead of the minimum ID. In cases where add is called without any other mutations, the behavior should be identical to the unoptimized version. The cache is invalidated whenever the availabilityMap is mutated in any other way, in order to force a full rescan and not change any behavior.

can't start minecraft

Minecraft Version: {1.20.1}

Forge Version: {forge-1.20.1-47.1.59}

Logs: {}

Steps to Reproduce:

1. installer the noforged
2. start game

Description of issue:
i can't start game
minecraft-exported-crash-info-2023-08-02T09-33-24.zip

[ 1.20.1 ] Neoforge server idle load (expectation) load it is more (5000 ms)

Minecraft Version: 1.20.1

Forge Version: 47.1.76

Logs: spark
https://gist.github.com/steam9w/8ea233148b20e34e45fca3a2c67aab31

Steps to Reproduce:
NO MODS SERVER
New World
SERVER 1.20.1
neoforge server idle load (expectation) load it is more (5000 ms)
vanilla server minecraft (0.500 ms)

Description of issue:

1.7.10 support?

Look, I know you have your position on this, but 1.7.10 is still actively modded far more than many recent versions, and there are things that could be improved. Just sayin'.

ModConfigEvent can cause concurrency issues in mods

Forge fires ModConfigEvent.Loading when a config is first loaded, and ModConfigEvent.Reloading when a config reloads as a result of the file watcher detecting a change. However, there is no locking done in the function that posts these events, meaning that it is possible for both Loading and Reloading to fire simultaneously.

Many mods have ModConfigEvent event handlers that are not protected against this, and will therefore occasionally throw CMEs. This is technically a bug in those mods but I also think the design of this event is confusing/misleading - it really does not make sense for a config to load and reload at the exact same time.

ExcessiveAmountsOfZombies/Croptopia#517 is an example of this occuring in the wild; I patched it in ModernFix by wrapping the Forge function that posts the event with a wrapper that synchronizes on the underlying config object, ensuring that all mods will never see two config events posted concurrently.

Resource path being searched twice

Minecraft Version: 1.20.1

Forge Version: 47.1.3 (MCF)

Description of issue:

1.19.3 port introduced doubled call of pack.getResource(type, location)

side also: TextureManager patch is not needed, see fix on file line 5 of the patch

Will it support older versions of Minecraft?

Can you tell me if this NeoForge Modding API will support
Minecraft 1.6.4 ~ Minecraft 1.14

[1.19.2] Config deadlock

Forge 43.2.14

This can randomly occur when joining a world
(Even if you place all the server configs in the defaultconfigs directory - it can still try to check / correct some configs)

The config / mod it hangs seems to not be consistent (sometimes its mod A, sometimes mod B etc.)

I don't know if this can have an effect on the behaviour:

https://github.com/embeddedt/ModernFix/blob/1.19.2/forge/src/main/java/org/embeddedt/modernfix/forge/config/NightConfigFixer.java

Mod annotation scanner slows down launch

The Forge mod annotation scanner is rather slow and can take over 20 seconds to scan mods in a large enough modpack. A simple optimization that could improve this is to provide the flags that skip parsing code, debug info, and frames on this line.

-        cr.accept(mcv, 0);
+        cr.accept(mcv, ClassReader.SKIP_CODE | ClassReader.SKIP_DEBUG | ClassReader.SKIP_FRAMES);

I've tested this change in modpacks using an external agent, and it seems to give a free performance boost to the scanner without requiring any invasive changes. However, in the long term, it would also be prudent to consider caching this data rather than rescanning mods on each startup, as this is a waste of time. A cache might also allow retrieving the data from disk as needed instead of needing to permanently store many ModFileScanData objects, which wastes memory especially since many of the annotations might never be queried.

It possible to support Velocity?

We all know the Forge TEAM and Lex don't like Velocity or Waterfall bungee. But is it possible to support it in NeoForge?

I hope to add the ability to download and install mods from courseforge or modrinth and automatically restart MC

I hope Neofoged to add the ability to download and install mods from courseforge or modrinth and automatically restart MC,such as Winget,Modget,Apt-get and so on

[Bug] Air bubbles don't regen

Minecraft Version: 1.20.1

Forge Version: 47.1.54

Logs: N/A

Steps to Reproduce:

1. Open world in survival
2. Stay underwater a few seconds
3. Come above water
4. See issue

Description of issue: Because of the new events, air bubbles no longer regenerate once out of water...

PlayMessages.OpenContainer swallows exceptions during screen construction

Any exceptions thrown during the construction of a screen will be ignored entirely, and the screen will fail to open.
This is due to the following try/finally block not having a catch block, which causes the exception to vanish.
https://github.com/neoforged/NeoForge/blob/1.20.x/src/main/java/net/minecraftforge/network/PlayMessages.java#L297

[experimentalForgeLightPipelineEnabled] Tinted glass shadow (AO) is broken

experimentalForgeLightPipelineEnabled:

Vanilla:

Note: FabricMC/fabric#1708 ?

Will it be possible to be compatible with Fabric/Quilt in the future?

For a gamer, "The farthest distance in the world is not life and death, but the availability of mods you want to play, one only supporting Forge, and the other only supporting Fabric/Quilt."

Forge configs occasionally become corrupted

This is a continuation of MinecraftForge/MinecraftForge#9122.

After performing an analysis of the code Forge uses to interact with the Night Config library, I identified a design flaw which seems to have the potential for race conditions and corruption. In ConfigFileTypeHandler when a config is first registered and loaded, a file watcher is attached. Shortly after that method returns save is invoked on the config object. In summary, this can lead to the following sequence of events:

1. The CommentedFileConfig instance is built and the watcher is registered (the file on disk is now being watched for changes)
2. Forge code invokes config.save() which calls into Night Config to write to the file synchronously.
3. As part of the process of saving, Files.newOutputStream is invoked with the config file's path, which, according to the Javadoc, "initially [truncates] an existing regular-file to a size of 0 if it exists." I verified using a simple test program that, at least on Linux, the OutputStream given by this method is not atomic. The file is truncated immediately upon return of the method, and writes are seen in the underlying file even before the stream is closed.
4. Because Night Config's file watcher is asynchronous, it will detect any changes to the underlying file, regardless of whether or not saving has actually completed. That means it may see the fully truncated file, or a half-written file. In this scenario, attempting to read from the incomplete file is very likely to result in random errors when the system encounters some corrupted version.

When testing on 1.16, I was able to reliably observe symptoms similar to the theory I have described above - by augmenting the Forge file watcher's run function with my own, I confirmed that the currentlyWriting flag in WriteSyncFileConfig (the config class in NC responsible for saving) was still true when the watcher was invoked, indicating that saving is NOT completed before the watcher is fired.

I think fully fixing this will require a fundamental rethink of how the file watcher is used in Forge, as ideally it needs to never be listening when .save is called.

For completeness, here is a link to the Discord conversation in which I first brought up this new theory.

Mixin application order can be inconsistent between client and server

For some reason, Forge can apply mixins from individual mods in differing orders on the client and server.

An example of why this matters in the real world: some mods mix into vanilla entity classes and add custom EntityDataAccessor data values to be synced. Suppose both mod A and B add a custom data value field. Vanilla assigns these IDs based on the order of the fields in the class (since that is the order the values are registered in). It is possible for the mixins to be applied in the order A, B on the client and B, A on the server. This causes the field order to differ on each side, which means the data values are given different IDs on the server and client. This then leads to error spam/improperly synced entities when trying to play in multiplayer as the client receives incorrect data for each value.

That specific example could be solved by adding some type of event/more predictable ID system for mods to add custom EntityDataAccessor flags on entities, or by syncing the IDs to the client on server join (which is what I did in ModernFix), but it doesn't fix the issue that mods are already doing this, and there may be other mixins that subtly break as a result of this order difference.

I think something simple like sorting the mod list by ID would be a clean way to address this issue.

[1.20.2] Global Datapack Folder

Sort of as labeled, this would be a folder provided by Neoforge for loading in a global datapack.

As we move further towards datapackified everything, the bar for the end user to customize mods is becoming increasingly more difficult. The core issues with the existing datpack system are mostly in usability, but also the per-world nature of them.

As forge is largely played in cobbled together packs, any distributed pack almost always has a mod like Kubejs for providing a datapack that can be applied to any world.

Proposed solution:
Add a /neoforge folder at the top level that Neoforge loads in as a datapack. Overrides for mods would be added like any other datapack:
/neoforge/data/ars_nouveau/recipes
/neoforge/assets/ars_nouveau....

[1.20.x] Elytra Flight Attribute

Currently, enabling elytra flight requires an Item to override the flight method. Any other method of enabling flight with potions or abilities currenly requires several mixins. Forge already patches most of these methods to hook into the ForgeItem interface method.

There are 3 tiny mixins required to add Elytra flight via a potion: https://github.com/baileyholl/Ars-Nouveau/tree/1.20/src/main/java/com/hollingsworth/arsnouveau/common/mixin/elytra

The main issue with these mixins is that they easily conflict with other mods. Caelus, an API that provides an attribute for Elytra flight, also causes other mixin injections to fail on these points, requiring at least a soft check on the mod to provide compat.

Proposed solution:
Add a player attribute that uses the existing forge hooks to check for the ability to fly. This should be backwards compatible, as these hooks already exist at the required points.

[Feature Req] EntityMultiblockFormationEvent

The idea for this event is intercepting the point between the match of a BlockPattern and the creation of the target entity.

This would be used for Iron Golems, Snow Golems, and Withers, to either prevent, intercept, or manipulate the spawns.

Example hook point for iron golems:

         BlockPattern.BlockPatternMatch blockpattern$blockpatternmatch1 = this.getOrCreateIronGolemFull().find(pLevel, pPos);
         if (blockpattern$blockpatternmatch1 != null) {
            IronGolem irongolem = EntityType.IRON_GOLEM.create(pLevel);
            irongolem = ForgeEventFactory.entityMultiblockFormation(blockpatternmatch1, pLevel, pPos, irongolem);
            if (irongolem != null) {
               irongolem.setPlayerCreated(true);
               spawnGolemInWorld(pLevel, blockpattern$blockpatternmatch1, irongolem, blockpattern$blockpatternmatch1.getBlock(1, 2, 0).getPos());
            }
         }

Minecraft's title display position is incorrect

Minecraft Version: 1.20.1

Forge Version: 47.1.70

Logs: latest.log

Steps to Reproduce:

1. Automatically install NeoForge 47.1.70 using third-party launcher
2. Install JEI and JourneyMap mods
3. start games

Description of issue:
When the game was loading (small window), the Minecraft icon displayed an error and a portion was split to the right.