← All documentation

Viper Racing Modding — History, Tools & Credits

Viper Racing (Sierra / Monster Games, 1998) grew a small but remarkably dedicated modding community that kept the game alive for over two decades — converting cars from other games, building tracks, patching the engine to run on modern hardware, and passing format knowledge along in hand-written tutorials.

This document records who did that work, the tools they built, and how the game's file formats came to be understood. It's the companion to VIPER_RACING_FILE_FORMATS.md: that reference describes what the formats are; this one describes how the community learned them and what they built — the context that made a toolkit like vrmod worth writing.

The short version: the formats were understood intimately, but almost entirely by hand — a hex editor, a 3D modeller, and a scattering of single-purpose command-line converters. vrmod is the first attempt to fold that manual knowledge into one programmatic library.

Before the mods: how MGI built the game

Shortly after Sierra announced the game in mid-September 1998, Gaming Entertainment Monthly interviewed Richard Garcia, president of MGI (Monster Games) and the game's lead engineer. It's the fullest account from the developers themselves, and much of it matches what the code shows. The main points, paraphrased (archived copy):

• The team. Garcia had spent most of ten years at Papyrus (Indy 500: The Simulation, and NASCAR Racing Online Series, then codenamed "Hawaii"). MGI was new and started from nothing, so the first of about two years of development went on the racing technology alone. The whole team was six people: three programmers, two artists and one designer/producer.
• Why the Viper. The aim was a highly detailed simulation of a single car, built from its own suspension and drivetrain measurements, and the Viper was one of the fastest production cars available. The programmers went to the Skip Barber Racing School, and the team had a real Viper to measure and photograph.
• The physics. Garcia describes it as his first project where the CPU was fast enough not to fake the maths: tyre rubber deformation, every suspension component, the complete drivetrain and whole-car aerodynamics. There are three physics settings (arcade, intermediate and simulation). The AI cars run the same full model, "the AI can't cheat", which is why the hardware needed rose with every car added. The code agrees: an AI car is the same kind of physics object as the player's (see "How an obstacle lives" in the file-format reference).
• The graphics. A Direct3D card was required, from an S3 ViRGE or Matrox Mystique up to a Voodoo Banshee or Riva TNT. The art was drawn for 16-bit colour, and the polygon counts made a software renderer "nearly impossible". The car had over 1,000 polygons at full detail and eight levels of detail, the eight-step ladder in viper.car described under How good were the models, actually?. Minimum spec was a Pentium 133 with 32 MB, with force feedback and AMD 3DNow! supported.
• What was cut. Rain was dropped because it made the cars too hard to drive: players went too fast when they couldn't feel the tyres slipping.
• The views. Over ten cameras shipped, including x-ray and TV views, and the player could ride along in any car to watch how the AI drove a track.
• The tracks. Each track was set in a real region of the US, but the layout was free. They were laid out on an SGI workstation and raceable within a few hours. A layout that wasn't fun was thrown away, and the cycle could run for over a week before one went into full production (textures, terrain, trees, rocks, signs). The MK* build tools that turned those designs into game files survive; see Where the MK* toolchain came from.
• Multiplayer. Two-player modem, direct connect and LAN, with a "rogue" internet server planned so players with fast connections could host private races. The engine's imports match: WinSock for the network and TAPI for the modem.
• The schedule. MGI expected to go gold in mid-October 1998, with the game in shops two to four weeks later, and a demo was in progress. The retail race.exe was linked on 21 October 1998.

The people

