Developing Nexus Addons in Other Languages

Nexus addons are native Windows DLLs, and the Nexus API is a plain C interface. Any language that can produce a 64-bit DLL with a C-compatible export can therefore be used to write addons. This guide lists the available bindings and explains what you need to know to use, or write, bindings for another language.

C and C++

The official header, Nexus.h from RCGG-lib-nexus-api, works with both C and C++. C++ is the most common choice, mainly because Dear ImGui, which you use to draw your interface, is a C++ library. All guides in this section use C++.

Raidcore also publishes headers for related interfaces:

• RCGG-lib-mumble-api for the MumbleLink structures Nexus shares.
• RCGG-lib-arcdps-api for ArcDPS's combat API types, used by the ArcDPS events.

Community bindings

Community bindings are maintained by their authors, not by Raidcore. Check their documentation for which API version and features they cover. If you maintain bindings for another language and would like them listed here, get in touch on the Raidcore Discord.

What any language needs

Whatever language you use, your addon has to meet the same requirements as a C++ addon:

• A 64-bit Windows DLL. The game is 64-bit and loads your addon with LoadLibrary.
• An export named GetAddonDef, without name mangling, that returns a pointer to an AddonDefinition_t.
• The C calling convention. On 64-bit Windows there is only one, the Microsoft x64 convention. Every function you pass to Nexus, and every function Nexus gives you, uses it.
• Exact struct layouts. AddonDefinition_t, AddonAPI_t and all other structures must match Nexus.h field by field, with C alignment rules. Enums are 32-bit integers, bool is one byte, and strings are null-terminated UTF-8.
• No unwinding across the boundary. Exceptions, panics and similar mechanisms must never leave a callback and travel into Nexus. Catch them at the edge of every function Nexus calls.
• A clean unload. Everything in the addon lifecycle applies, including stopping all threads before Unload returns.

Dear ImGui

To draw into the shared interface, your language needs ImGui bindings that are compatible with Dear ImGui 1.80 exactly, and they must be able to use an existing context and allocator instead of creating their own. Wrappers based on cimgui built from the 1.80 sources are a common route. See Rendering and Dear ImGui Integration for why the version matters.

Managed languages

Languages with a runtime, such as C# or Java, add extra challenges. For C#, .NET's Native AOT compilation can produce a native DLL with a GetAddonDef export using [UnmanagedCallersOnly(EntryPoint = "GetAddonDef")]. Keep in mind:

• A Native AOT library cannot be safely unloaded from a process. Set AF_DisableHotloading, so Nexus never tries.
• Keep every delegate you pass to Nexus alive, for example in a static field, so the garbage collector does not collect it while Nexus still holds its function pointer.
• Each additional runtime in the game process costs memory and startup time. Keep your addon lean.

Writing new bindings

If you create bindings for a new language, these points help other developers rely on them:

• Generate or check the struct definitions against Nexus.h, and test them with a sizes and offsets check. A single misplaced field shifts every function pointer after it.
• Support the current API version, NEXUS_API_VERSION 6. Nexus keeps older versions working, so bindings for an older version stay usable, but new addons should get the full feature set.
• Offer safe wrappers for the lifecycle: registering in load and automatically deregistering in unload prevents the most common addon crashes.
• Wrap events and shared resources with typed helpers, including the built-in ones described in Event Handling and Sharing Resources.
• Document which Nexus.h revision the bindings are based on.

The API reference lists every function with its C signature.