Jackson Perr

This is a good question! First off, I'd like to start by saying that you probably should NOT be rewriting the entire source code of another mod only to change so little. No offense, but it is a bit unorthodox, but in all honesty, if a mod is open source, and I can save the time from writing code to manipulate the mod FROM ANOTHER MOD, I'm downloadin' that source code, so I can't blame you too much for takin' the "easier" option 'cause then I'd be a bit of a hypocrite... However, if you don't want your time spent trying to rewrite the code to go to waste, you could just create a new mod project, copy the forge code for the backpack mod into your new project, and assemble the raw mod from there. But it seems that for some reason you want to push this mod as an artifact, which I honestly don't really see the point when it's just a mod for you and your friends, as you could just as easily slap that thing in ya' google drive and call it a day. Alternatively, you could make your own github repository and change the references in the gradle project to that instead, but this is probably the MOST unorthodox thing you could possibly do, and I honestly think that if you were to do this then Satan himself might personally drag you into hell. So to save yourself from eternal damnation, you might not want to do this. But from a more practical and orthodox standpoint, it is MUCH more appropriate to make a mod that modifies the code for the original mod in some way. There are two ways this can be done: the orthodox way and the unorthodox way. Let's start with the unorthodox way, as it's a lot easier to explain. Basically, you can change the code for another mod by making sure your mod loads in first into the JVM, which is easily done by just putting a bunch of "a"'s in the mods name. Next, find whatever piece of code you want to add in, and create a class with that same code in your mod with the exact same path as the class you wish to change (e.g. net.minecraft.entity.Entity if you wanted to change code in the entity class). The goal here is to trick the JVM into using your class instead of the original. This also means that you don't even have to do like any setup, not even including the backpacks mod as a dependency, so it's SUPER simple. However, this might not be that easy for you to do, because you mention that you need to change enums. I haven't looked too deep into the mods code, and by that I haven't actually looked at all, but if there is one thing I think I remember about enums, it's that they might be treated similar to CONSTANTS after compiling, which means that changing the enum class will have no effect because every usage of the enum is treated like putting in a constant number. If you choose the unorthodox route though, then I could be wrong, so it's still worth a shot. Finally, you have the proper orthodox way to do it, which is with an assembly transformer. If you don't want to go through the headache of having to set up your own bytecode transformer and learning java assembly bytecode, then I would recommend just using mixin. Basically, mixin or any other ASMTransformer are special tools that can be used to modify the code for certain classes. If you have used Harmony for c# or c++ unity mods, then it's much the same thing: give the transformer a class to do it's magic in, give it a function to use for it's magic, and tell it where to do it. For mixin, this is done by using the @Inject thingamabob (legitimately forgot wth this kind of thing was called). If you want examples of the ASMTransformer route and how to set it up, I would recommend looking at the source code for Galacticraft, as it uses transformers EXTENSIVELY. If you wish to use mixin, then there is extensive documentation on it's usage. Hope this helps!

You shouldn't completely remove a post after you find a solution, as it prevents anybody with a similar problem as you from finding a solution as well. Unless it was something REALLY dumb like "Guys, why does java keep telling me that 1 + 2 = 3, I mean, that's clearly not true." If it's something like that then you should ABSOLUTELY delete it. Not only is it EMBARASSING, but if any employer were to find out about it, let's just say you probably aren't gettin' that codin' gig.

I have only ever really seen things like this done with assemble transformers, for example in Galacticraft. If you would like to see an example, then I believe the Galacticraft source code is open on github. If not, then NTM-CE HBM 1.12.2 and techguns ore open on github and both also mess around the sky and sun. This is the best I can tell you for now, so I'm sorry if it's not very concise or helpful. But if I may ask, what do you mean by "two layer". Isn't the sun a single flat texture in the sky? Do you plan on putting a mask over it, thus making it two layer? Although what you mean by two layer sun is not very clear, I believe it is clear what you mean by custom sky. I would recommend you use gimp to make a TILEABLE sky map. If you already have a sky texture, then you should add it in to your assets folder for your mod as long as whatever else you need for what you want done with the sun. Again, this is the best advice I can offer for now.

