Wiki en construcción. Muchos conceptos de aquí provienen de la alpha 0.2 y todavía pueden cambiar. La wiki se finalizará para la versión 1.0 — por ahora está para ayudar a los testers cerrados y, más adelante, a los jugadores del acceso anticipado a orientarse. Para la información más actual y fiable, únete al Discord — es donde se anuncian los cambios primero y donde puedes preguntar directamente.

Únete al Discord para las últimas novedades

R&D — Private Testing

A standing run plan for the development car, re-run every weekend — it buys part potential and trait knowledge.

Aún sin traducir. Este artículo solo está disponible en inglés por ahora. Estamos traduciendo la wiki artículo a artículo — Discord es la vía más rápida para preguntar en tu idioma.
En elaboración. El primer borrador ya está aquí, pero el contenido puede evolucionar y todavía estamos añadiendo capturas. ¿Has visto algo mal? Cuéntanoslo en Discord.
En esta página

Private Testing is a standing programme: you write one run plan for the development car, and it re-runs on your own test circuit every Grand Prix weekend until you change it. It buys two things money cannot — part potential (head-room you can then develop) and trait-discovery kilometres — and it pays for them out of the weekly Engineering pool.


How to open it

  • Car icon → Private Testing (tab 8).
  • It is one of the three tabs open during pre-season (with Inventory and Production), so the programme can be set up before round 1.
  • RndScreen::with_tab clamps to 8 — Private Testing is the real last tab.

The team test circuit

Every team owns a test track, derived deterministically from the team country’s ISO code:

seed        = FNV-1a hash of the ISO code
turns       = 10 + (seed % 6)              → 10–15 turns
lap length  = 3500 + (seed % 3000) metres  → 3.5–6.5 km

It never changes for a given country, and it is the same venue the Infrastructure screen previews. The tab names it {City} Test Circuit and draws its outline in the Summary panel alongside length and turn count.

Lap length matters directly: a 6.5 km circuit costs almost twice the maintenance per lap of a 3.5 km one, because everything is priced in kilometres.


What you need before it runs

Three hard requirements. Miss any one and the programme idles — with a mail explaining which.

RequirementFailureMail says
A Reserve driver signedIdleNoReserve”the team has NO RESERVE DRIVER to run the mule”
The mule (car slot 2) has parts fittedIdleMuleNotBuilt”the development car (car 3) has no parts fitted”
Enough Engineering WU for the plan’s maintenanceIdleNoWu”its maintenance cost exceeds the whole weekly Engineering pool”

An empty plan or a zero-lap plan sends no mail at all — nothing was asked, so nothing is reported.

The header card shows the Reserve’s helmet, flag and name over the baked mule; with no Reserve it turns red: “No Reserve driver — the programme is idle”.


The run plan

Up to 4 runs. Each row carries:

ControlBehaviour
TypeStatic label Development. Race Sim and Quali Sim are disabled on this programme; legacy rows are coerced to Development at load
− / +Laps in steps of 2, clamped [2, 30]. A new run starts at 10 laps
kmThe run’s distance, laps × lap_length
Target (purple button)Cycles the development component through all 11
🗑Deletes the run

+ Add run appears while the plan has fewer than 4 runs.

The budget wall

The steppers cannot grow the plan past what the week can pay:

budget = rnd_wu_remaining − (WU queued on this screen: repairs + improves + selected design)

Exactly the arithmetic the shared gauge calls “Free”. Before drawing a +, the tab predicts the next increment’s cost (test_track_wu_cost_for_laps over a hypothetical lap count) and, if it would not fit — or the run is already at the 30-lap cap — draws a grey inert block instead of a clickable button. Same for + Add run (which must fit its 10 starting laps). Both handlers enforce the same wall and revert a growth that exceeds it.

Shrinking a run always works.

A plan can still end up over budget from the other side — an older save, or a week where you spent everything on repairs. In that case the Work Order panel shows a red line: “The plan exceeds this week’s remaining WU — the programme will not run this weekend.” That is the visible form of IdleNoWu.


