← Multiplayer Game System handbook

Ride customization and workshops

Working engineering guide; illustrated final documentation will follow at the project finish line.

Player flow

Open Character > Vehicles & Mounts. Select an owned ride, then a compatible category and part. The right panel previews the candidate on the ride, with white stat values and green/red differences. Selecting a candidate does not spend currency or fit it. Buy & Fit requires a nearby, open workshop selling that part. Fit Owned Part and Restore Stock Part work anywhere, including while mounted or driving. They update the current ride without changing the rider's seat. Restoring stock retains purchased ownership.

Purchases, fitting, services and deployment are server validated. Personal balances and purchased-part records are owner-only; installed cosmetics/tuning replicate publicly. The new RideGarage feature is included in existing per-character persistence and local feature checkpoints. Existing checkpoint restrictions on loading while mounted still apply; those are separate from fitting parts.

Editable content

Mesh parts accept static or skeletal assets, with transforms relative to matching points. Paint uses a vector parameter on the existing material, or an explicitly assigned replacement material. Pick the parameter after loading the material. Paint presets are individually purchasable; this pass does not provide arbitrary RGB mixing, decals or livery editing. Performance parts modify data-defined stats. (base + flat bonuses) * (1 + percentage bonuses) determines the final value; 0.15 means +15%.

Adding the future car

  1. Add or edit a ride profile with its readable name and stable ID. Assign the car Skeletal Mesh or its existing Blueprint implementing NGSRideDriver.
  2. Add seat transforms/sockets and rider animations matching each supported character skeleton. Existing CMC/Mover animation graphs remain unchanged.
  3. Add attachment points for wheels, bumpers, wing and other visual categories. Match sockets and transforms to the actual car. The example geometry is only a positioning aid.
  4. Create compatible part definitions and list them in the relevant vendor's Parts For Sale. Select existing categories, profiles, stats and currencies from the lists.
  5. For production physics, implement NGSRideTuningReceiver.ApplyRideTuning on the car Blueprint and apply Maximum speed, Turn rate and any custom stats to its movement system. The built-in kinematic driver already applies Maximum speed and Turn rate. Acceleration/custom stats need a receiver implementation that uses them.
  6. Call UpdateRideCondition from authoritative damage/fuel/animal-energy logic. Repair and Refuel services restore these persistent values. The placeholder driver does not simulate fuel consumption, mechanical damage or animal fatigue.
  7. Award a ride using authority-only GrantRide, and Credits or another registered currency using GrantCurrency. No client RPC grants money or ownership. Quest/story reward extensions may call these APIs on the server.

Inspection clones Blueprint native/SCS mesh templates without running the Blueprint's gameplay logic. If a construction script creates visuals dynamically, provide a profile preview mesh; construction-script behavior is not executed in the inspection stage. Ride-specific physics, production meshes, driving/riding clips and realistic material authoring remain separate asset work.

Validation

Native tests cover purchases, duplicate-charge prevention, incompatible/unowned parts, closed vendors, free refitting, slot replacement, services, balances and invalid-save rejection. Rendered runtime validation also boards an owned car, fits a wing while mounted with the vendor closed, and checks the same seat and ride remain active. Network validation must additionally confirm client RPCs, public appearance replication, private purchase records and travel persistence.