HTML overlay

Status: O6a Runtime built, in-game test pending. O1 to O5 have all passed; the O4 scene threshold is still open (see the O4 result). O6a runs Node mods in the host beside overlay apps, with one rednode package for both. To build an app today, see the Overlay apps guide. The proof of concept passed in game, alone and side by side with CET and 10 other RED4ext plugins (2026-10-11). See Test results and the plan.

REDnode overlay apps are small web apps (HTML, CSS and JavaScript) drawn on top of the game, like CET’s ImGui windows. They talk to the game through the same rednode API as Node mods.

Why HTML

Architecture

 Overlay host (Electron, out of process)            Game process (REDnode plugin)
 ┌──────────────────────────────────────┐          ┌───────────────────────────────────┐
 │ Node: rednode API, Tier 2 mods       │          │ Present hook: draw overlay quad   │
 │ Chromium, off-screen: renders apps   │ frames → │ Window hook: hotkey, mouse, keys  │
 │   to a BGRA image                    │ ← input  │ Game thread: run bridge requests  │
 │ Input injection into the page        │ requests→│   through RTTI                    │
 │ Bridge: window.rednode in each app   │ ←results │ Events from scripts (Tier 1 path) │
 └──────────────────────────────────────┘  events  └───────────────────────────────────┘
                    one named pipe: \\.\pipe\rednode-overlay

Synchronous and asynchronous kernels

Chromium always runs page JavaScript in its own renderer process. So an overlay app can never be part of the game’s synchronous path.

Proof of concept

Goal: decide whether the approach is worth building out. Each step is a separate thing to check in game.

Running the test

The overlay needs REDnode 0.3.0 in the game and the host running on the desktop. Setup is in Dev setup, section 10.

1. Start the host in a terminal and leave it running: npm run overlay. It prints Waiting for the game.
2. Launch the game. At the main menu a panel appears in the middle of the screen. Without the host it is a dark placeholder with a yellow frame and a moving cyan line. That alone means step 1 works.
3. With the host running, the panel shows the demo app, and the terminal prints Connected to the game. The clock should tick (step 2).
4. Press F10 for interactive mode. A yellow cursor appears in the panel. Click Click me, click the text box and type (step 3). Press Esc to give input back to the game.
5. Load a save. The events tile shows PlayerPuppet.OnGameAttached. In interactive mode, click Read player position, walk a few steps, and read it again (step 4).
6. Press F10 twice more to hide the panel, and once more to show it again.
7. Quit to desktop through the menu.

Note what you see at each step, plus any stutter, flicker, wrong colors, or input that leaked to the game. The plugin’s log lines start with Overlay: in red4ext/logs/rednode-*.log.

Simplifications

Simplifications in the proof of concept, all to revisit if it goes further:

• CPU frame copy. Frames travel through the pipe as raw BGRA pixels and are uploaded each time the page repaints. The real version would share a GPU texture with Chromium.
• One fixed panel of 1024 x 640 pixels, scaled with the screen height. No window management.
• One app, loaded by the host at start.
• The plugin draws the cursor in its shader, from the position it tracks. Off-screen Chromium does not paint one, and a page-drawn cursor lags (see the test results).
• HDR: the shader converts for scRGB and PQ output, but the brightness level is a guess.

Test results

Run 1: 2026-10-11, clean setup

Run 2: 2026-10-11, with CET and other mods

Observation: CET windows can be dragged. The REDnode panel cannot, because the proof of concept has one fixed panel. Window management belongs in the real version.

Risks and open questions

Decision after the test

The result was the first row.

Plan for the real version

Status: draft for review. Phases are numbered O1 to O7 so they do not clash with the project phases P0 to P4. Each phase ends with an in-game test, like the proof of concept.

Goal

Overlay apps that can look like part of the game: borderless, any shape, transparent where the app is transparent, either interactive windows or HUD widgets that never take input. They are written as web pages and use the same rednode API as Node mods.

Window model

The plugin owns window placement, so moving a window never waits on Chromium. The host owns rendering, one off-screen page per window.