• Val (Moose Jaw, Saskatchewan, Canada) — ran the community's central site (originally vnovak, created 9 December 2003; later mirrored at valsgames.com) and was its most prolific modder, responsible for on the order of 1,500 car conversions and most of the community's tracks. He also wrote the how-to tutorials the rest of the scene learned from (hex editing, NFS→Viper conversion, track-making, AI-name editing).
• Frank P. Wolf ("Frank Wolf") — a major car converter (Aston Martins, Ferraris, Porsches and more; ~155 cars) and toolmaker, author of the CarMan and WheelMan management programs. His car packages were also the ones that shipped with an anti-tamper "lock" (decoy directory entries).
• Sucahyo — produced the 2007 "1.2.4 beta" race.bin, the community engine patch that raised the game's polygon and per-object vertex limits (the reason high-detail mods load at all). This is the lineage behind the widely-used community race.bin (v1.2.x).
• Charlie Ward (Brunswick, Maine) — modified race.bin in 2016 to fix the modern-GPU startup error (the game's video-memory check overflows on cards with several GB), building on a solution found by beatcracker. This lets the game start on any 32/64-bit Windows including 10/11.
• Eric "Zero" — supplied the finding behind the 2017 v1.2.6 race.bin. Val's note shipped with that build credits him: "According to Zero's information I modified my 2016 race.bin so as to not always show the extra rear wing in the viper.car and ai viper cars." That is the last change anyone made to the engine, and it started with his diagnosis. He is also a car modder in his own right — the 2018 Viper.car and ViperGT.car retextures (3D modifications, brakes and a rear spoiler built from scratch over the EA model) and a 2019 ViperGT v2.0 adding a full interior. His readmes are unusually careful about attribution, and are the source for several of the names on this page.
• Dave Broske and Dave Pollatsek (Monster Games) — the two MGI programmers who kept supporting the mod scene years after release. Community readmes thank them for a decade as "both Dave's from MGI" and "Dave P. and especially Dave B.", rarely spelling either out; Zero's 2018 readmes name both. Broske built the 1.2.3 beta race.bin for the VRgt team — the binary every later community build is hex-edited from.
• Matthias Walden — toolmaker: the Surface Modifier and UV Map Editor for .mod files, the ResEdit tool, and the programmer behind the Tire Editor.
• Matthias Nyberg ("Matt") — the tyre/handling expertise behind the Tire Editor, and the source of the finished tyre sets it could apply.
• Kevin Combs — released RESTools (MGI's own mkres/mktex/mksfx/mkcar, with Frank Wolf's rescrack) for NASCAR Heat modding, "with the help of the Monster Games developers and the producer for the game"; he went on to iRacing as its Technical Art Director (staff profile).
• Ashes48 — Frank Wolf's closest collaborator: "the hex hacker king" who found most of the settings Frank's tools edit, designed the replacement race.res that WheelMan needs, and in Frank's words "kicked my ass to write the necessary programs".
• Maurizio — author of VRDSC, which advertised a dedicated server to the VRgt RaceFinder.
• BlasterMaster555 ("Impreza") — ran wrxds.mine.nu, from 2003 a Viper Racing dedicated server, and wrote the community's most complete car creation / conversion tutorial (19 pages). His machine also hosted the FTP archive Val's site linked as "accumulated from 1998". Archived copy: docs/tutorials/wrxds-car-tutorial/.
• Max — a car modder ("Add-on cars by Max").
• …and the wider community of racers and converters who contributed cars, tracks, retextures, and testing over the years.

The community toolchain

A capable but entirely manual set of tools. Where a binary survives in the preserved archives it's marked ✓.

Archive / packaging — RESTools

Most of the converters below were not loose utilities but one suite, RESTools. Its mk* programs are Monster Games' own in-house tools: they carry MGI's 1998 build dates and the same Microsoft linker 3.00 that built the game. Kevin Combs (now iRacing's Technical Art Director) released them for NASCAR Heat modding "with the help of the Monster Games developers and the producer for the game", in his own words in his iRacing staff profile. RESTools' own readme lists ResCrack, Mkres, Mktex and Mksfx and says: "These are not official releases from MGI … Myself, nor Employees from MGI can be held responsible". The exception is rescrack, which is community-built (MinGW, December 2000); Frank P. Wolf says he wrote it himself. Frank distributed the set from his own site (members.aol.com/racingwolf999/), the same address his cars and CarMan came from, which is why the community long credited RESTools to him. The wrxds tutorial (see Preservation & sources) walks through using them and names the set.

• rescrack.exe ✓ — unpack a .car / .res / .trk archive into its loose members, plus a reslist.txt. Frank P. Wolf's: "written by me in C++ based on some code snippets somebody from MGI had dropped on the way" (his site).
• mkres.exe ✓ — (re)pack an archive from a reslist. MGI's (1998-08-07).
• mkcar.exe ✓ — MGI's (1998-08-19): mkcar <src.txt> <dest.cf>, which compiles the car's .cf physics file from text, not the .car archive. Named in the tutorial's step 4 alongside mktex/mkres/mksfx; it survives in Frank Wolf's toolpack2.zip.
• extract.exe ✓ (Sucahyo) — not an unpacker. A multi-function track utility, recovered 2026-09-10 with its own readme: .ase → vertex text for mkflt, .ase → .ili, .ase → wall quad objects, .ase → a "pipeline" of walls down both sides of the road, mod2quad (wall quads from a .mod, with an added-height box), .bpp → .mod, .ase → camera.tab, and injection of obstacle records into track.obt. Its earlier description here as an unpacker was wrong.

Cars

• CarMan / CarMan2 / AICarMan ✓ (Frank Wolf) — install/activate/organise cars and set up the AI field.
• WheelMan (Frank Wolf) — wheel manager. vrcarrenamer ✓ — rename a car.
• cf2txt ✓ / txt2cf — convert the .cf physics file to and from editable text (hp, torque, mass, wheelbase, suspension…).
• Viper Racing Tire Editor ✓ — tyre/handling editor.
• Zmodeler 1.07 — the free mesh editor at the heart of every car conversion (Need For Speed 4 / Sports Car GT → Viper), used with the vrzmodtemplate ✓. 3DS Max 3.1 — the professional alternative.

Textures

• mktex ✓ / tex2tga ✓ / tga2tex ✓ — convert between the game's .tex and standard .tga. GIMP — the free image editor of choice.

Sound

• mksfx ✓ — convert a .wav to the game's .sfx.

Tracks

• Bob's Track Builder (BTB) — track authoring (with a BTB→Viper tutorial); the Pro edition is still sold on Steam, though the tutorial targets the original.
• vrTrackMaker ✓ (Sucahyo, "VR simple Track Maker") — consumes a .ase centreline from 3DS Max and produces the driving model: collision surfaces with their material codes, walls, checkpoint gates, the four .ili racing lines and a speed profile. It also emits simple swept meshes, but in a modern BTB-based build those are a fallback — the visible track comes from BTB via Zmodeler. Fully specified in VIPER_RACING_FILE_FORMATS.md.
• MKWORLD / mkfltoa ✓ — generate the surface + collision set (.sol / .obt / .bsp / .grf / .bpp) from a text scene description; nhmkworld ✓ — the graphic pass that adds objects to .grf / .bpp. vrmod now writes .bsp, .obt and .grf itself, and packs the .tra, all confirmed in a track that loads and drives; only .bpp still needs these.
• MKSTAMP / Stp2Tga / tga2stp ✓ — the .stp menu screenshot and Trackmap.
• MKTABLE / mkilicc ✓ — data tables / the AI racing lines. mkilicc -nolat is run three times: track.ili→track.ild (the track-map line), track-ai.ili→default.ili (forward AI line) and track-ai-reverse.ili→rdefault.ili (reverse AI line). vrmod now generates these lines directly from a centreline (ili.generate), confirmed in a track that loads and drives — so neither mkilicc nor its .ili source format is needed for a generated track.
• make-track.bat + compile-track.bat ✓ — the two batch files that drive the whole build and then pack the .tra with mkres @reslist.txt. Reproduced verbatim in VIPER_RACING_FILE_FORMATS.md.
• trkaitweaker ✓ — AI tuning. jpg2sky / sky-tga2tex — the four skybox tiles.

Where the cars came from

Almost no Viper Racing car was modelled for Viper Racing. The scene ran on conversion — lifting a mesh out of another PC racing game, re-texturing it, and rebuilding the physics and sounds around it. Val's site was organised around exactly that, with a FILES section per source game.

Counted across 1,710 car readmes in this archive — the readmes are unusually diligent about crediting a source, so the numbers are close to real practice:

Two things worth drawing out.

Re-Volt topping the list is the surprise, and it makes sense once you see why: it is a radio-control racer, so its cars are small, low-poly, cleanly UV-mapped meshes — far easier to bring into a 1998 engine with tight vertex limits than a modern high-detail model. The conversions credit the original Re-Volt car authors by name (SKARMINATER, Beroc, scloink, BurnRubr and others), not just the game.

The chain was long. A typical car passed from its origin game, through Zmodeler 1.07 for the mesh, vrl2wrl or a hand conversion for the format, tga2tex for the textures, and cf2txt for the physics — every step a separate command-line tool. That pipeline is what Part A below catalogues, and what vrmod folds into one library.

How good were the models, actually?

The VRgt team ran to a higher standard than the open community, and it shows in the binaries. Measured across 1,792 cars — every car in this archive — reading body vertex counts, material splits and texture counts straight out of each <prefix>0.mod. VRgt-authored cars are excluded from the community column so they don't inflate the baseline they're being compared against:

Three times the geometry, twice the material splits, and over half again the texture work. 90% of VRgt cars clear 2,000 vertices against 23% of community cars, and their heaviest — the Edo Competition Enzo at 13,536 vertices — is 68× the body of the retail Viper it parks next to.

The ranking inverts on LOD discipline, though. A car ships <prefix>1.mod through <prefix>7.mod as progressively cheaper stand-ins for distance, roster shots and traffic. Counting a level as real only when it is actually decimated — bytes that merely differ prove nothing, since some cars ship LOD1–7 at equal or higher detail:

MGI built a genuine ladder — viper.car steps 325 → 299 → 221 → 186 → 122 → 79 → 48 → 26 vertices. The community ships the full seven-level chain as copies of LOD0: ks360.rar is 9,268 vertices replicated eight times, so it renders at full detail at every distance, and the chain buys nothing at all. VRgt did roughly half the work — just over half their cars reduce at all, and even those only reach 76% of LOD0 by the last level.

So the fair summary is that VRgt modelled better and were the only group besides MGI doing any optimisation, but they built three times the geometry while only partly paying for it. A grid of VRgt cars costs far more than anything MGI shipped — which is the pressure behind the community race.bin builds raising the vertex budget to 20k (see Engine patches below).

One incidental result of the sweep: not one of the 1,792 cars ships its own cockpit.mod. Every car in the scene, VRgt included, puts the driver behind the Viper's dashboard — the per-car cockpit override the engine supports was never once used.

Engine patches & race.bin versions

Every modern install runs a community-patched race.bin (the game engine). The version is shown in-game at the Options screen, bottom-right corner, and is stored as a plain string inside race.bin itself (near offset 0x0D37FD — e.g. 1.2.4 BETA, v1.2.5 2016).

That indicator arrived with the second pressing. The first pressing runs race.exe, which contains no version string at all, and its Options screen shows nothing in that corner — confirmed in game. See The first pressing shipped a release candidate below.

Official (Sierra / Monster Games):

Monster Games' own server only ever hosted a handful of downloads: the Viper patches, two NASCAR Heat patches and a Heat changelog.

MGI released exactly one car

VIPERGT.CAR — the Viper GTS-R — 25 February 1999, one day before the 1.1 patch. The two went out together. Its readme leaves no doubt:

                         VIPERGT.CAR
                 Viper GTS-R for Viper Racing
                            MGI
                      root@mgiracing.com
                       25 February 1999

    Thanks for buying Viper Racing.  We appreciate it.
    ...
    The Viper GTS-R can be selected at the Hacks screen, exactly like
    the other "extra" cars in Viper Racing.

It is not on either retail disc — the discs carry five cars (exotic, plane, sedan, sports, viper) and this is a sixth. It survives at vnovak.com/vr/mgivipergt.zip.

No official track was ever released, though. Val's site also hosts mgi-bemidji, mgi-castle, mgi-dayton, mgi-dundas, mgi-ridge, mgi-rock, mgi-silver and mgi-sunset, which look like eight more official releases and are not: mgi-bemidji.zip holds a bemidji.trk byte-identical to the one on both retail discs. Those are Val repackaging the stock tracks so a player could restore an original after TrackMan overwrote its slot. mgiviper.zip is the stock car for the same reason.

Is there a 1.2 beta at all?

Probably not, and it is worth writing down so nobody spends another decade looking.

viperpatch12beta.zip appears in the Wayback index, which is why it gets cited as a lost release. But a URL enters that index when a crawler follows a link to it — being indexed is not evidence it ever served anything. Its capture history is one line:

viperpatch12beta.zip    2021-01-26   404          <- the only capture, ever
viperpatch121beta.zip   2005 404 · 2006 200 · 2007 200 · 2021 404

The 1.2.1 was retrieved successfully twice, in 2006 and 2007, with the same content digest both times. The 1.2 was never seen served, in any capture, by anyone.

Two further things point the same way. A June 2002 thread on NTCompatible has someone hunting specifically for "the Viper Racing 1.2 Beta patch" for days, on a compatibility note's recommendation — and what he eventually finds, quotes the readme of, and declares fixed is viper121beta.zip. Nobody in the thread produces a 1.2. And of the ten distinct race.bin builds catalogued for this project, none carries a v1.2 stamp — they run 1.0, 1.1, 1.2.1, 1.2.3, 1.2.4, 1.2.5.

The likeliest reading is that "1.2 beta" is simply how people referred to the 1.2.1 beta, or that a 1.2 existed so briefly it was replaced before anyone archived it. Either way, the patch everyone has been hunting for is the one already in hand.

What 1.1 actually fixed — from the patch's own readme

The official patch survives as viper11.zip → viper11.exe, 988,905 bytes, dated 26 February 1999. It is a 16-bit NE executable (a Wise "Sierra Patch Installation"), with two consequences worth knowing: archivers cannot open it, and it will not run on 64-bit Windows, which dropped 16-bit support entirely. Its payload has to be recovered by other means.

Inside are ten deflate streams, recovered by scanning the file for raw-deflate streams and decompressing each in turn. Six are Wise's own scaffolding (its version resources, two small helper executables, REBOOTNT.EXE, the installer's 118×258 dialog bitmap, and the readme — the bitmap and readme each stored twice). The other four matter, and two of them carry the whole patch: a 192,369-byte engine delta and a 1,837,008-byte race.res. Both are dissected under How 1.1 is actually delivered below.

The readme is dated 19 January 1999 and lists the fixes in MGI's own words:

Two of those are worth pulling out. -nointro originates here — the runtime reference lists it among the engine's flags, and this is why it exists. And the "crash on exit reporting a memory leak" is the same panic class a modern builder hits when objects are created without reaching the engine's master object array (runtime reference §4): MGI shipped a fix for it in 1999.

A note on "official". The Patches Scrolls — which mirrored these for decades — lists 1.1 as official and both 1.2.1 beta and 1.2.3 beta as unofficial. That is a classification by support status, not by origin: 1.2.1 was hosted on mgiracing.com itself and its readme is written in MGI's own voice ("we don't have service pack 2 installed anywhere in the office yet"). The table above classifies by where the file actually came from, which is why 1.2.1 sits under official here and 1.2.3 — built by an MGI programmer but released by the VRgt team — sits on its own.

How 1.1 is actually delivered

The patch contains no game executable and no race.bin — and there is no room for one, since race.exe alone is 2,404,451 bytes. For a long time that left the obvious question open. It is now answered: the engine ships as a binary delta, and race.res ships whole.

The engine: a 192 KB delta

192,369 bytes stand in for a 1,298,432-byte engine. The stream is 44.5% printable — literal runs interleaved with binary copy instructions — and the decisive evidence is which strings those literal runs contain. A replacement binary would carry everything the engine carries. A delta carries only what changed:

Every string v1.0 already has is absent; every string v1.1 introduces is present. So the literal runs are exactly the changed regions — the new build banner and version, the -nointro flag this very readme introduces, and the new multiplayer and FOV strings — and the installer stitches them into the binary already on disk.

That also narrows the table's open question at the top of this section. The delta's banner is Jan 25 1999 11:47:39, the same build timestamp as the second pressing's race.bin. So the patch and the repressing deliver the same build; whether the patch also performs the race.exe → race.bin filename transition is still untested, but it is aiming at the same binary.

race.res: shipped whole, and only one resource changed

The 1,837,008-byte stream is a complete race.res, not a delta — 0TSR magic, the same header words as the retail archive, and it parses as 57 members, the same count as v1.0's 1,850,130-byte race.res. Diffing member by member (sha256 of each payload) against the v1.0 RC:

The entire 1.8 MB archive rides along to deliver one new sound. Decoding both revisions:

Same format and rate, an entirely different clip — a third as long and roughly half the amplitude. 32,339 is within 1.3% of 16-bit full scale, so the v1.0 horn was recorded essentially at the clipping point; 15,104 is about −6.7 dBFS. A shorter, quieter horn.

And the readme never mentions it. Its only audio item is "Replay: Some Cars Have no Engine Sound". So the one resource change in the entire patch is undocumented — MGI evidently decided the launch horn was too loud and too long and said nothing about it.

An earlier pass here recorded the patch's race.res as byte-identical to the second pressing's. That is not carried forward: no second-pressing tree survives locally, so the claim is untestable and has been dropped rather than repeated. The diff above is against the v1.0 RC, which can actually be checked.

Community race.bin (unofficial, built on 1.2.3):

One more thing they fixed, and it helps date the 1.2.4 lineage

The community builds also moved the car list on the Hacks options screen. In retail the Vehicle list's top edge sits at y=200 — halfway down a 480-line frontend — so once an install carries a real collection the entries run off the bottom of the window where nothing can reach them.

Added@HackOptionsControl builds that screen as a table of UIDialogItem descriptors, and the list's geometry is four literal immediates at one call site. Diffing every build held here:

76 pixels higher and 55 taller. The 0x50 bytes of descriptor either side are byte-identical between retail and 1.2.4, so the entire fix is those four numbers — nothing structural.

Two things follow. First, this is another change that only ever reached race.bin, so the v1.0 pressing — which runs race.exe — never got it, the same gap as the horn ball and the RC's module assertion. vrmod carlist applies it to either engine.

Second, it is a dated data point for the 1.2.4 muddle. The table above lists Sucahyo's 1.2.4 BETA as October 2007, but the build carrying this fix is the v1.2.4 BETA extracted from the 2005 VRgt Demo installer — a different file from Sucahyo's, as that build's provenance note already records. So the car-list fix was circulating at least two years before the 1.2.4 everyone knows. Which build first made the change is not established: no 1.2.1, 1.2.3 or Sucahyo 2007 binary is held here to narrow it further.

Notes for anyone cataloguing binaries: - The pcgamingwiki "Viper Racing Unofficial Patch 1.2.4" (uploaded by Blackbird) is a re-upload of Sucahyo's 2007 1.2.4-beta, not a separate build. - A file circulated as race.bin-25kvert-512tex-allmirror is byte-identical to the 1.2.4-beta (whose own readme still says 20,000 vertices) — the name over-promises. "512tex" most plausibly means the number of textures loaded simultaneously (a limit Sucahyo's notes mention raising), not a 512×512 resolution, but it can't be confirmed from that mislabeled file. - ResolutionChanger.exe (shipped in Data/) sets screen resolution independently of the race.bin version.

