Native game UI (ink)

Status: I1 passed in game on 2026-10-22 (REDnode 0.27.2, third run), after a crash in the first run (0.27.0) and one at quit in the second (0.27.1), both REDnode bugs, fixed. What it means for I2: I1: what it decides. Decided by the owner the same day: the ink API requires Codeware. I2a passed in game on 2026-10-22 (REDnode 0.28.0, results). I2b passed in game on 2026-10-22 (REDnode 0.29.0, results); placement across resolutions is left for later, as agreed. I2c’s plan was agreed on 2026-10-22, with the language split off as I2d. I2c passed in game on 2026-10-22 (REDnode 0.30.1, retest results, after a first run on 0.30.0 whose list moves failed). I2d’s plan was agreed on 2026-10-22. I2d passed in game on 2026-10-22 (REDnode 0.31.0, results): phase I2 is done. The design, the tags and the phases I1 to I6 are in the design doc, section 06. Order agreed with the owner on 2026-10-21: H2 world.refresh, then this API from I1, then the Sound API’s S2. H2 stopped after H2b on 2026-10-22; H2c (NPCs, props, with EDGEbuilder) comes after this API.

The game draws its own UI with ink, a tree of widgets with logic controllers. REDnode’s overlay apps and the ui builder draw in Chromium over the game; the game’s UI never sees them. The ink API lets JavaScript and TypeScript mods build into the game’s own UI, drawn by the engine, the way redscript mods do.

I1 Spike: plan

I1 answers the questions the design leaves open, so I2 builds the driver on facts. It adds no modder API. The tools:

• A test app, Ink test (packages/overlay/apps/ink-test), that does everything through the api in the rednode package, like the Refresh test did for H2.
• A small script, native/scripts/REDnodeInk.reds: the root hooks and a listener class. It ships with the plugin, so the spike is a REDnode build (0.27.0).

What I1 answers

The script is checked with redscript-cli against a copy of r6/cache/final.redscripts, with and without Codeware’s scripts, before it reaches the game: one compile error stops every script in the game.

The Ink test app

One window, a button per step, each answer written to the window and the Mod log:

Dump source (idea, 2026-10-22)

Proposed by the owner: a Dump source button. A modder opens a game screen, such as the perks screen, presses it, and gets that screen written as REDnode’s ink tags, or as code that builds it, to start their own screen from. RED Hot Tools’ Ink Inspector shows such a tree is readable at run time; I1’s item 10 checks REDnode can read it too, and how fast.

The dump is a snapshot of the look, not the screen’s logic. It is game data: the modder keeps it locally, and REDnode never ships or commits one.

When: I1 tests the reading. The generator needs the tags, so a first version that writes primitives can come with I2, and the full one, with library items and composites, with I4. Where the button lives (the O9 window debugger, the MCP server for REDagent, or its own tool window) is decided then.

After I1

The results decide, for I2:

I1 build (REDnode 0.27.0)

Built on 2026-10-22, as planned:

Checked: the scripts compile with redscript-cli (v1.0.0-preview.22) against the game’s final.redscripts, without Codeware (no errors) and with Codeware’s scripts (errors only in Codeware’s own files, which redscript-cli is stricter about, as before). The app’s buttons ran against a stand-in for the rednode package with a fake widget tree, without and with Codeware, with script and native class names. Nothing ran in the game yet: which root suits a mod, which class names AddChild takes, whether clicks arrive and the speeds are all unverified.

I1 test

On the laptop, Cyberpunk 2077 - Copy, REDnode 0.27.2 (update zip over 0.27.1), Ink test 0.1.1, with Codeware. Each button writes its answer to the Ink test’s window and the Mod log.