Rules that make borderless windows behave:

Phases

O1 Windows: test

Built 2026-10-11, REDnode 0.4.0. Window logic is covered by 19 unit tests in native/tests/windows_test.cpp, run by tools/build-native.ps1. The host was tested against a mock of the plugin. Two apps open: the demo (1024 x 640, title bar is its drag handle) and Signal (a round 320 x 320 widget with a transparent middle and a yellow drag tab).

1. Start the host (npm run overlay) and the game. Both windows appear at the main menu.
2. F10 for interactive mode. Drag the demo by its title bar and Signal by its yellow tab. They should follow the cursor with no lag.
3. Overlap them. Click one: it comes to the front, and the other one’s title dims.
4. Put Signal over the demo. Click inside Signal’s transparent middle: the click should reach the demo underneath, for example its Click me button.
5. Click Ping on Signal: it shows the game frame.
6. Click empty screen, away from both windows: interactive mode ends and the game gets input back.
7. Quit the game and the host, start both again: the windows come back where you left them.

Result, 2026-10-11: passed. Modded profile with CET, 3840 x 2160 SDR. Every step worked: dragging, front-to-back order and focus, click-through on Signal’s transparent middle, Ping, leaving interactive mode by clicking empty screen, and saved positions across a restart of the game and the host. No errors in the logs.

O2 UI kit: test

Built 2026-10-11, REDnode 0.5.0. The kit is packages/ui: 12 components as markup, two themes, keyboard navigation, and UI sounds through the new bridge call audio.play. Both test apps were checked against a mock of the plugin. Gamepad navigation is left for later, because the game also reads the controller.

The host now opens two apps: Kit, a titled window with every widget, and Native, a borderless game-style button at the lower right.

1. Start the host and the game. Kit and the red Open stash button appear.
2. F10. In Kit, try each tab: press buttons, flip toggles, drag the slider, type a call sign and press Enter, pick list and menu items. Hover Hover me for a tooltip.
3. Flip Game theme in Kit’s title bar: the window switches to the game look.
4. Use the keyboard: Tab between widgets, arrows in the list and menu, Enter to choose.
5. Click Open stash, pick an item: a game-style notification appears. Drag the button by its striped grip.
6. Kit’s Sound tab: pick a name and press Play. Note which names make a sound; the names are unverified.

Result, 2026-10-11: passed. Modded profile with CET, 3840 x 2160 SDR. All widgets, both themes, keyboard use, the native-style button and its notifications worked. Game UI sounds played through audio.play, so AudioSystem.Play with no entity works for overlay sounds. No errors in the logs.

O3 Apps: test

Built 2026-10-11, REDnode 0.6.0. Apps are folders with a rednode-app.json manifest. The launcher, built into the host, lists them and opens or closes them. The host is packaged as REDnode-overlay.exe and the plugin starts it with the game, in a job object so it never outlives the game. Tested against a mock of the plugin: app discovery, anchors, the launcher, opening an app from it, saved choices, the log file and the single-instance lock. Window anchoring has 5 new unit tests.

This is the player path: no npm run overlay.

1. Close any host you started by hand. In the game folder, REDnode now has host/ (the packaged host) and apps/ (Kit, Native, Demo, Signal).
2. Launch the game normally. Do not start anything else. At the main menu: Kit, the Open stash button, and a small REDNODE · 2/4 tab at the lower left appear on their own.
3. F10, then click the REDNODE tab. The launcher lists the four apps with their versions and descriptions.
4. Switch Signal and Demo on: they open. Switch Kit off: it closes.
5. Quit the game through the menu. The host closes with it: REDnode-overlay.exe is no longer in Task Manager.
6. Launch the game again. The apps you left on are on, and the ones you switched off stay off.

Logs: the host writes red4ext/logs/rednode-overlay.log in the game folder.

Result, 2026-10-11: passed. Modded profile with CET. The game started the packaged host by itself (the plugin logged started the host); the host found the 5 apps and opened the defaults. The launcher opened Signal and Demo and closed Kit, and the choices were saved. The host closed with the game. The user confirmed the saved choices on the next launch.