The first pressing shipped a release candidate

The retail v1.0 disc — Redump #61183, Viper Racing (USA) — boots to a title screen carrying this, in green above the artwork:

Oct 21 1998 08:49:56 NON-DEBUG MSVC-4.0
feedback@mgiracing.com
Release Candidate 1:  CONFIDENTIAL
Copyright © 1998 MGI. All rights reserved.

Release Candidate 1: CONFIDENTIAL and the feedback address appear only in v1.0's race.exe. Neither race.bin — v1.0's or v1.1's — contains them.

This is why the first pressing carries a symbol map. race.exe has a ~1 MB overlay holding a full linker map: 10,414 symbols across 296 object files (physics:control.obj, ai:driver.obj, gx:gfx.obj, edit:modtool.obj, multi:server.obj…). It also carries the reader for it — No mapfile present, Couldn't open exe: %s, Can't map view of file — so the binary opens itself and symbolises its own crashes:

Panic : Can't load options.def
trace: byte 0x88 of "?OptionsBegin@@YAXXZ"
trace: byte 0x72 of "?app_begin@@YAXXZ"
trace: byte 0x1b of "?AppMain@@YAXXZ"
trace: byte 0x120 of "_WinMain@16"

None of that was a gift to modders. It is an RC build with its diagnostics still switched on, pressed to manufacturing.

It also explains the second pressing. Comparing the two discs file by file, 306 of the files are identical and only 9 differ — but the executable is replaced outright, and the engine moves out of it into race.bin:

v1.0  Data\race.exe    2,404,451 b   .text 890,368   + a 1 MB symbol-map overlay
v1.1  Data\Viper Racing.exe 388,608 b   .text  16,384   (a launcher; no map, no banner)

So February 1999 was not a tidy-up. Sierra and MGI pressed a release candidate, and the v1.1 disc replaced it with the actual release build — banner gone, map gone, RC markings gone, the CD check and environment gates moved into a proper launcher.

The irony is worth stating plainly: the artefact this community has reverse-engineered against for twenty-five years — the binary long circulated as ai-tweaker.exe, which is byte-identical to v1.0's Data\race.exe — reached the public through a manufacturing mistake.

Practical consequence. A first pressing gives you the symbol map, self-symbolising crash traces, and the RC title screen. A second pressing gives you none of it. If you are buying a disc to work from, the revision matters.

Hex editor

• XVi32 — the community's recommended editor. Nearly every "edit" that wasn't geometry was a hex edit here: the <car>1.tab spec sheet, texture-name strings inside a .mod, AI/track names in english.lng.

Master chart — every known tool, and its vrmod counterpart