If I remember correctly, I believe one of the rules, or maybe the faq, states something like, "This is not a java school, so make sure you know enough java." I think it's clear that you might not know enough java to accomplish the task you have set out to do (or not, I can't really say based solely on these two snippets of code that you seemed to have selected and modified), but whatever the case may be, I find this rule, or suggestion, whatever it is, to be really stupid in some cases. With that said, if you wish to save the data to the world, then with the code you have provided, I see no Event Handlers to do this with. I'm not sure if you know how to subscribe to event handlers with forge, but if you have your mod running in literally any capacity, then you should have done this with some methods in your main mod class container, otherwise how on earth is your mod gonna' work? So, I'm going to assume that you have gotten your mod to work in some capacity, if you haven't then please look into some more basic mod development, but I might also be able to help you out a little. Anyways, there is an event you can set up with one of your methods called "FMLServerStoppedEvent". I could have the wrong one, so you should probably look into the difference between "FMLServerStoppedEvent", and "FMLServerStoppingEvent", but either should work. The essential idea is to use this event with one of your methods, that way when the server stops, you can have a method called that will save all of your team data. Basically, you're going to want to write into your main mod class something that looks a little like this: @EventHandler public void serverStopHandler(FMLServerStoppedEvent event) { //Code to save team data }And, in case you haven't done this yet, you're of course going to use the FMLServerStartingEvent to load this data into your mod, so you can do something similar to the above. But if you already have a method to load the mod data, then this shouldn't be needed. Now, there are a number of mechanisms that you can use to save your data, one such method being to write the data into an nbtdata file and save it to the world folder, or writing it to some forgecaps and loading those forge caps through some other means. However, by far the simplest thing you could do would be to use a Buffer object to write and read data to and from a raw binary file saved directly to your server folder so it can be easily accessed. The first idea to accomplish this task would be to create a file that will contain your team save data if none exists, then open this file and either read your save data from it, or write your save data to it. Creating your file is as simple as importing the java.io.File class, creating a new instance of the file class with whatever name you want, for example, new File("teamsavedata.bin"), and using a FileOutputStream to write the bytes to the file, or if you need to read the bytes from the file, you should specifically use the java.io.Files class's Files.readAllBytes method. This takes a file path as one of its arguments. This can be acquired after you create an instance of java.io.File, you can simply use the toPath(), method on that instance. It is important that you use the readAllBytes method because it is not only very simple, but it returns the data in the file as a byte array, which fits the implementation of the ByteBuffer function. Now, the ByteBuffer function is what I think best for you to use to serialize (aka store as a series of numbers or bytes) the information contained within any simple class. NOTE: SIMPLE CLASS. Your Team class isn't exactly simple, but I will get into what you should do about that after I demonstrate serialization here. Now, the ByteBuffer class is very simple, but it does have some caveats that I will get into soon here. But for now, let's move on to actually serializing your data so that it can be written to your save data file. First off, you're going to want to add the methods "toBytes", and "fromBytes" into your Team class. These methods should take a ByteBuffer as an output and input respectively. That should be all they need. Now, ByteBuffers work by reading data from a byte array and spitting out the data. I think this is going to be best shown with some code, so lets imagine we have some class we want to turn into bytes, and it has a boolean, a double, and a float as it's variables. If you were to implement the above into this class, it should look something like this. public class MyClass { float floatValue; double doubleValue; boolean booleanValue; // Gets the required size of the Buffer to store our information // This can really be replaced with some big number like 1000 if you don't want to have to deal with size serialization // However, the above isn't exactly recommended if you care about good code private int getSize() { return 4 + 8 + 1; // Size of a float (4 bytes) plus the size of a double (8 bytes) plus the size of a boolean (1 byte) } // Takes all class values and writes them to a ByteBuffer so it can be written to a file public ByteBuffer toBytes() { ByteBuffer retValue = ByteBuffer.allocate(this.getSize()); retValue.putFloat(floatValue); retValue.putDouble(doubleValue); retValue.put(booleanValue ? 1 : 0); } // Takes the ByteBuffer created from the contents of the file and sets all class values accordingly public void fromBytes(ByteBuffer buf) { floatValue = buf.getFloat(); doubleValue = buf.getDouble(); booleanValue = buf.get() == 1 ? true : false; } }Now, it is important to note that the ByteBuffer function, although easy to implement, it is very primitive, and with more complex data types such as strings and lists, it can be much harder to use than the netty ByteBuf class. The ByteBuf class is practically the same as the ByteBuffer class, except it has much more versatility. You would probably want to use this class for handling your data as opposed to the ByteBuffer class. I just use the ByteBuffer class here because it is a bit easier to demonstrate and describe specifically in examples. If you want to use the ByteBuf class, you need to instantiate and instance of ByteBuf by doing something like Unpooled.buffer() if you are creating an empty buffer, and Unpooled.wrappedBuffer(fileByteArray) if you are creating a ByteBuf with a byte array already put into it. Now, I believe the ByteBuf class is intended to be used for networking serialization rather than file stream serialization, but it's just too good not to use here, so although this is a bit of an inappropriate usage of the class, things should still be fine. Simply just use ByteBuf in the same way as described for ByteBuffer above. Make sure to use the right methods when handling data. With all that said, you should be practically done here and ready to write your code to handle saving and loading your custom data. You will have to take the liberty with how you are going to handle serializing your data. I will give you some quick pointers here for how to do that. STRINGS These guys can be a bit annoying to deal with, but the best way to do it is, if you are using a ByteBuf, to write the size of the string first, then write the characters of the string to the array, which can be done with the writeCharSequence method. String are implicitly CharSequences, so you shouldn't have to worry about casting, and use Charset.defaultCharset as your second argument. When reading the string data, read the integer first, which is the size of the string, then use the string size with the readCharSequence function. You might need to instantiate a new instance of String to convert a CharSequence to a string. LISTS/ARRAYS These can be serialized much the same way as strings, with the only difference being that you aren't serializing an array of chars, but an array of specific data types. Basically, read or write the size of the list to the ByteBuf, then iterate over either the size of the list and individually serialize or deserialize each object instance individually. OTHER CLASSES If there is another class that you wish to serialize or deserialize, then if it doesn't have the built in methods for converting to or from bytes, just find a way around storing them as data by any means. If you have no choice, then you will have to build your own functions to serialize and deserialize other classes you wish to use. Some classes may be convertible into arrays that can be serialize or deserialized, such example being UUIDs, which if I remember correctly, can be converted into an array of bytes through a built in function and such an array can then be serialized. Hopefully you find this helpful enough to be able to figure out what you need to do now on your own. If you do not fully understanding something that I have mentioned here, then please use the tools at your disposal to understand it better. If you are still struggling and need some pointers or additional advice, please reply to the thread with any questions or concerns you may have. I did not go fully into detail here, but rather just provided some pointers on what to do. I will clarify again, if you do not understanding something here, do not be frustrated, as I didn't put nearly enough effort into this reply in order to fully describe the topic at hand. Remember to pray before running your code. Little know fact, but all great programmers carry a bible, a cross, and some holy water just in case they run into any errors of biblical proportion that requires divine intervention in order to solve. Please let me know if this helps or not.

