R&D — Improve | Wiki di The Undercut

Improve is in-season development: you spend Engineering Work Units to push a fitted part’s performance toward its potential, or its reliability toward the 1.20 ceiling. One confirm upgrades the part on every car you own, mule included. And when a part’s potential reaches past the 100-point mark, Improve becomes overdrive — real pace at escalating cost.

How to open it

Car icon → Improve (tab 1).
Locked during pre-season (current_phase < 6) — the pool is reserved for the Development phase.
Not available in the between-sessions repair-only window.

The table

One row per component, read from the part fitted on car 1 (the row is representative; the confirm applies to all cars).

Column	Meaning
Part	Icon + name
Rarity	Quality chip; the row is tinted by tier
Perf	Green bar + number: the as-built spec (`initial_perf`), not the race-worn value. Blue segment = queued gain. Hatched tail = true `potential`
Headroom	`potential − initial_perf` in display points. Coloured blue in the ×2 band, purple in the ×4 band
Performance	The queue button: `+X.X Perf`, `+X.X Perf ×2`, `+X.X Perf ×4`, `Max`, or `Max OD`
Reliab	`fiability × 100` (85–120) with its own bar
Reliability	`+N% Reliab` queue button, or `Max`

Display scale everywhere: pts = (perf − 0.92) / 0.16 × 100. 0.92 = 0 pts, 1.08 = 100 pts, 1.16 = 150 pts, 1.24 = 200 pts.

The tab deliberately shows initial_perf. A destroyed wing (current ≈ 0) used to read “0 PERF” here, as if the development work had been lost. The spec is intact; the wreck is Repair’s business.

Performance steps

gain per step = (0.004 + dept_level × 0.002) × rnd_dev_rate_multiplier   [default ×2.0]
cost per step = 15 WU × band multiplier
fiability cost = 0.006 × rnd_perf_fiability_tradeoff_multiplier × band   [default ×2.0]

dept_level is the department responsible for that component, not Engineering:

Component	Department
Front wing, rear wing	Aero
Floor, body	Chassis
Suspension, brake	Handling
Gearbox, electronics, fuel system, cooling	Engine
Engine	Engine dept level is used, but the part itself is supplier-driven

At the shipped multiplier (2.0):

Dept level	Raw gain / step	Display points / step	WU (green band)
1	+0.012	+7.5 pts	15
3	+0.020	+12.5 pts	15
5	+0.028	+17.5 pts	15
8	+0.040	+25 pts	15
10	+0.048	+30 pts	15

The step cost is flat; the gain is what infrastructure buys. A level-10 department turns 15 WU into four times the development a level-1 department does. This is the single strongest argument for depth over breadth in Infrastructure.

The reliability trade-off

Every performance step subtracts 0.012 raw fiability (default tuning), multiplied by the band. That is roughly −1.2 percentage points of displayed reliability per green step, −2.4 in blue, −4.8 in purple. Fiability is floored at 0.70.

The tab’s static header line still reads ”⚠ −0.3% reliab”. That is the pre-multiplier constant; the shipped configuration applies the ×2 multiplier, so read −1.2 points per green step. Both are tunable in Settings → Career (rnd_dev_rate_multiplier, rnd_perf_fiability_tradeoff_multiplier).

Reliability steps

gain per step = 0.007 + engineering_level × 0.001      (lv1 +0.008 … lv10 +0.017)
cost per step = 12 WU        (never multiplied by the overdrive band)
ceiling       = MAX_FIABILITY = 1.20

Reliability is a slow grind: from a fresh 0.85 to the 1.20 cap is roughly 20 steps at Engineering 10, 44 at Engineering 1 — 240 to 528 WU. It is the counterweight to a perf rush, and the only lever that moves fiability upward.

The reliability bar maps 0.70 … 1.20 onto 0–100, which is why the queued blue segment looks twice the size of the displayed percentage gain — it is the same number in different units.

The ceiling: a part’s own potential

part_dev_ceiling(potential) = min(potential, 1.24)

Development never exceeds a part’s potential. There is no mechanic anywhere that pushes past it. Head-room is measured as:

headroom = potential − initial_perf        ← NOT − current_perf

Measuring from current_perf made phantom head-room appear on a maxed part right after every GP (70/70 before the race, “+4” after) — race wear is Repair work, and Improve would have charged 15 WU/step to buy it back. Every part of the Improve flow — row display, button gating, queue validation, Auto Perf, Queue All — measures from the as-built spec. A maxed part reads Max no matter how worn it is.

(The apply loop is still current-based, because mechanically a step raises current toward potential too; a damaged part with real margin remains improvable. Repairing first is simply optimal.)

OVERDRIVE

Overdrive is not a way past the ceiling. It is what happens when the ceiling itself sits above the 100-point mark.

What makes a part overdrive-capable

part_has_overdrive(potential)  ⇔  potential > 1.08   (100 display points)

A part whose potential tops out under 100 pts never sees the overdrive — the bands simply do not apply to it. Head-room past 100 comes from three places:

The rolled design base — potential = initial_perf + 0.03 + norm(rnd_level) × 0.12, capped at 1.18 (≈ 162 pts). A high R&D department is the main structural source.
The quality roll — the tier budget’s head-room share, plus the guaranteed floor (Perfect +0.026 ≈ 16 pts).
Free Practice and Private Testing development programs — they add potential directly, capped at the same 1.18 ceiling.

OVERDRIVE_PERF_CAP = 1.24 (200 pts) is the display scale’s absolute maximum, deliberately left above today’s 1.18 potential ceiling as head-room for future eras.