Consolidated from the sections above, from vrgt.com's downloads page (see Preservation & sources), and from the community binaries that still ship inside Data/. Creator is listed only where a source actually names one. The last column is the honest state of vrmod's coverage — including where there is none, since that is the clearest map of what is left to build.

Two kinds of software are kept apart deliberately:

• Part A — community tools: one-off utilities written for Viper Racing, by the people above. These are the fragile part of the record. Several exist only as a single surviving binary, and the sites that hosted them are gone.
• Part B — third-party software: general-purpose commercial or free applications the workflow leaned on. Not Viper-specific, not at risk, and mostly still obtainable — but you can't reconstruct how a car was actually built without knowing which ones were in the chain.

Part A — community tools (Viper Racing–specific)

reslist.txt had two incompatible shapes, and that is why a "reorder" step existed. An extracted track's list is one long whitespace-separated row (castle's is 62 entries on a single line); the track-building kit ships one entry per line (19 entries, 18 newlines). VRcarEditor's tutorial spells out the consequence — its REORDERRESLIST button "lines up the reslist.txt contents in a row in order for mkres.exe to recognize it". A hand-maintained list that two tools in the same chain disagreed about is the kind of failure vrmod pack removes by not needing a list at all.

Archive / packaging

Cars

Textures & sound