O4 HUD widgets: test

Built 2026-10-11, REDnode 0.7.0. Apps can be "kind": "hud": drawn, but never focused and never in the way of a click. "hideWith" hides any window while the game shows a menu, photo mode, a scene or the main menu. The plugin reads those states on the game thread a few times a second and hides windows itself, so there is no delay through the host. Apps also get a ui-state event. 4 new unit tests cover HUD input and hiding.

Two new apps open: Coords HUD, a strip at the top of the screen with V’s position, and Game state, which shows what the plugin reads.

1. Launch the game. At the main menu, Coords HUD is not shown (hidden with main-menu); Game state shows Main menu / loading: yes.
2. Load a save. Coords HUD appears at the top and its numbers change as you walk.
3. F10, then click on the Coords HUD: the click goes through it (here, to empty screen, which ends interactive mode).
4. Open the inventory or map, then the pause menu: Coords HUD hides, Game state shows Menu open: yes.
5. Enter photo mode: Coords HUD hides.
6. Talk to an NPC, and if you can, trigger a cutscene. Note the scene tier Game state shows in each, and whether Coords HUD hid when you think it should have.
7. F10 to hidden mode: everything hides, HUD included.

Result, 2026-10-11: passed, with one open item. Modded profile with CET. The HUD was hidden at the main menu, showed in gameplay with live coordinates, let clicks through, and hid with the inventory, map, pause menu and photo mode. It stayed visible while talking to NPCs, as intended: conversations are normal play, with the dialogue choices shown in the world. Hidden mode hid everything.

Open: the scene threshold. A conversation with an NPC is scene tier 2, so the threshold must be above 2, and at 4 the HUD correctly stays up in conversations. No cutscene could be triggered in this save, so whether cutscenes are tier 4 or 5, and what tier 3 is, is still unverified. Test it on a fresh playthrough, where the opening has several scenes: watch the scene tier in the Game state app and check that the HUD hides in cutscenes but not in normal conversations.

O5 Performance: test

Built 2026-10-11, REDnode 0.8.0. Three changes, each measurable in the new Perf app:

The launcher has a GPU sharing switch at the bottom to compare the two paths. The host’s memory is about 60 to 100 MB per open window, because every window is its own Chromium process: 786 MB with 6 windows in the mock run.

1. Launch the game. The Perf window is at the top right. It should say Render path: GPU sharing, with GPU-shared frames counting up.
2. Check that every window looks right: no garbage, flicker, tearing or stale frames. Switch Signal on in the launcher: its ring should animate smoothly.
3. In interactive mode, click through Signal’s transparent middle: click-through must still work on the GPU path.
4. Switch Stress on. Note the game’s frame rate, the overlay’s CPU and GPU times, and the host’s memory and CPU.
5. Switch GPU sharing off at the bottom of the launcher. The windows reopen on the CPU path. Note the same numbers with Stress still on.
6. Switch GPU sharing back on and Stress off.

Logs: the plugin logs GPU sharing failed if it had to give up, and the host logs Released ... shared frame(s) the game did not answer if frames were not acknowledged.

Result, 2026-10-12: passed. Modded profile with CET, 3840 x 2160 SDR, REDnode 0.8.0. GPU sharing ran the whole session without falling back. All windows looked right, click-through worked through Signal’s transparent middle on the GPU path, and the GPU sharing switch reopened every window on the other path and back. The host logged a perf line every 5 seconds; these are the 30-second stretches with Stress open:

O1 to O4 make the feature usable. O5 makes it cheap. O6 joins it to the rest of REDnode. O7 hardens it.

Order agreed on 2026-10-12: REDclaude, an in-game Claude assistant built as an overlay app, comes right after O6. O7 follows it.

O6 One runtime: plan

