Inside an XVR OnScene scenario file
Ever wondered how XVR OnScene works under the bonnet?
An XVR OnScene scenario is a zip archive wrapped around one very large text document, and everything you see in the simulator is written down in it. Each .xscn file is an XVR scenario package: a zip archive in the Open Packaging Conventions (OPC) format — the same container Microsoft Office uses for a .docx.
Ours range from about 160 KB to a little over 5 MB. A straightforward training scenario holds 13 entries, a large multi-agency one 27. Most are small: a content-types manifest, relationship parts, three JSON descriptors, and any custom content the scenario carries, such as an MP3 of turn-out tones.
One entry matters far more than the rest — snapshot.xml is the scenario. In a modest commercial-premises fire it runs to 1.2 MB and 37,862 lines, carrying 2,498 globally unique identifiers (GUIDs). In a full road traffic collision (RTC) with chemical, biological, radiological and nuclear (CBRN) elements it runs to 6.4 MB and 202,203 lines, with 19,484 GUIDs across 6,130 named items. Every appliance, casualty, marker, task and event exists in there as text.
It is organised into about thirty modules, each owning one kind of thing. The item module holds every object placed on the map; the state module the appearance and posture states a character can be put into. The event module holds the instructor's event list, the deployment module the tasks an operator clicks on a selected character, and the path module the drive routes.
There are further modules for weather, traffic, victims, navigation mesh, popups, roles and sound. Actions live in a dictionary of key/value pairs, where the key must equal the GUID inside its own value.
Knowing this allows the scenario creator, with the aid of a good AI harness and model such as Claude Code or Codex, to update a collection of scenario files quickly, sort the tables, rename to a standard convention, clone an event or task across scenarios, and many more useful edits that would take months in the GUI. Having standard names and characters always in the same order makes running scenarios much easier for our various XVR operators.
This isn't officially supported — it's the product of my own poking around inside the files, entirely experimental, and it could break in ways I haven't hit yet. I always back up the original scenarios before touching anything, then load and test, test, test after every change.
None of it is documented, but all of it is recoverable from the files themselves. Treat a scenario as a database rather than a drawing, and much of what looks unfixable becomes tractable.