DEV Community: Emil Sjöstedt

How I Fixed Relative Docking & Physics Drift in UE5 (Aether Framework Deep Dive)

Emil Sjöstedt — Fri, 25 Sep 2026 23:24:51 +0000

Hey DEV! 👋

Last week I shared an update on my open-world space sim Sirius (on reddit KadmiumTech), built on my custom Aether Framework in Unreal Engine 5. Aether leverages UE5's Network Prediction Plugin (NPP) and Large World Coordinates (LWC) to handle deterministic 6DOF space physics.

One of the trickiest mechanics in space games is Relative Docking—landing a small, agile fighter onto a massive, fast-moving capital carrier without physics jitter or netcode desync. Here is a deep dive into four specific physics bugs I encountered and how I solved them in C++!

This is still work in progress and needs some adjustmends but the core works.

1. Jittery Rotation on Moving Carriers

The Problem: Whenever a ship entered a relative movement zone, rotational smoothing was completely bypassed. Every micro-rotation of the carrier hit the player's ship as a harsh, frame-by-frame stutter. Additionally, the camera aim director was running post-physics, creating a phase shift between camera, mesh, and physics state.

The Solution: I synchronized the Aim Director updates directly with netcode prediction ticks and re-enabled rotational smoothing for relative zones in AetherMovementComponent.cpp. Rotation offsets are now smoothly interpolated toward Identity using FQuat::Slerp.

// AetherMovementComponent.cpp - FinalizeSmoothingFrame()
if (Sync->bIsRelative && Sync->ZoneID > 0)
{
    if (UAetherGravitySubsystem* Subsystem = GetGravitySubsystem())
    {
        FTransform ParentTransform;
        if (Subsystem->GetZoneTransform(Sync->ZoneID, ParentTransform))
        {
            TargetLocation = ParentTransform.TransformPosition(TargetLocation);
            TargetRotation = ParentTransform.TransformRotation(TargetRotation);
        }
    }

    // Smoothly interpolate translation and rotation offsets back to identity
    SmoothingTranslationOffset = FMath::VInterpTo(SmoothingTranslationOffset, FVector::ZeroVector, DeltaTime, 15.0f);
    SmoothingRotationOffset = FQuat::Slerp(SmoothingRotationOffset, FQuat::Identity, FMath::Clamp(DeltaTime * 15.0f, 0.0f, 1.0f));

    VisualComponent->SetWorldLocationAndRotation(
        TargetLocation + SmoothingTranslationOffset,
        (SmoothingRotationOffset * TargetRotation).GetNormalized()
    );
    return;
}

2. Violently Oscillating / "Sticky" Landing Gear

The Problem: Landing gear suspension forces were calculated using raw spring velocity multiplied by friction and mass—missing delta-time scaling and impulse limits. Pressing into the ground created an unscaled force that catapulted the ship into space in an violent feedback loop.

The Solution: In AetherLandingGearSim.cpp, damping forces are now properly scaled by mass, frequency, and time step, with impulses clamped against maximum allowed Gs. I also isolated the "Sticky" (magnetic) landing gear behavior to apply a controlled, downward force vector.

// AetherLandingGearSim.cpp - Step()
const float ActiveStiffness = ScaledStiffness * ProgressiveMultiplier;
const float ActiveDamping = (AxisVelocity < 0.0f) ? (ScaledDamping * 0.2f) : ScaledDamping;

// Calculate spring force and clamp max impulses to prevent violent bounce-backs
float SpringForce = (Compression * ActiveStiffness) - (AxisVelocity * ActiveDamping);
SpringForce = FMath::Clamp(SpringForce, 0.0f, (MassPerGear * 980.0f) * Gear.MaxSuspensionGs);
FVector CurrentGearForce = GearUpDir * SpringForce;

// Separate magnetic ground attraction force
if (Gear.GearMode == EAetherLandingGearMode::Sticky && Compression > 0.001f)
{
    const float AdhesionForce = MassPerGear * 980.0f * 1.5f; 
    CurrentGearForce -= GearUpDir * AdhesionForce;
}

3. Rolling 90° Caused Unwanted Sideways Drift

The Problem: The aerodynamic lift vector calculation contained a matrix transformation flaw that simplified to applying lift straight up against world gravity, regardless of ship orientation. Rolling 90° put the wings vertical, but lift kept pushing world-up, producing unintended lateral drift.

The Solution: Lift must always evaluate relative to the ship’s local Up axis (Sync->Rotation.GetAxisZ()). In AetherAeroSim.cpp, the lift force vector is now computed directly along the local roof vector and scaled by atmospheric density.

// AetherAeroSim.cpp - Step()
if (EnvDensity > 0.001f)
{
    const FQuat InvShipRot = Sync->Rotation.Inverse();
    const FVector BodyVel = InvShipRot.RotateVector(Sync->LinearVelocity);

    const float ForwardSpeed = FMath::Max(0.0f, BodyVel.X);
    const float InvMaxLiftSpeed = 1.0f / FMath::Max(1.0f, Aux->MaxSpeed * Aux->OptimalLiftSpeedRatio);
    const float LiftAlpha = FMath::Clamp(ForwardSpeed * InvMaxLiftSpeed, 0.0f, 1.0f);

    // FIX: Get local ship up direction instead of world up!
    const FVector ShipUpDir = Sync->Rotation.GetAxisZ();
    const float GravityMag = LocalGravity.IsNearlyZero() ? 980.0f : LocalGravity.Size();

    // Apply aerodynamic lift aligned with local ship orientation
    Sync->LinearVelocity += ShipUpDir * (LiftAlpha * GravityMag * EnvDensity * DeltaSeconds);
}

4. Loss of Inherited Speed When Exiting Moving Carriers

The Problem: When exiting a carrier, zone transition logic calculated inherited world velocity correctly (e.g., combining 2,000 cm/s ship speed + 55,000 cm/s carrier speed). However, on the exact same frame, the velocity was clamped against the ship's standalone engine MaxSpeed (e.g., 5,000 cm/s), causing the ship to instantly lose over 90% of its momentum.

The Solution: I removed the hard top-speed clamp during world-zone handshakes in FAetherSpaceUtils::ProcessZoneHandshake. Instead, excess momentum bleeds off dynamically over time (Dynamic Bleed) inside AetherAeroSim.cpp.

// AetherAeroSim.cpp - Step()
const float SpeedSq = Sync->LinearVelocity.SizeSquared();
const float MaxSpeedSq = FMath::Square(EffectiveMaxSpeed);

// Exponentially bleed off excess inherited velocity instead of hard-clamping
if (SpeedSq > MaxSpeedSq)
{
    const float CurrentSpeed = FMath::Sqrt(SpeedSq);
    const float ExcessSpeed = CurrentSpeed - EffectiveMaxSpeed;
    const float DynamicBleed = Aux->DynamicBleedBase + (ExcessSpeed * Aux->DynamicBleedFactor);
    const float NewSpeed = EffectiveMaxSpeed + (ExcessSpeed * FMath::Exp(-DynamicBleed * DeltaSeconds));

    Sync->LinearVelocity *= (NewSpeed / CurrentSpeed);
}

Key Takeaway

Developing networked physics for space games requires strict separation of local and world reference frames. By dividing the simulation tick into modular sub-simulations (Kinematics -> Aerodynamics -> Landing Gear -> Collision) within UE5's Network Prediction Plugin, we can guarantee deterministic simulation across server and client views.

Have you worked with relative physics frames or NPP in Unreal Engine 5? I’d love to hear your thoughts or questions in the comments below!

Zero-Budget Web Dev Part 2 — Mobile Breakpoints & Giving AI a Clean Entry Point

Emil Sjöstedt — Fri, 18 Sep 2026 01:51:06 +0000

Welcome back to Part 2.

In Part 1, I moved the Kadmium portal away from Discord chaos and onto a $0 Google Sites setup.

This part is about what happened afterwards: fixing the mobile layout, dealing with the limitations of embedded HTML, and giving AI crawlers a cleaner way to understand the site.

1. The Mobile Breakpoint Problem

Google Sites handles its native components reasonably well across different screen sizes. Custom HTML embeds are another story.

Embedded HTML runs inside sandboxed <iframe> elements, which means the embed has its own layout context. My original implementation relied too heavily on fixed pixel widths, so the desktop layout looked fine while smaller screens could end up with horizontal overflow.

Basically: desktop-first worked until someone opened it on a phone. 🤣

My bad.

The fix is fairly straightforward:

Use fluid widths such as width: 100%.
Apply sensible max-width values where necessary.
Use relative spacing such as rem instead of relying entirely on pixels.
Keep custom HTML components self-contained.
Let Google Sites handle the larger page layout through its native containers.

For embeds that contain their own HTML document, I also use an explicit viewport declaration:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

The general rule I'm using now is: Google Sites handles the page layout. Custom HTML handles individual widgets. That keeps the two systems from fighting each other.

2. The More Interesting Problem: AI Crawlers

The mobile issue was annoying. The crawler problem was more interesting.

If you're trying to make a technical site discoverable through tools such as ChatGPT, Claude, Gemini or Perplexity, the crawler isn't necessarily interested in the page exactly the way a human visitor is.

A rendered website can contain:

Navigation elements
Styling & layout rules
JavaScript hydration
Embedded content & iframe boundaries
Duplicated markup & UI components

For a human, that's normal. For an AI system trying to extract technical information, it's additional context that may not be useful.

