Thunderbolt_lib

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

> 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`
• `STREAM_CODEC` — vanilla `StreamCodec`
• `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

• Source code — github.com/QianChang-official/Thunderbolt_lib
• Changelog — CHANGELOG.md
• GitHub releases (jar mirror) — all 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.