![]() shimForgeLibraries task predownloads Forge's runtime-downloaded deps and places them in the location Forge expects, because the URLs hardcoded in forge are long dead.runClient gets in-game (on at least 1.4.7 and 1.5.2).Asset downloading, in the old file layout that legacy versions use.genSources (sans methods with MCP messed-up switchmaps), attaching sources in intellij, browsing and find usages, MCP comments in source code.1.6/maybe 1.7: parse and apply gdiff archive.Patching Minecraft with Forge's classes:.Downloading Minecraft, merging the jars, remapping, etc (the usual from a minecraft toolchain).Forge's Maven is configured for you with free bonus metadataSources forward-compat magic for gradle 5+.If you're looking for general 1.4 Forge development advice, try here. Investigate some of the file paths written to the log see if there's any weird things like corrupt or empty files.Try dumping the cache: run with -refresh-dependencies (to enable the global refresh-dependencies mode) or -Pvoldeloom.refreshDependencies (to refresh only Voldeloom artifacts).Run with -info -stacktrace for much more detailed log output.Just use the runClient Gradle task for launching purposes. Don't use the IDE integration like genIdeaRuns yet.set( 6) //Forge doesn't understand classes compiled to versions of the class-file format newer than Java 6's String minecraftVersion = "1.4.7 " String forgeVersion = "1.4.7-6.6.2.534 " of( 11) //Last version able to set a -release as low as 6ĬompileJava. ![]() These workspaces are much more well-tested.Īlso: this should go without saying, but do not bother the official Forge community with support requests.Ĭlasspath "agency.highlysuspect:voldeloom:2.4 "Īpply plugin: " " I strongly suggest testing the release version of your mod often in a "real" Forge production environment, like a Prism Launcher Forge instance. Additionally: there's a healthy dose of secret strips of duct-tape used to get things working, some important aspects of modding that you can't do yet, and a lot that's just plain WIP. There are behavioral differences with just about all of these components. The MCP parsers and remappers and jar mergers and jar processors and access-transformers and other components used in this plugin share no lineage with anything Forge or MCP ever used. They patch source code, we install Forge like a jarmod. This project implements a Forge modding toolchain from first principles, using a radically different approach than MCP/ForgeGradle ever did. Take this project with a grain of salt, especially the runClient dev workspace. □ -> I think it's possible? Haven't tested it yet.Yes it's possible to develop mods like that. ![]() "Deobf" -> A working runClient environment, with MCP names and IDE debugger, that you can use to test your mod without needing to build a release jar and copy it into a real Minecraft launcher."Release" -> You might be able to drop these mods into a production Forge environment. ![]() ![]() The sample mod links against a few classes from Forge and Minecraft, so at least some amount of project setup works.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |