Jump to content

hypehuman

Members
  • Posts

    12
  • Joined

  • Last visited

hypehuman's Achievements

Tree Puncher

Tree Puncher (2/8)

2

Reputation

  1. But it shouldn't have anything to do with the IDE, right? I'm doing all the setup and builds from the command line. I'm just using Eclipse to edit the source code.
  2. Is there a way to start the dev environment and log into Mojang so that you can join servers? EDIT: Now that I think about it, I'm not sure I know what you mean by "development environment". Do you mean running Minecraft using a gradle command from the MinecraftForge directory?
  3. I'd like to do this so that I can play with my mod before the pull request is accepted!
  4. Thanks! That fixed the eclipse errors. However, I can't get it to run; please see my comment: https://gist.github.com/mcenderdragon/6c7af2daf6f72b0cadf0c63169a87583#gistcomment-2895146
  5. Thanks! I ran into another problem, but we've now departed enough from the original topic that I made a new post for it:
  6. This tutorial has served me well for 1.12.2: https://mcforge.readthedocs.io/en/latest/forgedev/ However, I'm having trouble getting it to work for 1.13.2. I managed to figure out that "setupForge" has been renamed to "setup" (makes sense!), but in Eclipse, there are build errors all over the place. Also, I can't get the test mods to enable. When I right-click src/test/java, I don't get any build options. Is there an updated guide somewhere that I'm missing? Thanks!
  7. Are you suggesting that I grab the GuiIngameForge from the current Minecraft instance, pass it to a wrapper that passes through everything besides renderHUDText, and pass it back into Minecraft.ingameGUI? Sounds workable, except that it wouldn't be compatible with another mod that uses a similar approach. Would that constitute "a good case" for a PR?
  8. Thanks! I'll try both approaches. I'll also look at your 1.13.2 tutorial, since it looks like things have changed since 1.12.2.
  9. Ah thanks, you made it even easier for me Now I'm able to set those fields, but it doesn't get rendered on the screen. See code here. It looks like the problem is in GuiIngameForge.renderHUDText, it calls debugOverlay.update() and then immediately debugOverlay.getLeft(), which converts the ray traces into text, with no method call inbetween. So when it fires RenderGameOverlayEvent.Post, it's already too late. I think I could watch for RenderGameOverlayEvent.Text and then modify getLeft(), but that seems pretty bad because I would have to try to guess at what's supposed to come before and after the "Looking at" lines. Any other approaches? I still think the simplest would be to just make it a static field (see code), but I'm not sure that would get approved in a pull request.
  10. Ah great, thanks! Looking at the code, I believe the value in Minecraft.getInstance().ingameGUI will be an instance of GuiIngameForge, even though it's stored in a field of type GuiIngame. So that should be perfect, thanks! I think I can just watch RenderGameOverlayEvent.Post and re-do what was done in GuiIngameForge.GuiOverlayDebugForge.update(). EDIT: Rather, take the GuiIngame, pull out its protected GuiOverlayDebug overlayDebug (find the field name for that), and then do as you described to set GuiOverlayDebug.rayTraceBlock and rayTraceFluid.
  11. My approach is to create a folder in the user's .minecraft folder (which you can get from Minecraft.getInstance().gameDir) putting a subfolder for my mod, and then subdirectories for each world named after the server address (Minecraft.getInstance().getCurrentServerData()). It works most of the time, but the problem with this approach is that if you're connected to a server, then you use a command or something that moves you to a different server without going back to the connection screen, your mod will still think you're in the server you originally connected to.
  12. I'd like to create a mod that increases the distance at which you get the "Looking at" text on the debug overlay. After bumping around in the code (version 1.13.2 - 25.0.149), it looks like the place this is done is in GuiIngameForge.GuiOverlayDebugForge.update(), where it uses a hard-coded distance of 20. Now this is Forge, so I know I'm not supposed to go replacing chunks of code. However, I see no events that I can pull from, and besides, the fields being set here are private. So I figured maybe I'm supposed to extend GuiOverlayDebug and have it reinitiatlize its debugOverlay with a custom subclass of GuiOverlayDebugForge, but the problem there is that both the field and the type are private. So what's the "correct" way to do this? Should I make a pull request to Forge? If so, would it be appropriate to take that hard-coded value and move it to a static field with a public setter? Thanks for reading, and please let me know if I can clarify anything.
×
×
  • Create New...

Important Information

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