The maintenance reserve

Running the mule does not cost money. It costs a share of the weekly Engineering pool, proportional to the kilometres you drive:

km    = total_laps × lap_length_m / 1000
share = clamp( km / 1000, 0, 0.50 )
cost  = round( weekly_pool × share )
  • 1000 km would reserve the whole pool — that is the reference.
  • A 200 km plan blocks 20% of the pool.
  • The share is hard-capped at 50%: no plan can ever eat more than half your week.

Worked example — Engineering 5 (100 WU pool), a 5.0 km test circuit:

PlankmShareReserve
1 × 10 laps505%5 WU
2 × 15 laps15015%15 WU
4 × 25 laps50050% (capped)50 WU
4 × 30 laps60050% (capped)50 WU

Note the cap: past 500 km on that circuit, extra laps are free maintenance. Finding your circuit’s cap point is a real optimisation.

It is shown as already spent

The Summary panel reports N WU reserved from the Engineering pool for maintenance (P% of the pool). In the shared Work Order gauge the same number appears under Testing, counted as consumed — because reserved is consumed. It is deducted centrally in spendable_wu_pool, so Repair, Improve and Testing all read the same remaining figure. A “10 WU reserved” note next to a 0/95 bar used to read as a desync; it does not any more.

Only the weekly Engineering pool funds the mule. The at-track weekend repair pool never does.

The ordering that makes it honest

In the post-race pass: pool refills first, then the test programme debits its share of that fresh pool, then the week spends the remainder. Billing it against the previous week’s leftovers made the mule look free inside Improve. Because of the ordering, IdleNoWu now means precisely one thing: the plan costs more than the entire weekly pool.

A maxed Improve queue can never starve the mule either — the next debit lands on the next refill.


Structural wear — what the maintenance does and does not absorb

The WU are the maintenance that keeps the mule race-ready. Consequently:

  • Performance is untouched. current_perf on the mule’s parts does not move a thousandth. This is locked by a regression test.
  • Health is only grazed.
