Jump to content

bomber055

Members
  • Posts

    28
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

bomber055's Achievements

Tree Puncher

Tree Puncher (2/8)

2

Reputation

  1. The in game time value in Forge 1.8.8-11.15.0.1624 is not correct. In 1.8.8 vanilla, this is what /time set 0 does: In 1.8.8 Forge, this is what /time set 0 does: You can see the sun gets set to different spots in the sky. This is causing my in game clock to not function correctly for my mod Zyin's HUD. (see GitHub issue).
  2. Try using the RenderCustomTexture() function in this file: https://github.com/Zyin055/zyinhud/blob/master/src/main/java/com/zyin/zyinhud/ZyinHUDRenderer.java
  3. 1st stacktrace (after "/kill" is executed): 2nd stacktrace (after "Respawn" is clicked) Sure enough, when "Respawn" is clicked, Minecraft decides it wants to open a new null screen, which the game then interprets as a GuiGameOver because the player has <= 0 health. So it is just an unintended side effect of some bad coding from Mojang. I used this to my advantage by using the following logic: if(mc.currentScreen != null) { //"Respawn" is clicked } else { //GuiGameOver is initially displayed }
  4. First off, this is most likely a Minecraft issue and not a Forge bug. I am registered to receive the GuiOpenEvent in one of my classes and noticed that it gets fired twice for GuiGameOver. Once when the GUI is first opened (expected) and again when it is closed by clicking the "Respawn" button (unexpected). At first I thought it may be because the GuiGameOver screen creates a 2nd new screen, GuiYesNo, after clicking the "Title screen" button but in both cases event.gui.toString() is still "net.minecraft.client.gui.GuiGameOver". To reproduce this, simply get to the death screen by typing "/kill" and notice that the GuiOpenEvent fires twice. I am using Forge 1.8-11.14.0.1261.
  5. I see, then the event wouldn't get fired if the custom GuiScreen overrode the handkeKeyInput() method without calling super. What about firing the event on the line right before 1814:this.currentScreen.handleKeyboardInput(); ? Then it should work even for modded GuiScreens.
  6. Currently, the KeyInputEvent only gets fired when no Gui is being displayed. This is because any open GUI takes over they key input before the KeyInputEvent gets fired. I would very much like to have the KeyInputEvent get fired in two places, one where it already is, and again in the GuiScreen class function handleKeyboardInput(). The reason I want this is because I need to detect when a key is pressed while in a GuiScreen, but my only way to do that is to use a ClientTickEvent and check for key presses.
  7. Like the title says, right clicking a horse with food (such as Apples or Sugar), an empty hand, or a saddle does nothing. If I run Minecraft 1.8 without Forge installed it works as expected.
  8. Figured out the issue after downloading a fresh copy of the src. In build.gradle, it should be: version = "1.8-11.14.0.1239-1.8" with an extra -1.8 tacked on the end. Also as an FYI: "cpw.mods.fml" has moved to "net.minecraftforge.fml". Gotta fix all your imports after updating from 1.7.10 to 1.8.
  9. I saw that 1.8 Forge was released a few hours ago so I decided to try updating. I did my usual steps for updating for a new version (clean, setupDevWorkspace, setupDecomWorkspace, eclipse) after updating my build.gradle file to use "version = "1.8-11.14.0.1239", but on the setupDevWorkspace step I got a 403 Forbidden: build.gradle Any ideas? Right now I'm guessing that its some setup error on their end.
  10. Solved the issue. Need to use the same function that Minecraft uses for their translations: public static String get(String key) { return I18n.format(key, new Object[0]); }
  11. My mod uses a language file en_US.lang which has worked perfectly in 1.7.2. Today I tried upgrading to Forge-1.7.10-10.13.0.1152 and now it throws a null pointer exception whenever I try to access a key from my language file. Debugging the error shows that the languageMap variable in LanguageManager.java is empty, so it returns null when attempting to get the key "en_US". Is there another function I need to run to get the language files to setup properly before using them, or is this an error on Forge's part (it is a beta version after all)? My code to get the localized string value: public static String get(String key) { String text = LanguageRegistry.instance().getStringLocalization(key); if (text == null || text.equals("")) text = LanguageRegistry.instance().getStringLocalization(key, "en_US"); return text; } crashlog: [/code]
  12. That fixed the compile errors, but now I can't find the Minecraft source code in the Reference Libraries section in Eclipse. Did it move somewhere? Am I missing another step besides running these commands? gradlew clean gradlew setupDevWorkspace gradlew eclipse gradlew setupDecompWorkspace --refresh-dependencies EDIT: I ran gradlew eclipse and gradlew setupDecompWorkspace again and I see the source code now. Thanks for the help diesieben07.
  13. I ran "gradlew setupDevWorkspace" and "gradlew eclipse" which worked just fine, and I'm able to start up eclipse and access my source code and see various errors in it. The issue I'm having is I can't see the Minecraft source code, so I tried running both "gradlew setupDecomWorkspace" and "setupDecompWorkspace --refresh-dependencies" and both give me the following errors: In my build.gradle I changed classpath 'net.minecraftforge.gradle:ForgeGradle:1.1-SNAPSHOT' to classpath 'net.minecraftforge.gradle:ForgeGradle:1.2-SNAPSHOT' because of another forum post I saw, and added inputs.property "version", project.version inputs.property "mcversion", project.minecraft.version to processResources { }. I also changed the line in Client.watch to: <stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="--version 1.7 --tweakClass cpw.mods.fml.common.launcher.FMLTweaker --username=ForgeDevName --accessToken FML --userProperties={}"/> My build.gradle:
  14. To resolve my issue, I ended up using the ClientTickEvent event. In it, I basically wrote my own key handler: private static boolean keyDown = false; public static void MyKeyTickHandler(ClientTickEvent event) { if(Keyboard.getEventKey() == Keyboard.KEY_X) { if(Keyboard.getEventKeyState()) { if(keyDown == false) OnKeyDown(); keyDown = true; } else { if(keyDown == true) OnKeyUp(); keyDown = false; } } }
×
×
  • Create New...

Important Information

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