oldcheese

Didn't work after I added it. Immediately worked after I restarted my pc (?) No clue how the hell that worked. Most likely there was a bugged build still going on untill the restart. Thanks for the help regardless.

Alright, thank you. I know not to put it in the mod folder now. Mekanism blocks still don't get loaded. So my question: How can I actually launch other people's mods along with mine on runClient to test this out? I now have the runtimeOnly ones like Mekanism told me, but there's definitely 0 mekanism blocks when I launch the game. I do understand that I'm the one asking for help, if it's not possible just tell me outright. It's a bit frustrating to not be able to get this done, at this point I'm just going to assume pulling stuff out of the block using pipes will work. Am I stuck just compiling, adding it to a modpack and launching it with those mods every time I want to test?

Having the corresponding version of mekanism in the run/mods folder gives me the same error even with runtimeOnly and following Mekanism's exact instructions. Not having the mod inside mods/run produces no mekanism blocks in game. To reiterate. My goal is simply to have Mekanism installed into my client so I can test interactivity with pipes and the like. I'm not looking to use any API as a hard dependency. I simply want to click 'runclient' and be able to put down both my blocks and Mekanisms. Maybe I misrepresented my goal.

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 = '0.0.1' group = 'com.cheese.mattercraft' // http://maven.apache.org/guides/mini/guide-naming-conventions.html archivesBaseName = 'Mattercraft' 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: '20201028-1.16.3' // 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', 'info' mods { examplemod { 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', 'info' mods { examplemod { 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', 'info' // Specify the modid for data generation, where to output the resulting resource, and where to look for existing resources. args '--mod', 'examplemod', '--all', '--output', file('src/generated/resources/'), '--existing', file('src/main/resources/') mods { examplemod { source sourceSets.main } } } } } // Include resources generated by data generators. sourceSets.main.resources { srcDir 'src/generated/resources' } repositories { maven { url 'https://modmaven.dev/' } } 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.4-35.1.15' // 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' // These dependencies get remapped to your current MCP mappings // deobf 'com.mod-buildcraft:buildcraft:6.0.8:dev' compileOnly "mekanism:Mekanism:${mekanism_version}:api" implementation fg.deobf("mekanism:Mekanism:${mekanism_version}")// core // 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": "examplemod", "Specification-Vendor": "examplemodsareus", "Specification-Version": "1", // We are version 1 of ourselves "Implementation-Title": project.name, "Implementation-Version": "${version}", "Implementation-Vendor" :"examplemodsareus", "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" } } } There you go.

Welp. I've added the Mekanism Repository to my repositories in build.grade and added the following lines to my dependancies: implementation fg.deobf("mekanism:Mekanism:1.16.4-10.0.18.445") Now I get > Cannot find a version of 'mekanism:Mekanism' that satisfies the version constraints: Dependency path 'com.cheese.mattercraft:mattercraft:0.0.1' --> 'mekanism:Mekanism:1.16.4-10.0.18.445' Dependency path 'com.cheese.mattercraft:mattercraft:0.0.1' --> 'mekanism:Mekanism' strictly '1.16.4-10.0.18.445_mapped_snapshot_20201028-1.16.3' I've also tried the steps outlined in the Mekanism readme which proved usefull in helping me understand dependencies, but ultimately failed to add any mekanism usability to my launch.

Hey guys. It's been a while. I'm trying to add other mods to my IntelliJ environment to load alongside mine to test interactions. However, when I launch mods I always get NoSuchMethod errors. I've checked the forums for similar interactions, but to no avail. Time: 12/28/20 12:57 PM Description: Mod loading error has occurred java.lang.Exception: Mod Loading has failed at net.minecraftforge.fml.CrashReportExtender.dumpModLoadingCrashReport(CrashReportExtender.java:85) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading} at net.minecraftforge.fml.client.ClientModLoader.completeModLoading(ClientModLoader.java:188) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading,pl:runtimedistcleaner:A} at net.minecraft.client.Minecraft.lambda$null$1(Minecraft.java:513) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A} at net.minecraft.util.Util.acceptOrElse(Util.java:323) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading} at net.minecraft.client.Minecraft.lambda$new$2(Minecraft.java:509) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A} at net.minecraft.client.gui.ResourceLoadProgressGui.render(ResourceLoadProgressGui.java:113) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading,pl:runtimedistcleaner:A} at net.minecraft.client.renderer.GameRenderer.updateCameraAndRender(GameRenderer.java:492) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A} at net.minecraft.client.Minecraft.runGameLoop(Minecraft.java:1002) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A} at net.minecraft.client.Minecraft.run(Minecraft.java:612) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading,pl:accesstransformer:B,pl:runtimedistcleaner:A} at net.minecraft.client.main.Main.main(Main.java:184) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {re:classloading,pl:runtimedistcleaner:A} at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_131] {} at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_131] {} at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_131] {} at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_131] {} at net.minecraftforge.userdev.FMLUserdevClientLaunchProvider.lambda$launchService$0(FMLUserdevClientLaunchProvider.java:52) ~[forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {} at cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(LaunchServiceHandlerDecorator.java:37) [modlauncher-8.0.6.jar:?] {} at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:54) [modlauncher-8.0.6.jar:?] {} at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:72) [modlauncher-8.0.6.jar:?] {} at cpw.mods.modlauncher.Launcher.run(Launcher.java:82) [modlauncher-8.0.6.jar:?] {} at cpw.mods.modlauncher.Launcher.main(Launcher.java:66) [modlauncher-8.0.6.jar:?] {} at net.minecraftforge.userdev.LaunchTesting.main(LaunchTesting.java:105) [forge-1.16.4-35.1.15_mapped_snapshot_20201028-1.16.3-recomp.jar:?] {} This is the way I figured I could add an external mod. If someone could point me in the right direction on how I get this to work. I apparantly don't have enough knowledge of Gradle to properly google such things. Edit: I just realized this is probably in the wrong subforum alltogether. My apologies.