Tracks

Engine patches & install fixes

Where the MK* toolchain came from CONFIRMED(binaries)

Most of the tools above name a person. The MK* ones never have, and the blank was doing real work: those are not community tools at all. They are Monster Games' own build pipeline, and the binaries say so without being asked.

They were built alongside the game. Every 1998 tool carries the same linker version as race.exe itself, and dates from the months before release:

MKWORLD reads OpenFlight (.flt) — "can't read this version of Openflight! (%d.%d)" — MultiGen's professional simulation format, licensed software with a commercial price tag in 1998. That is not a format a fan scene builds against.

The community tools look nothing like them. vrtrackmaker, trkaitweaker and extract all carry the fake 1992-06-19 22:22 timestamp and linker 2.25 — the Borland/Delphi signature — and are full of TFieldAttribute and AttributeSet, Delphi's VCL. Different language, different decade of toolchain, different authors. The split is visible in the file headers alone.

They arrived via NASCAR Heat, not via Viper Racing. Monster Games reused the pipeline on their next game, and that is the disc the community got it from. mkfltoa.exe still carries the path it was built in:

D:\Install\NASCAR Heat\Disc29\Tools\mkflt_new by TheMask\Public\beta
  (fixed flipped textures and displaced hitable walls bugs)\Sou...

along with modified by TheMask in 2005. and a switch that gives the game away:

-viper = viper mode (uses v%d, strips out pit paths)

A Viper Racing track has no pit paths; a NASCAR one does. The Viper support is the bolt-on. extract.exe has a file dialog reading Nascar heat mod file|*.mod, and nhmkworld.exe — the nh is NASCAR Heat — shares MKWORLD's usage string verbatim while adding MKWORLD supports autox and cheater walls, and a Cartman quote (RESPECT MY AUTHORI-TAH!) that no 1998 release build contained.

So two of the "1998 SDK" tools are not from 1998. nhmkworld.exe is 2003-01-02 and mkfltoa.exe is 2005-07-03, both linker 6.0: NASCAR Heat descendants, re-aimed at Viper Racing by the community. Six of the eight are genuinely Monster Games, 1998.

None of this contradicts the developers' documented generosity — Dave Broske built the 1.2.3 beta race.bin for the VRgt team, and both Daves supported the scene for a decade. It refines it: the track toolchain did not need a quiet hand-off, because Monster Games had already shipped it on another product.

Multiplayer & community infrastructure (historical)

No prior equivalent

Parts of vrmod answer to nothing in the historical toolchain, because the community did these by hand or not at all: the 3D viewers (car, cockpit, track, parts), vrmod doctor (install health), carshot/gallery, the cockpit calibration tools (cockpitdump/cockpitset), the LOD-chain generator (modlod), carfork, and the horn-ball tuning (hornball).

What the gaps say. Every "none" above is in track authoring — mesh generation, collision building, AI-line tuning, UV work. That is not an accident of effort: the community needed four separate tools for one track (Track Maker, BPP-2-Mod, Bad Poly Fix, Track AI Tweaker) because the visual mesh, the collision BSP, the solids and the AI lines all have to stay mutually consistent. vrmod reads all four layers today but writes only textures — and closing that gap is a design problem, not a parsing one.

Part B — third-party software (general-purpose)

Not written for Viper Racing, and not at risk of being lost — but the workflow is unreconstructable without them. A car conversion was modelled in one of these and only then pushed through the community converters in Part A.

Bob's Track Builder is three different products, and only one is still available

Worth spelling out, because "BTB" in a 2000s-era tutorial does not mean the BTB you can buy today:

The developer's current focus is Race Track Builder, which targets Assetto Corsa only.

There was never an official Viper Racing exporter in any version. BTB contributes the geometry, which is then carried through Zmodeler and 3DS Max before reaching the MKWORLD source files. The full route is documented by HerbFargus from tracks built with it, and written up step by step in VIPER_RACING_FILE_FORMATS.md:

BTB Pro  ->  .dof  ->  Zmodeler  ->  .mod + .3ds  ->  3DS Max (spline)  ->  .ase
         ->  vrTrackMaker  ->  MKWORLD source set  ->  make-track.bat  ->  the track

So the position is much better than this chart used to imply. Track authoring is not a dead end and not a research problem — it is a working pipeline that still runs, with a purchasable modeller at the front and recovered tools at the back. What vrmod lacks is the middle: the spline-generation and vrTrackMaker stages, i.e. .ase spline plus mesh set in, MKWORLD source files out. That is a bounded piece of work with both ends specified, which is the concrete shape any future track-authoring scope would take.

The honest summary of Part B: the community's real "editor" was a general-purpose 3D package plus a hex editor. Everything in Part A existed to bridge between those and the game's formats. vrmod collapses that bridge — which is why its Part B column is mostly "any modeller you like".

How the formats were understood

The scene's format knowledge was real and deep, but it lived in hex-editor tutorials and muscle memory, not code:

• <car>1.tab (the "garage" spec sheet). Val's 2015 hex-editing tutorial shows opening it in XVi32 and reading off Name, 0-60, top speed, engine, power max, torque max, redline, etc. as plain text — the exact structure vrmod now parses to derive a car's display name and stats automatically.
• .mod (meshes). Editing here was limited to finding and renaming the texture-name string inside the file; actual geometry was always done in Zmodeler and re-exported.
• english.lng. AI driver names and track slot names were changed with a fixed-width, never-longer-than-the-original hex edit — the same constraint the modern switcher works within.
• The engine. Rather than being decompiled, race.bin was binary-patched: Sucahyo lifted the limits (2007), Charlie Ward/beatcracker fixed the GPU check (2016), and Val Novak made the last edit in 2017 on a finding by Zero. The first two are what most modern installs still rely on.

So the community had mapped the what of these formats byte by byte. What it never had was the how at scale — a way to read and write them programmatically rather than one file at a time in a hex editor.

Preservation & sources

The game's mods are, remarkably, preserved several times over:

