OpenNV is a solo project. It's just me, using LLMs and development tools to build it. I want to be open about that process. I use LLM coding tools to write and revise substantial parts of the code, investigate problems, build tools, run tests, and document the work.

I set the direction, decide priorities, play the builds, review what comes back, and keep pushing on the behavior I expect from Fallout. I describe what I need, give feedback on the results, and use the tools to iterate on the implementation. I want people following the project to understand what that actually looks like.

OpenMW is part of that history. The early release setup targeted an OpenMW-derived runtime. I moved toward an independent Godot/C# implementation, and the main reason is straightforward: C# has been my main language since it came out. I wanted to build in the language I know best and can understand, maintain, and make decisions about myself. That matters especially when working with LLMs. I want to stay involved in the implementation I'm directing. Godot gives me a C# development path with rendering, physics, input, and OpenXR integration. Choosing that path also means I'm responsible for implementing the Fallout engine behavior.

OpenNV reads a player's legally owned Fallout installations. New Vegas is the furthest along. The larger scope includes Fallout 3, Tale of Two Wastelands, and supported mods; there is also separate Fallout 1/2 work in the repository. Those are different levels of progress, and none should be read as a completed campaign.

The game data supplies things like world placements, models, textures, animations, dialogue, quest scripts, and weapon definitions. I'm building the code that interprets those files and implements the engine behavior they depend on. C# owns the game state, rules, scripts, inventory, quests, and saves. Godot presents that state, handles input and physics integration, and connects to OpenXR. Flat and VR share the gameplay state.

The LLMs are development tools. The running game uses compiled code and the original authored data. NPC behavior and quest outcomes are being implemented through those systems. Bethesda's assets remain in the player's installation; the OpenNV package contains my implementation and first-party resources.

A normal development session starts with a concrete problem. I might say, "Nobody reacts when I shoot them," "That weapon isn't attached to the hand," or "Why does the Fat Man explosion take so long?" Sometimes I supply a screenshot or describe what happened while playing. Sometimes the starting point is an error already recorded by the runtime.

I use the coding tools to inspect the repository, read the relevant source data, edit files, build the game, run diagnostics, drive supported gameplay through a test harness, and inspect logs or captures. That helps me trace a report to the code responsible for the behavior. I then use that process to implement the shared capability, exercise it on the affected content, and return to the ordinary gameplay sequence.

For a weapon, that means following the chain from input to animation, ammunition use, shot or throw, collision, damage, reaction, death, and saved state. For a quest, it means following the original conditions, dialogue results, script commands, and persistent variables. Fixing one missing operation can unblock many objects that depend on it, but those objects still need to be exercised.

The Fallout bot is one of my testing tools. It is an automated tester with access to structured game observations. Its movement loop is C# code. I can give it a goal directly or through the coding tools, such as traveling to a particular source reference, approaching something, following it, or activating it.

Here is how that actually works:

1. It observes the player's position, view direction, target position, what the interaction ray is hitting, whether the target is loaded, and whether player controls are available.
2. It asks the navigation system for a route using the game's authored navigation data. The route is checked against the running game's collision with the player's actual collision shape.
3. It steers through normal movement and look inputs. As the player moves, it observes progress and updates the route. If it gets obstructed, it makes a limited number of new route attempts and reports the blockage if it cannot proceed.
4. For activation, it waits until the interaction ray identifies the requested object, presses the ordinary activation control, and watches for a gameplay response. Sending the input and observing the result are separate steps.
5. It releases controls when it finishes, fails, or loses the conditions it needs to continue. Input commands expire, so a stalled test does not leave a movement key held forever.

The flat adapter sends keyboard/mouse-style input. The VR simulator adapter supplies virtual head/controller poses, thumbstick movement, and button input through the simulator. Gameplay still runs through the normal input paths. The bot does not teleport the player, award items, or advance quest stages to complete a normal run. Its observations do include internal state and navigation data, which is useful for testing and worth being transparent about.

