
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 (2/8)
2
Reputation
-
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).
-
Scaling problem on a texture in 1.8.
bomber055 replied to needoriginalname's topic in Modder Support
Try using the RenderCustomTexture() function in this file: https://github.com/Zyin055/zyinhud/blob/master/src/main/java/com/zyin/zyinhud/ZyinHUDRenderer.java -
[SOLVED] GuiOpenEvent fires twice for GuiGameOver
bomber055 replied to bomber055's topic in Support & Bug Reports
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.
-
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][1.7.10] Mod language file not working
bomber055 replied to bomber055's topic in Modder Support
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]
-
[SOLVED][1.7.10]-10.13.0.1152 setupDecomWorkspace errors
bomber055 replied to bomber055's topic in ForgeGradle
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:
-
Suggestion: KeyInputEvent() should fire on GuiScreens
bomber055 replied to bomber055's topic in Suggestions
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; } } }