Google Sites also doesn't give me the same level of control over infrastructure that I would have on a conventional web stack. For example, I can't simply treat the site root like a server I fully control and configure everything around the crawler.

So instead of trying to make the crawler understand the entire rendered site, I decided to give it another option.

3. /ai-summary

I created kadmium.dev/ai-summary.

The idea is simple: Give AI agents a plain-text representation of the important parts of the site.

Rather than forcing a crawler to reconstruct the architecture from rendered pages,give it pieces of candy! The endpoint provides a structured Markdown index containing the information I actually want machines to discover.

The page includes things such as:

Project and product descriptions
Technical areas & module specs
Documentation routes & article links
Repository references
Metadata, versioning, and explicit boundaries around what is public and what isn't

It also follows the general direction of the emerging llms.txt pattern: provide machines with a deliberately simplified representation of a website instead of relying entirely on rendered HTML.

4. Why Explicit Boundaries Matter

One part I consider particularly useful is separating known public information from things that aren't actually exposed.

For example, the index can explicitly state that internal implementation details are not part of the public documentation. That's important because an AI system should not have to guess.

If the public documentation says:

This module exists and performs X.

That doesn't mean the model should invent the internal C++ implementation of X.

The /ai-summary document therefore acts more like an information boundary than just a sitemap. It tells an AI system:

Here is what you can verify from the public documentation.
Here is where to find it.
Here is what isn't being exposed.

That doesn't magically prevent hallucinations, but it gives the model a much cleaner source of truth to work from.

5. The Engineering Trade-off

I'm not trying to replace the actual website with a giant text dump. Humans still get the normal site.

The /ai-summary endpoint is simply another representation of the same information, optimized for machines that don't need the visual UI.

So the architecture is roughly:

                    ┌─────────────────┐
                    │   Kadmium.dev   │
                    │   Human UI      │
                    └────────┬────────┘
                             │
                    Public information
                             │
              ┌──────────────┴──────────────┐
              │                             │
        Human visitors                AI / crawlers
              │                             │
       Rendered website                 /ai-summary
              │                             │
        Visual context                 Plain Markdown

It's a small addition, but it means I don't have to rebuild the frontend just to make the underlying information easier for machines to consume.

6. An Honest Dev Note

I'm a C++ developer.

Given the choice, I'd rather spend 14 hours in Visual Studio working on Network Prediction Plugin rollbacks, SIMD vector math or engine architecture than debugging HTML padding. 😂

The portal exists for practical reasons:

Distributing builds
Publishing stress-test telemetry
Documenting the project
Handling B2B inquiries
Giving people a central place to find technical material

The actual engineering work is still where my attention goes.

If you want the raw architecture, the public C++ material is available here:

Public C++ Mirrors: KadmiumShowcase_UE
Technical Deep-Dives: Dev.to/kadmium
B2B & Audits: Kadmium Services

7. What I Learned

The main lesson from this was that a website doesn't necessarily need one representation.

The visual website is optimized for people.
A plain-text index can be optimized for machines.

And when the platform underneath you limits how much control you have over the rendered frontend, providing a separate machine-readable layer can be a surprisingly simple workaround.

The /ai-summary endpoint is still a work in progress, but that's the direction I'm taking for Kadmium.

If you're doing something similar with AI indexing, llms.txt, or machine-readable documentation, I'd be interested to hear how you're approaching it in the comments below!

AI Disclosure: The underlying codebase, architecture, and implementation are developed and tested by Kadmium in C++ / C#. AI tools were used to help refine parts of the documentation wording.

Aether 6DOF NPP UE5 Release - Video, Profiler results & UE Setup

Emil Sjöstedt — Wed, 16 Sep 2026 12:51:00 +0000

TL;DR - Showcase and UE setup is under the Introduction. Contact details and commercial licensing are placed right below for quick access.

AI Disclosure: Documentation and product copy were refined with AI assistance. The underlying codebase, architecture, and logic are 100% handcrafted and tested by Kadmium.

Technical Advisory & Code Audits

For engineering teams working on custom Unreal Engine 5 movement, Network Prediction Plugin (NPP) physics, or high-performance C++ architecture, direct advisory and repository audits are available:

1-on-1 Advisory Call (1h): Architecture Q&A and sanity checks for specific UE5 networking or simulation blockers.
Async Code Audit: Deep-dive analysis of repository bottlenecks, resimulation rollbacks, and memory layouts.
Engineering Retainers & Custom Integration: Dedicated C++ support and Aether framework integration for active production builds.

Full service details, availability, and scheduling are available at kadmium.dev/b2b-services or via direct contact at legal@kadmium.dev.

Commercial Licensing & Full Source Code

Early access includes free updates until Aether core is completed see roadmap on

Kadmium - Aether

kadmium.dev

The public showcase repository functions as a read-only architectural overview.

For teams and developers looking to integrate this full 6-DOF movement system into production without rebuilding the proprietary simulation math, 3D suspension, and quantization from scratch

Full C++ Source Code: Available now on Gumroad. (30% until 30 september 14:00 CEST Sweden)

Aether [UE5 Plugin] UE5 C++ Movement & Physics

Aether Framework6-DOF Movement & Physics for Unreal Engine 5Free updates are available until V1 is completed! Limited support for indiesAether is a high-performance C++ aerospace movement framework built natively on Epic's experimental Network Prediction Plugin (NPP). It delivers deterministic, server-reconciled 6-DOF spaceflight, atmospheric aerodynamics, and raycast suspension physics—engineered specifically to eliminate network desync, resimulation stutter, and Large World Coordinate (LWC) precision loss.[Use Code aetherlaunch26 for 30% the sourcecode - includes both indie & enterprise tiers ] - valid to 30:th september 2026 14:00 CEST SwedenNeed Enterprise / B2B Invoicing?Studios & Enterprise Clients: If you require Corporate VAT Invoicing (via Stripe), Purchase Orders (POs), Direct Wire Transfers, or Custom Integration Retainers, please order directly through our Services Portal or contact finance@kadmium.dev.Licensing Tiers Indie License: For solo developers and small teams with gross annual revenue under $100,000 USD. Studio License: For studios or commercial entities with gross annual revenue exceeding $100,000 USD. (For Studio Extended, Custom Engine Integration, or VAT-compliant Invoicing, please request a invoice via finance@kadmium.dev)Official Technical Resources Technical Manual & Roadmap: kadmium.dev/aether Public C++ Architecture Showcase: GitHub / KadmiumShowcase_UE Deep-Dive Engineering Write-up: DEV.to Architectural Breakdown Key Architectural Capabilities NPP-Native Prediction Pipeline: Built directly on UNetworkPredictionComponent for deterministic client-side prediction, authoritative server rollbacks, and zero-stutter visual mesh decoupling. Multi-Source Vector Gravity Engine: Subsystem-driven gravity handling spherical planetary bodies (radial falloff) and localized directional zones (hangars, moving capital ships) with explicit priority blending. Raycast Suspension Dynamics: Damped harmonic oscillator landing gear featuring progressive cubic stiffness ($1 + 2x^3$), asymmetric rebound damping, and dual friction modes (Rolling vs Sticky). Atmospheric Aerodynamics: Dynamic lift vectors, atmosphere density scaling, terminal velocity dive bonuses, and real-time $G$-force / Angle of Attack (AoA) telemetry tracking. Dual Control Schemes: Seamless runtime switching between Mouse Aim (with auto-banking and flight-director target interpolation) and Direct Axis manual flight. True Reflection & Parameter Overrides: Native C++ parameter injection—works standalone or seamlessly paired with the Flux Framework for zero-boilerplate runtime stat updates. Why Choose Aether? Save 200+ Senior Engineering Hours: Skip months of struggling with Network Prediction Plugin setups, resimulation edge-cases, and tick memory allocations. 100% Zero-Allocation C++: Handcrafted, modular source code designed for dedicated server performance with zero dynamic memory allocation inside simulation ticks. Modular Ecosystem Integration: Outputs real-time $G$-force and AoA telemetry directly into the Kinetix Framework for procedural airframe stress and mesh destruction. What’s Included Full C++ Source Code: Complete Aether runtime module (.h and .cpp). Core Components: UAetherMovementComponent, UAetherGravityComponent, UAetherGravitySubsystem, UAetherLandingGearComponent, and UAetherAimDirectorComponent. Editor Telemetry Tooling: Built-in Slate debug overlays and developer settings panels. FOR INDEPTH TECHNICAL INFO SEEDev.to/kadmium or visit kadmium.dev/

kadmium.gumroad.com

Enterprise & Audits
For extended licensing or NDA-based audits, reach out to:

legal@kadmium.dev
finance@kadmium.dev

This is the video showcase over the Aether C++ UE5 NPP 6DOF Framework (Timestamps and more will be added later!)

Raw, unedited footage of Aether showcasing client simulation when the server is running at 16.67ms (60Hz). With NPP, servers can be optimized without worrying about client simulation breaking.

Developer Notes

RestoreEvents in 'Ideal': This is a calculation bug in the GravityZone forcing Atmos density to change too fast under 1 frame. :)
RestoreEvent in 'JustNo': This scenario is caused by a threshold in ClientSmoothing. Upon removal, we can push it to even more extreme network conditions.

Reach out if you have any questions!

Tested Network Scenarios