• Val's site, captured on the Internet Archive as downloadable items (not just Wayback pages): "Val's Viper Racing Site Backup" (a full ~3 GB copy of the site, mods included) and a smaller later capture. Val also maintains valsgames.com, which points back to these.
• A community "Complete CarPack / TrackPack" collection on the Internet Archive (39 car-pack volumes + 6 track-pack volumes), sourced from Val's set.
• The original tutorials, tool binaries, and readmes are inside those captures.
• viper-racing-recovered — an Internet Archive item holding material recovered from Wayback captures of the sites above: tools, patches, sky and texture packs, the track-making toolchain, and the site images. It ships a MANIFEST.json giving every file's original URL, byte count and SHA-256, so what came from where is checkable rather than asserted.
• viper-racing-legacy-modding-tools — a curated republication of that material on GitHub, organised as Car Tools, Car Mods, Track Tools and Track Mods, sourced from Val via vnovak.com. Its wiki also carries the modern track-building workflow, which is the only description of the front half of that pipeline anywhere — it is not in Val's tutorials, the wrxds tutorial, or the tool readmes.

vrgt.com — the other hub, mostly lost

Alongside Val's site, vrgt.com was a central gathering point for the scene: the VRgt mod, online championships, the RaceFinder, and a downloads page that hosted much of the toolchain above. It also ran dedicated forums for car and track modding — the place where a lot of this knowledge was originally worked out in public.

It went offline around 2019 and was never archived as a whole. What survives is Wayback captures and whatever individuals kept; the forum threads in particular appear to be gone. The downloads page is one of the pieces that did survive, and it is the source for several attributions in the chart above (FPWolf's Trackman/Lapman/Optman, M. Walden's .mod tools, Sucahyo's track utilities) that are recorded nowhere else here.

Its loss is the reason this document exists in the form it does. Much of what follows was re-derived from the binaries rather than read from a tutorial, because the tutorials are no longer there to read.

How much was lost, precisely. The forum's front page survives in the Wayback Machine (captured 20 May 2019, weeks before the site went dark), and it carried its own statistics — so the scale is not a guess:

"Our users have posted 9,734 Posts in 913 Topics in 14 Forum(s)" — 311 forum members. Running Web Wiz Forums 7.01.

The two Editing boards alone — the ones that held the car- and track-modding knowledge — account for 269 topics and 3,818 posts, roughly 39% of everything ever posted there. Not one of those threads is retrievable: the front page was captured, the threads behind it were not.

Two further details the capture preserves. The board list shows 11 boards while the statistics count 14 forums, and the page legend includes "No Access" — so three boards (the empty Development category among them) were private. And the last posts in Cars (Jan 2019) and General (Mar 2019) show the place was still active right up to the end; it didn't fade out, it simply stopped being hosted.

The capture also quietly corroborates this document's attributions: the last posters include sucahyo, val5662 (Val) and Matt — the same people credited above for the engine patch, the tracks, and the Tire Editor.

wrxds.mine.nu — the tutorial that survived

Where vrgt's forums are gone, one substantial piece of documentation came through intact: the Car Creation / Conversion Tutorial at http://wrxds.mine.nu/tutorial/, by BlasterMaster555. Nineteen pages covering the whole pipeline — meshes, dashboard, RESTools, textures, sounds, performance, the car's long name, packing, and a second pass of fixes down to the brake lights.

The same host carried the FTP archive (ftp://wrxds.mine.nu/vrmods/) that Val's site pointed at as "accumulated from 1998". That listing was never captured — the files and their names are gone. The tutorial pages were, and are now kept in docs/tutorials/wrxds-car-tutorial/ with their images and the assets they offered for download.

It matters twice over. It is the era's best surviving account of how a car was actually built; and it is the missing citation for parts of this very document. The tool list above — Zmodeler 1.07, XVi32, vrzmodtemplate, the rescrack/mkres/mktex/mksfx set — is documentation-derived knowledge, not anything recoverable from a binary, but no source was recorded for it. Reading the tutorial supplied what had been lost in the retelling: that those converters are one suite (RESTools: MGI's own mk* tools released by Kevin Combs, plus Frank P. Wolf's rescrack), that it includes mkcar, and where it was distributed.

One gap worth noting: those public archives are Val-centric. Frank Wolf's ~155 cars are not in them, and his original site is long dead — so aggregated community collections may be their only surviving copy.

Why vrmod

This project was built to find the underlying file types and coding structures that made all of the above necessary in the first place — and, having found them, to do in software what the community did by hand:

• read a car or track's real geometry, textures, physics, sounds, spec sheet and AI line directly, with no hex editor;
• render them in 3D in the browser;
• edit and write them back safely;
• and check an install for the very fixes (the GPU patch, the limit patch, resolution, audio) that this community discovered.

It stands entirely on the shoulders of the people above. Where their tools were single-purpose and manual, vrmod aims to be one library that understands the formats — so the next twenty years of keeping Viper Racing alive don't have to start in a hex editor.