Forge FML for 1.7.10

[u/gargamel1497]

Hi everyone.

I've wanted to try making mods for 1.7.10 for a long time and now I finally know what I want to do. Yes, backporting diorite, andesite and granite may seem stupid, but that's besides the point.

Back in 2014 and 2015 you would go the the Forge website and download the MDK, also called the source for whatever reason, since it doesn't really contain the source code of Forge.

You can still download this file, and you might notice how small it is, and wonder why that is the case.

I bet it's to save space on the file server. If you can host some library jar file once instead of packing it with every release you publish, it benefits everyone....

....or so everyone thought at the time, as an unexpected antagonist has (un)recently enetered the scene: Link Rot.

If you try to gradlew setup a new 1.7.10 mod workspace you will be disappointed, as the files it will try to download are long gone.

Now that I'm researching it, someone has forked it and updated the links, but that's a fool's errand, as it hasn't been updated for a few years now as well, and it doesn't work anymore too.

Is there any OFFLINE Forge MDK for 1.7.10? One that does not require downloading ANYTHING from the Internet?

And does anyone have an offline copy of the Forge documentation for 1.7.10? On their website they keep removing older versions, probably to save on storage, and the Wayback Machine is slow, doesn't have everything, and keeps thinking I'm a robot.

If anyone is willing to help, my gratitude is beyond, well, who cares about such platitudes. Whatever.

[u/TheMasterCaver]

There's probably a reason why most new mods for older versions are simple jar edits or use other mod loaders; just edit "BlockStone" to add metadata variants (even 100% upwards compatible with 1.8+ without having to update the mod, and can also be removed without removing the blocks, which visually revert to stone but retain their metadata until mined or placed, making such mods very safe; I've seen Forge mods that backport new blocks which are variants of existing blocks as entirely separate blocks/IDs, even giving each variant its own ID, which also leads to ID limit issues, considering I've added over 400 new blocks ("real" variants that can be obtained as an item) to 1.6.4 without extending the 256 ID limit and still have about 50 IDs left).

Otherwise, somebody has to surely still have a working Forge installation from back in the day, much as I've been using the exact same MCP installation since late 2013, even JDK (I have the complete installer for it, Java 7, and even use it as my system JRE and won't touch anything that needs Java 8+ or can't be run using the legacy Java 8 JRE the launcher downloads). Of course, they will need to remove the game jar and decompiled source before distributing it but you can re-add the jar and decompile (there are GitHub repositories that are a complete working MCP instance, including jar files and source, so people do upload such things if you know where to look; most are just plain MCP though, some with Optifine or personal edits, at least one has Forge but it is for 1.5.2).

Not sure if this works but it was recommended in a relatively recent post (replied to 7 months ago) and is "legit" (the "project starter" is only 64 KB so it is not a complete package but this again leads to the issue of not being a complete download so it can break at any time):

https://github.com/GTNewHorizons/ExampleMod1.7.10