Scenario	1-Way Latency / RTT	Packet Loss / Jitter / Reorder
Ideal	0 ms / 0 ms	0% / 0 ms / 0%
GoodBroadband	20 ms / 40 ms	0% / 2 ms / 0%
BadWiFi	40 ms / 80 ms	8% / 20 ms / 3%
HighPing	180 ms / 360 ms	0% / 10 ms / 0%
SevereJitter	80 ms / 160 ms	2% / 60 ms / 10%
PacketLossSpike	50 ms / 100 ms	15% / 10 ms / 0%
AetherStable	300 ms / 600 ms	15% / 80 ms / 1%
AetherUnstable	600 ms / 1200 ms	25% / 100 ms / 3%
AetherExtreme	1200 ms / 2400 ms	35% / 200 ms / 5%
JustNo	3000 ms / 6000 ms	70% / 300 ms / 10%

UNREAL ENGINE SETUP

Aether Framework 6DOF NPP UE5 C++ Architecture Deepdive

Emil Sjöstedt — Wed, 09 Sep 2026 22:56:51 +0000

Hi! I wanted to share a quick showcase and technical breakdown of what I'm building with Aether.

If you're curious about anything, feel free to ask. I'm happy to answer questions, discuss the architecture, or hear feedback. I've included all relevant links and contact information at the bottom.

And if you're an Unreal Engine beginner reading this: ask yourself how something works. Then go find the answer. That's how you learn. :)

Please ask questions — I promise, I don't bite.

VIDEO SHOWCASE : https://youtu.be/szciROm9ppU
(Check out the link above to see the live footage of Aether pushing 6000ms ping and 70% packet loss!).

Technical Advisory & Code Audits

For engineering teams working on custom Unreal Engine 5 movement, Network Prediction Plugin (NPP) physics, or high-performance C++ architecture, direct advisory and repository audits are available:

1-on-1 Advisory Call (1h): Architecture Q&A and sanity checks for specific UE5 networking or simulation blockers.
Async Code Audit: Deep-dive analysis of repository bottlenecks, resimulation rollbacks, and memory layouts.
Engineering Retainers & Custom Integration: Dedicated C++ support and Aether framework integration for active production builds.

Full service details, availability, and scheduling are available at kadmium.dev/services or via direct contact at legal@kadmium.dev.

WHY AETHER

Note on Repository Access:
This project is a read-only architectural showcase, not an open-source plugin. I published the repository structure to prove concept viability, document my findings with UE5's experimental Network Prediction Plugin (NPP), and share clean C++ architecture patterns for 6-DOF movement. Full implementation details are kept proprietary under the Kadmium license, but the public headers and layout serve as a reference for how the system is structured under the hood.

KadmiumDev / KadmiumShowcase_UE

Public READONLY Showcase of Kadmium UE5 Frameworks

Articles & Community Discussions

Read the full background story and technical write-up on DEV.to | https://dev.to/kadmium/aether-framework-c-architecture-showcase-2f20
Showcase Video : https://youtu.be/szciROm9ppU
A playable demo will release shortly after as soon as time permits.
Aether availablity: The aether source code is available now on gumroad and stripe - https://kadmium.gumroad.com/l/AetherFramework/aetherlaunch26 or for studios/Enterprise that need extended licensing or custom architecture vistit https://www.kadmium.dev/services

Technical Advisory & Code Audits

For engineering teams working on custom Unreal Engine 5 movement, Network Prediction Plugin (NPP) physics, or high-performance C++ architecture, direct advisory and repository audits are available:

1-on-1 Advisory Call (1h): Architecture Q&A and sanity checks for specific UE5 networking or simulation blockers.
Async Code Audit: Deep-dive analysis of repository bottlenecks, resimulation rollbacks, and memory layouts.
Engineering Retainers & Custom Integration: Dedicated C++ support and Aether framework integration for active production builds.

Full service details, availability, and scheduling are available at kadmium.dev/services or via direct contact at…

View on GitHub

This is a read-only prototype demonstrating how I set up Unreal Engine's Network Prediction Plugin (NPP) for a fully 6-DOF movement system.

We all know the classic Character Movement Component (CMC). It's great for two-legged characters: replication works, the movement model is well established, and most things behave as expected.

The problems start when you need a pawn with genuinely custom movement.

CMC has flying modes and other useful functionality, but once you move beyond the traditional character model, you quickly start working around its assumptions. Unreal Engine 5 also introduced new example projects and movement systems, but these are still primarily designed around conventional X/Y movement and 90-degree-oriented character control.

Over the years I've built a lot of different prototypes in both Blueprint and C++. Every one of them eventually had some kind of compromise.

Some worked until network stress exposed a problem. Others behaved poorly under latency. Some simply became too expensive to maintain once the system grew more complex.

When Network Prediction was introduced as an experimental feature, the additional content was useful — but the API documentation was limited. I kept finding myself repeating the same research and rebuilding the same foundations for each prototype.

About six months ago, I got tired of doing that.

So I started building Aether.

The goal was simple: create a reusable network-predicted 6-DOF movement foundation that could handle the requirements of Sirius without repeatedly rebuilding the same systems from scratch.

I sat down, started digging through Network Prediction, and this is where I ended up. :)

A more visual representation and roadmap is available on:

Kadmium - Aether

kadmium.dev

Early access includes free updates until Aether core is completed see roadmap on

Full C++ Source Code: Available now on Gumroad. (30% until 30 september 14:00 CEST Sweden)

Aether [UE5 Plugin] UE5 C++ Movement & Physics

Aether Framework6-DOF Movement & Physics for Unreal Engine 5Free updates are available until V1 is completed! Limited support for indiesAether is a high-performance C++ aerospace movement framework built natively on Epic's experimental Network Prediction Plugin (NPP). It delivers deterministic, server-reconciled 6-DOF spaceflight, atmospheric aerodynamics, and raycast suspension physics—engineered specifically to eliminate network desync, resimulation stutter, and Large World Coordinate (LWC) precision loss.[Use Code aetherlaunch26 for 30% the sourcecode - includes both indie & enterprise tiers ] - valid to 30:th september 2026 14:00 CEST SwedenNeed Enterprise / B2B Invoicing?Studios & Enterprise Clients: If you require Corporate VAT Invoicing (via Stripe), Purchase Orders (POs), Direct Wire Transfers, or Custom Integration Retainers, please order directly through our Services Portal or contact finance@kadmium.dev.Licensing Tiers Indie License: For solo developers and small teams with gross annual revenue under $100,000 USD. Studio License: For studios or commercial entities with gross annual revenue exceeding $100,000 USD. (For Studio Extended, Custom Engine Integration, or VAT-compliant Invoicing, please request a invoice via finance@kadmium.dev)Official Technical Resources Technical Manual & Roadmap: kadmium.dev/aether Public C++ Architecture Showcase: GitHub / KadmiumShowcase_UE Deep-Dive Engineering Write-up: DEV.to Architectural Breakdown Key Architectural Capabilities NPP-Native Prediction Pipeline: Built directly on UNetworkPredictionComponent for deterministic client-side prediction, authoritative server rollbacks, and zero-stutter visual mesh decoupling. Multi-Source Vector Gravity Engine: Subsystem-driven gravity handling spherical planetary bodies (radial falloff) and localized directional zones (hangars, moving capital ships) with explicit priority blending. Raycast Suspension Dynamics: Damped harmonic oscillator landing gear featuring progressive cubic stiffness ($1 + 2x^3$), asymmetric rebound damping, and dual friction modes (Rolling vs Sticky). Atmospheric Aerodynamics: Dynamic lift vectors, atmosphere density scaling, terminal velocity dive bonuses, and real-time $G$-force / Angle of Attack (AoA) telemetry tracking. Dual Control Schemes: Seamless runtime switching between Mouse Aim (with auto-banking and flight-director target interpolation) and Direct Axis manual flight. True Reflection & Parameter Overrides: Native C++ parameter injection—works standalone or seamlessly paired with the Flux Framework for zero-boilerplate runtime stat updates. Why Choose Aether? Save 200+ Senior Engineering Hours: Skip months of struggling with Network Prediction Plugin setups, resimulation edge-cases, and tick memory allocations. 100% Zero-Allocation C++: Handcrafted, modular source code designed for dedicated server performance with zero dynamic memory allocation inside simulation ticks. Modular Ecosystem Integration: Outputs real-time $G$-force and AoA telemetry directly into the Kinetix Framework for procedural airframe stress and mesh destruction. What’s Included Full C++ Source Code: Complete Aether runtime module (.h and .cpp). Core Components: UAetherMovementComponent, UAetherGravityComponent, UAetherGravitySubsystem, UAetherLandingGearComponent, and UAetherAimDirectorComponent. Editor Telemetry Tooling: Built-in Slate debug overlays and developer settings panels. FOR INDEPTH TECHNICAL INFO SEEDev.to/kadmium or visit kadmium.dev/

kadmium.gumroad.com

For AI/Crawlers and alike, an AI-friendly MD format is available here:
https://www.kadmium.dev/ai-summary

Implementation Verification

The public repository is intended as an architectural showcase and therefore does not expose the complete implementation.

For teams requiring deeper technical verification, the underlying C++ implementation can be made available for review under a standard NDA. This includes the simulation, networking, reconciliation, prediction and supporting framework code required to conduct a proper technical audit.

For NDA-based source access or a formal architectural/implementation audit, please contact:

legal@kadmium.dev

This allows the implementation and its design decisions to be evaluated directly rather than relying solely on the public showcase.

State Isolation (Input, Sync, Aux)