structural = km_metres / component_lifetime          (fraction of the part's life)
graze      = max( 4.0 × km/1000 , structural × 100 × 0.10 )
health     = max( health − graze , 1.0 )

Component lifetimes come straight from the sim config — the same table the per-session wear model uses — so short-lived components (engine, gearbox, brakes) graze faster than a body or a floor.

  • The structural kilometre ledger runs in full. A heavily tested car ages. The mule is not a free perpetual-motion machine; its parts eventually need replacing like any other.

Trait discovery

Every kilometre the mule drives feeds trait discovery on its own fitted parts (slot 2), plus the shared tyre-supplier traits:

gain = car_km × (1 + reserve_intelligence / 20) × session_mult × dilution
session_mult = trait_mult_practice × TEST_TRACK_DISCOVERY_MULT = 0.30 × 1.0
  • A private test day is worth exactly a Free Practice session per kilometre — noticeably better than qualifying (0.08) or a race (0.06).
  • The Reserve’s Intelligence multiplies it, 1.0 at INT 0 up to 2.0 at INT 20. A sharp Reserve is worth double the mileage.
  • Dilution applies as usual: with N still-undiscovered traits on that car, each accrues at 1 / (1 + 0.5 × (N−1)), so multi-trait cars learn slower and confirm one trait at a time.
  • Runs on this programme carry no focus multiplier in the current build — the row exposes the development-component picker only. The ×8 focus lever lives in the Free Practice run plan.

Thresholds and states are the standard ones: Suspected at 15% of the km threshold, Discovered at 100%, both with an email. Thresholds ship at 90–140 km by trait family. See Free Practice and Car Traits.

Discoveries land on the version fitted to the mule, which is why running the mule on your current spec matters.


Development runs — buying potential

Each run targets one component and behaves exactly like a Free Practice development program:

intel_factor = (1 − w) + w × clamp(intel / 20)      w = dev_program_intel_weight  (1.0)
lap_frac     = min( laps / dev_program_laps_ref , 1 )    dev_program_laps_ref = 15
points       = dev_program_max_points × lap_frac × intel_factor    max_points = 5.0

points are display points of potential; the raw gain is points × 0.16 / 100, added to potential and capped at 1.18. Runs yielding under 0.005 points are dropped.

At the shipped tuning:

Lapslap_fracReserve INT 10Reserve INT 20
40.27+0.7 pts+1.3 pts
100.67+1.7 pts+3.3 pts
151.00+2.5 pts+5.0 pts
301.00 (capped)+2.5 pts+5.0 pts

Two hard consequences:

  1. 15 laps is the sweet spot. lap_frac caps at 1.0, so laps 16–30 add zero development while still costing maintenance WU and structural wear. Only run longer for discovery mileage.
  2. The Reserve’s Intelligence is the whole multiplier at the default weight of 1.0. An INT 4 Reserve delivers a fifth of an INT 20 one. Scouting a smart Reserve is a development investment, not a driver decision.

Four 15-lap runs on four components = up to +20 potential points per weekend, every weekend, for the price of the maintenance.

The gain is applied to every part in your inventory of that component with the same version as the one fitted on the mule — so the head-room lands on the race cars’ parts too, not just the mule’s.

This is the main way a mid-grid team creates overdrive capability: potential above the 100-point mark is what unlocks the blue and purple Improve bands. See R&D — Improve.


The report mail

Every round with a plan produces one “Private testing report” from the Chief Engineer — results when it ran, the blocker when it idled. The programme used to be completely silent, which was unreadable: potential gains are invisible unless you open Improve, and a missing Reserve made the whole thing a no-op nobody could see.

A successful report names the venue, the driver, the laps and kilometres, then lists each development programme’s potential points, the maintenance WU reserved, and a reminder that discovery and the structural ledger both ran.


Advanced

  • Run the mule on your current spec. Discovery is keyed to the version fitted on the mule. Testing last year’s v1 floor teaches you nothing about the v3 you race.
  • Size the plan to the 50% cap, not to the lap cap. On a 5 km circuit the reserve stops growing at 500 km. Laps beyond that are free discovery mileage — but they still age the mule.
  • Split runs across components rather than stacking laps. Four 15-lap runs on four parts beat one 30-lap run on one: lap_frac is already maxed at 15.
  • Potential caps at 1.18. Once a part’s potential hits the ceiling, further development runs on it are wasted. Rotate the target.
  • A Reserve is three jobs in one: mule driver, development multiplier, and injury cover. Weight Intelligence heavily when signing one — see Scouting.
  • The reserve competes with your repairs. On a heavy-damage week, a 40 WU mule reserve out of a 100 WU pool leaves 60 for a repair bill that may be 80. Shrink the plan for that round rather than letting it idle.
  • Break weekends are free testing. The pool is 2–4× larger on a regulation or season break, so the same plan reserves the same absolute WU but a much smaller share — a Full-severity GP 5 effectively gives the programme away.
  • Build the mule in pre-season. Production delivers instantly at standard price there; a third set of parts is the cheapest it will ever be.

Common mistakes

  • Setting a plan without signing a Reserve. The tab renders, the numbers look right, and the programme never runs. Check the header card is not red.
  • Building two cars and forgetting the third. IdleMuleNotBuilt — the plan is configured but there is no car under it.
  • Running 30-lap development stints. Half the laps buy nothing. Cap at 15 unless you want discovery kilometres.
  • Wondering where the Engineering WU went. The reserve is shown as spent in the gauge, on purpose. It is not a display bug.
  • Leaving a big plan running through a crash-heavy stretch. The reserve is taken before your repairs, and the wall only blocks growth, not an already-saved plan. Trim it when the damage bill spikes.
  • Expecting performance from the mule programme. It buys potential, not current_perf. You still have to spend Improve WU to convert head-room into pace.

See also