Agreed 2026-10-12. Node mods and overlay apps run in the same host, use the same rednode package and get the same answers. This also covers most of P2 (the pipe bridge and the Node SDK), and builds what REDclaude needs: live game queries, mod logs and hot reload. O6 has two test gates, O6a and O6b.

O6a Runtime

O6b Game API

O6a Runtime: test

Built 2026-10-12: plugin 0.9.0, host 0.2.0, rednode 0.1.0. Tested against a stand-in for the game (a mock of the plugin’s pipe), packaged and unpackaged:

New in the plugin: shared frames are given back at once when nothing draws them, opened textures are reused, and the perf line splits the overlay CPU time into GPU wait (waiting for the frame from three frames ago) and opening (opening shared textures).

In the game, do these in order, with a 30-second pause after each, timed on a phone stopwatch:

1. Start the game and load a save. Stand still in gameplay for 60 seconds. Hello mod sits at the right edge, the Coords HUD at the top: both show the same X, Y and Z, and change together when you walk.
2. F10 for interactive mode. In Hello mod, press Play sound: a sound plays. Switch Follow off: the position stops changing. Switch it on again. Drag Hello mod by its title.
3. Open the launcher (the REDNODE tab, bottom left). Hello mod and Ticker mod show RUNNING · own process and their memory; Crash mod is off. Switch Hot reload on. Then either tell me “edit” in chat and I change Hello mod’s file in the game folder, or open red4ext\plugins\REDnode\apps\hello-mod\mod.mjs in Notepad and change first version to anything, then save. Within a few seconds, Hello mod’s window comes back with the new text.
4. In the launcher, switch Mod log on. It opens at the bottom right with every line the mods printed so far. Then switch Crash mod on. Its window opens at the left. Press Throw an error: its window closes, the launcher shows CRASHED, the Mod log shows the error in red, and Hello mod keeps updating. Press Restart in the launcher.
5. In the Mod log, switch Errors only on and press Copy. Paste it into this chat: it should be the crash and the line in mod.mjs that threw. Switch Errors only off.
6. In Crash mod, press Hang forever. Hello mod keeps updating. After about 10 seconds the launcher shows NOT RESPONDING. Press Restart.
7. Switch Shared process on for all three mods. Each restarts; the launcher then shows shared process (3 mods) and one memory figure.
8. In Crash mod, press Kill the process. All three mods show CRASHED and their windows close; about 2 seconds later all three are running again.
9. Press F10 until the overlay is hidden. Wait 30 seconds. Press F10 to come back to passive.
10. Open the inventory for 30 seconds: the Coords HUD hides, Hello mod and the Mod log stay. Close it.
11. Load a save. Hello mod’s Saves loaded count goes up by one.
12. Quit the game.

After the test, switch Shared process off again if you want each mod in its own process.

What I read from the logs afterwards: rednode-overlay.log (the perf lines with GPU wait and texture reuse, and the Mod processes: memory lines every 10 seconds) and rednode-mods.log (everything the mods printed, and their crashes).

UI kit

UI is written as markup, not built by hand in code. Two layers keep it optional:

Web components (custom elements like <rn-button>) work in plain HTML, React, Vue or anything else. Their styles are sealed in Shadow DOM, so app CSS cannot break them, and themes are CSS custom properties.

<!-- A titled REDnode window with widgets in it (kind: window) -->
<rn-window title="Weather control" draggable>
  <rn-toggle label="Freeze time"></rn-toggle>
  <rn-slider label="Rain" min="0" max="100"></rn-slider>
  <rn-button>Apply</rn-button>
</rn-window>

<!-- A borderless button that looks like part of the game (kind: hud or window) -->
<body style="background: transparent">
  <rn-button theme="game" sound="ui_click">Open stash</rn-button>
</body>

Every REDnode kernel reaches the same widgets, because only the overlay host can render a page:

Player install

Running npm run overlay by hand is the developer setup. Players should install from Nexus Mods or with Vortex and have it work, like CET. Planned for O3:

The player’s path then is: install RED4ext and REDnode, add any REDnode apps, launch the game.

Looking like the game

Known limits and research items