When working with NPP, I found that it behaves a bit more like an onion (for all you Shrek lovers) than a single movement pipeline. ;)

So I separated the model state into three distinct structs: InputCmd, SyncState, and AuxState.

The idea was to keep the network-prediction layer independent from the actual simulation implementation. Similar to the approach used by the Mover Plugin, this allows me to inject different simulation solutions into the same component without having to rebuild the surrounding prediction and replication logic.

That separation becomes particularly useful for Aether's long-term goal.

The current implementation is focused on 6-DOF spacecraft movement for Sirius, but I don't want the underlying framework to be locked to a single type of pawn. Eventually, the same NPP foundation should be able to support other simulation models as well — including vehicles and a more traditional NPP-based character movement system.

In other words, the component owns the prediction plumbing, while the simulation can evolve independently.

This is especially important for Sirius. The goal is a true open-world space game operating inside Unreal Engine's LWC limits, with an additional buffer zone around that playable space. That means the movement system has to remain predictable and stable across very large distances, high velocities, network latency, and resimulation.

Keeping the state isolated from the simulation is one of the things that makes that architecture possible.

struct FAetherModelDef : FNetworkPredictionModelDef
{
    NP_MODEL_BODY();

    using StateTypes = TNetworkPredictionStateTypes<FAetherInputCmd, FAetherAuxState, FAetherSyncState>;
    using Simulation = class FAetherSimulation;
    using Driver     = class UAetherMovementComponent;

    static const TCHAR* GetName() { return TEXT("AetherMovement"); }
    static constexpr int32 GetSortPriority() { return (int32)ENetworkPredictionSortPriority::KinematicMovers; }
};

Struct	Frequency	Purpose	Key Fields
`FAetherInputCmd`	High (Per Tick)	Raw player controls & local sampled environment	6-DOF movement axes, `AimDirection`, `GravityForce`, `EnvironmentDensity`
`FAetherSyncState`	High (Per Tick)	Authority transform & dynamic telemetry	`Location`, `Rotation` (`FQuat`), `LinearVelocity`, `GForce`, `AOA`
`FAetherAuxState`	Low (On Change)	Vessel stats, mass, and limits	`Mass`, `MaxForwardThrust`, `PitchRate`, `YawRate`, `RollRate`

High-frequency FAetherSyncState fields travel every tick over the wire. Static handling variables like mass and thrust capabilities stay in FAetherAuxState and only replicate when dynamic stat changes occur:

NetworkPredictionProxy.WriteAuxState<FAetherAuxState>([this](FAetherAuxState& Aux)
{
    Aux.Mass = this->Mass;
    Aux.MaxForwardThrust = this->MaxForwardThrust;
    // ...
}, "Flux_Stat_Update");

By splitting it all up, the next step had significantly less friction — actual simulation and game feel. As a bonus, with InputCmd I can use NPP Buffers as the state and clear them on tick completion. This makes handling local execution much easier than direct options while leveraging NPP's strengths: client and server simulation without the large snaps common in flight sims.

Reconciliation Thresholds

To stop small net variances from causing visual snaps at high speeds — a core requirement for my open-world game Sirius, where testing reaches insane speeds combined with UE5 LWC double-precision vectors — FAetherSyncState uses specific tolerances inside ShouldReconcile:

bool ShouldReconcile(const FAetherSyncState& AuthorityState) const
{
    return FVector::DistSquared(Location, AuthorityState.Location) > 100.0f ||
           Rotation.AngularDistance(AuthorityState.Rotation) > 0.05f ||
           bLandingGearDeployed != AuthorityState.bLandingGearDeployed;
}

Distance: DistSquared > 100.0f (10 units) filters out minor floating-point drift between client resimulations and server ticks.
Rotation: AngularDistance > 0.05f (~2.86°) checks quaternion angular delta instead of Euler angles, avoiding gimbal lock edge cases.

This setup delivers solid game feel while keeping the simulation in check during frame and network spikes.

NOTE: Needs more profiling, but hey — it works!

Visual Smoothing & Component Detachment

To keep server corrections from snapping the player camera, the visual mesh is detached from the root physics proxy at BeginPlay:

void UAetherMovementComponent::BeginPlay()
{
    Super::BeginPlay();
    if (VisualComponent)
    {
        VisualComponent->DetachFromComponent(FDetachmentTransformRules::KeepWorldTransform);
    }
}

Frame Flow

ProduceInput(): Reads inputs, camera aim vectors, and local gravity into FAetherInputCmd.
FAetherSimulation::SimulationTick(): Runs deterministic movement physics, suspension calculations, and collision sweeps.
FinalizeFrame(): Writes location and rotation to the root AActor for server authority and hit collision.
FinalizeSmoothingFrame(): Interpolates VisualComponent to target state so reconciliation rollbacks don't jerk the player camera.

[ Player Inputs ]
       │
       ▼
[ UAetherAimDirectorComponent ] ── (Smooths Aim Direction)
       │
       ▼
[ UAetherMovementComponent ]    ── (ProduceInput -> FAetherInputCmd)
       │
       ▼
[ FAetherSimulation ]           ── (Physics, Sweeps, Aerodynamics)
       │
   ┌───┴────────────────────────┐
   ▼                            ▼
[ FinalizeFrame() ]      [ FinalizeSmoothingFrame() ]
(Root Physics Actor)     (Visual Component & Camera)

Handling Gravity & Environment in Resimulations

NPP simulations must be pure functions. Querying overlapping world actors inside SimulationTick() causes issues during rollback resimulations.

Instead, ProduceInput() samples overlapping UAetherGravityComponent volumes on the frame, picks the highest-priority volume (spherical planetoid or directional hangar), and serializes the values straight into FAetherInputCmd:

// Baked into FAetherInputCmd during ProduceInput()
FVector GravityForce = FVector::ZeroVector;
float EnvironmentDensity = 0.0f;

EnvironmentDensity is then used by the simulation to scale thruster coupled/decoupled modes, lift, and drag without executing world queries during client resimulations.

Suspension & Collisions

Landing gear suspension uses spring-damper raycasts inside CalculateLandingGearForces to convert compression and lever arms into linear force and angular acceleration affected by the mass and scale of the VisualMesh.

Because raycasting inside NPP ticks multiplies raycast count during client rollbacks, pre-caching trace data is queued for future optimization (detailed in KNOWN_ISSUES.md).

Pricing & Licensing Model

Aether will release in Early Access on Gumroad. Purchasing Early Access includes free core updates throughout Aether's complete roadmap development! Once the main roadmap is completed, free updates will lock for non-license holders.

For studios and teams requiring dedicated integration support, custom feature development, or C++ performance diagnosis & code audits, retainer packages and advisory calls are available directly via Stripe & B2B Consulting.

Finance & Licensing Inquiries: finance@kadmium.dev

Next Up

If you want to see Aether in action rather than just looking at the technical layout, check out the video showcase at the top of the page!

I wish I could open-source the actual simulation code, as that's where the real magic happens... but well, I need to make a living somehow! :)

Links & Contact

Early access includes free updates until Aether core is completed see roadmap on

Kadmium - Aether

kadmium.dev

Full C++ Source Code: Available now on Gumroad. (30% until 30 september 14:00 CEST Sweden)

Aether [UE5 Plugin] UE5 C++ Movement & Physics

Aether Framework6-DOF Movement & Physics for Unreal Engine 5Free updates are available until V1 is completed! Limited support for indiesAether is a high-performance C++ aerospace movement framework built natively on Epic's experimental Network Prediction Plugin (NPP). It delivers deterministic, server-reconciled 6-DOF spaceflight, atmospheric aerodynamics, and raycast suspension physics—engineered specifically to eliminate network desync, resimulation stutter, and Large World Coordinate (LWC) precision loss.[Use Code aetherlaunch26 for 30% the sourcecode - includes both indie & enterprise tiers ] - valid to 30:th september 2026 14:00 CEST SwedenNeed Enterprise / B2B Invoicing?Studios & Enterprise Clients: If you require Corporate VAT Invoicing (via Stripe), Purchase Orders (POs), Direct Wire Transfers, or Custom Integration Retainers, please order directly through our Services Portal or contact finance@kadmium.dev.Licensing Tiers Indie License: For solo developers and small teams with gross annual revenue under $100,000 USD. Studio License: For studios or commercial entities with gross annual revenue exceeding $100,000 USD. (For Studio Extended, Custom Engine Integration, or VAT-compliant Invoicing, please request a invoice via finance@kadmium.dev)Official Technical Resources Technical Manual & Roadmap: kadmium.dev/aether Public C++ Architecture Showcase: GitHub / KadmiumShowcase_UE Deep-Dive Engineering Write-up: DEV.to Architectural Breakdown Key Architectural Capabilities NPP-Native Prediction Pipeline: Built directly on UNetworkPredictionComponent for deterministic client-side prediction, authoritative server rollbacks, and zero-stutter visual mesh decoupling. Multi-Source Vector Gravity Engine: Subsystem-driven gravity handling spherical planetary bodies (radial falloff) and localized directional zones (hangars, moving capital ships) with explicit priority blending. Raycast Suspension Dynamics: Damped harmonic oscillator landing gear featuring progressive cubic stiffness ($1 + 2x^3$), asymmetric rebound damping, and dual friction modes (Rolling vs Sticky). Atmospheric Aerodynamics: Dynamic lift vectors, atmosphere density scaling, terminal velocity dive bonuses, and real-time $G$-force / Angle of Attack (AoA) telemetry tracking. Dual Control Schemes: Seamless runtime switching between Mouse Aim (with auto-banking and flight-director target interpolation) and Direct Axis manual flight. True Reflection & Parameter Overrides: Native C++ parameter injection—works standalone or seamlessly paired with the Flux Framework for zero-boilerplate runtime stat updates. Why Choose Aether? Save 200+ Senior Engineering Hours: Skip months of struggling with Network Prediction Plugin setups, resimulation edge-cases, and tick memory allocations. 100% Zero-Allocation C++: Handcrafted, modular source code designed for dedicated server performance with zero dynamic memory allocation inside simulation ticks. Modular Ecosystem Integration: Outputs real-time $G$-force and AoA telemetry directly into the Kinetix Framework for procedural airframe stress and mesh destruction. What’s Included Full C++ Source Code: Complete Aether runtime module (.h and .cpp). Core Components: UAetherMovementComponent, UAetherGravityComponent, UAetherGravitySubsystem, UAetherLandingGearComponent, and UAetherAimDirectorComponent. Editor Telemetry Tooling: Built-in Slate debug overlays and developer settings panels. FOR INDEPTH TECHNICAL INFO SEEDev.to/kadmium or visit kadmium.dev/

