Thunderbolt_lib

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

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<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.

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:

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.