Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Weirdness when opening item via keybind b4 it has been initialised via r-click


Recommended Posts

Well, here's the scenario:

I have my Wireless Crafting Terminal mod which is an item that has slots for various things.

One of those things is a filterable magnet upgrade, which upon right-click opens a GUI.

I also have a keybind performing the same action (opening the GUI), but of course done via packets.

 

The issue is initial saving of NBT data.

 

If I right-click using the item, it "initializes" it. and then I can put items in the filter slots and so forth.

At this point everything is great. The keybind functions, NBT data is saved and all is well.

 

However, if I create the magnet item and place it in it's appropriate slot in my Wireless Crafting Terminal without first right-clicking and then try to access the magnet GUI, it does open the magnet GUI, but none of the NBT data is saved when I add items to the filter list or change the mode from whitelisting to blacklisting.

 

This issue is referenced on my GitHub repo @ https://github.com/p455w0rd/WirelessCraftingTerminal/issues/7

 

Any ideas?

 

Note: 1.7.10

 

Also, if you just want to install the mod to reproduce what I'm talking about, get it @ http://minecraft.curseforge.com/projects/wireless-crafting-terminal

Link to post
Share on other sites

Okay, so I've tried setting an empty NBT tag as soon as the item is created thinking that maybe that was the problem. It's certainly not. I even tried automatically adding a stack on creation using a new Instantiation of InventoryMagnetFilter (specifically I tried InventoryMagnetFilter#setInventorySlotContents) to no avail. This wouldn't make sense though since using the "Whitelisting/Blacklisting" button has nothing to do with the inventory and it has no effect either. It just seems that until it is initialized via right-click, it somehow references a wrong instantiation of the ItemStack. I was thinking client/server sync might be the problem, but since it works after the initial right-click I think that is ruled out. It's like it references a new instance of the itemstack until the item is initialized via right click. After that it references correctly. The item is retrieved via RandomUtils#getMagnet. I should also note that if the keybind is used and the item is held/in InventoryPlayer, it also works fine. RandomUtils#getMagnet first tries to get the held item if it's the magnet and this works. also if there is no magnet in the WCT, but there is one in player's inventory, it works fine as RandomUtils#getMagnet does this check as a final check for returning the magnet ItemStack before giving up and returning null. It only fails to initialize when first inserted into the custom inventory (InventoryMagnet instantiated in ContainerWirelessCraftingTerminal) and the keybind is then used without first having right-clicked with item in-hand.

Link to post
Share on other sites

It may help if you posted some of the code related to the issue.  If you haven't already i would recommend implementing an item NBT helper. It will make working with NBT much easier and may or may not help you solve your problem.

Here is mine (You can copy it if you like) https://github.com/brandon3055/BrandonsCore/blob/master/src/main/java/com/brandon3055/brandonscore/common/utills/ItemNBTHelper.java

I am the author of Draconic Evolution

Link to post
Share on other sites

I would post code, but I don't even know where to begin. I've been as concise I as can be. I reference the repo and in post #2 made direct references to specific classes/methods. Also, as far as implementing an NBT helper class: I just don't see a real point. It does the same thing Forge already has implemented without adding any functionality. Not bashing in any way. I just don't see a reason to do this. There is probably something I'm missing in that aspect since I trust your judgement, I just don't see it atm.

Link to post
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.

Guest
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.



  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • Minecraft forge is crashing whenever I create a new world. It will load in the world for a few frames before freezing, and then crashing to the launcher. It gives me a game crash error that says; The game crashed whilst unexpected error Error: java.lang.IllegalArgumentException: (256, 0) outside of image bounds (256, 8192) Exit Code: -1 This is the crash report.  
    • Sorry, just made it public, forgot to do that.
    • Latest commit from here should do the trick: https://github.com/hammy3502/survival-extras-2 .   I haven't tested on a built JAR, only when using the runClient task.
    • Looks fine. Can you post a Git repo that reproduces this issue?
    • 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 = '2.0.0' group = 'net.blf02.survivalextras2' // http://maven.apache.org/guides/mini/guide-naming-conventions.html archivesBaseName = 'survival_extras_2' 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', 'debug' mods { examplemod { source sourceSets.main } } // For Patchouli property 'mixin.env.remapRefMap', 'true' property 'mixin.env.refMapRemappingFile', "${projectDir}/build/createSrgToMcp/output.srg" } 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 { 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', 'debug' // 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 { // location of the maven that hosts JEI files name = "Progwml6 maven" url = "https://dvs1.progwml6.com/files/maven/" } maven { // location of a maven mirror for JEI files, as a fallback name = "ModMaven" url = "https://modmaven.k-4u.nl" } maven { name = "Patchouli" url = "https://maven.blamejared.com" } 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.4-35.1.37' // compile against the JEI API but do not include it at runtime compileOnly fg.deobf("mezz.jei:jei-${mc_version}:${jei_version}:api") // at runtime, use the full JEI jar runtimeOnly fg.deobf("mezz.jei:jei-${mc_version}:${jei_version}") compileOnly fg.deobf("vazkii.patchouli:Patchouli:1.16.4-50:api") runtimeOnly fg.deobf("vazkii.patchouli:Patchouli:1.16.4-50") compile fg.deobf("net.blf02.vivecraftapi:Vivecraft-API-1.16.4-0.1.0") // 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' // 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" } } } EDIT: The JAR is stored in libs/, and is named `Vivecraft-API-1.16.4-0.1.0.jar`
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.