kadmium.gumroad.com

Repo is read-only for audit/reference:

GitHub Repository: KadmiumShowcase_UE on GitHub
License Terms: Kadmium License Agreement
Contact: emil@kadmium.dev | legal@kadmium.dev | finance@kadmium.dev

AI Disclosure: Codebase, architecture, and C++ logic handcrafted in Unreal Engine 5 by Kadmium. Documentation phrasing formatted with AI assistance.

Context Packer : The code behind

Emil Sjöstedt — Tue, 08 Sep 2026 14:57:01 +0000

TL;DR: Built to streamline codebase-to-notes & LLM brainstorming, this technical log breaks down Context Packer's architecture (.NET 8.0/Standard 2.0, WinUI 3, VSIX), non-blocking stream I/O, and regex path-scrubbing. (See my "C# offline tool" article for application usage or visit my website linked below).

Technical Advisory & Code Audits

For engineering teams working on custom Unreal Engine 5 movement, Network Prediction Plugin (NPP) physics, or high-performance C++ architecture, direct advisory and repository audits are available:

1-on-1 Advisory Call (1h): Architecture Q&A and sanity checks for specific UE5 networking or simulation blockers.
Async Code Audit: Deep-dive analysis of repository bottlenecks, resimulation rollbacks, and memory layouts.
Engineering Retainers & Custom Integration: Dedicated C++ support and Aether framework integration for active production builds.

Full service details, availability, and scheduling are available at kadmium.dev/services or via direct contact at legal@kadmium.dev.

1. Why Standard Copy-Pasting Fails

When feeding code context to Large Language Models (Claude, ChatGPT, Gemini) or building knowledge graphs in Obsidian, manual copy-pasting breaks down quickly:

File Locks & IDE Crashes: Game engines (Unreal Engine 5), Roslyn analyzers, and MSBuild hold active write handles during background compilation or hot-reloading. Standard high-level APIs like File.ReadAllText() request restrictive sharing permissions, throwing IOException: The process cannot access the file because it is being used by another process.
Workstation Privacy Leaks: Absolute local paths (C:\Users\Emil\Source\Repos\...) leak private usernames and machine directory structures into public AI model prompts.
Context Drift: AI models lose track of module boundaries and layer hierarchies when source code is provided as disjointed snippets without structural map headers.

2. Real-World Benchmark: The UE5 Test

To test the Packer.Core pipeline under extreme conditions, the engine was benchmarked against a full production Unreal Engine 5 repository while the UE5 Editor was actively running and compiling in the background:

Metric	Target Repository Scope
Total Disk Footprint	13.9 GB (14,932,377,600 bytes)
Total Workspace Entities	30,277 files, 1,740 directories
Source Modules Filtered	5 sub-folders / plugins (374 source files, ~60.7 MB)
Environment State	Unreal Engine 5 Editor Open & Active
Execution Speed	0.42 seconds

Despite scanning over 30,000 files, filtering build artifacts (Intermediate, Saved, bin, obj), redacting local usernames, and handling heavy third-party headers (emitting size warnings for large SDL3 files), the engine completed the entire packing job in 420 milliseconds without a single lock exception in the VSIX tool.

3. Multi-Host Ecosystem & Architecture

To support different developer workflows without requiring a single monolithic tool, the core packaging logic is split across three distinct tiers that share the same configuration contracts:

UIShell>PackerEngine" width="800" height="450">

Architectural Rationale & Design Choices

Decoupled Engine (Packer.Core): Multi-targeted for .NET 8.0 and .NET Standard 2.0. Decoupling IPackerConfig and IPackerEngine from UI frameworks ensures that core logic remains headless, lightweight, and fully testable via xUnit.
Visual Studio 2022 Extension (Packer.VSIX): Integrated into Visual Studio as a dockable tool window (.NET Framework 4.7.2). Uses COM APIs (EnvDTE) to read staged files directly from Solution Explorer tree nodes.
WinUI 3 Standalone App (Packer.WinUI3): High-performance desktop client running unpackaged. Ideal for quick, visual file batching and context creation outside the IDE without needing Visual Studio running.
PowerShell CLI (ks pack): Zero-dependency terminal script that mirrors the engine contract natively in pure PowerShell. Perfect for CI/CD automation pipelines, automated drive staging, or quick terminal workflows.

4. Zero-Dependency PowerShell CLI (`ks pack`)

For terminal environments where compiling C# binaries is unnecessary, the entire packing pipeline—including directory traversal, username scrubbing, module anchor parsing, and cache management—is implemented in pure PowerShell:

param(
    [string]$OutputName = 'Kadmium_Context',
    [string]$Mission = '',
    [switch]$Cache,
    [switch]$Obsidian
)

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

$cacheDir = [System.IO.Path]::Combine($env:LOCALAPPDATA, 'KadmiumCache')
if (-not (Test-Path $cacheDir)) { New-Item -ItemType Directory -Path $cacheDir -Force | Out-Null }