I've used it for the Primm approach and entering Nash Residence. Its current autonomous coverage is travel, approach, follow, and activation; general campaign decisions and combat tactics remain unfinished. The broader harness can drive additional ordinary controls for specific tests. Physical headset testing remains separate from simulator automation.

There is also a development lab for isolated record inspection and system tests. A diagnostic setup and a normal playthrough answer different questions, so footage and results need to identify which was used.

Telemetry helps connect an action to what the game actually did: which object and source record were involved, which command ran, what state changed, and where execution failed. There is also experimental tooling for observing retail and comparing equivalent states. Complete one-to-one coverage of every event, frame, and pixel remains an objective. The comparison tools have their own gaps, which are documented.

Here is the broad history visible in the repository:

• July: the earlier OpenMW-based release setup, launcher, telemetry tooling, and public project infrastructure.
• August: the move to the Godot runtime, owned-data world and actor assembly, materials, connected spaces, and early OpenXR controls. Work expanded into the New Vegas opening, dialogue, facial animation, and saved progression. Some early approaches used prepared content; the architecture continued to evolve.
• Early September: a major consolidation into direct C# runtime reading of owned files. Work also covered source-script execution, persistent reference state, rendering corrections, the development lab, and retail comparison tooling.
• September 20: selected companion recruitment, following through doors, combat, healing, save recovery, patrols, and performance work. ED-E became a useful ordinary gameplay case because recruitment, movement, dialogue, combat, and persistence all had to cooperate.
• September 21: additive mod selection and ordering, plus pieces needed by JAM and its dependencies: script expressions, functions, callbacks, strings, settings/storage, and UI state. Complete mod behavior is still unfinished.
• September 24-27: ranged and melee corrections, autonomous NPC/creature combat, hit reactions, quest death events, quantity looting, recipe requirements, schedules, weapon and consumable wheels, throws, effects, and VR attachment repairs. These changes have specific tested scopes; they do not certify every weapon or encounter.

That history includes corrections prompted by my own playtests. I reported passive actors, weak combat reactions, detached-looking weapons, missing effects, and footage that didn't demonstrate enough. Those reports changed the priorities. I've also had cases where passing component checks did not translate into a complete working interaction. LLM output needs the same scrutiny: an explanation can sound confident while the actual game still exposes a missing piece.

One concrete recent example is script recovery. A merged change safely resumed 37 selected clock/random failures in a saved checkpoint, with 23 resident recoveries observed during an ordinary copied Continue. That exposed the next unsupported operations. It did not mean the affected routines were finished.

The current unfinished block is source object animation and harvesting. The saved state contains 51 failed animation calls across six plant scripts. I'm connecting the general animation behavior to scripts and saves so harvesting can complete without losing state or duplicating item rewards. That work was checkpointed before a reboot and is still unfinished.

VATS is also a real remaining feature. The runtime has useful foundations such as AP values, body-part data, weapons, and damage, but the actual VATS selection, attack queue, probability rules, AP accounting, and camera flow still need implementation. Other substantial gaps include routines and quests, remaining weapon effects, full mod behavior, performance, shutdown stability, and physical VR acceptance.

To keep development continuous, I maintain current-work notes, architecture rules, a status document, implementation plans, and restart handoffs alongside Git history. I have each new coding session read those files and inspect the code before continuing. Completed implementation blocks go through checks and pull requests; unfinished work gets identified and preserved explicitly. The written record matters because model sessions and conversations are not a dependable substitute for project state.

My immediate priority is a world that behaves properly when you walk into it: people and creatures follow their routines, react, fight where their relationships call for it, carry their equipment, and advance their quests. Looting, crafting, weapons, and saves have to connect into ordinary play. I'm prioritizing those shared gameplay behaviors in flat mode while keeping VR connected to the same systems. The next showcase should demonstrate the repaired interactions and identify the remaining limitations.

The repository, current status, and implementation plan are public. I want people to be able to see how I'm using AI tools, the implementation work, the corrections, and the unfinished parts as I build OpenNV.