UPDATE: Okay, so I have a really good fix going on rn, but the problem still isn't exactly solved. Although the quick fix works well enough to be practical, it's not exactly perfect and can cause bugs. Basically, I just injected code at the start of the execute method of the execute command, as well as many others that search the argument list for the string "commands:onepunch" (the name of the super item that I don't want my friends to be able to have), and if it detects said string, it forces the function to return without doing anything. This might sound like a foolproof method of preventing anyone from getting the super item, which it is, but the problem is that it's a bit too foolproof. Instead of the logic behind the practical obtainment of this item in reference to commands being something like, "You can't spawn in this item by any means unless you are the server owner", it turns it into something like, "You can't reference the item in ANY WAY in commands unless you are the server owner." This could cause some issues, like, for example, if I were popbob, and I were to run the command "/execute @e[type=sheep] ~ ~ ~ give popbob commands:onepunch", the code would run the execute command successfully, even though it detects that the super item is referenced because popbob, me, the server owner, is running the command. However, because it is still not able to differentiate between a /execute trigger for a command and a directly run command, even though I am the one who ran the execute command, it will fail once the /give part of it is passed to the sheep. Although for all practical purposes I am happy with what I have so far, it still doesn't really work as intended, so I'll refrain from tagging this thread as solved in the hopes that somebody can come up with a solution to the specific problem at hand.

Okay, took a look. This might be helpful. This also might not be helpful. I'm not exactly sure what the issue is, but then again, with strange and unexpected problems, I'm not sure if anyone can be. Regardless, I will still do my best to help ya' out. First off, I don't think that the "caused by" error segment is really helpful for the context of the problem. Looking at the root error, the "Critical injection failure: " states that the Mixin injection function (that I'm going to hopefully assume is your function), addCustomEndBiomeMusic, is unable to find a method in the minecraft class with the specific name of "m_91107_", which takes zero arguments and returns an object of type net.minecraft.sounds.Music, which all matches with what should work in an srg environment. However, there are two issues that I have here. My first issue I have is that I'm not exactly sure you're in an srg environment. I noticed that when your environment loads the forge "mod", it loads a file with the name "forge-1.20.1-47.4.0_mapped_parchment_2023.06.26-1.20.1.jar". Now, this could mean two things. The first could be that you are in a MAPPED environment, specifically parchment, so when Mixin tries to find the method "m_91107_", it ends up failing because the loaded forge jar doesn't have srg mapped functions. If this case ends up being true, then the fix would be to simply just rename the method from "m_91107_" to "getSituationalMusic". If you are not in direct control over the addCustomEndBiomeMusic method, then you could also try remapping to an srg environment. If the parchment mappings are interfering with the getSituationalMusic method, which I'm not sure why they would be doing that, then you might want to try using the parchment mappings in reference to the getSituationalMusic method, if that even means anything at all. Now, keep in mind that I have literally never used parchment, and I don't even know wth it really is other than what the website described as a mod that "provides the Librarian gradle plugin to allow the use of Parchment mappings in a Minecraft Forge development environment." I don't know what this means, or how exactly this is accomplished, so it's VERY possible that I could be misinterpreting this situation. Assuming that I am misinterpreting the situation or that the suggested fixes above do not work, then my next issue would have to be the fact that Mixin references a file named "blueprint.refmap.json" for its mappings. I also noticed a mod being loaded named "blueprint". This gives me the impression that the blueprint mod provides a mapping file for Mixins to use to make it cross compatible between normal minecraft forge mappings and parchment mappings. If anything else, then maybe you provided the blueprint.refmap.json file. Idk, I'm literally just guessing as to what the problem is at this point. But assuming that this is true, then it might be pertinent to know that after carefully looking through your log file, it states the following: "Found 2 mods for first modid blueprint, selecting most recent based on version data". After which, it then states, "Selected file blueprint-382216-6408581_mapped_parchment_2023.06.26-1.20.1.jar". Now, after looking even more carefully, it seems as though you might have put blueprint in your gradle dependencies when I'm not sure if it should really need to be put in there if you have a dependency folder, causing the exact same mod to load twice. Now, the problem shouldn't be that the mod is loading twice (although you might want to look into that), but the problem could be that you might have an incorrect version of blueprint. If this is the case, then, well, you should know what to do (get the right version). There is one more thing worth considering for the last suggested issue. If blueprint has nothing to do with parchment, or is not equipped to handle parchment related mappings, or if there is some mechanic of parchment and how it crosses its mappings that the blueprint refmap cannot handle, then you might want to try just supplying your own refmap specific to the mappings that should work with your environment to your Mixin. Don't ask me how to do this, because I have absolutely no idea. Now, this isn't another suggested fix for you, but I do believe it would significantly help you to understand the issues at hand here. If at all possible, get your hands on the blueprint.refmap.json file and take a good look at it. Make absolutely sure that the refmap matches the loaded version of the forge jar that you have, and if you aren't using forge mappings, then first off wth are you doing???, but secondly, just make sure that the blueprint refmap matches the environment mappings that you have. Use a java decompiler if needed. Whatever the case may be for the issue at hand, I am not well equipped to deal with it. Ultimately, this issue seems more to be an environment issue rather than a general issue that any well rounded person could solve. Specifically, your issue depends on factors that you particularly control in your environment, which means that solving it requires mastery of these factors. Although you provided more information than most people would, and although you did this as concisely as humanly possible, in the end it doesn't really matter, because you can't fully describe every little detail without ending up like me, and I'm not even capable of coming close to explaining everything I do. These little factors, like implementing Mixin, adding parchment mappings, using 1.20.1 forge, using Eclipse Adoptium, and many more, are just going to be further testament to the fact that, and I know you probably don't want to hear this, the person who is most likely to solve your problem is going to be you, because you are the only person that understands your environment better than anyone else. Now don't get me wrong, I'm most DEFFIDENTLY not saying that you shouldn't post to forums for help with these more complicated problems, because you should; although you are unlikely to get a concise and precisely accurate answer as to the solution for the problem at hand, there is a chance that posting can get somewhere, or even provide the chance for others to possibly give another perspective for your issue that will help you end up at the best solution possible. And when you solve your problem, you can come back to the forums and tell everybody, that way when others come upon your situation, as strange as the situation may be, they can know what to do. With that said, please let me know if anything here gets you anywhere, even if it isn't helpful. Also, sry for constantly making massive text walls.

Hey fellas! So, to make it as short as possible here, I need to know how to determine if a command being executed is from "/execute" or not from the scope of the execute method in the command interface implementation. For example, if, let's say, popbob were to run the command "/summon tnt", and then if some other random player ran the command, "/execute popbob ~ ~ ~ summon tnt", from the scope accessible by the "execute" method of the summon command class, I need to be able to tell the difference between the one that was actually run by popbob and the one that was run by popbob as a result of another player making them use this command through the execute command. Now, this isn't really pertinent information needed to answer the above question, so if you are not interested then please skip past this paragraph, but I'm always open to answer the question of "why on earth do you want this?" First, for context, I play Minecraft with my friends on my own Minecraft server. HOWEVER, they do not really trust me completely with hosting a Minecraft server because they believe me to be a "little troll" (which they're not wrong btw). So the agreement I have with them is that every single one of us gets to have operator, that way we are not only all as close to equal as possible, but also so that we can check on each other independently. To make sure that each of us stays operator, and also so that we each don't actually abuse operator against other players too much, I disabled commands like /stop, /ban, /kick, and /deop for players, making it so these commands can only be executed on the server. However, I would come to find out that they would also seem to be "little trolls", and they would constantly do things like spawning in Tsar Bombs, using the open inventory command to make sure I wouldn't be able to pull the item from them, and blasting the entire server to smithereens. Now, I still don't want to take away their operator status, but when they're using commands to kill me constantly as well as demolishing everything in sight with nuclear bombs, it's kind of hard to actually stop them. So, in response, I created an item that was so powerful, anybody who had it would be completely unstoppable by any immediate means what-so-ever. This includes things like complete immunity to all forms of harm, including every single potion effect, the /kill command, the void, HBM nuclear explosions, the Avaritia Sword of The Cosmos, etc., and on top of that, it would provide protection from other nuisances they would try to use, like opening another player's inventory, the teleport command, and the gamemode command. But that's not the only insane thing the item provides, as it also allows players to fly at infinite speeds, create nuclear explosions, annihilate entire biomes, and kill any player no matter what, even if they have the Avaritia infinity armor. So, with all that being said, it's pretty clear that should one of my friends get their hands on this item, I would probably be f****d. The only way to get rid of the item from their inventory would be to manually use an inventory editor after either kicking them off the server or stopping it entirely. In an effort to ensure that nobody but me is able to control who has this item, I overwrote a bunch of commands to do nothing if my code detects that they're trying to spawn in the god item. However, there is one major caveat, that being that they could just use the execute command to make me run the give command, thus my code would determine that I am running the give command and proceed with the operation. I DON'T WANT THIS AT ALL, but I also don't want to restrict their freedoms by disabling the execute command. Hence, that's why I need to know how to detect a command being run by "/execute" or not.

Hold on, wait a minute. So are you saying that the server you are trying to run is crashing or failing to work properly? If this is the case, then it should have nothing to do with a warning message. Could you be a little more specific as to what's going on? Are you just annoyed that there are some warning messages being displayed? (I mean, if that's the case then I can totally understand.) Again, I notice that you use the word "attempted" when referring to launching the forge server. This gives me the impression that something is going much more wrongly than a warning.

