bomber055

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

Try using the RenderCustomTexture() function in this file: https://github.com/Zyin055/zyinhud/blob/master/src/main/java/com/zyin/zyinhud/ZyinHUDRenderer.java

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 }

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.

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.

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.

Holy sh*t that was fast. Thanks!

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.

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.

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.

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]); }

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]

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.

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:

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; } } }

Even if I do mc.currentScreen.allowUserInput = true on every game tick, Forge's hotkey event still does not fire when I look at a GuiChest and press the button. I know I have my hotkey setup correctly because I do a System.out.println() for each time it is pressed and that fires when I am not looking at a GuiScreen.

Hasn't anyone else experienced this in 1.7.2?

[sOLUTION] Change: itemRenderer.renderItemAndEffectIntoGUI(mc.fontRenderer, mc.renderEngine, itemStack, x, y); To this: GL11.glEnable(GL11.GL_DEPTH_TEST); itemRenderer.renderItemAndEffectIntoGUI(mc.fontRenderer, mc.renderEngine, itemStack, x, y); GL11.glDisable(GL11.GL_DEPTH_TEST); GL11.glDisable(GL11.GL_LIGHTING); [/sOLUTION] This is for forge 1.7.2-10.12.0.1029. Back in 1.6.4, the renderItemAndEffectIntoGUI() worked just fine. Now in 1.7.2 it works, but the enchantment overlay effect covers an entire block of area instead of just on top of the item being rendered. Is there a new way to do this, or is this just a bug with 1.7.2 Forge? Look at the screenshot to see what it's doing in 1.7.2:

My problem is that I have a hotkey set up to do something in the player's chest inventory when pressed. This worked in 1.6, but in 1.7 the new key handler event system does not allow the event to be fired when the user is looking at a GuiScreen. In Minecraft.java in the the runTick() method, then FMLCommonHandler.instance().fireKeyInput(); on line 1969 is not reached. I suggest changing it so that: 1) this event still fires even if the player is looking at a GuiScreen or 2) create a new KeyGuiInputEvent that fires when a key is pressed inside a GuiScreen

Found it in Minecraft > Referenced Libraries > forgeSrc-1.7.2-10.12.0.1024.jar > net.minecraft.block > Block.class I didn't realize you could view the source code of the .class files, I thought they had to be .java.

I followed the standard Forge installation instructions posted by Lex I then ran "gradlew setupDecompWorkspace" and "gradlew setupDecompWorkspace eclipse" commands which I found from this post (http://www.minecraftforge.net/forum/index.php?topic=15415.0) but I still can't find Minecraft's .java files like I could with Forge in 1.6. What do I have to do to view Minecraft's partially deobfuscated source code in Eclipse so I can start writing my mod?

Found in another thread the solution to the main() error. You need to change –version 1.6 –tweakClass cpw.mods.fml.common.launcher.FMLTweaker –accessToken anything to --version 1.6 --tweakClass cpw.mods.fml.common.launcher.FMLTweaker --accessToken anything in the run configurations

Although that may cause problems later, I don't think thats the issue that I am experiencing. If I comment out the Block.dirt line it still errors when attempting to find the main() method for Minecraft. Also, I don't even see the source files in Eclipse - should I? This is what my environment looks like: http://i.imgur.com/8Th7WpK.jpg

I followed the instructions from the sticky [TUTORIAL] (http://www.minecraftforge.net/forum/index.php/topic,14048.0.html) and end up getting a compile error after the environment is setup with Eclipse. In their sample mod, it errors on line 18 at Block.dirt: System.out.println("DIRT BLOCK >> "+Block.dirt.getUnlocalizedName()); If I comment out this line and try to run it again, it errors with: [main/ERROR]: Unable to launch java.lang.NoSuchMethodException: net.minecraft.client.Minecraft.main([Ljava.lang.String;) at java.lang.Class.getMethod(Unknown Source) ~[?:1.7.0_21] at net.minecraft.launchwrapper.Launch.launch(Launch.java:131) [launchwrapper-1.9.jar:?] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?] Which tells me it can't find Minecraft's main() class. Minecraft's class files exist in the Referenced Libraries > forge-1.7.2-10-12.0.968.jar section in .class form (no source code). All the imports in the sample mod don't give any compile errors. This is my first time using Gradle, but I am experienced with setting up the 1.6.4 forge environment.

From how diesieben07 explained it, it sounds like a Minecraft bug and not a forge bug. If you would like to see how I overcame this issue, you can check out my open source mod Zyin's HUD: http://www.minecraftforum.net/topic/1851472-162forgesspsmp-zyins-hud-now-with-horse-stats/.