Jump to content

Build terminates at :extractRangemapReplacedMain


CraftedCart

Recommended Posts

I have a mod set up and it works fine when running

:runClient

with Gradle. The issue I have though, is that when running

:build

, the build terminates at

:extractRangemapReplacedMain

. This only seems to happen for one of my mods though. That depends on another mod which builds just fine.

 

I've tried running

gradle clean

, deleting ~/.gradle, as well as deleting my mod's

.gradle

and

build

folders. Doing neither helped.

 

Forge Vesion:

1.9.4-12.17.0.1990

 

gradle build

output:

 

#################################################
         ForgeGradle 2.2-SNAPSHOT-0447b4e        
  https://github.com/MinecraftForge/ForgeGradle  
#################################################
               Powered by MCP unknown               
             http://modcoderpack.com             
         by: Searge, ProfMobius, Fesh0r,         
         R4wk, ZeuX, IngisKahn, bspkrs           
#################################################
Found AccessTransformer: cargo_at.cfg
:deobfCompileDummyTask
:deobfProvidedDummyTask
:sourceApiJava
:FluidUI:compileJava
Note: /Users/Mike/Developer/IdeaProjects/FluidUI/src/main/java/io/github/craftedcart/fluidui/FontCache.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:FluidUI:processResources UP-TO-DATE
:FluidUI:classes
:FluidUI:jar
:FluidUIMinecraftAdditions:deobfCompileDummyTask
:FluidUIMinecraftAdditions:deobfProvidedDummyTask
:FluidUIMinecraftAdditions:sourceApiJava
:FluidUIMinecraftAdditions:compileApiJava UP-TO-DATE
:FluidUIMinecraftAdditions:processApiResources UP-TO-DATE
:FluidUIMinecraftAdditions:apiClasses UP-TO-DATE
:FluidUIMinecraftAdditions:sourceMainJava
:FluidUIMinecraftAdditions:compileJava
:FluidUIMinecraftAdditions:processResources
:FluidUIMinecraftAdditions:classes
:FluidUIMinecraftAdditions:jar
:compileApiJava UP-TO-DATE
:processApiResources UP-TO-DATE
:apiClasses UP-TO-DATE
:sourceMainJava
:compileJava
Note: /Users/Mike/Developer/Minecraft Mod Projects/Cargo/build/sources/main/java/io/github/craftedcart/cargo/util/StringManager.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
:processResources
:classes
:jar
:sourceTestJava
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:extractMcpData SKIPPED
:extractMcpMappings SKIPPED
:getVersionJson
:extractUserdev UP-TO-DATE
:genSrgs SKIPPED
:reobfJar
:extractRangemapReplacedMain
/Users/Mike/Developer/Minecraft Mod Projects/Cargo/build/sources/main/java
> Building 55% > :extractRangemapReplacedMain%

 

 

build.gradle

:

 


// For those who want the bleeding edge
buildscript {
    repositories {
        jcenter()
        maven {
            name = "forge"
            url = "http://files.minecraftforge.net/maven"
        }
    }
    dependencies {
        classpath 'net.minecraftforge.gradle:ForgeGradle:2.2-SNAPSHOT'
    }
}
apply plugin: 'net.minecraftforge.gradle.forge'

/*
// for people who want stable - not yet functional for MC 1.8.8 - we require the forgegradle 2.1 snapshot
plugins {
    id "net.minecraftforge.gradle.forge" version "2.0.2"
}
*/
version = "1.0"
group= "io.github.craftedcart.cargo" // http://maven.apache.org/guides/mini/guide-naming-conventions.html
archivesBaseName = "Cargo"

//Java 1.8 required
sourceCompatibility = 1.8
targetCompatibility = 1.8

minecraft {
    version = "1.9.4-12.17.0.1990"
    runDir = "run"
    
    // 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 allways work.
    // simply re-run your setup task after changing the mappings to update your workspace.
    mappings = "snapshot_20160518"
    // makeObfSourceJar = false // an Srg named sources jar is made by default. uncomment this to disable.
}

dependencies {
    // 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"
      
    // 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'

    // the deobf configurations:  'deobfCompile' and 'deobfProvided' are the same as the normal compile and provided,
    // except that these dependencies get remapped to your current MCP mappings
    //deobfCompile 'com.mod-buildcraft:buildcraft:6.0.8:dev'
    //deobfProvided 'com.mod-buildcraft:buildcraft:6.0.8:dev'

    // for more info...
    // http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html
    // http://www.gradle.org/docs/current/userguide/dependency_management.html

    compile project(':FluidUI')
    compile project(':FluidUIMinecraftAdditions')

}

jar {
    manifest {
        attributes 'FMLAT': 'cargo_at.cfg'
    }
}

