Redstone Issues

[Dis-play-Name]

I were messing around with redstone and gates stuffs and found something i think

Environment

1. Forge: 1.20.1 (integrated singleplayer)

2. Mods:

   • Blueprint 7.1.3
   • Pantz's Mod 0.1-1.20.1 (pantz_mod) (latest version available on CurseForge
   • JEI 15.20.0.129

What happened
When interacting with XNOR or Advanced XNOR logic gates from pantz_mod, the game reliably crashes with a java.lang.StackOverflowError during world ticking. This is reproducible in singleplayer whenever those gates are placed in circuits that feed outputs back into inputs (self-activation / feedback loops), or in dense gate networks.

Crash originates at:
pantz.mod.common.block.LogicGateBlock.m_6807_(LogicGateBlock.java:43)

m_6807_ is the obfuscated name for neighborChanged(BlockState state, Level level, BlockPos pos, Block neighborBlock, BlockPos neighborPos, boolean isMoving)
i.e., the method called when adjacent blocks change (redstone updates, etc.). The method enters a tight recursion loop until the JVM stack overflows (~thousands of calls).

Steps to reproduce:

1. Start a Forge 1.20.1 instance with the listed mods.
2. Create an XNOR or Advanced XNOR gate from pantz_mod.
3. Wire the gate so its output feeds back into one of its inputs (create a simple feedback loop).
4. Activate the circuit (player movement near it, toggling power, or letting ticks propagate).
5. Observe the crash: StackOverflowError during world/chunk ticks.

This also happens with larger/dense gate setups where neighbor updates cascade.

Expected behavior
Logic gates should handle neighbor updates without unbounded recursion
feedback loops should either settle/stabilize or be rate-limited so they don’t crash the game.

Root cause

• Infinite recursion inside LogicGateBlock.neighborChanged, the neighbor update handling causes repeated neighbor updates that call neighborChanged again, creating a deep recursion chain until the JVM stack overflows.
• The crash point is LogicGateBlock.java:43 (obfuscated method m_6807_).

Trigger conditions

• Self-activation / feedback (output→input)
• Dense networks of gates (neighbor updates amplify)
• Happens during chunk ticks / server ticks / when the player moves near the circuit

Additional notes

• I only tested XNOR and Advanced XNOR; they’re definitely broken in feedback setups. Other gates may be less prone but could behave similarly under feedback/dense conditions.
• The issue looks like a logic/update ordering problem rather than a memory leak — it’s stack depth overflow from recursive calls.

Words to reader:

• Avoid wiring XNOR / Advanced XNOR gates into direct feedback loops (keep outputs from feeding inputs).
• Break circuits with repeaters/delayers or use single-direction wiring to prevent immediate neighbor update loops.
• Reduce gate density in a region to limit cascading neighbor updates.

LOGS:

logger.txt

latest.log

[Dis-play-Name]

Heh im known as the bug hunter