1. Switch on Test timer in the launcher, press Start, and press Mark after each step. Type what you saw into its note before each Mark.
2. Make sure Ink test is switched on in the launcher. Load a save. F10, press Roots. Mark.
3. Type cw.inkHUDLayer in the root field and press HUD text. Close the overlay (F10): is a dark box with “REDnode ink” in the upper left? Mark.
4. Open the overlay, press Speed and wait for its line in the log (a few seconds), then press Check. Mark.
5. Press Esc for the pause menu. Open the overlay, type menu.pause in the root field, press Roots, then Menu button (not HUD text). Close the overlay: is a red “Ink button 3” in the pause menu? Hover it, then click it with the game’s cursor. Mark.
6. Open the overlay: does the log show “ink hoverOver”, “ink press” and “ink release” lines? Mark.
7. Leave the pause menu. Open the overlay, press Check. Mark.
8. Type new_perks in the screen field and press Open screen: does the perks screen open? Mark.
9. With the perks screen open, open the overlay, type cw.inkMenuLayer in the root field and press Read screen. Wait for its line, then type menu.hub and press Read screen again. Mark.
10. Leave the perks screen and close the hub. Quit the game from the menu. Send rednode-mods.log, red4ext/logs/rednode-*.log of this run, and the two dump files Read screen named (they stay on your PC otherwise: they are game data). Does the game quit without a crash report?

I1 test: first run (0.27.0)

2026-10-22 at about 16:37, on the laptop, with Codeware. Steps 1 to 4 ran. The player’s notes:

The crash report: an access violation in REDnode.dll+0x2fd30, reading 0x7FF70000000D. Read from the dump: the plugin was converting RegisterToCallback’s object argument (a handle:IScriptable), the REDnodeInkListener the app had just made with api.$new("REDnodeInkListener", { id }). The object was alive (its reference counter held 2 strong references, and its ref field pointed at itself), but the low half of its vtable pointer read 5: the listener’s id, which was 5 at that point in the test. The plugin’s rtti.new wrote the properties it was given at each property’s offset in the object. A script class (one written in redscript) keeps its own fields in a value holder beside the object, so id went over the vtable, and the next virtual call on the object crashed. rtti.get and rtti.set already found script fields correctly (the SDK’s GetValuePtr); only rtti.new’s properties did not. W1’s $new calls built native classes, which keep their fields in the object, so this never showed before.

Fixed in REDnode 0.27.1: rtti.new finds each property through GetValuePtr, as rtti.get and rtti.set do, for every class; structs keep their plain offsets.

Step 2’s empty screen is unverified. A likely reason: the health bar’s root fades out of combat with the rest of the health bar, and widgets added into it fade with it. The retest’s Roots line shows each root’s size and visibility.

I1 test: second run (0.27.1)

2026-10-22 at 16:48 to 16:55, on the laptop, REDnode 0.27.1, Ink test 0.1.0, with Codeware. Steps 1 to 10 ran; at step 5 HUD text was pressed rather than Menu button, so clicks are still untested. The game crashed when the player quit.

The crash at quit. The crash report: an access violation in REDnode.dll+0x243cc, a handle’s destructor calling the object’s CanBeDestructed through its vtable, which pointed into memory no longer loaded. REDnode’s table of the objects Node mods hold is a global, so its destructor ran when the DLL unloaded, after the other plugins had gone. The objects held then included Codeware’s (the resource token and layer objects from Menu entries and Roots), whose code was already unloaded. Fixed in 0.27.2: the table is cleared when the game’s Running state ends, while everything is loaded, and is never destroyed at unload.

Fixed in REDnode 0.27.2:

I1 test: third run (0.27.2)

2026-10-22 at 17:07 to 17:14, on the laptop, REDnode 0.27.2, Ink test 0.1.1, with Codeware. Passed: every step, and the game quit with no crash report (the plugin log ends with the pump stopping and the host disconnecting).

I1: what it decides

The decisions the plan left to I1, with what the runs showed. The recommendations are for the owner to agree before I2.

I2: plan

Decided by the owner on 2026-10-22, after I1: the ink API requires Codeware (“a foundational mod that most people have already”). A package that uses ink lists it in requires, and ink calls fail with a message naming Codeware when it is missing.

The design’s I2 row is large: the driver, the primitives, layout and theme words, bindings, data-driven trees and localization. Proposed: three steps, each with its own in-game test, so the driver is proven before anything is built on it.

Agreed by the owner on 2026-10-22: build I2a.

The game look (owner, 2026-10-22)

Proposed by the owner with I2a’s go-ahead: modders can build any ink they like (a button with a border or without, any font and size), but they should not have to work out how to make a button look like the game’s own (the red ones with angular borders, their hover glow and sounds). REDnode gives a clear marker that means “look like the game”, and the piece then looks and behaves like the game’s.

