LexManos
-
Posts
9264 -
Joined
-
Last visited
-
Days Won
66
Posts posted by LexManos
-
-
Some zip managers like to take control of the .jar file extension away from Java.
Make sure you have Java installed and try running Jarfix once, then try the installer again. -
Its an error applying a mixin, which is something that breaks into internals of things and are very fragile in comparison to using the systems we put in place in Forge. This is the definition of not our problem. If they used Forge directly it wouldn't ever try to apply a mixin and thus wouldn't get a mixin application error.
-
My tests through VPNs show that it is working fine. However, if it messes up for you feel free to skip it. We provide the direct links for people who either can't, or don't want to see the ads. If you feel like you still want to give back, we have donation options.
-
Some zip managers like to take control of the .jar file extension away from Java.
Make sure you have Java installed and try running Jarfix once, then try the installer again. -
We are not Curse.
We are Forge.
Two completely different things. -
Correct, We are Forge, we do not load Fabric mods.
It is recommended that you stick to Forge mods.
-
You are correct, this has been discussed many times. And nothing you've brought up addresses any of the issues properly.
The answer is no. it's not going to happen.
-
The version you are using is no longer supported on this forum.
Please update to a modern version of Minecraft to receive support.
-
Yes we could randomly generate version numbers for java's module system and fix modders being stupid.
But we don't. Because we don't fix modders stupidity. They have to work within the confines of the systems they are in. This one in particular was exposed by us fixing a bug where we didn't honor the standard Java's spec on defining versions. The modder actually went out of their way to specify the version as defined in the Java spec. But inserted a incorrect value. It's like if you ask someone for a glass of water, and they hand you a glass of battery acid. Should you silently accept it, and find your own water, or should you yell at them that acid isn't water.
-
1
-
-
Just verified, The old installers work just fine, however we don't support walking you thought the basics of your launcher. Especially for older versions. You're on your own.
-
3 hours ago, ChampionAsh5357 said:
The code examples should be integrated into the post itself, and the example is not the only way to do it. I don't like very specific code examples in most cases as people will tend to copy and paste code and expect it to work. This typically leads to people not understanding what they are doing and then getting mad when it doesn't work as they wanted it to. Code snippets are typically better when people need to infer the context based on previous topics and understand what is going on. Though, I could swing either way depending on how the examples are explained.
That is actually one of my requirements for the docs to be "official" We can not have copy pasteable "example" code because the amount of people who will just copy pasta and not learn anything is stupid high. Everything *should* be psudo-code. This is an intentional design decision. Not to mention this allows you to not have to worry about mappings or anything that changes based on user setup.
11 hours ago, Jontom Xire said:At https://nekoyue.github.io/ForgeJavaDocs-NG/javadoc/1.19.2/ there is a github repository for the Javadocs for Forge. They can be automatically generated using scripting etc. Why is it left to someone else to generate these documents? Why not have a simple script that will generate the documentation for each release and publish it. Then you can put a link to it in the official Forge documentation. More than that, each time you put a function name in the documentation, it could be a link to the relevant part of the javadocs.
As mentioned by Ash, this site is illegal due to Mojang's license. Combined with the entire concept of us publishing javadocs being useless because of obfuscation and mappings being a crowdsourced ever changing system. We used to publish javadoc archives. But decided to stop doing that when e got to 5TB of wasted space. As every build was around 20MB of just javadocs even compressed. And again, they were almost completely useless due do obfuscation of Mojang's code. Your IDE has great javadoc generation functionality. Hell you could build them yourself locally from the MDK. So it's not worth it to host publicly.
What you have to remember, is that you're modding a game that was never designed to be modded. We're hacking together a somewhat standard development interface for you using a lot of black magic in the backend to make things behave. As well as respect Mojang's wishes/copyrights. Plus this is all being done by hobbyists/volunteers. We have reasons for doing everything the way do we it, including the docs.
-
No. We don't support creating hacks/cheats/piracy.
-
1
-
-
Forge does not have a app/launcher.
We are not Curse, we suggest you use the official launcher from Mojang. -
Our stance will always be to be on the latest version. So we will always have to be on that update grind. Unfortunately that's just how modding a closed source game works. People will always throw fits no matter what we do. Us supporting one older version has been decided feasible enough for us to do. So whatever we call this secondary support version, there will only ever be one. There is a history of external things changes causing older versions to break especially in the development side {Gradle is a wonderful system that has no bugs or stupid design decisions...} We have had a bunch of people saying that we should support older developmental versions. We have given those people the option to step up and help with the manpower requirements to do that support. The RetroGradle project, they have not done that. So I don't see expanding dev support to more versions, even if community based, would be viable.
As for the modding plateaus. They are great for the community. Having one version of Minecraft with a ton of supported mods are great. However, these plateaus typically come from a handful of mods not updating. Combined with random packs using those mods becoming popular via youtube, twitch, or whatever. There really isn't anything we can do to predict when that'll happen. Unfortunately, none of us have actually functional crystal balls. So we got to pick something. The other problem is that IF we DID pick say.. 1.18.2 as the next "we'll support it for 2 years no matter what Mojang does" all it would take is one popular modder/youtuber to pick a 1.19.1 mod to make that choice moot.
Aside from that, this is a is a potentially one off vote. Mainly because this is potentially the first in Mojang's new mantra. IF things go the way they have described. With minor versions being code breaking by introducing features via feature flags. Then using the Major version as the 'enable these feature flags by default'. Our new marching orders may be to only allow '.0' releases as LTS. For those who arnt getting what i'm saying. In the past we have had release candidate versions, that then switch to full releases. Here is an example of 1.17's RC to release changes:
diff -r -u3 versions\pre\1.17\1.17-rc2\projects\joined\src/main/java/net/minecraft/DetectedVersion.java versions\release\1.17\projects\joined\src/main/java/net/minecraft/DetectedVersion.java --- versions\pre\1.17\1.17-rc2\projects\joined\src/main/java/net/minecraft/DetectedVersion.java 2021-06-08 09:30:16.357996900 -0700 +++ versions\release\1.17\projects\joined\src/main/java/net/minecraft/DetectedVersion.java 2021-06-08 09:55:02.419312200 -0700 @@ -29,9 +29,9 @@ private DetectedVersion() { this.f_132478_ = UUID.randomUUID().toString().replaceAll("-", ""); - this.f_132479_ = "1.17-rc2"; - this.f_132480_ = false; - this.f_132481_ = 2723; + this.f_132479_ = "1.17"; + this.f_132480_ = true; + this.f_132481_ = 2724; this.f_132482_ = SharedConstants.m_136192_(); this.f_179761_ = 7; this.f_179762_ = 7; diff -r -u3 versions\pre\1.17\1.17-rc2\projects\joined\src/main/java/net/minecraft/SharedConstants.java versions\release\1.17\projects\joined\src/main/java/net/minecraft/SharedConstants.java --- versions\pre\1.17\1.17-rc2\projects\joined\src/main/java/net/minecraft/SharedConstants.java 2021-06-08 09:30:17.929174300 -0700 +++ versions\release\1.17\projects\joined\src/main/java/net/minecraft/SharedConstants.java 2021-06-08 09:55:03.744839600 -0700 @@ -10,11 +10,11 @@ public class SharedConstants { @Deprecated - public static final boolean f_142912_ = true; + public static final boolean f_142912_ = false; @Deprecated - public static final int f_142951_ = 2723; + public static final int f_142951_ = 2724; @Deprecated - public static final String f_142952_ = "1.17-rc2"; + public static final String f_142952_ = "1.17"; @Deprecated public static final String f_142953_ = "1.17"; @Deprecated @@ -156,7 +156,7 @@ } public static int m_136192_() { - return 1073741859; + return 755; } static {As you can see functionally nothing has changed. It's just setting flags. IF future '.0' versions are like this. Then it would make sense for us to make the .0 our LTS vs the 'last version of the old major'. But ya we'll see what happens when Mojang releases 1.20.
-
As a note, the plan is to have 1.19.3's first RB be January 1st. Because I like that date and it gives people time to look at things during Christmas break. So this poll will stay open until that time and be what we do.
-
2
-
1
-
-
Obfusication, thats why. During runtime the vanilla methods are named with SRG names. So m_12345_ not getAttackDamage.
You'll need to pick a different name for your interface.
-
Quote
i change to java 17 but not work
[16dic2022 18:29:21.563] [main/INFO] [cpw.mods.modlauncher.Launcher/MODLAUNCHER]: ModLauncher 9.1.3+9.1.3+main.9b69c82a starting: java version 19.0.1 by Oracle Corporation -
For version with a forge jar in the root folder. Run the Forge jar, as its an executable jar.
For other versions, run the run script for your OS. -
-
To an extent, its still not worth it. And god knows what that proxy server is actually doing with all the data you're sending it.
And again this isn't anything you couldn't do on your own. Yes it would require you to have two server running. The real one and a proxy, but why would you want to.
Anyways, TLDR We dont support 3rd party launcher no matter how you try and justify it. -
Its not where you host your own minecraft server...
You host the server on your machine.
The launcher doesnt do anything special for you, nothing you couldn't do yourself with 5 mins of effort.
Anyways, our installers work, they use the now standard systems in java that java has been pushing for years. So our only answer will be to use the normal processes and not some 3rd party wrapper.
-
No, you should use the vanilla launcher. 3rd party launchers are a bad idea. And most 'clients' are hacks {dont try to argue this} which we don't support.
As for their 'host a minecraft server for free' crap.. You're just hosting the server yourself. Just run it yourself dont add a 3rd party into it or no reason.
-
Because Java doesn't like executable jars anymore Yell at them
Or use a server host that has updated their systems to support a system that was released 5 years ago.
-
One of the mods you have installed has a invalid version `1.0-1.19+` you'll need to figure out which one and remove it.
-
1
-
when running the installer it doesnt give me the jar file i need
in Support & Bug Reports
Posted
You don't. The jar file to run a server doesn't exist anymore.
Use the bat file if on windows, or the sh file if not. If you're using a server hosting company thats asking for a jar file. Tell them to update to modern java.