Hey man, I looked at your crash log, and I gotta' say: I'm not exactly sure wth is goin' on here either. But I believe I can offer some advice to you to hopefully help you better pinpoint the issue here. Now, I checked the crash file and you have a TON of mods. When making a mod pack, adding a lot of mods together can cause some issues, as their transformer functions can interfere with each other often. Because of this, you might have choices of mods that you can try to remove instead of just one singular mod being the culprit. You just need to make sure that the mods that aren't exactly compatible with each other are removed. Since you have many mods installed, you should try first backing up your world. Then, create a copy of the back up and remove a large chunk of the mods from your mod folder. Then, load your copy of the back up. If there are no errors, then you know one or both, maybe even all, of the problematic mods is in the chunk you selected. If not, then it's the other way around. Try and use this kind of logic to rapidly hone in on the problematic mod, constantly creating a new copy of your world from the back up each time and loading it from there. Let me know if this is feasible for you. If not, I can try'n brain storm another solution for ya'. Hope this helps man!

Omg, lmao.

Hey fellas! I've been trying for the past few months to fix this miserable, horrible, god awful, hair pulling, hopelessly relentless error I've been having with my imported Gradle projects that have worked fine for several years until I made the mistake of installing Java-17 and Java-21. Basically, I think I know exactly what is causing the error. Gradle for Minecraft Forge 1.12.2 uses Gradle Distribution 4.9, which is literally like ancient technology, so it requires Java-8. But for some incredibly stupid reason that is just completely beyond me, the moment I installed Java-17, it became utterly and entirely impossible to convince eclipse to just use Java-8. I've tried everything: I've yelled at it, I've spoken softly to it, I've even tried actually fixing, but nothing I have done has seemed to work. Literally, every single time I try to fix this problem, a new one pops up. I am sick and tired of having to navigate this LABYRINTH of errors. I think I know how Hercules must have felt trying to slay the hydra at this point. I add launch options to fix it, and now it's generating, "Could not run build action." I try to force eclipse to use a different java version, and it says, "Eclipse requires java blah blah blah." What am I supposed to do at this point? The only way I am able to assemble my 1.12.2 mods is to use Command Prompt and forcibly set the JRE for the gradlew batch file to Java-8. BUT THEM I'M STUCK WITH RUNNING IT ON THE BATCH FILE. I already have so many windows pulled up when I'm modding Minecraft that when I assemble my mod istg I can actually hear my computer start shaking. Trying to reach google through all my windows is like trying to uncover ancient mayan ruins! The last thing I need is EVEN MORE WINDOWS. Now, before you ask any questions, I'm going to try to cover them here, so get ready: Have you tried praying? Yes, that's like the first thing I tried. Did you try putting it in rice? ... Did you try changing your Gradle Distribution version? Yes, it needs gradle 4.9, otherwise I get another error that says something like "Needs gradle 4.9.x or below". Can you please provide the errors that were generated? Sure, here's the error that was first generated when I noticed this problem: org.gradle.tooling.GradleConnectionException: Could not create an instance of Tooling API implementation using the specified Gradle distribution 'https://services.gradle.org/distributions/gradle-4.9-bin.zip'. at org.gradle.tooling.internal.consumer.loader.DefaultToolingImplementationLoader.create(DefaultToolingImplementationLoader.java:99) at org.gradle.tooling.internal.consumer.loader.CachingToolingImplementationLoader.create(CachingToolingImplementationLoader.java:45) at org.gradle.tooling.internal.consumer.loader.SynchronizedToolingImplementationLoader.create(SynchronizedToolingImplementationLoader.java:44) at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.onStartAction(LazyConsumerActionExecutor.java:104) at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:86) at org.gradle.tooling.internal.consumer.connection.CancellableConsumerActionExecutor.run(CancellableConsumerActionExecutor.java:45) at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:61) at org.gradle.tooling.internal.consumer.connection.RethrowingErrorsConsumerActionExecutor.run(RethrowingErrorsConsumerActionExecutor.java:38) at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor.lambda$run$0(DefaultAsyncConsumerActionExecutor.java:55) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) at java.base/java.lang.Thread.run(Thread.java:1575) at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46) at org.gradle.tooling.internal.consumer.DefaultModelBuilder.get(DefaultModelBuilder.java:51) at org.gradle.tooling.internal.consumer.DefaultProjectConnection.getModel(DefaultProjectConnection.java:50) at org.eclipse.buildship.core.internal.util.gradle.CompatProjectConnection.getModel(CompatProjectConnection.java:53) at org.eclipse.buildship.core.internal.util.gradle.IdeAttachedProjectConnection.configureOperation(IdeAttachedProjectConnection.java:68) at org.eclipse.buildship.core.internal.util.gradle.IdeAttachedProjectConnection.model(IdeAttachedProjectConnection.java:59) at org.eclipse.buildship.core.internal.CachingProjectConnection.model(CachingProjectConnection.java:59) at org.eclipse.buildship.core.internal.CachingProjectConnection.getModel(CachingProjectConnection.java:39) at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.runTasksAndQueryModels(EclipseModelUtils.java:56) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.lambda$null$4(DefaultModelProvider.java:75) at org.eclipse.buildship.core.internal.DefaultGradleBuild$GradleConnectionOperation.runInToolingApi(DefaultGradleBuild.java:329) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39) at org.eclipse.buildship.core.internal.DefaultGradleBuild.withConnection(DefaultGradleBuild.java:122) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.lambda$fetchEclipseProjectAndRunSyncTasks$5(DefaultModelProvider.java:75) at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4878) at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3529) at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278) at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2155) at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2045) at com.google.common.cache.LocalCache.get(LocalCache.java:3953) at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4873) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.getFromCache(DefaultModelProvider.java:98) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.executeOperation(DefaultModelProvider.java:90) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.fetchEclipseProjectAndRunSyncTasks(DefaultModelProvider.java:72) at org.eclipse.buildship.core.internal.DefaultGradleBuild$SynchronizeOperation.runInToolingApi(DefaultGradleBuild.java:226) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39) at org.eclipse.buildship.core.internal.DefaultGradleBuild$SynchronizeOperation.run(DefaultGradleBuild.java:192) at org.eclipse.buildship.core.internal.DefaultGradleBuild.synchronize(DefaultGradleBuild.java:100) at org.eclipse.buildship.core.internal.workspace.SynchronizationJob.runInToolingApi(SynchronizationJob.java:64) at org.eclipse.buildship.core.internal.workspace.SynchronizationJob.runInToolingApi(SynchronizationJob.java:30) at org.eclipse.buildship.core.internal.operation.ToolingApiJob$1.runInToolingApi(ToolingApiJob.java:54) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39) at org.eclipse.buildship.core.internal.operation.ToolingApiJob.run(ToolingApiJob.java:65) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by: java.lang.ExceptionInInitializerError at org.gradle.internal.classloader.FilteringClassLoader.<clinit>(FilteringClassLoader.java:45) at org.gradle.initialization.DefaultClassLoaderRegistry.restrictTo(DefaultClassLoaderRegistry.java:39) at org.gradle.initialization.DefaultClassLoaderRegistry.restrictToGradleApi(DefaultClassLoaderRegistry.java:35) at org.gradle.initialization.DefaultClassLoaderRegistry.<init>(DefaultClassLoaderRegistry.java:29) at org.gradle.internal.service.scopes.GlobalScopeServices.createClassLoaderRegistry(GlobalScopeServices.java:210) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73) at org.gradle.internal.service.ReflectionBasedServiceMethod.invoke(ReflectionBasedServiceMethod.java:35) at org.gradle.internal.service.DefaultServiceRegistry$FactoryMethodService.invokeMethod(DefaultServiceRegistry.java:821) at org.gradle.internal.service.DefaultServiceRegistry$FactoryService.create(DefaultServiceRegistry.java:774) at org.gradle.internal.service.DefaultServiceRegistry$ManagedObjectServiceProvider.getInstance(DefaultServiceRegistry.java:568) at org.gradle.internal.service.DefaultServiceRegistry$SingletonService.get(DefaultServiceRegistry.java:625) at org.gradle.internal.service.DefaultServiceRegistry.applyConfigureMethod(DefaultServiceRegistry.java:188) at org.gradle.internal.service.DefaultServiceRegistry.findProviderMethods(DefaultServiceRegistry.java:170) at org.gradle.internal.service.DefaultServiceRegistry.addProvider(DefaultServiceRegistry.java:244) at org.gradle.internal.service.DefaultServiceRegistry$1.addProvider(DefaultServiceRegistry.java:225) at org.gradle.tooling.internal.provider.ConnectionScopeServices.configure(ConnectionScopeServices.java:55) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73) at org.gradle.internal.service.ReflectionBasedServiceMethod.invoke(ReflectionBasedServiceMethod.java:35) at org.gradle.internal.service.DefaultServiceRegistry.applyConfigureMethod(DefaultServiceRegistry.java:192) at org.gradle.internal.service.DefaultServiceRegistry.findProviderMethods(DefaultServiceRegistry.java:170) at org.gradle.internal.service.DefaultServiceRegistry.addProvider(DefaultServiceRegistry.java:244) at org.gradle.internal.service.ServiceRegistryBuilder.build(ServiceRegistryBuilder.java:52) at org.gradle.tooling.internal.provider.DefaultConnection.initializeServices(DefaultConnection.java:123) at org.gradle.tooling.internal.provider.DefaultConnection.configure(DefaultConnection.java:106) at org.gradle.tooling.internal.consumer.connection.AbstractPost12ConsumerConnection.configure(AbstractPost12ConsumerConnection.java:37) at org.gradle.tooling.internal.consumer.loader.DefaultToolingImplementationLoader.createConnection(DefaultToolingImplementationLoader.java:104) at org.gradle.tooling.internal.consumer.loader.DefaultToolingImplementationLoader.create(DefaultToolingImplementationLoader.java:88) at org.gradle.tooling.internal.consumer.loader.CachingToolingImplementationLoader.create(CachingToolingImplementationLoader.java:45) at org.gradle.tooling.internal.consumer.loader.SynchronizedToolingImplementationLoader.create(SynchronizedToolingImplementationLoader.java:44) at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.onStartAction(LazyConsumerActionExecutor.java:104) at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:86) at org.gradle.tooling.internal.consumer.connection.CancellableConsumerActionExecutor.run(CancellableConsumerActionExecutor.java:45) at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:61) at org.gradle.tooling.internal.consumer.connection.RethrowingErrorsConsumerActionExecutor.run(RethrowingErrorsConsumerActionExecutor.java:38) at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor.lambda$run$0(DefaultAsyncConsumerActionExecutor.java:55) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) at java.base/java.lang.Thread.run(Thread.java:1575) Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module java.base does not "opens java.lang" to unnamed module @6d8d945b at java.base/java.lang.reflect.AccessibleObject.throwInaccessibleObjectException(AccessibleObject.java:388) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:364) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:312) at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:203) at java.base/java.lang.reflect.Method.setAccessible(Method.java:197) at org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:42) at org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:32) at org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:36) at org.gradle.internal.reflect.JavaReflectionUtil.method(JavaReflectionUtil.java:186) at org.gradle.internal.classloader.ClassLoaderUtils.<clinit>(ClassLoaderUtils.java:42) ... 45 more And here is the error I am getting after adding the launch options: org.gradle.tooling.GradleConnectionException: Could not run build action using Gradle distribution 'https://services.gradle.org/distributions/gradle-4.9-bin.zip'. at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:55) at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29) at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:43) at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor.lambda$run$0(DefaultAsyncConsumerActionExecutor.java:57) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) at java.base/java.lang.Thread.run(Thread.java:1575) at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46) at org.gradle.tooling.internal.consumer.DefaultBuildActionExecuter.run(DefaultBuildActionExecuter.java:66) at org.eclipse.buildship.core.internal.util.gradle.CompatProjectConnection$CompatBuildActionExecuter.run(CompatProjectConnection.java:407) at org.eclipse.buildship.core.internal.CachingBuildActionExecuter.run(CachingBuildActionExecuter.java:198) at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.queryCompositeModel(EclipseModelUtils.java:121) at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.runTasksAndQueryModels(EclipseModelUtils.java:63) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.lambda$null$4(DefaultModelProvider.java:75) at org.eclipse.buildship.core.internal.DefaultGradleBuild$GradleConnectionOperation.runInToolingApi(DefaultGradleBuild.java:329) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39) at org.eclipse.buildship.core.internal.DefaultGradleBuild.withConnection(DefaultGradleBuild.java:122) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.lambda$fetchEclipseProjectAndRunSyncTasks$5(DefaultModelProvider.java:75) at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4878) at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3529) at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278) at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2155) at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2045) at com.google.common.cache.LocalCache.get(LocalCache.java:3953) at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4873) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.getFromCache(DefaultModelProvider.java:98) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.executeOperation(DefaultModelProvider.java:90) at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.fetchEclipseProjectAndRunSyncTasks(DefaultModelProvider.java:72) at org.eclipse.buildship.core.internal.DefaultGradleBuild$SynchronizeOperation.runInToolingApi(DefaultGradleBuild.java:226) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39) at org.eclipse.buildship.core.internal.DefaultGradleBuild$SynchronizeOperation.run(DefaultGradleBuild.java:192) at org.eclipse.buildship.core.internal.DefaultGradleBuild.synchronize(DefaultGradleBuild.java:100) at org.eclipse.buildship.core.internal.workspace.SynchronizationJob.runInToolingApi(SynchronizationJob.java:64) at org.eclipse.buildship.core.internal.workspace.SynchronizationJob.runInToolingApi(SynchronizationJob.java:30) at org.eclipse.buildship.core.internal.operation.ToolingApiJob$1.runInToolingApi(ToolingApiJob.java:54) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317) at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39) at org.eclipse.buildship.core.internal.operation.ToolingApiJob.run(ToolingApiJob.java:65) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by: org.gradle.api.GradleException: Unable to start the daemon process. This problem might be caused by incorrect configuration of the daemon. For example, an unrecognized jvm option is used. Please refer to the user guide chapter on the daemon at https://docs.gradle.org/4.9/userguide/gradle_daemon.html Please read the following process output to find out more: ----------------------- FAILURE: Build failed with an exception. * What went wrong: java.lang.ExceptionInInitializerError (no error message) * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org at org.gradle.launcher.daemon.client.DaemonGreeter.parseDaemonOutput(DaemonGreeter.java:35) at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startProcess(DefaultDaemonStarter.java:160) at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startDaemon(DefaultDaemonStarter.java:136) at org.gradle.launcher.daemon.client.DefaultDaemonConnector.doStartDaemon(DefaultDaemonConnector.java:212) at org.gradle.launcher.daemon.client.DefaultDaemonConnector.startDaemon(DefaultDaemonConnector.java:206) at org.gradle.launcher.daemon.client.DefaultDaemonConnector.connect(DefaultDaemonConnector.java:130) at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:139) at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:93) at org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:60) at org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:41) at org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:58) at org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:37) at org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:180) at org.gradle.tooling.internal.provider.ProviderConnection.runClientAction(ProviderConnection.java:142) at org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:132) at org.gradle.tooling.internal.provider.DefaultConnection.run(DefaultConnection.java:239) at org.gradle.tooling.internal.consumer.connection.ParameterizedActionRunner.execute(ParameterizedActionRunner.java:36) at org.gradle.tooling.internal.consumer.connection.CancellableActionRunner.run(CancellableActionRunner.java:52) at org.gradle.tooling.internal.consumer.connection.AbstractConsumerConnection.run(AbstractConsumerConnection.java:69) at org.gradle.tooling.internal.consumer.connection.ParameterValidatingConsumerConnection.run(ParameterValidatingConsumerConnection.java:56) at org.gradle.tooling.internal.consumer.DefaultBuildActionExecuter$1.run(DefaultBuildActionExecuter.java:80) at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:87) at org.gradle.tooling.internal.consumer.connection.CancellableConsumerActionExecutor.run(CancellableConsumerActionExecutor.java:45) at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:61) at org.gradle.tooling.internal.consumer.connection.RethrowingErrorsConsumerActionExecutor.run(RethrowingErrorsConsumerActionExecutor.java:38) at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor.lambda$run$0(DefaultAsyncConsumerActionExecutor.java:55) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) at java.base/java.lang.Thread.run(Thread.java:1575) What launch options did you add to the eclipse jre? These ones: --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED I put them at the very end of my eclipse.ini file, btw. Have you tried uninstalling your later java versions? Yes, but it's no use, eclipse will just magically pull up another more updated java version like a magician pulling a bunny out of a hat. Have you tried just using IntelliJ? I will never join the dark side! You know IntelliJ actually provides some better maneuverability than ecli- YOUR TRICKS AREN'T GOING TO WORK ON ME! Have you tried just simply deleting the java that eclipse will use? Yes, but when I do eclipse blows up and melts down like reactor number 4. (I will not be trying that again, btw.) What did you do to the gradlew batch file to make it work that you can't do with eclipse? VERY EXCELLENT QUESTION! I just added set "JAVA_HOME=C:\Users\[MY USERNAME]\JDK8\jre" to the very beginning of the batch file. And yes, I know this JRE is installed in a very strange spot, and I also know that it says "JDK" before opening into a folder called "jre". I installed this folder when I was like, six; c'mon, cut me a little slack. Could you provide the path to the java environment that eclipse is currently using? Absolutely: C:/Users/[MY USERNAME]/.p2/pool/plugins/org.eclipse.justj.openjdk.hotspot.jre.full.win32.x86_64_23.0.1.v20241024-1700/jre/bin Have you tried changing your java home variables on your system and what not? Yes, but to no avail; eclipse will just continue using the JRE supplied to it in it's ini file. Have you tried just making a new project and exporting everything over there to see if it works? I tried making a new project, but I could instantly tell it wasn't going to work just based on that fact that I immediately get the "Could not create an instance of Tooling API" error. Have you tried downgrading eclipse? No, and I'm honestly pretty scared to do that because I don't want to have to deal with another meltdown again. If there are no other ways to get eclipse to use a lower java version, then this is probably what I'll end up doing if I don't die from frustration before I get there. Have you tried uninstalling some eclipse plugins and downgrading the java that eclipse requires in the ini file? No, and I'm again afraid of doing it for the exact same reasons as stated above. What is the required java version in the eclipse ini file? Java-11 I'm hoping somebody here knows a way around this problem that allows me to use eclipse to build my forge 1.12.2 gradle projects. Actually, strangely, I just though of the fact that it's JUST my 1.12.2 projects that are failing. That's interesting because I do in fact have a GT New Horizons 1.7.10 mod that NEVERMIND, I just checked and apparently those crazy insane people down workin' on the GTNH mod pack managed to used gradle distribution 8.13 in their template project. I guess they're just a bunch of gigachads that literally built their mod pack from the ground up. Maybe I might end up just doing what they did and make my own forge gradle mod template, but that would REALLY suck having to do that for any gradle version that doesn't like java 21. If somebody knows how to get eclipse to just use an earlier version of java, please for the love of all that is holy, help me out! In the meantime, I guess I got no other good choice but to use the command line. I'm hoping this post reaches somebody that can help.