processResources
{
    // this will ensure that this task is redone when the versions change.
    inputs.property "version", project.version
    inputs.property "mcversion", project.minecraft.version

    // replace stuff in mcmod.info, nothing else
    from(sourceSets.main.resources.srcDirs) {
        include 'mcmod.info'
                
        // replace version and mcversion
        expand 'version':project.version, 'mcversion':project.minecraft.version
    }
        
    // copy everything else, thats not the mcmod.info
    from(sourceSets.main.resources.srcDirs) {
        exclude 'mcmod.info'
    }
}

 

 

settings.gradle

:

 

include ':FluidUI'
project(':FluidUI').projectDir = new File(settingsDir, '../../IdeaProjects/FluidUI')

include ':FluidUIMinecraftAdditions'
project(':FluidUIMinecraftAdditions').projectDir = new File(settingsDir, '../FluidUIMinecraftAdditions')

 

Link to comment
Share on other sites

  • 3 months later...

I found that this problem occurs when I define a constructor of a class defined in a location that can not be reached from outside.

 

// A.java
public class A {
public void example() {
	// class in method
	class B {
		// constructor of class
		public B() {
			// define constructor
		}
	}
	new B();
}
}

It should be solved by defining it to be visible from the outside.

// A.java
public class A {
public void example() {
	new B();
}

// class in class
class B {
	// constructor of class
	public B() {
		// define constructor
	}
}
}

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I am not using hardcoded recipes, I'm using Vanilla's already existing code for leather armor dying. (via extending and implementing DyeableArmorItem / DyeableLeatherItem respectively) I have actually figured out that it's something to do with registering item colors to the ItemColors instance, but I'm trying to figure out where exactly in my mod's code I would be placing a call to the required event handler. Unfortunately the tutorial is criminally undescriptive. The most I've found is that it has to be done during client initialization. I'm currently trying to do the necessary setup via hijacking the item registry since trying to modify the item classes directly (via using SubscribeEvent in the item's constructor didn't work. Class so far: // mrrp mrow - mcmod item painter v1.0 - catzrule ch package catzadvitems.init; import net.minecraft.client.color.item.ItemColors; import net.minecraft.world.item.Item; import net.minecraftforge.registries.ObjectHolder; import net.minecraftforge.fml.event.lifecycle.FMLClientSetupEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.eventbus.api.SubscribeEvent; import net.minecraftforge.client.event.ColorHandlerEvent; import catzadvitems.item.DyeableWoolArmorItem; @Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD) public class Painter { @ObjectHolder("cai:dyeable_wool_chestplate") public static final Item W_CHEST = null; @ObjectHolder("cai:dyeable_wool_leggings") public static final Item W_LEGS = null; @ObjectHolder("cai:dyeable_wool_boots") public static final Item W_SOCKS = null; public Painter() { // left blank, idk if forge throws a fit if constructors are missing, not taking the chance of it happening. } @SubscribeEvent public static void init(FMLClientSetupEvent event) { new Painter(); } @Mod.EventBusSubscriber private static class ForgeBusEvents { @SubscribeEvent public static void registerItemColors(ColorHandlerEvent.Item event) { ItemColors col = event.getItemColors(); col.register(DyeableUnderArmorItem::getItemDyedColor, W_CHEST, W_LEGS, W_SOCKS); //placeholder for other dye-able items here later.. } } } (for those wondering, i couldn't think of a creative wool helmet name)
    • nvm found out it was because i had create h and not f
    • Maybe there's something happening in the 'leather armor + dye' recipe itself that would be updating the held item texture?
    • @SubscribeEvent public static void onRenderPlayer(RenderPlayerEvent.Pre e) { e.setCanceled(true); model.renderToBuffer(e.getPoseStack(), pBuffer, e.getPackedLight(), 0f, 0f, 0f, 0f, 0f); //ToaPlayerRenderer.render(); } Since getting the render method from a separate class is proving to be bit of a brick wall for me (but seems to be the solution in older versions of minecraft/forge) I've decided to try and pursue using the renderToBuffer method directly from the model itself. I've tried this route before but can't figure out what variables to feed it for the vertexConsumer and still can't seem to figure it out; if this is even a path to pursue.  The vanilla model files do not include any form of render methods, and seem to be fully constructed from their layer definitions? Their renderer files seem to take their layers which are used by the render method in the vanilla MobRenderer class. But for modded entities we @Override this function and don't have to feed the method variables because of that? I assume that the render method in the extended renderer takes the layer definitions from the renderer classes which take those from the model files. Or maybe instead of trying to use a render method I should be calling the super from the renderer like   new ToaPlayerRenderer(context, false); Except I'm not sure what I would provide for context? There's a context method in the vanilla EntityRendererProvider class which doesn't look especially helpful. I've been trying something like <e.getEntity(), model<e.getEntity()>> since that generally seems to be what is provided to the renderers for context, but I don't know if it's THE context I'm looking for? Especially since the method being called doesn't want to take this or variations of this.   In short; I feel like I'm super super close but I have to be missing something obvious? Maybe this insane inane ramble post will provide some insight into this puzzle?
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.