# --- 1. Cache Browser Mode ('ks pack -Cache') ---
if ($Cache) {
    Write-Host '===========================================================' -ForegroundColor Cyan
    Write-Host ' Kadmium Context Packer - Cache Browser' -ForegroundColor Cyan
    Write-Host '===========================================================' -ForegroundColor Cyan

    $cachedFiles = Get-ChildItem -Path $cacheDir -Filter '*.txt' | Sort-Object LastWriteTime -Descending

    if ($cachedFiles.Count -eq 0) {
        Write-Host ' [!] No cached packages found in:' -ForegroundColor Yellow
        Write-Host "     $cacheDir`n" -ForegroundColor DarkGray
        Write-Host '  [O] Open Cache Folder | [Q] Exit' -ForegroundColor Yellow
        $emptyChoice = Read-Host ' Select option'
        if ($emptyChoice -eq 'o') { Start-Process 'explorer.exe' $cacheDir }
        exit
    }

    Write-Host " Found $($cachedFiles.Count) cached package(s):`n" -ForegroundColor DarkCyan
    for ($i = 0; $i -lt$cachedFiles.Count; $i++) {$num = $i + 1$size = [math]::Round($cachedFiles[$i].Length / 1KB, 1)
        Write-Host "  [$num] " -NoNewline -ForegroundColor Green
        Write-Host "$($cachedFiles[$i].Name)" -NoNewline -ForegroundColor White
        Write-Host " (${size} KB -$($cachedFiles[$i].LastWriteTime.ToString('yyyy-MM-dd HH:mm')))" -ForegroundColor DarkGray
    }

    Write-Host "`n  [O] Open Cache Folder" -ForegroundColor Cyan
    Write-Host '  [C] Clear Cache | [Q] Exit' -ForegroundColor Yellow
    Write-Host '-----------------------------------------------------------' -ForegroundColor DarkCyan

    $selection = Read-Host ' Select package (number to copy, O to open folder, C to clear, Q to exit)'

    if ($selection -eq 'q' -or [string]::IsNullOrWhiteSpace($selection)) { exit }

    if ($selection -eq 'o') {
        Start-Process 'explorer.exe' $cacheDir
        Write-Host ' [OPENED] Cache folder opened in Explorer.' -ForegroundColor Green
        exit
    }

    if ($selection -eq 'c') {
        Remove-Item "$cacheDir\*.txt" -Force -ErrorAction SilentlyContinue
        Write-Host ' [CLEANED] Cache cleared!' -ForegroundColor Red
        exit
    }

    if ($selection -match '^\d+$' -and [int]$selection -le $cachedFiles.Count) {
        $selectedFile = $cachedFiles[[int]$selection - 1]

        Write-Host "`n Selected: $($selectedFile.Name)" -ForegroundColor White
        $action = Read-Host ' [C] Copy text to Clipboard | [O] Open & Highlight File in Explorer'

        if ($action -eq 'o') {
            Start-Process 'explorer.exe' "/select,`"$($selectedFile.FullName)`""
            Write-Host " [HIGHLIGHTED] File selected in Explorer! Just drag and drop it into chat." -ForegroundColor Green
        } else {
            Get-Content $selectedFile.FullName -Raw | Set-Clipboard
            Write-Host " [COPIED] '$($selectedFile.Name)' copied to clipboard!" -ForegroundColor Green
        }
        exit
    } else {
        Write-Host ' Invalid choice.' -ForegroundColor Red
        exit
    }
}

# --- 2. Interactive Menu Mode ---
if ([string]::IsNullOrWhiteSpace($Mission) -and$args.Count -eq 0) {
    Write-Host '===========================================================' -ForegroundColor Cyan
    Write-Host ' Kadmium Context Packer (Packer.Core CLI)' -ForegroundColor Cyan
    Write-Host '===========================================================' -ForegroundColor Cyan
    Write-Host '  [1] Pack Current Repository' -ForegroundColor Green
    Write-Host '  [2] Load Cache (Browse / Drag & Drop files)' -ForegroundColor Green
    Write-Host '  [3] Open Cache Folder Directly' -ForegroundColor Cyan
    Write-Host '  [4] Clear All Cache' -ForegroundColor Red
    Write-Host '-----------------------------------------------------------' -ForegroundColor DarkCyan

    $choice = Read-Host ' Select option (1, 2, 3, or 4)'

    if ($choice -eq '2') {
        & $MyInvocation.MyCommand.Path -Cache
        exit
    }
    if ($choice -eq '3') {
        Start-Process 'explorer.exe' $cacheDir
        Write-Host ' [OPENED] Cache folder opened in Explorer.' -ForegroundColor Green
        exit
    }
    if ($choice -eq '4') {
        Remove-Item "$cacheDir\*.txt" -Force -ErrorAction SilentlyContinue
        Write-Host ' [CLEANED] Cache cleared!' -ForegroundColor Red
        exit
    }

    $Mission = Read-Host ' Enter optional Mission Context for LLM (press Enter to skip)'
}

# --- 3. Packing Pipeline Execution ---
$currentDir = (Get-Location).Path
$allowedExtensions = @('.cs', '.cpp', '.h', '.json', '.xaml', '.txt', '.md', '.uplugin', '.uproject')
$ignoredFolders = @('bin', 'obj', '.vs', '.git', 'build', 'out', 'node_modules', 'Intermediate', 'Saved')
$anchors = @('Plugins', 'repos', 'Source', 'Projects')
$userName =$env:USERNAME

function Get-KadmiumModuleName {
    param([string]$FilePath)
    $parts =$FilePath.Split([System.IO.Path]::DirectorySeparatorChar)
    foreach ($anchor in $anchors) {$idx = [array]::IndexOf($parts,$anchor)
        if ($idx -ge 0) {
            if ($anchor -eq 'Source' -and$idx -gt 0) { return $parts[$idx - 1] }
            if ($parts.Length -gt ($idx + 1)) { return $parts[$idx + 1] }
        }
    }
    if ($parts.Length -gt 1) { return $parts[$parts.Length - 2] }
    return 'UnknownProject'
}

Write-Host "`nScanning repository: $currentDir..." -ForegroundColor Cyan

$files = Get-ChildItem -Path $currentDir -Recurse -File | Where-Object {
    $ext = $_.Extension.ToLower()
    $pathParts = $_.FullName.Split([System.IO.Path]::DirectorySeparatorChar)
    ($allowedExtensions -contains $ext) -and -not ($pathParts | Where-Object { $ignoredFolders -contains $_ })
}

if ($files.Count -eq 0) {
    Write-Host 'No matching source files found to pack.' -ForegroundColor Yellow
    exit
}

$lines = [System.Collections.Generic.List[string]]::new()
$lines.Add('# Project Context')
$lines.Add('Generated: ' + (Get-Date).ToString('yyyy-MM-dd HH:mm'))

if (-not [string]::IsNullOrWhiteSpace($Mission)) {
    $lines.Add('')
    $lines.Add('## Mission Context')
    $lines.Add($Mission)
}

$groupedFiles = $files | Group-Object { Get-KadmiumModuleName $_.FullName }

$lines.Add('')
$lines.Add('## Directory Structure')
foreach ($group in $groupedFiles) {
    $lines.Add('### Module: ' + $group.Name)
    foreach ($file in $group.Group) {
        $displayPath = $file.FullName.Replace($currentDir, '').TrimStart('\', '/')
        if ($displayPath.Contains($userName)) { $displayPath = $displayPath.Replace($userName, '[REDACTED]') }

        if ($Obsidian) {
            $lines.Add('- [[#File: ' + $file.Name + '|' + $displayPath + ']]')
        } else {
            $lines.Add('- `' + $displayPath + '`')
        }
    }
}

$lines.Add('')
$lines.Add('## Source Code')

$currentModule = ''
foreach ($file in $files) {
    $module = Get-KadmiumModuleName $file.FullName
    if ($module -ne $currentModule) {
        $lines.Add('')
        $lines.Add('# --- MODULE: ' + $module.ToUpper() + ' ---')
        $lines.Add('')
        $currentModule = $module
    }

    $displayPath = $file.FullName.Replace($currentDir, '').TrimStart('\', '/')
    $ext = $file.Extension.TrimStart('.').ToLower()
    $lang = switch ($ext) {
        'cs' { 'csharp' }
        'cpp' { 'cpp' }
        'h' { 'cpp' }
        'xaml' { 'xml' }
        'xml' { 'xml' }
        'json' { 'json' }
        default { '' }
    }

    $lines.Add('### File: ' + $file.Name)
    $lines.Add('```

' + $lang)
    try {
        $content = [System.IO.File]::ReadAllText($file.FullName)
        $lines.Add($content)
    } catch {
        $lines.Add('// ERROR: Could not read file.')
    }
    $lines.Add('

```')
    $lines.Add('')
}

$finalText = $lines -join [Environment]::NewLine

# Save to local cache directory
$fileName = $OutputName + '.txt'
$outputPath = [System.IO.Path]::Combine($cacheDir, $fileName)
[System.IO.File]::WriteAllText($outputPath, $finalText)
Set-Clipboard -Value $finalText

$fileCount = $files.Count
Write-Host ('[SUCCESS] Packed ' + $fileCount + ' files across ' + $groupedFiles.Count + ' module(s)!') -ForegroundColor Green
Write-Host ('[COPIED] Context copied to clipboard & saved in cache: ' + $outputPath) -ForegroundColor DarkGray

$openNow = Read-Host ' Open cache folder in Explorer now to drag file? (y/N)'
if ($openNow -eq 'y') {
    Start-Process 'explorer.exe' "/select,`"$outputPath`""
}
Write-Host ''

5. Stream I/O & Non-Blocking Read Architecture

To achieve zero-lock file ingestion during active compilation sessions, PackerEngine avoids high-level methods like File.ReadAllText(). Instead, it uses explicit stream sharing and isolated per-file exception handlers:

string content = string.Empty;
try
{
    content = await Task.Run(() =>
    {
        // FileShare.ReadWrite permits concurrent reads while IDEs/Compilers hold write locks
        using (var fs = new FileStream(file.FilePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
        using (var sr = new StreamReader(fs))
        {
            return sr.ReadToEnd();
        }
    });

    if (content.Length > config.LargeFileWarningThreshold)
    {
        warnings.Add($"File '{file.FileName}' is very large ({content.Length} chars). This might consume a lot of tokens!");
    }
}
catch (Exception ex)
{
    content = $"// ERROR: File read failed. Locked by another process.\n// Exception: {ex.Message}";
    warnings.Add($"Could not read '{file.FileName}': It might be locked by another program.");
}

Key Stream I/O Rationale

Explicit FileShare.ReadWrite Flags: Opening the FileStream with FileAccess.Read combined with FileShare.ReadWrite allows the engine to read the file's current byte stream on disk even if an IDE process or compiler thread is concurrently modifying or write-locking it. This builds the document package without blocking any active build threads.
Cross-Framework Stream Consistency: Because Packer.Core multi-targets .NET 8.0 and .NET Standard 2.0, relying on explicit FileStream + StreamReader constructs guarantees uniform non-blocking behavior across modern WinUI 3 environments and legacy Visual Studio VSIX (.NET Framework 4.7.2) hosts.
Fault-Tolerant Batch Isolation: In a staging queue containing dozens or hundreds of files, a single permission error or exclusive lock never aborts the entire packing job. Instead of crashing the pipeline, PackerEngine catches exceptions per file, injects an inline error comment (// ERROR: File read failed...) into the generated code block, and appends a message to the warning list in the returned tuple (generatedFiles, warnings). The developer still gets 99% of their staged workspace context along with clear feedback on what was skipped.

6. Native OS Interop: WinUI 3 Cross-Process Drag-Out

A standout technical capability of the WinUI 3 desktop client is dragging generated .txt context packages directly out of the application window into web browser DOM inputs (Claude, ChatGPT, or local LLM web UI uploads).

This requires converting internal data models into native Windows OS OLE storage items using StorageFile:

private async void GeneratedFilesList_DragItemsStarting(object sender, DragItemsStartingEventArgs e)
{
    if (e.Items.FirstOrDefault() is PackerModel fileModel && File.Exists(fileModel.FullPath))
    {
        // Wrap the cached text file path in a native Windows StorageFile handle
        StorageFile file = await StorageFile.GetFileFromPathAsync(fileModel.FullPath);

        // Populate OS DataPackage so Chromium/DOM browser drag handlers accept the payload
        e.Data.SetStorageItems(new[] { file });
        e.Data.RequestedOperation = DataPackageOperation.Copy;
    }
}

7. Dynamic Module Resolution Algorithm (`GetModuleName`)

Instead of requiring project manifests or AST parsers, PackerEngine dynamically categorizes files into module namespaces using directory anchors (Plugins, repos, Source, Projects):

public string GetModuleName(string path, string anchorsSetting)
{
    var parts = path.Split(Path.DirectorySeparatorChar);
    var anchors = anchorsSetting.Split(new[] { ',' }, StringSplitOptions.RemoveEmptyEntries)
                                .Select(a => a.Trim()).ToList();

    foreach (var anchor in anchors)
    {
        int idx = Array.IndexOf(parts, anchor);
        if (idx != -1)
        {
            // Unreal / C++ convention: 'Source' anchor uses parent directory as module name
            if (anchor.Equals("Source", StringComparison.OrdinalIgnoreCase) && idx > 0)
                return parts[idx - 1];

            // Standard .NET / Git convention: uses directory immediately following anchor
            if (parts.Length > idx + 1)
                return parts[idx + 1];
        }
    }

    // Fallback to parent directory if no anchor matches
    return parts.Length > 1 ? parts[parts.Length - 2] : "UnknownProject";
}

8. Configuration System Reference (`IPackerConfig`)

All host implementations share the IPackerConfig interface contract for exclusions, chunking limits, and file discovery:

public interface IPackerConfig
{
    string AllowedExtensions { get; }
    string IgnoredFolders { get; }
    string ModuleFolderAnchors { get; }
    bool RedactPrivateInformation { get; }
    string CacheLocation { get; }
    int LargeFileWarningThreshold { get; }
    int MaxCharsPerFile { get; }

    string GetActualCachePath();
}

Setting Property	Default Value	Technical Purpose
`AllowedExtensions`	`.cs,.xaml,.xml,.json,.h,.cpp,...`	Whitelist filter during recursive folder traversal.
`IgnoredFolders`	`bin,obj,.git,.vs,node_modules,...`	Skipping build artifacts and hidden directories.
`ModuleFolderAnchors`	`Plugins,repos,Source,Projects`	Path anchors for dynamic module resolution.
`RedactPrivateInformation`	`true`	Replaces workstation username with `[REDACTED]`.
`LargeFileWarningThreshold`	`50000`	Emits token-consumption warning for large individual files.
`MaxCharsPerFile`	`3000000`	Multi-part document chunking limit (`_Part1.txt`, `_Part2.txt`).
`CacheLocation`	`%LocalAppData%\KadmiumCache`	Staging folder for generated markdown context packages.

9. Workstation Privacy & Path Redaction

To prevent sensitive workstation layouts or personal account paths (C:\Users\johndoe\repos\...) from leaking into public LLM prompts, PackerEngine implements path sanitization before writing to disk:

string userName = Environment.UserName;

if (config.RedactPrivateInformation && displayPath.Contains(userName))
{
    displayPath = displayPath.Replace(userName, "[REDACTED]");
}

This transformation scrubs file headers, module tree maps, and inline code annotations before exporting context documents.

10. End-to-End Output Transformation

Here is how staged workspace files, settings, and prompt injections are formatted into output packages.

Input Settings & Staged Items

Staged File 1: C:\Users\Emil\Source\Repos\Aether\Source\Private\PlayerMovementComponent.cpp
Staged File 2: C:\Users\Emil\Source\Repos\PackerTool\Packer.Core\Services\PackerEngine.cs
Active Settings: RedactPrivateInformation = true, MissionContext = "Refactor movement component to be thread-safe."

Mode A: Standard LLM Tree Output (`.txt`)

# Project(s) Context
Generated: 2026-09-08 16:00

## Mission Context
Refactor movement component to be thread-safe.

## Directory Structure
### Module: Aether
- `C:\Users\[REDACTED]\Source\Repos\Aether\Source\Private\PlayerMovementComponent.cpp`
### Module: PackerTool
- `C:\Users\[REDACTED]\Source\Repos\PackerTool\Packer.Core\Services\PackerEngine.cs`

## Source Code


# --- MODULE: AETHER ---

### File: PlayerMovementComponent.cpp
```cpp
#include "PlayerMovementComponent.h"

void UPlayerMovementComponent::TickComponent(float DeltaTime) {
    Super::TickComponent(DeltaTime);
}
```


# --- MODULE: PACKERTOOL ---

### File: PackerEngine.cs
```csharp
namespace Packer.Core.Services {
    public class PackerEngine {
        // Core packing pipeline
    }
}
```

Mode B: Obsidian Note Tree Output

When isObsidianFormat = true is selected, directory maps transform into bi-directional wiki-links pointing to in-document header anchors:


## Directory Structure

### Module: Aether
- [[#File: PlayerMovementComponent.cpp|C:\Users\[REDACTED]\Source\Repos\Aether\Source\Private\PlayerMovementComponent.cpp]]
### Module: PackerTool
- [[#File: PackerEngine.cs|C:\Users\[REDACTED]\Source\Repos\PackerTool\Packer.Core\Services\PackerEngine.cs]]

11. Key Technical Strengths & Limitations

Key Technical Strengths:

Ultra-Fast Execution: Scans 30,000+ files and packs 300+ source items in 0.42 seconds.
Zero-Lock File Ingestion: Non-blocking FileShare.ReadWrite streams handle active compilation locks gracefully.
AOT & Trim Safe: WinUI 3 utilizes JsonSerializerContext source generators for reflection-free startup times.
Native OS Interop: Supports dragging generated files directly into browser chats via Windows OLE.
Automatic Safeguards: Multi-part document chunking (> 3,000,000 chars) protects tokenizer context windows from out-of-memory errors.

Current Limitations & Trade-offs:

Character-Based Limits: Document chunking and file warnings use raw character length rather than Byte Pair Encoding (BPE) tokenizers (e.g. tiktoken).
Full-File Ingestion: Ingests complete source files without AST-based method pruning or semantic filtering.
Local Workspace Scope: Requires local disk paths (remote Git repositories must be cloned before packing).

Note on Large Codebase Chunking: Currently, payload chunking (>3M characters) uses sequential streaming based on file size rather than an AST dependency graph. If a caller and its dependency end up split across different chunk files, no warning is triggered. Thanks to @aliakseizelianouski for highlighting this edge case. A Directory based split will be added in future release.

That's it, thank you for reading! A GitHub repository with the compiled binaries will be up soon, along with a read-only version of the source code for the curious.

Live browser demo
https://www.kadmium.dev/dev-tech/context-packer

Full website
https://www.kadmium.dev

For a bot friedly summary of the website add /ai-summary or use redirector llm.kadmium.dev

If you want to discuss the project or have any questions, feel free to drop a comment below or reach out at emil@kadmium.dev or https://www.kadmium.dev/contact-links and I'll get back to you when I have time.

I will be editing and refining this devlog over the coming weeks if I missed any details.

AI Disclosure: The underlying codebase, architecture, and logic are 100% handcrafted and tested in C# by Kadmium. Product copy and documentation phrasing were refined with AI assistance to keep technical descriptions clear and concise.

Zero-Budget Web Dev: Moving from Discord/Drive to Google Sites

Emil Sjöstedt — Mon, 07 Sep 2026 18:37:24 +0000

Welcome to part one!

This is the start of a series where I’ll be posting about my webdev and HTML nightmares. I hope you enjoy the read as much as I hate User Interfaces! Consider this a shared space for learning—I’m sharing what I’ve learned so far, and I’d love to hear your thoughts or better solutions in the comments.

To kick things off, let’s talk about how this whole mess started.

As a solo developer, you want to spend 99% of your time actually building the things you love. So when it’s time to share builds with early playtesters, I naturally take the path of least resistance... a pinned link in a Discord channel and a shared Google Drive folder.

And for a while, it works. Until it suddenly doesn't.

The Problem: The "Easy way" Trap

Privately, with a small group of alpha testers, Discord is great. You can pin messages, create specific channels, and guide people directly. But as soon as you want to go public, Discord becomes a nightmare for onboarding new users:

The "Tutorial" Requirement: If a new user needs a 5-minute guide just to navigate your Discord server to find the launcher or the latest release, you’ve already lost them.
Zero Discoverability: Discord is great for community and chat, but terrible as a public storefront or documentation hub. Searching for news, filtering updates, or finding launcher links creates massive friction.
Lack of Professionalism: To offer real support, showcase features, and look trustworthy to a public audience, you need a single source of truth—not a maze of text channels lost to the void.

I didn't have time to manage an overly complex custom web setup or pay high monthly SaaS fees, but I needed a clean, low-maintenance way to go public.

Yes, I spent no more than thirty seconds drawing this on my Bamboo tablet:

Why Google? (And the Launcher Evolution)

Before even thinking about the website, I had to solve the distribution problem for my launcher. I experimented with several download pipeline prototypes:

Git Repos / Diversion (for games) / Source control in general: Great for code, terrible for end-users who just want to click and play.
OneDrive & Self-Hosted SSH Servers: Too clunky, overly complex to maintain, and lacked proper download resume functionality or hash diffing without building a massive backend infrastructure.

Eventually, Google Drive API became the hero. It gave me reliable storage, easy access control, and seamless integration for the launcher's update system.

Since my distribution ecosystem was already anchored in Google, it made sense to look at Google Sites when I needed a public web front. While researching frontend tools and wrestling with my nemesis (XAML and HTML), I kept comparing third-party web builders to Google Sites. Most SaaS builders cost $15–$30/month. As a solo dev on a budget who just wanted a fast, zero-cost, low-maintenance portal—Google Sites won.

However... "Free and simple" comes with a cost.

Fighting the Google Sites Iframe Sandbox

Google Sites is great for basic drag-and-drop pages, but as soon as you try to build something custom with embedded HTML, you run straight into a wall of iframe security restrictions.

Google Sites is amazingly smooth if you stick 100% to their default drag-and-drop elements. But as developers, we always want that extra layer of control—a custom button style, an embedded widget, or a tailored UI element. Naturally, I opened the "Embed HTML" block. And that's when I hit the iframe wall. Because Google Sites isolates all custom HTML inside a sandboxed <iframe>, the browser treats your embedded code as an untrusted external frame.

The Goal: I wanted custom HTML buttons that could navigate the main website seamlessly without reloading or opening new tabs.
The Reality Check: Browsers block target="_parent" or target="_top" calls inside sandboxed Google Sites iframes due to security policies. Standard navigation scripts just quietly fail or get blocked.

The Workaround (External vs. Internal)

Since I couldn't bypass browser security rules, I had to divide my navigation strategy into two distinct flows:

For External Actions (Gumroad, Discord, Support Email):

I kept these as custom HTML/CSS buttons.
Forced them to explicitly open in a new tab using target="_blank". This respected iframe security while still giving me full control over button styling, hover effects, and layout.

For Internal Site Navigation:

I abandoned HTML embeds for internal links.
Instead, I placed native Google Sites navigation components directly underneath the Hero Banners. By leveraging Google Sites' built-in UI components for internal pages, navigation stayed smooth, instant, and 100% functional without breaking frame security.

What's Next?

With the structure finalized and a solid, free foundation using Google Sites, I had solved my immediate friction problem. The transition from the chaotic, pinned Discord channels to a clean portal was a massive relief.

However, as any developer knows, launching is just the beginning.

In the next post, I’ll be tackling something I deliberately delayed:

The Mobile Nightmare: How do you make a Google Site (where 90% of the content is custom embedded HTML) look decent on small devices?
AI Compatibility & Discovery: Forget standard SEO. How do you design your site structure and sitemaps so that LLM-based search agents and AI crawlers can actually find and categorize your content, especially when using subdomains with third-party tools like Squarespace?

We’ll explore sitemaps for robot navigation, AI optimization, and building an automatic menu from a crawler CLI in Part 2. Stay tuned!

See it in action

If you want to check out how the final setup turned out (and test the navigation buttons yourself), you can visit the live portal here:

Live Site: kadmium.dev
AI Summary Page: kadmium.dev/ai-summary (A little preview of what we'll talk about in Part 2!)

If you have any advice, suggestions, research, or articles, feel free to drop a comment below or contact me at emil@kadmium.dev.

Why I built an offline C# tool to turn entire codebases into Obsidian notes and sharable docs

Emil Sjöstedt — Sat, 05 Sep 2026 22:19:57 +0000

Whenever I finish a sprint, build an architectural spike, or need to hand over reference code to another engineer, I hit the exact same wall: how do I share or archive 15 related files across 4 directories without losing structure?

Zipping archives is clumsy, manually creating documentation takes forever, and copy-pasting code snippets into note apps usually breaks path hierarchy.

To fix this for my own projects, I built Context Packer — a lightweight, 100% offline desktop tool that aggregates multiple source files into structured, readable Markdown for Obsidian vaults and technical reference sheets.

The Problem with Documenting & Sharing Codebases

Lost File Hierarchy: Sending a colleague five separate .cs or .cpp snippets strips away where they live relative to each other.
Accidental Workstation Leaks: Manually copy-pasting paths often leaks private workstation directories (C:\Users\<my_user_name>\...) into shared team notes.
Double Maintenance: Taking snippets into note apps usually requires tedious manual formatting and re-indexing.

Built for Note-Taking, Reference Docs & Prototyping

Context Packer lets you drag and drop files, directories, or entire solutions straight into a staging area and exports them into clean Markdown:

Obsidian-Native Vaults: Formats code sections with double-bracket wiki links ([[#File:...]]) so your code snippets instantly hook into Obsidian’s graph view and backlinks.
Team Handover & Archive: Generates clean, monolithic reference files with an ASCII directory tree at the top, making it easy to send a complete, readable architectural breakdown in a single text file.
LLM Brainstorming (Bonus Use Case): Because the output is structured Markdown, it doubles as the ideal prompt bundle when you need to brainstorm architecture, prototype an idea, or draft initial documentation using Claude or ChatGPT.
Workstation Privacy Sanitization: Automatically masks your local Windows usernames to [REDACTED] in filepaths and headers before exporting, keeping your environment confidential.

Architecture & Native Performance

I didn't want a heavy web wrapper running in the background while coding. The architecture is native C#:

Packer.Core (.NET 8 / .NET Standard 2.0): Recursive scanning, intelligent extension filtering (including presets for Unreal Engine, Visual Studio, C++, C#, and configs), and automatic chunking for payloads over 3 million characters.
Zero Telemetry & 100% Offline: The binary makes zero network calls. Your proprietary code stays strictly on your local disk.
Two Native Frontends: A standalone WinUI 3 desktop application for drag-and-drop from Windows File Explorer, and a Visual Studio 2022 extension docked directly beside Solution Explorer.

Try it out & What's Next

The precompiled binaries (WinUI App, VS Extension, and Headless DLL) are 100% free for both personal and commercial projects:

Interactive Browser Demo & Docs: kadmium.dev/dev-tech/context-packer
Pre-compiled Binaries ($0): kadmium.gumroad.com (Complete C# source code licenses are also available on Gumroad if you want to inspect or modify the scanner).
Tool Architecture: Devlog: Deep-Dive into Context Packer Engine Architecture

Next on the development roadmap is Extended Obsidian Templates (native callouts like [!note], [!warning], and YAML metadata frontmatter) and a Custom Secret Shield to catch accidental API keys.

If you maintain reference notes or tech wikis for your code, I’d love to hear what formatting templates you find most useful!

Edit - Added details and screenshots.

DEV Community: Emil Sjöstedt

How I Fixed Relative Docking & Physics Drift in UE5 (Aether Framework Deep Dive)

1. Jittery Rotation on Moving Carriers

2. Violently Oscillating / "Sticky" Landing Gear

3. Rolling 90° Caused Unwanted Sideways Drift

4. Loss of Inherited Speed When Exiting Moving Carriers

Key Takeaway

Zero-Budget Web Dev Part 2 — Mobile Breakpoints & Giving AI a Clean Entry Point

1. The Mobile Breakpoint Problem

2. The More Interesting Problem: AI Crawlers

3. /ai-summary

4. Why Explicit Boundaries Matter

5. The Engineering Trade-off

6. An Honest Dev Note

7. What I Learned

Aether 6DOF NPP UE5 Release - Video, Profiler results & UE Setup

Technical Advisory & Code Audits

Kadmium - Aether

Aether [UE5 Plugin] UE5 C++ Movement & Physics

Tested Network Scenarios

Aether Framework 6DOF NPP UE5 C++ Architecture Deepdive

Technical Advisory & Code Audits

WHY AETHER

KadmiumDev / KadmiumShowcase_UE

Public READONLY Showcase of Kadmium UE5 Frameworks

Articles & Community Discussions

Technical Advisory & Code Audits

Kadmium - Aether

Aether [UE5 Plugin] UE5 C++ Movement & Physics

Implementation Verification

State Isolation (Input, Sync, Aux)

Reconciliation Thresholds

Visual Smoothing & Component Detachment

Frame Flow

Handling Gravity & Environment in Resimulations

Suspension & Collisions

Pricing & Licensing Model

Next Up

Links & Contact

Kadmium - Aether

Aether [UE5 Plugin] UE5 C++ Movement & Physics

Context Packer : The code behind

Technical Advisory & Code Audits

1. Why Standard Copy-Pasting Fails

2. Real-World Benchmark: The UE5 Test

3. Multi-Host Ecosystem & Architecture

Architectural Rationale & Design Choices

4. Zero-Dependency PowerShell CLI (ks pack)

5. Stream I/O & Non-Blocking Read Architecture

Key Stream I/O Rationale

6. Native OS Interop: WinUI 3 Cross-Process Drag-Out

7. Dynamic Module Resolution Algorithm (GetModuleName)

8. Configuration System Reference (IPackerConfig)

9. Workstation Privacy & Path Redaction

10. End-to-End Output Transformation

Input Settings & Staged Items

Mode A: Standard LLM Tree Output (.txt)

Mode B: Obsidian Note Tree Output

11. Key Technical Strengths & Limitations

Zero-Budget Web Dev: Moving from Discord/Drive to Google Sites

The Problem: The "Easy way" Trap

Why Google? (And the Launcher Evolution)

Fighting the Google Sites Iframe Sandbox

The Workaround (External vs. Internal)

What's Next?

See it in action

Why I built an offline C# tool to turn entire codebases into Obsidian notes and sharable docs

The Problem with Documenting & Sharing Codebases

Built for Note-Taking, Reference Docs & Prototyping

Architecture & Native Performance

Try it out & What's Next

4. Zero-Dependency PowerShell CLI (`ks pack`)

7. Dynamic Module Resolution Algorithm (`GetModuleName`)

8. Configuration System Reference (`IPackerConfig`)

Mode A: Standard LLM Tree Output (`.txt`)