- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 447
- Reaction score
- 7
Been digging into the current state of C# internals using NativeAOT lately. If you've ever tried to move away from messy externals and into the game process, you know the struggle of keeping that output clean.
I’ve got a basic internal base running for Assault Cube. Finding offsets and handling memory is the easy part—toggling infinite health, ammo, and armor via simple button presses works flawlessly with console logging enabled. The real headache starts when you try to move beyond console hacks and into visuals.
The Dependency Wall
The goal is a single, portable DLL. However, the standard C# ecosystem makes this a nightmare for internal projects:
I’m looking for a way to implement a menu and ESP logic that compiles down to a single DLL without external dependencies. Most of the resources out there are dated or focus on external overlays, which isn't the vibe for a proper internal project.
Has anyone here successfully integrated a raw ImGui implementation into a C# NativeAOT internal without relying on external wrapper DLLs? Curious if there's a lightweight bridge or if I'm going to have to manually map the exports.
anyone handled this specific dependency nightmare before?
I’ve got a basic internal base running for Assault Cube. Finding offsets and handling memory is the easy part—toggling infinite health, ammo, and armor via simple button presses works flawlessly with console logging enabled. The real headache starts when you try to move beyond console hacks and into visuals.
The Dependency Wall
The goal is a single, portable DLL. However, the standard C# ecosystem makes this a nightmare for internal projects:
- ImGui.NET is the obvious choice for the UI, but it’s just a wrapper. It demands cimgui.dll to function, which kills the single-file dream.
- Hooking OpenGL (since Assault Cube is an OG title) usually leads people toward Silk.NET. While powerful, it brings its own massive OpenGL implementation, leaving you with three or four files instead of one.
- NativeAOT is great for the entry point and exports, but bridging the gap to a raw OpenGL hook without managed bloat is where most C# devs get clapped.
Target: Assault Cube
Framework: .NET with NativeAOT compilation
Features Working: Memory Toggles (HP, Ammo, Armor)
Visuals Blocked: ESP, Menu Overlay
Current Bloat: DLL output requires multiple external dependencies (cimgui, Silk modules)
Framework: .NET with NativeAOT compilation
Features Working: Memory Toggles (HP, Ammo, Armor)
Visuals Blocked: ESP, Menu Overlay
Current Bloat: DLL output requires multiple external dependencies (cimgui, Silk modules)
I’m looking for a way to implement a menu and ESP logic that compiles down to a single DLL without external dependencies. Most of the resources out there are dated or focus on external overlays, which isn't the vibe for a proper internal project.
Has anyone here successfully integrated a raw ImGui implementation into a C# NativeAOT internal without relying on external wrapper DLLs? Curious if there's a lightweight bridge or if I'm going to have to manually map the exports.
anyone handled this specific dependency nightmare before?