Alright, I took a look at the code... again. I assume that you are using 1.20.1, as from your last post. First, let's get the "Have you tried putting it in rice?" questions out of the way first. Have you looked from world height to bedrock? Notice anything strange in that range? Did you set the bounds of your structure properly? Have you checked multiple different locations? Did you pray before you ran your mod? Alright, now assuming that you did all of that, try this! Pray really hard, and open your log file. CONTROL+F search for the following string: "Failed Start with id". Hopefully your praying payed off and manifested this message into reality, because if not, this could be real rough. In the case that you do not see this message, the problem could be literally almost anything without any code to reference. There is a significant amount of things that could go wrong when generating structures, and it's all up to how you programmed the Structure Pieces class and your Structure class. If none of this works, please post your code here. My previous post paragraph completely ignored the main bulk of the things you said in your post. Now I'll take it into account here. I notice that you said this one scary word: "structure block." Are you trying to use the datapack method to generate custom structures? If you are, I'm not exactly sure if this is the place for that kind of help, as I believe the people here are more experienced with PROGRAMMING WITH JAVA IN FORGE rather than operating general Minecraft datapacks. Perhaps somebody here will be more familiar with the datapack method of generating structures, but I'm not too sure. If you are trying to use the datapack method (which if you have forge and enough comfortability with java, then I would strongly recommend just making a mod instead), there is probably a more general Minecraft forum somewhere to ask in. If you are feeling up to it, you can actually very easily make a custom structure with this very old MCEdit method I remember from way back. I'm not sure if it could still work with 1.20.1, but it's worth a shot. Basically, you would just build a structure in a custom world, load that world in MCEdit, and use MCEdit to convert it into java code. I remember somebody made a program to "compress" the code that was generated from MCEdit, but I wasn't able to find the program. Sorry man. Anyways, if you are stickin' with the datapack rotue, then I'm sorry, but I don't have enough experience to help you with that, but I wish you the best of luck!