So ink.button("Track", onClick) is a game button with no styling written, and ink.button("Track", onClick, { look: "plain", color: "#ffffff" }) is the modder’s own. The same names work in overlay windows: the UI kit (packages/ui) gets a matching game look for its HTML elements (rn-button and the rest, through a look="game" attribute and a game theme), so an HTML app and an ink screen can look the same. Which library items the game has, and their paths, come from I1’s Read screen and REDbridge, kept in one table behind the tags (the design’s open question about paths changing with a patch).

When: the theme words and look: "game" on primitives in I2b; the game’s library items and the ready pieces in I4 (the design’s “Game look” phase); the UI kit’s game look beside I4. Unverified until then: whether every piece has a library item that spawns cleanly outside its own screen.

I2a Driver

In the plugin (native/src/overlay/ink.cpp):

In the rednode package (packages/rednode/src/ink.ts), the same style as the ui builder, so modders learn one way:

import { game, ink } from 'rednode';

const where = ink.text('', { size: 28, color: 'cyan' });
const board = ink.mount('hud', { anchor: 'top-right', x: -40, y: 120 },
  ink.column({ gap: 4 }, ink.text('REDnode', { size: 20 }), where));

setInterval(async () => {
  const p = await game.player.position();
  where.set({ text: `${p.x.toFixed(1)}  ${p.y.toFixed(1)}  ${p.z.toFixed(1)}` });
}, 250);

board.unmount(); // or let REDnode clean up when the mod stops

In the host: ink.apply passes through with the sender’s package id (a package can only touch its own widgets); ink.clear when a package stops; a missing Codeware answers with a message.

The docs simulation draws ink trees as plain HTML in the examples, so Ink Coords gets a live preview like the other samples.

Not in I2a: menus as mounts and events (I3), library items and the game’s styles (I4), screens (I5), bindings and localization (I2c).

I2a build (REDnode 0.28.0)

Built on 2026-10-22, as planned:

Checked: the plugin builds and its tests pass; the package builds; Ink Coords’ docs preview draws its two lines at the top right of the box and updates them. Not checked anywhere yet: the driver in the game.

I2a test

On the laptop, Cyberpunk 2077 - Copy, REDnode 0.28.0 (update zip over 0.27.2), with Codeware.

1. Switch on Test timer in the launcher, press Start, and press Mark after each step. Type what you saw into its note before each Mark.
2. Switch off Ink test, switch on Ink Coords in the launcher. Load a save. Close the overlay: is “REDNODE // WHERE” in red with V’s position in cyan under it, at the top right, below the minimap? Walk a few steps: does the position follow? Mark.
3. Open the pause menu, then the hub (inventory), then photo mode, and come back each time: does Ink Coords hide with the HUD in each, and come back? Mark.
4. Load the same save again. Wait a few seconds after the load: are the coordinates back without doing anything? Mark.
5. Open the overlay, switch Ink Coords off in the launcher: do they go? Switch it on again: do they come back, once (not twice)? Mark.
6. Quit the game from the menu. Send rednode-mods.log and this run’s red4ext/logs/rednode-*.log (the Ink: lines). Did the game quit without a crash report?

I2a test: results

2026-10-22 at 17:53 to 17:59, on the laptop, REDnode 0.28.0, with Codeware. Passed: every step, and the game quit with no crash report.

Found, to fix with I2b:

Open, raised by the owner: placement that holds across screen resolutions and aspect ratios, and placement relative to the game’s own HUD pieces (below the minimap, beside the health bar). To discuss with the owner as part of I2b’s layout words.

I2b: build (REDnode 0.29.0)

Agreed with the owner on 2026-10-22: I2b now, without the placement question (resolutions, and placement beside the game’s HUD pieces), which comes when its time comes.

The game look, from the game’s own style sheet. Read from the game’s archives with REDbridge on the dev PC (nothing from the game is committed): the game’s widgets take their colors from base\gameplay\gui\common\main_colors.inkstyle, by binding a property to a name in it (tintColor to MainColors.Red; the quest tracker’s widget file binds tintColor, opacity and textureAtlas this way). The sheet holds the game’s colors (MainColors.Red, Blue, Yellow, Green, Grey, White, Warning, ActiveRed, the fullscreen backgrounds and about 140 more), its readable text sizes (ReadableXSmall 30, ReadableSmall 38, ReadableMedium 42, ReadableFontSize 50, SubtitleHeader 60, TitleHeader 70, FluffFontSize 25) and weights (HeaderFontWeight Semi-Bold, BodyFontWeight Medium). Bound colors stay exact: HDR values, and the colorblind themes the game swaps in (unverified in game). No font binding was found in the widget files read, so text sizes and weights are set from the sheet’s values rather than bound.