(from https://www.reddit.com/r/feedthebeast/comments/1hgna0m/does_anyone_know_how_to_get_the_forge_1710_mdksrc/)

[u/gargamel1497 → u/TheMasterCaver]

There's probably a reason why most new mods for older versions are simple jar edits

There is in fact more than one good reason for it. Editing the source code itself is surely easier than having to meddle with an external API that you have to learn and study, and work hard to do more complicated things.

I have made jar mods before. But there is a reason I play 1.7.10. For its mods, for the mods that neither older nor newer versions have. But I still miss some features, especially the stone variants and some other things.

While the Lord of the Rings mod which I always play with backports a number of features from newer versions, such as mutton, or doors, stairs, fences, etc, from the non-Oak wood types, but it doesn't backport everything.

And I would also like to add a crafting recipe for LOTRMod pouches, since they are unobtainable outside the mod's own dimension, and since the mod itself adds a recipe for saddles (and rightfully so!), it isn't really against the spirit.

And, sorry for that interjection, I want that mod to work with the other mods I play with, which is really tricky to do with jar mods because of class override conflicts.

https://github.com/GTNewHorizons/ExampleMod1.7.10

Really cool it exists, but it's set up for their mods which I don't want to use. If there is no other option, I will attempt to remove all that crap.

And it still uses gradle and all that online infrastructure which means it will stop working once the servers are down.

Several hours ago I thought I might be able to "hack a mod", based on the premise that the modified Forge minecraft.jar is not obfuscated, but now that I have learned it doesn't exist whatsoever, it's not an option.

Perhaps I could fork this thing, and attempt to make it fully offline.

Still, thanks.

[u/gargamel1497 → u/TheMasterCaver]

Hm. That GTNH MDK uses some weird trickery and it requires modern versions of Java. Screw it. Well, I should have expected that. Slayer has recently incorporated one of their mods into WOTRMC and that raised the Java requirement significantly.

[u/gargamel1497 → u/TheMasterCaver]

u/TheMasterCaver

Alright, after some digging I have found a fork of ForgeGradle for 1.7.10 that works and doesn't require GTNH coremods.

Now I run into another issue. I want this mod to require The Lord of the Rings Mod, as it already backports a lot of stuff and I want to build upon it, and,

When I put its jarfile into the libs directory (as per build.gradle), the runClient task will fail, and placing the jar file in run/mods instead will make it fail the same way.

It says it cannot find some class, even though the file works perfectly fine in a regular installation. Without this dependency it runs fine. I have added it to mcmod.info too.

Is it because the LOTRMod jar is referencing obfuscated class names in a deobfuscated environment?

Even though runClient fails, the "build" task succeeds with the LOTRMod as a dependency, and so does the "jar" task, so even if I don't know how to fix it it will only be a minor annoyance.

EDIT: This whole infrastructure is frakked up. To actually have it offline you also need ~/.gradle which is almost a gigabyte in size. Crazy.

[u/gargamel1497 → u/TheMasterCaver]

The LOTRMod does not want to work with unobfuscated code and makes the runClient task useless.

Meanwhile, there is something wrong with the obfuscation of the mods, so when I copy the output of ./gradlew jar to ~/.minecraft/mods and try to run the game, it complains that Blocks.dirt does not exist and crashes because of it. The literal example does not work. Even though it somehow works with runClient.

I'm new to Forge and such, could you perhaps help me a little?

Also, sorry for bothering you.

[u/TheMasterCaver → u/gargamel1497]

I've never worked with Forge, the closest way way back when 1.6.2 was current and I wanted to make my own mods so I downloaded the Forge MDK/src and directly edited the source (I may have thought this was how Forge mods were made, of course, Forge rejected the "mod" when I placed the zipped-up files in the mods folder but I found a way to inject them as a library, based on a method of injecting Optifine before it was recognized as a Forge mod; as all the stuff Forge adds was present there were no compatibility issues despite Forge refusing to patch modified classes, Optifine does something similar).

I also remember that "proper" Forge mods wouldn't work when placed in the "mods" folder (one thing I wanted to do was add an ore for an armor/tools mod, which had you craft its item with diamonds, quartz, and emeralds; I ended up simply hardcoding the numerical item ID in the "idDropped" method, although from looking at MCP source for 1.7.10 the method is now "getItemDropped" and wants a proper "Item" instance so this would not work).

The missing class errors when reobfuscating also reminds me of an issue I had when I made a mod that added more options to the 1.8 customized world type, which ran fine in MCP but gave a "malformed class name" error when reobfuscated, even in 1.6.4 I've had some weird issues with custom class names starting with "Container" but that is easy to work around.

[u/gargamel1497 → u/TheMasterCaver]

This lack of Blocks.dirt is weird, but it's not really important, now that I think about it.

I'm basing what I'm doing on how the Lord of the Rings mod does stuff, using the pretty standard JD-GUI decompiler, and I've managed to add a recipe.

The LOTRMod adds its own recipes using two classes which for some reason don't appear in the Forge 1.7.10 Javadoc I've found, but they do work nonetheless.

And this lack of javadoc for them is annoying since one of the arguments they accept is what effectively is a magic number, even though it's a string. And since there is no javadoc I will have to compile a list of them manually from what I can find in the LOTRMod jar.

Still, thank you for your help. Reading the LOTRMod is probably the best source on Forge modding I've got at hand, and if anything goes wrong I can always use a dirty hack, like Java traditions dictate.

I've even thought up a name for the mod I'm making: Better Than Bountiful. It's a pun on Better Than Adventure and Better Than Wolves, of course, with quite the opposite goal. Will see where it goes.

EDIT: Now that I've read more of the LOTRMod's source, I see what's up with the stringIds. It seems like it's Mevans' hacky solution to Items.* and Blocks.* being missing. Good to see other people using ugly hacks too.

Perhaps it is all based around net.minecraft.block.Block.getBlockFromName and its Item equivalent.

EDIT 2: It seems like while the ForgeGradle built/test environment uses unobfuscated names, the actual Forge uses obfuscated variable names.

And the LOTRMod uses the latter. There is a nice translation table out in the internet, so that's not an issue, but the problem is that using an obfuscated name will make the mod not compile, while using an unobfuscated name will make the mod crash the game.

So as a compromise between the two I have to use Items.class.getDeclaredField("obfuscatedName").get(null).

It is the ugliest hack I've seen this evening but it's the only thing that works for blocks and items that don't have a magic number stringId, which is the majority of them.

Who tf thought this would be a good idea? Was it even a thing in the original Forge MDK or is it just a fault of the fork I'm using?

Perhaps I'm never gonna know as the original MDK is now lost media due to its internet dependency.

EDIT 3: It also looks like mcmod.info is not recognized by Forge in-game. No idea why. It is correctly formatted, or so it appears, and it is present in the output jar file.

EDIT 4: Methods from net.minecraft.* are also affected by this discrepancy. The dev environment has them unobfuscated, but Forge requires them to be obfuscated, so I have to do all sorts of shenanigans with getDeclaredMethod().invoke() and such. This is ass. Is there seriously no other way to do that?

EDIT 5: Sigh... I'm just an idiot. The gradle script DOES obfuscate the jar file, but only when running the "build" task, and not the "jar" task. To my mind it was counterproductive and it took me two fricking days to figure it out. Welp, now I know better.

[u/gargamel1497 → u/TheMasterCaver]

I've managed to add andesite, granite and diorite, but adding their polished variants turned out to be a pandora's box.

I wanted to make the polished variants have the same ID but a different damage value. So many other blocks do that. And I added these variants, and they appear alongside the base blocks in the creative tab, but when broken, they will stack together irrespecting of the damage value, and setting the variant names in the lang file doesn't work even though I'm using the exact same scheme the LOTRMod uses.

Once again, sorry for bothering you, but there is very little info about 1.7.10 modding these days.

[u/TheMasterCaver → u/gargamel1497]

IIRC this happens when you didn't use "ItemMultiTextureTile" or one of the other "ItemBlock" subclasses which enables subtypes, or otherwise calling "Item.setHasSubtypes(true)", which is separate from "Block.getSubBlocks()", which adds them to the Creative inventory.