# Legacy Vehicle Drivable Patch How-To
## Goal
Make a legacy vehicle:
– stay on the lot after placement
– expose vehicle key management
– appear as a real active vehicle instead of `None`
– support lot departure and arrival without route loops
## Important Files
– `TSOClient/tso.content/WorldObjectProvider.cs`
– `TSOClient/Newso.Guides/README.md`
The current loader-side patch lives in `WorldObjectProvider.cs`. Avoid editing the original `.iff` or `.piff` files unless the user specifically asks for asset-level surgery.
## Step 1: Find The Real IFF Base Name
User-provided names are often close but not exact. Search the repo first.
Example:
“`powershell
rg –files | rg -i “squad|car.*squad|squad.*car”
“`
For the squad car request, the user asked for `squadcar.iff`, but the actual repo asset is:
“`text
TSOClient/_far_extract/vehicle_batch/carsquad/carsquad.iff
“`
Use the file base name in the patch table: `carsquad`.
## Step 2: Decide Which Patch Mode It Needs
Legacy vehicle entries are listed in `LegacyVehiclePatches`.
Use the light patch when the vehicle already has modern vehicle behavior and only needs identity or upgrade-flag repair:
“`csharp
new LegacyVehiclePatchSpec(“filebase”, CarStudioVehicleDonorFileName),
“`
Use the full donor behavior conversion when the vehicle has old service, carpool, taxi, or decorative behavior:
“`csharp
new LegacyVehiclePatchSpec(“filebase”, CarStudioVehicleDonorFileName, true),
“`
Strong clues that it needs the full conversion:
– it drives away immediately after placement
– it exposes old service or taxi interactions
– the master object uses old `CarGlobals` behavior
– the local main/init/route BHAVs do not match modern drivable vehicles
– key management appears only after earlier fixes, but active vehicle still behaves wrong
For `carsquad`, the placement drive-away symptom means it needs:
“`csharp
new LegacyVehiclePatchSpec(“carsquad”, CarStudioVehicleDonorFileName, true),
“`
## Step 3: Understand What Each Mode Does
Light patch mode:
– forces any local `Upgrade Flags` BCON first constant to `1`
– patches `fso_vehicle_key_token.iff` so the vehicle has a token identity
– recaches the object if the upgrade flag changed
Full donor behavior mode:
– copies donor vehicle BHAVs from `fso-summer-pink-limo.iff`
– copies required string tables
– rebuilds the TTAB/TTA path for vehicle interactions
– copies donor upgrade flags and forces the vehicle drivable
– rewires OBJDs to donor-style vehicle functions
– patches route-part GUID assumptions for multitile arrival routing
– patches the vehicle key token identity mapping
## Step 4: Build
After editing `WorldObjectProvider.cs`, build the content project:
“`powershell
dotnet build TSOClient\tso.content\FSO.Content.csproj -p:Configuration=Debug -v:minimal
“`
Known existing warning:
“`text
MSB3884: Could not find rule set file “MinimumRecommendedRules.ruleset”
“`
That warning is not caused by the vehicle patch.
## Step 5: Test In Game
Retest with rebuilt runtime binaries:
1. Place the vehicle on a lot.
2. Confirm it stays where placed.
3. Confirm `Key Management` appears.
4. Set it as active vehicle.
5. Confirm the active vehicle name is not `None`.
6. Travel to another lot.
7. Confirm arrival completes without a `CT – Get Route Part` tracer loop.
## Cautions
Do not full-convert a real NPC commuter or service vehicle unless the user wants it to become buyable and drivable. The full conversion intentionally removes old service-style departure behavior.
Do not revert unrelated dirty files. This repo often contains generated or user-edited `.iff`, `.piff`, `.nfs`, and lot state changes.
If the fix looks correct but the game still behaves the old way, check for stale runtime DLLs before changing the patch again.