The driver applies a node’s props in the order ink needs: the style sheet, then the bindings being untied, then the other props, then the new bindings, so a color set after a tone stays. Bindings add up across changes, and a rebuild after a save load applies the current ones.

The two fixes from I2a: the driver waits for the plugin’s main-menu state to be off before it builds (InMainMenu in gamestate.cpp); an ink.apply that times out (the game closing or loading) leaves one quiet line in the Mod log instead of an error.

Samples: Ink Coords 0.2.0 uses the label and value styles; Ink styles 0.1.0 (packages/overlay/apps/ink-styles) is the test: a gallery on the HUD with buttons that change it while it shows.

Checked: the plugin builds and its tests pass; the package builds; in the mock game Ink styles sent its gallery in one call, a tone change as one binding, and a color over a tone as the tint with the tint’s binding untied; the docs preview of Ink Coords shows the label and value styles. Not checked in the game: whether the bindings take the game’s colors, whether the sheet sets on a widget REDnode made, the icons, align and grow.

I2b test

On the laptop, Cyberpunk 2077 - Copy, REDnode 0.29.0 (update zip over 0.28.0), with Codeware.

1. Switch on Test timer in the launcher, press Start, and press Mark after each step. Type what you saw into its note before each Mark.
2. Keep Ink Coords on and switch on Ink styles. Load a save. Close the overlay: is Ink Coords now a red upper-case “REDNODE // WHERE” over cyan numbers, both right-aligned, like the game’s own HUD text? Mark.
3. Open the overlay, press Show in the Ink styles window, close the overlay. At the left: the title, then eight text styles, each smaller than the one before (fluff faded), then eight tone words in different colors? Mark.
4. Under them: “plain look” white, “game look” red, “a game color” yellow, “#ff00ff” magenta? Then the changing line, the three lines in a 700-wide column, a bar of three boxes (blue, red twice as long, yellow 100 wide), three small boxes, and five icons? Mark.
5. Open the overlay, press Next tone a few times, then White over tone, then Next tone again: does the line change color each time, and go white then back to a tone? Mark.
6. Press Next align three times: do the column’s three lines move left, center, right? Press Next gap twice: do the three small boxes spread apart? Mark.
7. Type UIIcon.Assault_Area_02_Perk_1 in the field and press Show this icon: does the last icon change? Mark.
8. Load the same save again and wait a few seconds: are Ink Coords and the gallery back, in the same colors? Then quit to the main menu and wait a few seconds there, and quit the game. Mark before quitting if you can.
9. Send rednode-mods.log and this run’s red4ext/logs/rednode-*.log. Was there an “Ink:” line at the main menu (there should be none now), and did the game quit with no crash report?

I2b test: results

2026-10-22 at 19:09 to 19:19, on the laptop, REDnode 0.29.0, with Codeware. Passed: every step, and the game quit with no crash report.

The missing icon is the game’s data, not REDnode. Read with REDbridge: UIIcon.Assault_Area_01_Perk_1 names the part assault_area_01_perk1 in perks_icons.inkatlas, and that atlas (376 parts) has no such part, while assault_area_01_perk2 and assault_area_02_perk1 are there: a record left from the perks before 2.0, likely. So some UIIcon records point at parts that no longer exist, and an image shows nothing for them. Ink styles 0.1.1 uses UIIcon.Assault_Area_01_Perk_2 instead. A later build could warn about a missing part (unverified how to ask the atlas at run time).

The I2a fix for timeouts showed twice in the Mod log as one quiet line (“the game did not answer (closing or loading?)”), at the first start before a save and at quit, instead of errors.

I2c: plan

The I2 plan gave I2c three things: bindings (game values the plugin reads each frame), trees from data, and text in the player’s language. Proposed: I2c is the data, and the language becomes I2d. The language is most of the Localization plan’s L1 (the game’s language in the plugin, t() with package locale files, plurals, V’s gender forms), which serves the whole of REDnode, not only ink, and has its own unknowns (how the plugin reads the game’s language). Kept apart, each test stays small.

