[TUTORIAL] Getting Started with ForgeGradle
By
GrygrFlzr, in ForgeGradle
-
Recently Browsing
No registered users viewing this page.
-
Posts
-
By diesieben07 · Posted
Dungeon chests are not marked in a special way. They are simply chests, inside the dungeon structure, which have a loot table set on them. You would have to write your own loot table condition which checks that you are inside the dungeon structure. -
I was thinking that might be the problem with the imports, and i'll try that. Have any advice on making a serialized json for this specific issue? -
By diesieben07 · Posted
Make sure your version of Forge is up to date. -
Hello there! I'm currently working on a personal mod, and I have a number of custom items I want to show up as loot in dungeon chests. I've taken a look at the Global Loot Modifier documentation, as well as the 1.13.x loot table documentation. I have a couple of problems: 1. In my hour of internet searching I cannot find anything on conditions (as part of the serialized json) related to dungeon chests. 2. The import statements: import net.minecraftforge.common.loot.GlobalLootModifierSerializer; import net.minecraftforge.common.loot.LootModifier; ...Are not importing correctly, and are showing up red wherever I use them. Some further information: I'm currently using VSCode as a development environment. The Items in question are simple items, and their only purpose is to be crafted into other items. If there is an easier way that does not interfere with other potential mods, I will get on my knees and beg you for the documentation. If there is any more information I need to provide, please reply and let me know. As a side note, this is a very simple action I'm trying to do. It should not in any way require the confusing mess that is the Global Loot Modifier, especially when the documentation is barebones. If this is the only way to do it, there should be significantly more documentation. Such a simple action should not require this much work.
-
I finally figured it out. It was a combination of two things that were keeping me from the solution. First, I made a dumb mistake that took forever to track down. I just happened across a post that mentioned it. And two, knowledge. I know Java, but I am very new to gradle. Thanks to everyone you chimed in and provided tidbits of knowledge and pointers for me to research, learn, and seek after. I now have a better working understanding of how to read gradle.build files. Ok, back to the first piece. Everywhere I looked, everyone and everything was telling me to put my mods in the 'libs' folder for forge to pick them up in a dev environment. I thought this meant 'build/libs'. Dumb mistake, but what everyone was talking about was a 'libs' folder that you have to create (if not there) at the root level (same level as build.gradle file). Once I corrected this, things started to flow. Second, here is a copy of my working build.gradle file: buildscript { repositories { maven { url = 'https://files.minecraftforge.net/maven' } jcenter() mavenCentral() } dependencies { classpath group: 'net.minecraftforge.gradle', name: 'ForgeGradle', version: '3.+', changing: true } } apply plugin: 'net.minecraftforge.gradle' // Only edit below this line, the above code adds and enables the necessary things for Forge to be setup. apply plugin: 'eclipse' apply plugin: 'maven-publish' version = '1.0' group = 'com.blargsworkshop.horsepocket' // http://maven.apache.org/guides/mini/guide-naming-conventions.html archivesBaseName = 'Horse Pocket-1.16.1' sourceCompatibility = targetCompatibility = compileJava.sourceCompatibility = compileJava.targetCompatibility = '1.8' // Need this here so eclipse task generates correctly. println('Java: ' + System.getProperty('java.version') + ' JVM: ' + System.getProperty('java.vm.version') + '(' + System.getProperty('java.vendor') + ') Arch: ' + System.getProperty('os.arch')) minecraft { // The mappings can be changed at any time, and must be in the following format. // snapshot_YYYYMMDD Snapshot are built nightly. // stable_# Stables are built at the discretion of the MCP team. // Use non-default mappings at your own risk. they may not always work. // Simply re-run your setup task after changing the mappings to update your workspace. mappings channel: 'snapshot', version: '20200723-1.16.1' // makeObfSourceJar = false // an Srg named sources jar is made by default. uncomment this to disable. // accessTransformer = file('src/main/resources/META-INF/accesstransformer.cfg') // Default run configurations. // These can be tweaked, removed, or duplicated as needed. runs { client { workingDirectory project.file('run') // Recommended logging data for a userdev environment property 'forge.logging.markers', 'SCAN,REGISTRIES,REGISTRYDUMP' // Recommended logging level for the console property 'forge.logging.console.level', 'debug' mods { horsepocket { source sourceSets.main } } } server { workingDirectory project.file('run') // Recommended logging data for a userdev environment property 'forge.logging.markers', 'SCAN,REGISTRIES,REGISTRYDUMP' // Recommended logging level for the console property 'forge.logging.console.level', 'debug' mods { horsepocket { source sourceSets.main } } } data { workingDirectory project.file('run') // Recommended logging data for a userdev environment property 'forge.logging.markers', 'SCAN,REGISTRIES,REGISTRYDUMP' // Recommended logging level for the console property 'forge.logging.console.level', 'debug' args '--mod', 'horsepocket', '--all', '--output', file('src/generated/resources/') mods { horsepocket { source sourceSets.main } } } } } repositories { flatDir { dirs 'libs' } } dependencies { // Specify the version of Minecraft to use, If this is any group other then 'net.minecraft' it is assumed // that the dep is a ForgeGradle 'patcher' dependency. And it's patches will be applied. // The userdev artifact is a special name and will get all sorts of transformations applied to it. minecraft 'net.minecraftforge:forge:1.16.1-32.0.98' // You may put jars on which you depend on in ./libs or you may define them like so.. // compile "some.group:artifact:version:classifier" // compile "some.group:artifact:version" implementation fg.deobf("com.blargsworkshop.common:Blargs Workshop-1.16.1-1.0:1.0") // Real examples // compile 'com.mod-buildcraft:buildcraft:6.0.8:dev' // adds buildcraft to the dev env // compile 'com.googlecode.efficient-java-matrix-library:ejml:0.24' // adds ejml to the dev env // The 'provided' configuration is for optional dependencies that exist at compile-time but might not at runtime. // provided 'com.mod-buildcraft:buildcraft:6.0.8:dev' // These dependencies get remapped to your current MCP mappings // deobf 'com.mod-buildcraft:buildcraft:6.0.8:dev' // deobf 'com.blargsworkshop.common:Blargs Workshop-1.16.1-1.0:1.0' // For more info... // http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html // http://www.gradle.org/docs/current/userguide/dependency_management.html } // Example for how to get properties into the manifest for reading by the runtime.. jar { manifest { attributes([ "Specification-Title": "horsepocket", "Specification-Vendor": "horsepocketsareus", "Specification-Version": "1", // We are version 1 of ourselves "Implementation-Title": project.name, "Implementation-Version": "${version}", "Implementation-Vendor" :"horsepocketsareus", "Implementation-Timestamp": new Date().format("yyyy-MM-dd'T'HH:mm:ssZ") ]) } } // Example configuration to allow publishing using the maven-publish task // This is the preferred method to reobfuscate your jar file jar.finalizedBy('reobfJar') // However if you are in a multi-project build, dev time needs unobfed jar files, so you can delay the obfuscation until publishing by doing //publish.dependsOn('reobfJar') publishing { publications { mavenJava(MavenPublication) { artifact jar } } repositories { maven { url "file:///${project.projectDir}/mcmodsrepo" } } } The parts I added/changed to make it work. repositories { flatDir { dirs 'libs' } } This piece turns the new 'libs' folder I created into a repository so I can reference jars inside the folder in the dependency area which is the next change. dependencies { // ... implementation fg.deobf("com.blargsworkshop.common:Blargs Workshop-1.16.1-1.0:1.0") } I added the implementation line into the dependency area. As far as I can tell here is the breakdown I learned: implementation -- means about the same as using the compile keyword which tells gradle to compile this dependency into the build. fg.deobf -- is a method provided by ForgeGradle that transforms the jar from the obfuscated form into the obfuscated form. I'm not really clear about this so don't quote me. But in essence this dependency is a forge mod that I made myself. com.blargsworkshop.common -- This syntax is part of the "maven coordinates" structure (google it!). This first piece is actually not needed in that it can be anything. When pulling from the flatDir { } repository, this first piece of the coordinate gets ignored. Blargs Workshop-1.16.1-1.0 -- This piece is the name of the Jar file (aka artifact) (originally, I was leaving off the '-1.0' since that was the version, but don't do that.) 1.0 -- This last piece is the version. Also specified up higher in the gradle.build (of the dependency mod!) With all these piece in place I got my mod building and both mods installed and running when I run 'gradlew runClient'. Again, thanks for all those that helped and provided clues along the way. I hope this post breaks a few concepts down and makes it easy for newcomers learning gradle as well.
-
-
Topics
-
-
Who's Online (See full list)