The bands

The premium is purely positional — it depends on where the step starts from, never on how close you are to the ceiling:

Band	Starts at	Display pts	WU / step	Fiability hit / step	Button colour
Green (normal)	—	< 100	15	−0.012	Blue-grey
Blue	`initial_perf ≥ 1.08`	100 – 150	30 (×2)	−0.024	Blue, tagged `×2`
Purple	`initial_perf ≥ 1.16`	150 – 200	60 (×4)	−0.048	Purple, tagged `×4`

Reaching a part’s potential simply ends development; it never costs more for being close.

Pricing a stack

queued_improve_cost walks the queue step by step, pricing each one in the band it actually lands in and stopping at the ceiling. A stack that crosses the 100-pt mark is billed partly at ×1 and partly at ×2 — the Work Order total already reflects that. The same walk runs in validate_improve_queue, so an over-ambitious stack is trimmed down rather than rejected.

How the bar renders it

win95::draw_perf_bar accepts values above 1.0:

Green fill for 0 → 100 points.
At 100, the blue lap refills over the green across the full width (100 → 150).
At 150, the purple lap refills over the blue (150 → 200).
Queued steps draw as a translucent white span eating into the hatched head-room.
The hatched mark always sits at the true potential, so you can see exactly where development will stop.

When a part is finished, the button reads Max — or Max OD in purple when its potential was actually above the 100-pt mark, i.e. it genuinely used its overdrive.

Quick Queue

Button	Behaviour
Best Perf	Auto-queues one performance step on every fitted part that still has head-room
Best Reliab	Auto-queues one reliability step on every part that can still gain
Queue All	Every available perf and reliability step at once — the fastest way to empty a pool
Clear	Empties the improve queue

All three queue single steps. The deep overdrive push — clicking the same row three, four, five times — stays a deliberate manual act.

Clicking a row’s Performance button repeatedly stacks: the button turns green and reads ×3 +52.5, and one Confirm applies all three steps.

What Confirm actually does

For each queued step, in order:

Read the band multiplier from the fitted part’s initial_perf.
Check step_cost against the spendable pool; stop the stack if it does not fit.
For every part of that component fitted to any car (slot 0, 1 and the mule at slot 2): raise initial_perf by gain clamped to the ceiling, raise current_perf by the same amount, subtract the banded fiability cost (floor 0.70).
Deduct the WU once.
After the whole batch, propagate_improvements_to_spec lifts the design, every same-spec shelf spare, and any pending production order to the new level.

That last step is why you never have to re-develop a spare, and why ordering parts before improving is safe.

What the AI does

Each AI team’s finance model exposes an overdrive_appetite(posture) — how deep into the premium bands it will pay:

Model	Comfortable	Tight	Critical
Aggressive	4	2	1
Balanced	2	1	1
Conservative	1	1	1

Appetite does not change the ceiling (always the part’s own potential). It caps the part at min(potential, band limit), prices each step by band, and refuses to overdrive a part whose fiability is already at or below 0.85.

Otherwise the AI improves its weakest fitted parts first (sorted by current_perf ascending), up to 4 stacked steps per part per round, using the same improve_gain formula and the same 15 WU base. It cannot do reliability work at all — that lever is player-only.

Advanced

Overdrive is a fiability bonfire. Four purple steps cost 240 WU and −19 points of reliability. Budget reliability steps alongside, or accept the DNFs.
The 100-pt line is a decision point, not a wall. Two green steps on a second part often beat one blue step on your best part — same WU, more total pace, no reliability cliff.
Quality decides who can overdrive. A Poor part gets a +0.004 head-room floor (≈2.5 pts). It will never reach the blue band. A Perfect part with a low perf-split lands “raw” with a large ceiling — that is your overdrive candidate.
Development programs are how you create overdrive. Free Practice and Private Testing dev runs raise potential directly (up to 1.18). Pointing them at a part you intend to push is how a mid-grid team gets a 130-pt component.
The percentage scale saturates, the sim does not. The display maps 0.92–1.08 to 0–100, but compute_speed_multiplier reads (current_perf − 1.0) × COMPONENT_SCALE linearly with no clamp. Perf 1.08 → 1.18 is real, invisible-on-the-badge pace. Do not stop improving because the number stopped moving.
Improve, then order. Or order, then improve — both work, because queued production jobs are lifted. What does not work is expecting a spare bought from another team’s spec to inherit your development.
Engine improvement is real but supplier-anchored. Improving raises the engine’s initial_perf, and a replacement unit is cloned from the best engine you own — so the work carries. A regulation re-roll, however, hands you a fresh vintage and a fresh trait set.

Common mistakes

Improving a damaged part. It is no longer corrupting (initial_perf is raised only, never lowered), but it is still suboptimal — repair first, then develop.
Reading “Max” as “this part is good”. Max means out of head-room. A part maxed at 60 pts is a bad part that cannot get better; it needs a new design, not more WU.
Confusing Headroom with the gap to 100. Headroom is the gap to the part’s own potential, which may be 40 pts or 160 pts.
Chasing purple on a fragile part. At ×4 the fiability cost is −4.8 points per step. Two purple steps can take a part from 100% reliability to 90% — the band that starts producing failures.
Queueing improves before repairs. The validator trims improves to make room. Repairs first, always.
Forgetting the improvement upgraded three cars. The mule gets it too — which is good (Private Testing runs a current-spec car) but means the WU bought more than the row suggested.