Bindings: game values with no round trip

A node names a game value; the plugin reads it each frame and changes the widget only when the shown result changes. Node is not involved, so a health bar follows every hit.

ink.text('', { style: 'value', bind: 'player.health', format: '{value} HP' });
ink.bar({ bind: 'player.health', of: 'player.healthMax', width: 300, height: 8, tone: 'normal' });

Each source is read at most once a frame, and only while a node binds it. The cost per source is a few game calls on the game thread (measured in the test; the perf line shows it). A mod can still set a text at its own rate, as Ink Coords does; bindings are for values that change often.

Trees from data

const board = ink.list({ gap: 6 }, contracts, (c) => ink.row({ gap: 12 },
  ink.text(c.name, { style: 'body' }), ink.text(`${c.reward} €$`, { style: 'value' })), (c) => c.id);
board.set({ items: nextContracts }); // only what changed goes to the game

In the plugin: add takes an index (ink’s ReorderChild after AddChild), a new move op, and each node keeps its children in order, so a rebuild after a load puts them back in the same order.

Samples and test

The test: take damage and watch the bar and the numbers; spend money; let the RAM refill after a quickhack; add, remove, move and rename list items, and check that only those change (the plugin log counts the ops); a save load puts both back in order; the plugin’s perf line with several bindings on.

I2d: language (after I2c)

The game’s language in the plugin and a change event; LocKey# and secondary keys in ink texts (SetLocalizedText, so the engine follows a language change by itself) and in the ui builder; t() with a package’s locales/<language>.json, {name} parameters, plurals (Intl.PluralRules) and V’s gender forms; missing keys logged once. That is L1’s core and L3 of the Localization plan; the UI kit’s data-t, manifest names, fmt and REDnode’s own text (L1’s rest and L2) stay in the Localization plan’s order.

I2c: build (REDnode 0.30.0)

Agreed with the owner on 2026-10-22, as planned, with the language split off as I2d.

Checked: the plugin builds and its tests pass; the package builds; the built ink module, driven with a stand-in transport, sends one add with an index for an item added at the top, one remove, one move, one set for a rename, only the new text for a grown tree, and margins fixed after a removal and a reversal; in the mock game Ink list’s buttons sent only their changes; the docs previews of Ink vitals (bound values and bars from the simulated game) and Ink Coords draw. Not checked in the game: every source (which calls answer, and with what), the bars’ scale from the left edge, ReorderChild, and the bindings’ cost a frame.

I2c test

On the laptop, Cyberpunk 2077 - Copy, REDnode 0.30.0 (update zip over 0.29.0), with Codeware.