While I do not want to go off topic. I do like the fact that you seemingly made an account just to tell this person this.

Hello there. 1.8 is no longer supported on this forum due to it's age. Additionally you haven't attached an error log.

Do you mean a server wrapper like Admincraft that allows you to restart/show console/regulate ram from the web? The most 'common' one as far as I know is McMyAdmin.

Are there any errors? Are you sure you've put your texture in the correct folder? I'm not quite sure on this, but do you need to implement IHasModel? If you're simply making a 'basic' armourpiece then all you need to do is extend ItemArmor. If the item appears, 'works' (Has the right armour values etc.) and has names/stats except for the black and purple texture than all that's wrong is that it's either missing a texture or a model. Edit: An armour I have made in 1.12 follows the following structure: package com.cheese.brpg.item; import com.cheese.brpg.main; import net.minecraft.inventory.EntityEquipmentSlot; import net.minecraft.item.ItemArmor; public class ItemTestarmor extends ItemArmor { public ItemTutorialArmor(ArmorMaterial material, EntityEquipmentSlot equipmentSlot) { super(material, 0, equipmentSlot); setCreativeTab(brpg.RANDOM_SHIT); } }

https://mcforge.readthedocs.io/en/latest/models/blockstates/forgeBlockstates/ Usage of blockstates is found here. That page should be all you need. If you want to use it to it's fullest potential you might want to use an IStateMapper. I also want to say that if you want more than 16 ish colours, then using a tileEntity is simply easier. You can register them quite easily and probably should learn how to use them since they're very usefull for a variety of things.

Forgelin is a prerequisite of one of the mods you're running. I get the distinct feeling you're not reading the pages of the mods you're installing before installing them.

That's what I thought. I was just checking. English comprehension isn't my strongest suit. Thanks for all the help!

Are you running https://www.curseforge.com/minecraft/mc-mods/shadowfacts-forgelin ?

Thanks! I was just wondering because there's not a lot of documentation for 1.14 yet. I'll just follow 1.13 and adapt. Thanks again! Edit: I know I'm probably an idiot. Is there a 1.12 to 1.13 primer. Or is this not needed considering that 1.13 was an 'inbetween' version as you state?

A quick google reveals that the 1.12 version requires PTRLib. I mean look at the curseforge site. It's literally font size 5000. So you probably should've noticed it :)

Welp. I've been gone for ages. Mostly due to rl being crazy (Graduation year at college.) So I've been looking to update my mods and stuff. My main two questions are. 1. What version should I update to. Currently files are 1.12, should I go for 1.14? I see the forge versions are updated to 1.14.4 yet the documentation is just updated to 1.13 2. What are the main changes between 1.12 and 1.14. I do realize that stuff has been kept the same a lot since the overhauls to listeners. I heard that all drops are now in loot tables? Thanks in advance.

I was getting that mixed up! That's exactly what I needed for an answer. Thanks. I was somehow under the impression that there were differences. This is solved.

I'm looking to understand what happens when a capability is called. I don't have an actual problem. So I'm not loading the entire capability information object whenever I use the getCapability code? I'm just getting an interface so I can interact with a part of the object without crashing? And when I use the ItemStackHandler for example, I'm not getting literal info. I'm just 'loading' the interface so to speak, so I can then interact with the object that exists somewhere on my machine? So that would mean that having a single capability that contains many values would be as fast to load as having three/four capabilities with the values split among them? I feel like I might not have adequately clarified my question. I think you answered my first question about how capabilities are called if the above is true and I'm understanding it right. so imagine the following: Imagine if I had a capability that stored a single Integer. on tick 1, code X would load and initiate a 'getCapability' line to get the interface/capability and interact with it. on tick 2, a different class of my code would change the integer of my capability from 2 to 5. on tick 3, I would call the getInteger method from code X without using 'getCapability' again. Would I get 2 or 5? From what I understand from your comment I should get 5. But I could really try this myself once I get back home. I'd rather know if the above assumption is correct in that getting a value from a small capability is the same as getting one from a big capability. English is not my main language, so I might be constructing my questions a bit weird. I'm sorry if it's annoying.

So is what I'm passing on to my code a reference to where the capability is stored, or a copy of the capability itself? I'm calling the handler with a final method. So I'm guessing that I can change the state of the original object, but the values contained in 'handler' will always be the same untill I call it again?

