Redesign lighting logic

[stdNullPtr]

Currently, for every AIR block that needs to be lit, a new BukkitRunnable is scheduled to revert it. This can introduce a significant overhead when player count arises.

Maybe we can insert all lit blocks into a queue and have a scheduler pop the last element? But each player must have a personal scheduler. This idea will be scrapped entirely in favor of lighting using packets.

Update: It turns out a lot of issues arise with the initial approach of swapping air blocks to light blocks. The lighting logic must be redesigned to use packets and properly lit a location, instead of replacing blocks with LIGHT material.

[stdNullPtr]

Problem

Currently, TorchLight only works in AIR blocks. This is a deliberate design choice to prevent destroying blocks like grass, snow, water, decorations, etc. However, users report wanting torch lighting to work in grass fields and other non-air environments.

Current Limitation

• ✅ Works: Caves, buildings, open air spaces
• ❌ Doesn't work: Grass fields, underwater, snow areas, flower fields

Research Completed

We conducted extensive research into packet-based dynamic lighting (May 2025):

Deobfuscation Analysis

• Ran Spigot BuildTools on Minecraft 1.19 with --remapped flag
• Extracted and analyzed key NMS classes using fernflower decompiler
• Found exact packet structure and connection details

Key Technical Findings

// Packet structure discovered:
ClientboundLightUpdatePacket(
    ChunkPos chunkPos,
    LevelLightEngine levelLightEngine,  // This is the problem
    @Nullable BitSet skyLightSections,
    @Nullable BitSet blockLightSections,
    boolean trustEdges
)

// Connection is simple:
ServerPlayer.connection.send(packet)  // Public field, no obfuscation

The Core Issue

The LevelLightEngine parameter is required and contains the actual light data for the world. You can't easily:

• Create fake light data
• Bypass the light engine
• Inject custom lighting without modifying Minecraft's lighting system

Why Packet-Based Lighting is Impractical

1. Complex Integration: Requires deep integration with Minecraft's lighting engine
2. Light Propagation: Must handle how light spreads to neighboring blocks
3. Version Dependencies: NMS changes between Minecraft versions
4. Performance Impact: Custom lighting calculations would be expensive

Alternative Approaches Considered

1. Temporary Block Placement

   • Place glowstone briefly, then remove it
   • Issues: Flickering, no duration control, still modifies world

2. Client-Side Mods

   • Use mods like OptiFine for dynamic lighting
   • Issues: Requires all players to have specific mods

3. Bukkit API Enhancement

   • Wait for official dynamic lighting API
   • Issues: No timeline, may never happen

Conclusion

After thorough research, packet-based dynamic lighting is technically possible but impractical due to the complexity of integrating with Minecraft's lighting engine.

For Future Developers

If someone wants to attempt packet-based lighting:

1. Deobfuscate spigot 1.19 (you can lookup tutorials)
2. Focus on integrating with LevelLightEngine
3. Expect significant complexity and maintenance overhead

---

Effort: Very High (would require significant NMS expertise)