Crash when looking at Energizing rod

[twothe]

Version: (make sure you are on the latest version before reporting):

• Minecraft: 1.21.1
• Forge: 21.1.212
• Powah: 6.2.6

Issue description:

When looking at an Energizing Rod the game immediately crashes with a Rendering Exception.

Steps to reproduce:

Look at Energizing rod close enough to see the description.

Is this a crash?, please include it here: (Recommended to use Gist)

crash-2025-11-09_20.24.26-client.txt

[twothe]

ChatGPT analysis

Root cause

EnergizingRodBlock#renderHud renders a HUD overlay via Draw.drawTexturedModalRect(...), which builds a quad and calls BufferUploader.drawWithShader(...).
However, no shader is bound on the RenderSystem before the draw call. Under HUD batching / certain render states, the current shader is null, so VertexBuffer._drawWithShader(...) receives a null ShaderInstance and NPEs when calling setDefaultUniforms(...).

This typically doesn’t show up if some earlier code happened to bind a shader in the same pass, but with HUD batching (e.g., ImmediatelyFast) the assumption no longer holds → reproducible NPE.

Minimal fix (keep current rendering, bind shader explicitly)

Bind a vanilla 2D HUD shader right before issuing the draw in Draw.drawTexturedModalRect(...) (and ensure the texture is bound). Example (MC 1.21.1 signatures):

// owmii.powah.lib.client.util.Draw#drawTexturedModalRect(...)
// Before buffer upload / draw:
RenderSystem.setShader(GameRenderer::getPositionTexShader);
RenderSystem.setShaderTexture(0, textureLocation); // the ResourceLocation you're blitting from

// ... build vertices ...

// Instead of routing into a path that assumes an already bound shader,
// call the uploader after setting the shader:
BufferUploader.drawWithShader(bufferBuilder.end());

[Fr3shlama]

alternative: make it possible to disable the hud since most people use TheOneProbe (or similar mods) anyway

[twothe]

Testing with a self-made mixin that does exactly the thing suggested above does fix the issue. That confirms the root case and fix.

[Fr3shlama]

https://www.curseforge.com/minecraft/mc-mods/powahhudfix

i crammed that mixin into a mod, if anyone else cant wait for this to be updated

[SubordinalBlue]

Powah is LGPL, and thus your mod should be too.

[twothe]

Powah is LGPL, and thus your mod should be too.

The LGPL does not apply to his standalone mixin mod, because he does not distribute Powah’s code (source or binary) nor a modified version of it. He only ships his own JAR that runs alongside Powah at runtime.

Key license quotes:

• LGPL-2.1, §5 (“work that uses the Library”) “A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a ‘work that uses the Library’. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.” (GNU)

• LGPL-2.1, §5 (scope of combined executable) “However, linking a ‘work that uses the Library’ with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library) … The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.” This only matters when you distribute that executable containing portions of the Library. His mod’s JAR contains no Powah portions. (GNU)

• LGPL-3.0, §0 (definitions) “An ‘Application’ is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library.” “A ‘Combined Work’ is a work produced by combining or linking an Application with the Library.” His mod is an Application; the LGPL’s combined-work conditions apply only when one conveys (distributes) the Combined Work. He is not conveying Powah nor a modified Powah. (GNU)

Implication for this project:

• He does not bundle, modify, or redistribute Powah.
• His JAR contains only his mixin code and calls Powah’s public interfaces at runtime.
• Under §5 LGPL-2.1, his mod “in isolation … falls outside the scope” of the LGPL.
• The obligations in §6 (LGPL-2.1) or §4–§6 (LGPL-3.0) concern distributing a work that contains portions of the Library (or a modified Library). That is not what he ships.

If a modpack distributor includes Powah itself, their obligations regarding Powah’s LGPL (license notice, source availability for any modified Powah, etc.) remain, but they don’t flow through to his separate mod.

[SubordinalBlue]

Technically correct; modded community wise, bit suspect, imho... you're already benefiting from including Powah! as mod in your pack; could have just PR'd a two-line fix—one that ChatGPT gave you, mind, not even your own creation.

[Fr3shlama]

could have just PR'd a two-line fix

and leave it unfixed like the other open PRs?