Optifine support removed in build 780!

[_DroidFreak_]

I got Forge build 777 to work with Optifine HD U A2 last night, so I was completely baffled when I tried the exact same Optifine version and the exact same install procedure with Forge build 789 without success. I got this error: "The minecraft jar file[...]/minecraft/server/MinecraftServer.class appears to be corrupt! There has been CRITICAL TAMPERING WITH MINECRAFT, it is highly unlikely minecraft will work! STOP NOW, get a clean copy and try again!"

 

I thought it might just be a small bug, so I tried with the recommended version, build 784. The result was the same. It then occurred to me that since build 777 works and the newer builds don't, I should look up the changelog. Here's what I found:

 

"Build 1.6.2-9.10.0.780

LexManos

Updated FML:

MinecraftForge/FML@c997f2adbc4c11cd8c2abe5f82ccd00b0e954b68 FML now verifies that the minecraft jar is correct and intact. This is intended to discourage those who think that modifying the minecraft jar is still acceptable."

 

Hold on just a second there! LexManos made FML check for and reject jar mods! His intention was probably to prevent noobish mods from crashing Minecraft, but this is Optifine we're talking about here. I'm 95% positive that if it FML didn't check for jar mods and continued everything would work fine. I think that FML shouldn't try to prevent jar mods. Let's do a risk assessment:

 

Noobish jar mod + FML checks for jar mods = FML arrests startup, Minecraft doesn't start.

Noobish jar mod + FML accepts jar mods = Minecraft crashes.

Legit jar mod + FML checks for jar mods = FML arrests startup, Minecraft doesn't start.

Legit jar mod + FML accepts jar mods = Minecraft works fine.

 

If the jar mod is noobish and is going to crash MC anyways, this change accomplishes nothing because a failure to start and a crash on startup are virtually identical.

If the jar mod is legit, however, this change is bad because it STOPS MC from working.

 

If someone's trying to use a jar mod that's going to crash the game anyways, I say let them proceed and crash the game. I'd much rather deal with a crash than with Forge flat-out refusing to try.

[LexManos]

Forge has never, and will never Support any mod that edits the base classes.

There has been no need to do that for god.. almost a year now.

With 1.6's new launcher we are now able to do the entirity of Forge without editing the jar file. Anyone else should be able to do the same.

There are system in place to allow people to have the full power of editing base classes without actually editing the jar. We've had this discussion with Optifine and it will be up to them to do things properly.

However We do have flags to turn this off, but we HIGHLY recommend that you leave this enabled. And beg the mod author to move to the new system designed for 1.6. {its not necessarily to Forge as this new system is shipped by Mojang themselves and doesn't rely on Forge at all.}

[_DroidFreak_]

I do recognize that modifying the base classes is probably a bad idea. I even think Optifine should probably come out with a Forge version and make all our lives easier. Unfortunately, I'm not Optifine's dev, I'm just a player and server admin who wants to run Optifine and Forge together. Isn't there a better way to convince Optifine to port to Forge than making Forge intentionally incompatible? In any case, I wish you the best of luck in convincing sp614x. If there's any way you think I could help (Besides, you know, spamming the Optifine thread with "Y U NO FORGE") I'd be happy to. If sp614x is willing I might even be able to help with the porting, as I'm fairly experienced as a programmer, although I haven't developed anything major in Java.

 

Also, what do you mean by "flags to turn this off"? Do you mean the -Dfml.ignorePatchDiscrepancies=true JVM argument? Because I was using that (as per Optifine's instructions) in all cases mentioned, both the 777 case that worked and the post-780 cases that didn't. If that is the correct flag, post-780 Forge ignores it and if there's another flag I was not aware of it.

[acomputerdog]

Wait there is a vanilla way to avoid editing base classes in 1.6?  When did this happen!?

[LexManos]

I do recognize that modifying the base classes is probably a bad idea. I even think Optifine should probably come out with a Forge version and make all our lives easier. Unfortunately, I'm not Optifine's dev, I'm just a player and server admin who wants to run Optifine and Forge together. Isn't there a better way to convince Optifine to port to Forge than making Forge intentionally incompatible? In any case, I wish you the best of luck in convincing sp614x. If there's any way you think I could help (Besides, you know, spamming the Optifine thread with "Y U NO FORGE") I'd be happy to. If sp614x is willing I might even be able to help with the porting, as I'm fairly experienced as a programmer, although I haven't developed anything major in Java.

 

Also, what do you mean by "flags to turn this off"? Do you mean the -Dfml.ignorePatchDiscrepancies=true JVM argument? Because I was using that (as per Optifine's instructions) in all cases mentioned, both the 777 case that worked and the post-780 cases that didn't. If that is the correct flag, post-780 Forge ignores it and if there's another flag I was not aware of it.

It will always be up tot he Optifine dev, there are reasons why we added a disable flag.

We do not add optifine incompatibility We added Mojang jar verification. Because we have NEVER actually supported ANY base editing mods.  With forge this has not been necessary for a year. With Vanilla this has not been necessary since 1.6's new launcher was created.

 

The ONLY reason editing the jar was needed was because we could not re-direct the entry point of Minecraft. With the new launcher we CAN which means the is no longer NEEDED to edit the jar.

 

And as for optifine, his method is fairly easy to do. All he needs to do is use the tools that we made that are open source and freely available. All he has to do is:

GenPatchSet HisObfed.jar VanillaMinecraft.jar

And there is still a open call for if he wishes any help in cleaningup his workspace and making his life easier. But.. i've gotten nothing so meh.

 

Wait there is a vanilla way to avoid editing base classes in 1.6?  When did this happen!?

The new launcher allows you to specify your entry point into minecraft:

https://github.com/MinecraftForge/FML/blob/master/jsons/1.6.2-rel.json#L125

And to make 1.5.2 work with the launcher Mojang is using donated code from FML:

https://github.com/Mojang/LegacyLauncher

 

There are reasons why we do the things we do, contrary to popular belief we actually speak with developers and mojang themselves.

The old system of edit the jar was due to necessity, there are features in place that make it no longer necessary. So we will no longer support anyone who does so.

Its one of the main issues that i've ran into with people in MC modding. The inability to evolve or adapt to changes.

Everyone is under the "Well it worked 3 years ago why doesn't it work anymore!?!??!?!?"

And that is a sad sad thing.

[acomputerdog]

That is very good to know!  With just that I can probably convert my last JAR mod away from having to mod anything if I do it right!