jdawg3636

Because the server and the client may not be running on the same physical side you need to use networking. Forge does a lot of the work for you, see the official documentation: https://mcforge.readthedocs.io/en/1.15.x/networking/ You need to have the logical server send a message and then have the logical client receive that message and do whatever it needs to as a result (in this case change the gravity). Also, the functionality that you are describing sounds quite similar to Galacticraft. You might want to to a look at their code for a reference: https://github.com/micdoodle8/Galacticraft

All of it would be preferred, but definitely your main mod class and anything directly related to the entity.

Line 625 of net.minecraft.client.renderer.RenderState (in the TextureState inner class) is getting a null ResourceLocation. Please provide your source code (as a GitHub repository if possible) so we can help you find out why.

I'm assuming that you meant to write SMALL images at BIG scale; big images at small scale on the screen are always going to look pixelated on the screen because it doesn't have enough pixels on the monitor to represent all of the data. The "Texture Filtering" section of this page should help you with changing the way images are upscaled: https://learnopengl.com/Getting-started/Textures Also I obviously don't have any context based on what you posted but as a general rule you shouldn't have to be writing OpenGL directly in a Forge mod. Advanced topics like this aren't covered very much in the official Forge documentation but I would HIGHLY recommend that you look up the GitHub for another mod that has similar rendering features to your own to make sure that there's not a cleaner way to accomplish them.

Mojang deliberately obfuscates their code with the unreadable names. When you download Forge's MDK it uses the community-made mappings from the Mod Coder Pack project (You can download the mappings directly from http://mcpbot.bspk.rs/) and applies them so that you can see the readable ones. The mappings are specific to MC versions not to Forge versions and you can actually configure which mappings you use in the build.gradle file. TL;DR is that it's a lot of work that has to be done every time MC gets an update but it's a separate task from updating Forge. The mappings are never truly complete and get better over time.

Use https://pastebin.com/ or something similar to provide the full crash log, small snippets aren't enough information.

Found this in the 1.12.2 mappings for net.minecraft.client.gui.GuiScreen, assuming it's the legacy equivalent: /** * Draws the screen and all the components in it. */ public void drawScreen(int mouseX, int mouseY, float partialTicks) { for (int i = 0; i < this.buttonList.size(); ++i) { ((GuiButton)this.buttonList.get(i)).drawButton(this.mc, mouseX, mouseY, partialTicks); } for (int j = 0; j < this.labelList.size(); ++j) { ((GuiLabel)this.labelList.get(j)).drawLabel(this.mc, mouseX, mouseY); } } MCP Mappings (especially for newer version of MC) are often incomplete and contain arbitrary changes between versions, so looking at older mappings is definitely a good idea. Mekanism is open source and has a 1.16 branch. Their GUI is here: https://github.com/mekanism/Mekanism/tree/1.16.x/src/main/java/mekanism/client/gui It seems like they have to roll most of it from scratch, this class in the render package contains most of the low-level logic and event subscriptions: https://github.com/mekanism/Mekanism/blob/1.16.x/src/main/java/mekanism/client/render/MekanismRenderer.java Good luck!

As far as I can tell this is code from a non-forge based hacked client made specifically for a Hypixel minigame. Even if this forum was designed to ask other people to write code for you (which it isn't) and your code was for a Forge mod (which I'm pretty sure it isn't), no one here is going to be willing to help with that. Don't cheat at games.

Got it - hoping not to resort to that. Currently considering using reflection to add behavior to updateTick method - still intrusive and suboptimal but it's the best I can think of atm. Any particular reason that anyone knows of that forge doesn't expose stuff like this through the event bus? I had considered submitting a PR but frankly I'm not super familiar with forge's patch system.

Is there any clean/non-ASM way of overriding the behavior of fire spread? The goal of the mod (or the relevant portion) is to prevent fire spread (similar to vanilla gamerule doFireTick false), but only within a specific region. It seems to me that the vanilla gamerule is implemented through a simple if statement in the updateTick method of the BlockFire class, and thus I'm struggling to come up with a way to implement this behavior through Forge. I'm open to hacky workarounds, but would like to avoid ASM if at all possible. Thanks in advance!

Thanks! Just for future reference: I had to wait more than one tick. Five seems to do the trick; I'm not exactly sure what the minimum is.

Make a basic anticheat mod for server modpacks Also, I have found that the majority of cheaters don't know how Java works. Usually just some obnoxious kid with an Xray mod. How and when would I go about accessing this list? Also I might send other information in the future so I would still like to work this out. This is probably a really dumb question but I'm new to this.

It is intended to send a copy of the client's mod list to the server. What would be the best method of waiting a tick?

Okay... I'm wanting to send the message when the client joins the server. Is there another event that I can hook into?

You could probably get it to work, but it would be way more work than its worth. Just use Eclipse.