Alr, I just looked at the individual mods here (MixinBooter and Iris Flywheel Compat). I'm going to try my best to add some input here for when you get back next morning WITHOUT making a huge text wall again. Before your exception is thrown here and your game crashes, in your log you should see something like this: "Error loading class:". Try a CONTROL+F search to find it in your log file. If you do not see this message, then I really hope you have a bible on hand and a good prayer in mind, because you might be screwed. Hopefully that's not the case though. If you find this message in your log file, please post it here. Also, could you provide the name of the modpack you are using? One more thing I should add. I'm not exactly sure that removing Iris Flywheel Compat would work, but I would encourage you to do so anyways just in case it does work. If it does not work, then the problem is 100% being caused by a bad transformer function, in which case you should provide a link to your modpack. ONE MORE THING: if you are using any other additional mods in your modpack, please provide them here, even if they are hacked clients; I cannot help you with anything revolving around hacked clients, but knowing if you have a hacked client mod will still help determine the source of the problem. Hopefully removing Iris-Compat works...

Hmmmmm... It looks like your problem might be being cause by a transformer function that has previously failed. Basically, the game uses transformers to literally rewrite Minecraft's code. Think of these functions like a courier service. Let's say you buy a package from FedEX. They put your package in their big ol' trucks and send 'em off. However, let's say that this truck suddenly gets stopped to be searched, e.g. the transformer editing the package (the code). The guy searching the truck finds your package and he goes, "Hey, man, this package is a bit strange so we gotta' change it a bit, here-" and he opens up the package, removes a few things, adds a few things, and finally puts the package back in the truck and sends it off. When you get your package (again, the code), it will be changed by the man who searched the truck (again, the transformer). Everything went alright, HOORAY! Now, let's say this man searching your truck runs into a bit of an issue while modifying your package, and he... gets struck by and asteroid or something, idk. Because he failed so catastrophically, you will NEVER get your package, so the truck will just have to drive off without your package. Now let's say we have another guy on the track this time that wants to search the truck, and let's say he's looking for that same package that the first guy messed up with. He goes into the truck, looks around a bit, and says, "wth, there ain't nothin' here man." Then he calls the police and says something like, "ClassMetadataNotFoundException." This could be what has happened here, although I'm not too positive. But basically, the entire package (the code needed to be modified) is GONE! But here's the thing, the exception shown in your crash report is NOT going to be the one that's actually of note, because the original guy didn't throw an exception. What you need is evidence of what failed to change the class beforehand. Here's what you can do. In your log file, try finding the point where the exception is initially thrown, then try scrolling up and see what's there. If you see anything of note, please report it here. If all else fails and nobody is able to help you here, then as a last resort you could post the log file, although I wouldn't exactly recommend this right off the bat, who knows what might be in there. Hope this helps ya' out man!