Thunderbolt_lib

Thunderbolt_lib

Thunderbolt_lib is the addon API and runtime bridge library for AE2 Lightning Tech.

by
152 Downloads
forgeneoforgelibrary
Rent Server with this Mod

Screenshots

tiltle

About this Mod

Plugin API and runtime bridge library for AE2 Lightning Tech (AE2LT). Lets your mod integrate deeply with AE2LT's lightning energy network without ever touching its internal classes.

Thunderbolt_lib is a required dependency for any third-party plugin that extends, modifies, or hooks into AE2LT's lightning system. It ships no items, blocks, or recipes of its own — only frozen public APIs, NeoForge capability contracts, recipe builders, and a reflective runtime bridge that degrades gracefully when AE2LT itself is absent.

Why download this?

  • Players / modpack authors — if a mod or modpack lists ae2lt_api as a dependency, install this jar alongside AE2 Lightning Tech.
  • Plugin developers — depend on this library to access AE2LT's machines, recipe types, and lightning energy capabilities without coupling to AE2LT's internal classes.

Important: Thunderbolt_lib only does meaningful work when AE2 Lightning Tech is installed in the same Minecraft instance. Both mods must be present.

Target

Minecraft 1.21.1
Loader NeoForge 21.1.x
Java 21
Targets AE2 Lightning Tech (backwards-compatible since AE2LT introduced its lightning network)
Runtime mod ID ae2lt_api

The project is presented as Thunderbolt_lib, but registers under ae2lt_api, so existing plugin dependency declarations are unaffected.

What it provides

Lightning energy capability

Make your blocks and items first-class citizens of the AE2LT lightning network. ILightningEnergyHandler is exposed via two NeoForge capabilities — LIGHTNING_ENERGY_BLOCK (sided) and LIGHTNING_ENERGY_ITEM (void) — implement the interface and register it to participate in reads and writes. All quantities are expressed as long, scaling cleanly from a single machine to network-wide accounting.

Lightning energy tier

A unified two-tier voltage definition that flows losslessly across API surfaces. LightningEnergyTier is a two-value enum (HIGH_VOLTAGE / EXTREME_HIGH_VOLTAGE), and ships with:

  • CODEC — Mojang Codec<LightningEnergyTier>
  • STREAM_CODEC — vanilla StreamCodec<RegistryFriendlyByteBuf, LightningEnergyTier>
  • fromOrdinal(int) — ordinal-based static decoder

It shares its on-the-wire format with AE2LT's own LightningTier, so packets and NBT round-trip cleanly between the two APIs without any hand-written adapter.

Reflective runtime bridge

Won't crash when AE2LT is missing — just degrades gracefully. Instead of hard-referencing AE2LT's classes at load time, this library probes them reflectively at runtime and wires the lightning energy capability onto the five grid-connected block entities AE2LT publicly registers:

  • ae2lt:lightning_collector
  • ae2lt:lightning_simulation_room
  • ae2lt:lightning_assembly_chamber
  • ae2lt:overload_processing_factory
  • ae2lt:tesla_coil

ae2lt:crystal_catalyzer runs on FE only, does not participate in the lightning energy network, and is intentionally excluded.

Frozen ID constants

Reference AE2LT's registry IDs without dragging its main jar onto your compile path. Two ResourceLocation constant sets collect everything in one place:

  • AE2LTBlockEntityIds — AE2LT's block-entity IDs, plus LIGHTNING_GRID_MEMBERS (the list of the five grid-connected machines above)
  • AE2LTRecipeIds — AE2LT's recipe-type IDs

Both live in com.qianchang.ae2lt_api.api.ids. If AE2LT later renames any internal resource, the patch lands here so plugins don't have to chase it.

Native API detection bridge

Lets both API surfaces coexist in your mod, leaving you in control of which one to call. com.qianchang.ae2lt_api.api.bridge.AE2LTNativeBridge checks at runtime whether AE2LT's first-party API package (com.moakiee.ae2lt.api, namespace ae2lt) is loaded.

Surface This library AE2LT first-party
Java package com.qianchang.ae2lt_api.api.* com.moakiee.ae2lt.api.*
Namespace ae2lt_api ae2lt
Capability ID ae2lt_api:lightning_energy ae2lt:lightning_energy

The two API surfaces are deliberately namespace-distinct; this library performs no implicit conversion between them, so callers explicitly choose which side to use.

Events

Intercept lightning collection and apply your own conditional logic. LightningCollectedEvent is fired when an AE2LT collector picks up lightning energy. The event is cancellable and exposes isNaturalWeather() (to distinguish a true thunderstorm from a machine-induced strike) along with the matching 5-argument constructor; the original 4-argument constructor is preserved with naturalWeather defaulted to false, so migration is painless.

Recipe builders

Generate schema-compliant JSON for all six AE2LT recipe types — drop them straight into your data generation pipeline:

Builder Recipe type
LightningAssemblyRecipeBuilder ae2lt:lightning_assembly
LightningTransformRecipeBuilder ae2lt:lightning_transform
LightningSimulationRecipeBuilder ae2lt:lightning_simulation
OverloadProcessingRecipeBuilder ae2lt:overload_processing
CrystalCatalyzerRecipeBuilder ae2lt:crystal_catalyzer
LightningStrikeRecipeBuilder ae2lt:lightning_strike

CrystalCatalyzerRecipeBuilder additionally supports dustMode() and outputTag(...), matching AE2LT's crystal_catalyzer/dust/*.json schema.

Plugin loading & API facade

Unified registration callbacks, no hand-rolled NeoForge lifecycle wiring. Plugin discovery runs through @AE2LTPlugin, IAE2LTPlugin, and Java ServiceLoader; the static facade AE2LTAPI collects the API version, capability handles, and bridge utilities into a single entry point you can pull in with one import static and use across your codebase with minimal boilerplate.

Adding as a dependency

Plugin developers — declare both ae2lt_api (this library) and ae2lt (the main mod) as required in your neoforge.mods.toml:

[[dependencies.your_mod_id]]
    modId = "ae2lt_api"
    type = "required"
    versionRange = "[1.0.0,)"
    ordering = "AFTER"
    side = "BOTH"

[[dependencies.your_mod_id]]
    modId = "ae2lt"
    type = "required"
    versionRange = "[1.0.0,)"
    ordering = "AFTER"
    side = "BOTH"

Set the lower bound of versionRange to the minimum version your plugin actually supports.

Feedback

Bug reports and suggestions are welcome on the project issue tracker. When reporting an issue, please include the versions of Minecraft, NeoForge, AE2 Lightning Tech, and Thunderbolt_lib you are running — it makes reproduction and triage much faster.

Source, changelog, releases

Credits

Maintained and developed by QianChang.

Special thanks to the AE2 Lightning Tech team — MOAKIEE, CystrySU, gjmhmm8, _leng, TedXenon, and MHanHanBing — for publishing clear, stable registry IDs and recipe schemas that make this bridge possible.

Thanks also to the Applied Energistics 2 team — without AE2 there would be no AE2LT, and no reason for this bridge to exist.

Disclaimer

This name is used for non-commercial community purposes only. If any rights holder considers the name to be infringing or unsuitable, please contact the maintainer and it will be changed promptly.

Full notice — DISCLAIMER.md

Available Versions

Thunderbolt_lib 1.0.10-1.20.1forgerelease
MC 1.20.1forge
May 30, 2026
Thunderbolt_lib 1.0.11release
MC 1.21.1neoforge
May 30, 2026
Thunderbolt_lib 1.0.10release
MC 1.21.1neoforge
May 30, 2026
Thunderbolt_lib 1.0.8release
MC 1.21.1neoforge
May 30, 2026
Thunderbolt_lib 1.0.7release
MC 1.21.1neoforge
May 30, 2026

How to Install Thunderbolt_lib on Your Server

1

Order Server

Order a Minecraft Java server with at least 3 GB RAM (4 GB recommended).

2

Set forge Loader

In the panel under "Egg", select the forge loader and matching Minecraft version (26.1.2).

3

Install Mod

Open the mod browser in the dashboard and search for "Thunderbolt_lib". Click "Install" – done! Alternatively, upload the .jar via SFTP to the /mods folder.

Compatibility

Mod Loaders

forgeneoforge

Minecraft Versions

26.1.2, 1.21.1, 1.20.1

Server-side

Required

Recommended RAM

4 GB(min. 3 GB)

Frequently Asked Questions

Thunderbolt_lib server crashes on startup – what to do?

Most common cause: wrong forge version or insufficient RAM. Check the server log (latest.log) for "OutOfMemoryError" or "Mixin" errors. With Mado Hosting: ensure at least 3 GB RAM is allocated and the loader matches the mod version (26.1.2). You can switch loaders with one click in the panel.

Is Thunderbolt_lib compatible with forge and neoforge?

Thunderbolt_lib officially supports forge, neoforge for Minecraft 26.1.2, 1.21.1, 1.20.1. The Mado dashboard automatically detects incompatible loader combinations.

Server lagging with Thunderbolt_lib – how to optimize performance?

Recommended RAM: 4 GB (per 8 players). Use /spark profiler to check if Thunderbolt_lib consumes the most tick time. Common fixes: reduce server view-distance to 8-10, install "performant" or "starlight" as supplementary mods on Forge. With Mado Hosting, your server runs on NVMe SSDs with dedicated CPU cores for minimal latency.

Rent Modded Server

Install Thunderbolt_lib with just one click on your server.

Recommended RAM
4 GBab €8/mo
Min. 3 GB | +1 GB pro 8 Spieler
Create Server Now
1-Click Mod Install
NVMe SSD Storage
DDoS Protection included

Details

License
MIT License
Server-side
Required

Supported Versions

26.1.21.21.11.20.1