1. Switch on Test timer in the launcher, press Start, and press Mark after each step. Type what you saw into its note before each Mark.
2. Switch on Ink vitals (Ink Coords may stay on; Ink styles off). Load a save. At the bottom left: “VITALS”, an HP bar with its number, a RAM bar with a percentage, and your money? Do the numbers match the game’s own HUD? Mark.
3. Take some damage (a fall, or a fight): do the HP bar and number drop at once and climb back as health returns? Mark.
4. Use a quickhack, then wait: does the RAM bar drop and refill? Buy or sell something: does the money change? Mark.
5. Switch on Ink list, open the overlay and press Show. Close the overlay: “CONTRACTS” and “3 contracts” at the left, and three contracts under them (#1 Watson, #2 Kabuki, #3 Japantown, each with a reward)? Mark.
6. Open the overlay and press, looking at the list after each: Add (a 4th at the bottom), Add at top (a new first), Remove first, Last to top, Rename second (“prime”), Shuffle (the order reversed). Does each show as its log line says, with even gaps? Mark.
7. Press Update header three times: does the title change (Open gigs, Fixer board, Contracts)? Mark.
8. Load the same save again and wait a few seconds: are the vitals and the list back, the list in its last order? Mark.
9. Quit. Send rednode-mods.log and this run’s red4ext/logs/rednode-*.log (its Ink: lines: each list change’s counts, and the bindings’ cost a frame).

I2c test: first run (0.30.0)

2026-10-22 at 19:54 to 20:06, on the laptop, REDnode 0.30.0, with Codeware.

Why: every op that needed a place failed in the plugin log with “k56: argument 2 (newIndex, Int32): Int32 needs a whole number”. The driver’s number helper wrote the index as text, "0.000000", and the plugin’s Int32 conversion reads the text (to keep 64-bit values exact), so ReorderChild never ran. Adds at the end and removes need no place, so they worked; the rebuild after the load adds the children in the plugin’s order, so it was right.

The bindings’ cost: 5 bindings over 4 sources, about 0.25 to 0.37 ms a frame (one first reading of 21 ms covered the first frames after the load, when the game objects are found). Most of a read was finding the game function by name each time.

Fixed in REDnode 0.30.1: whole numbers are written whole (ReorderChild takes the index); the functions the driver calls are found once and remembered (FindNative in reflect.cpp), for every native call, bindings included.

I2c retest

On the laptop, REDnode 0.30.1 (update zip over 0.30.0), with Codeware; Ink vitals and Ink list on.

1. Switch on Test timer in the launcher, press Start, and press Mark after each step. Type what you saw into its note before each Mark.
2. Load a save. Ink vitals at the bottom left as before? Take a little damage: do the bar and number follow? Mark.
3. Open the overlay, press Show in the Ink list window, close the overlay: three contracts? Mark.
4. Open the overlay and press, looking at the list after each: Add at top (a new first), Last to top, Remove first, Rename second, Shuffle (the order reversed), Add (a new last). Does each match its log line, with even gaps? Mark.
5. Load the same save again: the list back in its last order? Mark.
6. Quit. Send rednode-mods.log and this run’s red4ext/logs/rednode-*.log (no “Int32” errors now, and the bindings’ cost a frame).

I2c retest: results

2026-10-22 at 20:15 to 20:23, on the laptop, REDnode 0.30.1, with Codeware. Passed: every step, no errors in the plugin log, and the game quit cleanly.

The bindings’ cost with the remembered functions: 5 bindings over 4 sources, 0.13 to 0.17 ms a frame, against 0.25 to 0.37 ms on 0.30.0. The first reading after each load (14.6 ms) covers the first frames, when the driver finds V and the game systems again: one short hitch at a load, not a cost each frame. A later build could find them before the first bound frame.

I2c is done. Next in the plan: I2d, the language (L1’s core and L3 of the Localization plan).

I2d: plan

Text in the player’s language, for ink first and for Node mods in general: the core of the Localization plan’s L1, and its L3 (ink).

What the game gives

Read from the game’s scripts and the API dump:

What I2d builds

Sample and test

Ink language (a test app): an ink panel with a game key (the game’s own word for a menu, found with REDbridge’s loc.search), a t() text with a parameter, a plural in three counts, a gendered line, and a key the package lacks; with locales/en-us.json and locales/fr-fr.json. The test: English first; switch the game to French in its settings (and back) and see which texts follow at once; the Mod log lists the missing key once; game.language() in the window.

Open, for the test to settle: whether the language changes live, and which gender the game’s own gendered text follows.

I2d: build (REDnode 0.31.0)

Agreed with the owner on 2026-10-22, as planned. The owner’s reminder the same day: never start the game on the dev PC, which would update it to 2.5 (a 2.31 backup is kept); every in-game test runs on the laptop.

The game’s text key for “Inventory”, found with REDbridge’s loc.search: LocKey#15396, secondary key UI-ResourceExports-Inventory. Each game text has a female and a male form in its files.

Checked: the plugin builds and its tests pass; the package builds; the built modules with a stand-in transport answering fr-fr: French text, plurals 1 and 5, the female form, the English fallback and the key fallback each logged once, game keys passed through as locKey, and a switch to English sending only the t() text again; in the mock game the real host read the package’s locales folder; the docs preview shows the English panel. Not checked in the game: the language read and its event, SetLocalizedText and its following a change, V’s gender.

I2d test

On the laptop, REDnode 0.31.0 (update zip over 0.30.1), with Codeware; the game in English to start.

1. Switch on Test timer in the launcher, press Start, and press Mark after each step. Type what you saw into its note before each Mark.
2. Switch on Ink language (others may stay on). Load a save. At the left: “LANGUAGE TEST”, a line en-us (en-US) 1,234,567.89, “The game’s own word, by key: Inventory”, “Inventory”, “Reward: 500 €$”, “1 contract found”, “2 contracts found”, “5 contracts found”, a thanks line, and two small lines (the last reads “nowhere”)? Does the thanks line match V’s body (mister or miss)? Mark.
3. The Language settings are not in the pause menu’s Settings (found in this test: the settings screen shows some groups only before a save is loaded, IsPreGame). Quit to the main menu, open Settings, Language, and set the on-screen language to French (Français); apply. If the game asks for a restart, restart it. If the main menu has no Language settings either, set the game’s language in Steam instead (the game’s Properties, General, Language), which needs a restart. Then load the save. Is the panel in French? Did both “Inventory” lines turn into French? Does the Ink language window’s log show “The language changed to fr-fr” (only when no restart was needed)? Mark.
4. With French on: “Récompense : 500 €$”, “1 contrat trouvé”, “5 contrats trouvés”, “Merci, monsieur.” or “madame.”, the number written 1 234 567,89; the line French lacks still in English? Mark.
5. Set the language back to English, as in step 2, and load the save. Does everything come back to English? Mark.
6. Quit. Send rednode-mods.log and this run’s red4ext/logs/rednode-*.log (its “Ink: the game’s language is …” lines).

I2d test: results

2026-10-22 at 21:21 to 21:31, on the laptop, REDnode 0.31.0, with Codeware. Passed: every step, and the game quit cleanly.

Found, for a later build:

The bindings cost 0.10 to 0.19 ms a frame in this run (5 bindings, 4 sources).

Phase I2 is done: the driver (I2a), layout and the game look (I2b), bound values and lists from data (I2c), and the language (I2d). Next in the design’s order: I3 Input (buttons, sliders, lists and text input in menus, with the game’s cursor), I4 the game look’s ready pieces, I5 Screens, I6 frame drawing. The order with the other work (H2c with EDGEbuilder, the Sound API’s S2, a release) is to agree with the owner.

UI Tools: plan

Asked for by the owner on 2026-10-29: carry native UI on to where modders build ink widgets and screens from REDnode’s own HTML-style tags, plus a UI Workbench app to inspect the game’s UI, write ink, run it live and save it. Everything below is proposed, to agree with the owner.

UI Tools is an optional app pack, like Sound Tools and Admin Tools. Its source lives in this repo in packs/ui-tools/, outside the REDnode build, with its own zip, version, changelog and Nexus page, and it installs into red4ext/plugins/REDnode/apps/. The UI Workbench is its first app, and more can join it. What the apps need from the game (reading trees, picking, the markup) goes into REDnode itself, so any mod can use it.

What the owner asked for

The markup: REDnode’s tags as HTML

The design already gives one tree format, written three ways: JSX in .tsx, a tagged template, or the functions. The workbench needs a fourth that is a plain file: ink markup, an .ink.html file with the same tags, and their properties as attributes.

<!-- bounty.ink.html -->
<mount layer="hud" anchor="top-right" x="-40" y="120">
  <column gap="6">
    <text style="title">Bounty board</text>
    <text bind="player.health" style="value" />
    <list items="contracts" key="id">
      <text style="body">{name}</text>
    </list>
  </column>
</mount>

// mod.mjs
import { ink } from 'rednode';
import * as handlers from './bounty.mjs';

const board = await ink.load('bounty.ink.html', handlers, { contracts: [] });
board.set({ contracts: await fetchContracts() });

UI Workbench

A tool window with three tabs. It has the admin permission, like the Admin Tools, and the root flag that keeps tool windows above other packages.

A project is a package. Each project is a folder with a rednode-app.json, its .ink.html and its script, kept in a development folder (from Developer mode) or the apps folder. Run starts that package, and saving restarts it through REDnode’s own hot reload. So the modder’s code runs as it will in their mod: in its own Node mod, with its own permissions and its own cleanup, and a crash in it does not touch the workbench. Export is then nothing more than copying its files.

What REDnode gains for it

How RED Hot Tools does it. RED Hot Tools is MIT-licensed: we read it for REDswap, and may port from it with its licence kept, as REDswap does. Its native code collects the layers, the widgets under the pointer and a widget’s spawn info. It gets a widget’s drawn box from its draw context (inkDrawArea::GetBoundingRect, a raw game address), and draws its window with CET. REDnode would port the collection and draw the window in the overlay. The raw addresses are game-version specific, so each needs a hash or a byte pattern for 2.5, as REDswap’s archive loader did (unverified).

Phases

Open questions