Hey guys. I've been rather idle lately. Busy porting stuff to 1.12 and finishing up college. I'm trying to get a deeper understanding of capabilities and the ways they're called and gotten from the server/client. Possibly I should be doing research into how objects are stored/remembered in your java program as a whole. But I'm having very little luck with finding sources on that. So when I try to use a capability in a class I use a static method getHandler to get it. I can't tell if the getcapability is static or not. Does it create a new object with the information of my capability in it and passes that to the class, or does it simply pass on a reference to the capability that's already in play? For example. I'm making a GUI That will be able to change depending on a variable stored in the capabilities of the player. I have a handler and 'get' that by using private final IStats handler = CustomStatsHandler.getHandler(Minecraft.getMinecraft().player); then I get the value as such, nothing really too interesting: int i = handler.getInt(); for example. If I change the value of handler.getInt() in another class yet NOT use my gethandler method again, would I get an updated int, or would I have to use my gethandler yet again to get an updated value? I'm also trying to decide if it's more efficient to put all capability data I have in seperate capabilities by 'category' or if I should just put them all into a single one. I'm mostly worried about possible lag if clients need to try and load capability data every few seconds and the capability cointains 20 values. Sorry if my question is stupid. It's been a while since I worked on coding. Cheers in advance.

I do know that https://ore.spongepowered.org/Erigitic/Total-Economy is one.

Your best sollution could be to just debug Start adding System out messages throughout your code. Add one in the switch you use to call the GUI, add one in the initialization for the GUI. That way you can tell if the GUI is opened at all or if it's just not rendering. It's really hard for us to figure out what's going on. Since you have about 15 classes here and all of them could have mistakes. It's very rare for something to not work without giving you even an error. I'm not used to interpreting code that doesn't use brackets for if statements. It's rather untidy to look at. Anyway, considering it gave an error when you right clicked the GUI about the slots. We can probably assume that the GuiContainer is at least trying to load.

So there's no error in the log right now but the UI still doesn't show anything? Does a 'blank' GUI open that has nothing in it? I'm gonna be gone for a few hours but I'll try to look at it more closely once I get back.

You have the following code: public SlotPestleOutput(EntityPlayer player, TileEntityPestle tileentity, int index, int xPosition, int yPosition) { super((IItemHandler) tileentity, index, xPosition, yPosition); this.player = player; } Where you're trying to cast a Tileentity to IItemHandler. Now you can usually cast for example an int to a double. Because they both essentially can contain very similar information. Or you can cast a class that implements another class to the original class. IItemHandler has nothing to do with tileentities. It's an interface that assists with the Capability you use to add itemslots to something. Now your super takes an IItemhandler, because it's trying to read the item from the slot. But you're trying to give it an TileEntity. That doesn't make sense. Instead you should just pass it the CAPABILITY attached to your tileentity so it can retrieve the information. Right now I'm browsing through your classes to see exactly why you feel the need to make a custom slot. I'm guessing what you're trying to do is get 1 item from the player's capability and 2 slots for the actual item? You could solve this by just passing the player's capability onto the slot and doing something like such: ContainerPestle(TileEntityPestle tileentity, EntityPlayer player) { /*note how I required a player to be passed along. This keeps us from having to get player from Inventoryplayer. Because it's more convenient to get the inventory from the player than it is getting the player from the inventory. */ this.tileentity = tileentity; this.addSlotToContainer(new SlotItemHandler(tileentity.getCapability(CapabilityItemHandler.ITEM_HANDLER_CAPABILITY, null), 0, 32, 25)); this.addSlotToContainer(new SlotItemHandler(tileentity.getCapability(CapabilityItemHandler.ITEM_HANDLER_CAPABILITY, null), 1, 67, 44)); this.addSlotToContainer(new SlotPestleOutput(player, player.getCapability(ITEM_HANDLER_CAPABILITY, null), 2, 124, 35)); //I've changed your slot to take an IItemhandler instead of an tileentity. for(int y = 0; y < 3; ++y) { //Player Inv for(int x = 0; x < 9; ++x) { this.addSlotToContainer(new Slot(player, x + y * 9 + 9, 8 + x * 18, 84 + y * 18)); } } for(int x = 0; x < 9; ++x) //Hotbar this.addSlotToContainer(new Slot(player, x, 8 + x * 18, 142 )); } Then your custom slot can be as such: public SlotPestleOutput(EntityPlayer player, IItemhandler itemhandler, int index, int xPosition, int yPosition) { super(itemhandler, index, xPosition, yPosition); //note how we can now properly pass along the capability Itemhandler, since we got it from the original GUI. this.player = player; } By changing the container to give us a player we also need to change a few things in our GuiHandler. Obviously it should now read player instead of player.inventory where applicable. I hope that helps. What is your goal for making a new type of slot ? I see why you'd make one, but I'm not sure what your slot class here has that you wouldn't get from a regular IItemhandler slot. regardless. you ALWAYS have to hand an IItemhandler to the item if you want to extend SlotItemHandler for your custom slot.