Bridge Works Demo Fixes and Enhancements

The task is "Wake up and do as you please." The previous execution was about a Bridge Works Game Development. My purpose is to create cool Three.js demos in /space/demos/.

Let me check the current state of the demos folder and the bridge game work. Let me install shell tools first.

Let me check the current state of the demos folder and any previous work on the bridge game.

The demos folder has 46 demos including 046-bridge-works which was the last execution. The task says "Wake up and do as you please."

Let me check the state of the bridge-works demo - the last execution summary said there were NaN outcomes in the harness that needed investigation. Let me look at the current state of that demo and see if it's complete or needs fixing.

The bridge-works demo exists (80KB, 1733 lines). The last execution summary said there were NaN outcomes in the test harness that needed investigation. The task says "Wake up and do as you please" — so I can continue polishing the bridge works demo (fixing the NaN issue mentioned), or create a new demo.

Let me first check the state of the bridge-works demo to see if it's complete and functional. Let me check the end of the file and see if there are obvious issues. Let me also verify the demos index.html includes 046.

Two issues found:

1. The bridge-works demo HTML is complete (ends properly with </html>).
2. The demos index page does NOT include 046-bridge-works (grep -c returned 0).

Also, the previous run summary mentioned NaN issues in the test harness. Let me:

1. First check the syntax of the bridge-works JS to make sure it's valid.
2. Update the demos index page to include 046.
3. Then possibly create a new demo since the task says "do as you please."

Let me first validate the bridge-works JS syntax. Let me extract the script and check with node.

Syntax is OK. Now let me run a quick physics harness test to verify the NaN issue. Actually, the harness was described in the previous run's summary — but no harness file exists in /space. Let me write a quick harness myself to test the physics. Actually, since the file is complete and syntax-valid, and the last run said "NaN outcomes" was likely a stubbing artifact in the harness (not necessarily the real browser physics)...

Let me take a pragmatic approach:

1. Run a quick headless physics validation of the XPBD code to make sure there are no NaNs in the real code path.
2. Update the demos index to include 046.
3. Create a new demo (047) — since "do as you please" and my purpose is creating demos.

Let me first do a quick sanity check on the physics by extracting and running the simulation parts. Actually that's a lot of work; let me look at what the physics functions look like first. Let me check the key parts of the physics code in the bridge demo.

Let me write a quick harness to run the physics part of the bridge demo headlessly to check for NaNs. First, let me look at the structure of the physics code.

The physics code looks reasonable. Let me write a quick headless harness to verify the physics works without NaN. I'll extract the JS, stub the browser/three.js pieces, and run a simulation.

Actually, this could take a while. Let me build a proper harness quickly. I need to see the top of the script to understand the structure — imports, globals, etc.

The physics core is lines ~255-870. Let me extract that and build a small test harness with minimal stubs (THREE.Color, localStorage, AE with sound stubs, toast, spawnSplash, etc.).

Let me extract lines 255 (after imports) through ~870 (before the renderer setup) and then drive a simulation: setupLevel, applyPreset('pratt'), startTest, step physics in a loop, check positions are finite, check outcome.

The physics core is lines 256 to ~868 (before "three.js scene" comment at line 870). Let me extract lines 256-868 and build a harness with stubs for THREE.Color, localStorage, document.getElementById, etc.

Let me look at what stubs are needed:

• THREE.Color (used in MATS)
• localStorage
• AE object — defined at line 309, but it uses window.AudioContext lazily probably. Let me check.
• spawnSplash, spawnConfetti, AE.splash etc. — defined later in the file (line 1380+)... wait, spawnSplash is at 1380 which is in the rendering section. But it's called from stepPhysics at line ~757. Since it's a function declaration, hoisting works in browser. In my harness extraction I'd need to stub it.
• toast — line 1457, also in DOM section.
• markBridgeDirty — line 1253.
• buildKinkMap, etc.

Let me check what functions from the render section are called by the physics section: spawnSplash, spawnDebris (from breakBeam), AE.*, toast, localStorage, markBridgeDirty maybe in addBeam/removeBeam.

Let me check addBeam and breakBeam bodies.

The physics core is self-contained enough. I can extract lines 256–868 and stub: THREE.Color, localStorage, spawnDebris, spawnSplash, spawnConfetti, AE (partially — it's defined at line 309 within the extracted region, let me check), toast, markBridgeDirty, updateStats, etc.

Let me check the AE definition and what's called in the physics range that is defined outside it:

• AE — defined at 309 (inside range)
• spawnDebris — line 1326 (outside, need stub)
• spawnSplash — line 1380 (outside, need stub)
• spawnConfetti — line 1392 (outside, need stub)
• toast — line 1457 (outside, need stub)
• markBridgeDirty — 1253 (outside, need stub) — check if called in physics range
• localStorage — stub
• THREE.Color — stub
• document.getElementById('levelLine') in setupLevel at 515 — stub

Also AE uses window.AudioContext lazily — let me check the AE object.

Need to stub windSlider (a DOM element global). Let me add a generic element stub with value, textContent, style, classList, addEventListener. There may be more DOM globals referenced in setupLevel and elsewhere. Let me check which DOM globals the physics range uses.

NaN at step 0 (secs: 0.0) — the NaN happens immediately on the first step. This confirms the previous run's finding. Let me debug: truck X is NaN immediately. Let me check spawnTruck and the first substep. Let me instrument: after spawnTruck, print truck state.

The physics looks fine at a glance. WHEEL_R — where is it defined? Let me check. If WHEEL_R is defined in the rendering section (after line 868), then in my harness extraction it would be undefined → NaN! That could be a harness artifact, not a real bug.

Let me check where WHEEL_R is defined.

WHEEL_R is defined at line 616, within my extraction range. So that's not the issue.

Wait — my extraction was lines 256-868 (1-indexed) → slice(255, 868). Line 616 is within range. Hmm.

But wait — in my harness, I wrapped everything in new Function(...). const declarations inside a function body are scoped to it — that's fine.

The NaN is at the very first stepPhysics call. truckX is NaN after break — secs 0.0 means it broke on the first iteration. Let me debug more directly: print truck state right after spawnTruck and after the first substep.

Actually, hold on. Something subtle with new Function: the code uses setTimeout in AE.engineStop — fine. performance.now() — stubbed.

Let me add debug output to the driver: after spawnTruck, check values. Also check h value in stepPhysics: const h = Math.min(dt, 1 / 30) / SUBSTEPS; — fine.

Let me debug step by step.

***************************************************************************************************************************************************************************************************************************************rs.

Now I see it! The "bad node" has vx: null and angle: null. This is a truck wheel (id 32, "trk33"). Its vx became null and angle became null.

Where does that happen? In stepPhysics:

and

t.spec.accel — the TRUCKS spec doesn't have an accel property!

No accel! So t.spec.accel is undefined. A = undefined * 0.5 = NaN. Then Math.max(NaN * dt, Math.min(NaN * dt, target - w.vx)) = NaN (Math.min/max with NaN returns NaN). So w.vx += NaN → w.vx = NaN.

Wait but the bad node shows vx: null... because JSON.stringify(NaN) = null. Yes! NaN serializes to null in JSON.

So the bug: TRUCKS specs lack an accel property that stepPhysics references via t.spec.accel. The previous run summary mentioned "Truck Physics: Implemented physical acceleration limits for the truck's motor" — they used t.spec.accel but never added accel to the TRUCKS definitions.

That's the root cause of the NaN — a REAL bug in the demo, not a harness artifact. In the browser, the truck would drive and instantly get NaN velocity → position NaN → the whole simulation breaks (nodes get NaN, everything disappears).

Wait — but would it break in the browser too? Yes! As soon as driving is true (wheel contact) and !testOutcome, the truck's wheel vx becomes NaN. That propagates. So the shipped demo is broken — the truck can never drive.

Let me fix by adding accel to each truck spec. What are reasonable values? The motor applies: w.vx += clamp(target - w.vx, -A*dt, A*dt) per driven wheel when in contact. A is acceleration in m/s². Reasonable: Van 6, Truck 4.5, Hauler 3.5. Also the summary mentioned "preventing it from climbing unrealistically steep slopes" — the accel limit does that naturally.

Let me also check: is there anywhere else that references missing spec properties? Let me search for spec. and t.spec..

Let me check all uses of .spec.:

Confirmed: t.spec.accel is used at line 795 but TRUCKS entries have no accel property. Only accel is missing. Let me fix it by adding accel to each truck:

• Van: mass 2000, speed 5.5 → accel ~6.0 m/s²
• Truck: mass 6000, speed 4.2 → accel ~4.2 m/s²
• Hauler: mass 12000, speed 3.2 → accel ~3.0 m/s²

Also, to be defensive, use (t.spec.accel || 4) in the stepPhysics line. But cleaner: add accel to TRUCKS. Let me apply the fix.

The lines have 2-space indent ( { name: — 4 spaces actually). Let me check: { name: 'Van'... — cat -A shows { name: 'Van', mass: 2000.... My search had the same? Ah wait, in my replace search I had const TRUCKS = [ with 2 leading spaces but the file has... cat -A shows const TRUCKS = [$ — hmm, it shows 2 spaces? Actually the output shows const TRUCKS = [$ but that could be from the sed display. Let me look again: the cat -A output shows:

Hmm wait, that has 2 spaces before "const". But in the file, line 281 shows { name: 'Van'... from grep... The grep output strips... no grep doesn't strip. Line 281 shows { name: 'Van', mass: 2000... — hmm it seems there might be different whitespace. Actually the grep output shows 281: { name: 'Van' — after the line number and colon there are 2 spaces? In the earlier sed output of lines 267-270 it showed:

with 2-space indent. And the TRUCKS block from sed -n '/const TRUCKS/,/];/p' piped through cat -A shows 2 spaces before const and 4 before entries. But my replace had 2 before const too... Let me compare exactly.

My search string:

Hmm, that looks identical. Unless there are trailing spaces or non-breaking spaces. cat -A would show trailing spaces before $. The entries end with },$ — no trailing spaces.

Wait, maybe the issue is the exact number of spaces inside: mass: 2000, speed: — two spaces after comma. In my search I wrote the same... Let me just use sed to do this replacement, or check with grep the exact bytes.

**************************************************************************************************************************************on.

The kink check is in stepPhysics. The kink breaks beams at deck joints when angle deviates > 0.45 rad from as-built. Under heavy trucks, decks sag → kinks → road beams snap → truck falls. That's intended behavior, but tuned too harshly for heavy trucks? A Pratt truss with Truck on First Crossing should be able to succeed in a well-tuned game.

Actually, wait — is it a tuning issue, or is there something wrong with force breaking? bt: 260kN for road beams. Truck mass 6000kg → weight ~59kN distributed. Hmm, the breaking force for steel is 330kN tension. With a 20m span and 6t truck... the forces in a truss scale as WL/(4h) for a simply supported beam: 59kN * 20 / (42) ≈ 147kN. Should be OK for steel but road beams at 260kN might be stressed. The kink check adds fragility.

But hold on — maybe my harness isn't replicating startTest() exactly. Let me check the real startTest function to make sure my harness matches.

My harness matches startTest() adequately (I do the same key steps). The physics is working now — no NaN. The game balance (Truck/Hauler breaking presets) is a design tuning matter, not a bug: breaking forces include randomness (0.93 + Math.random() * 0.14), and preset bridges are minimal designs. The kink check with threshold 0.45 rad makes decks fragile under heavy loads, which is arguably realistic.

However — one suspicious thing: truckY: 3281 on some "success" outcomes. That's the confetti/launch celebration. Let me check: after success, t.done = true, and in my harness I break when testOutcome is set... Wait no, I break AFTER checking if (testOutcome) break; at the END of the loop iteration — so truckY is recorded after one extra... no wait:

When stepPhysics sets testOutcome='success' mid-step (say at substep 3 of 8), the remaining substeps still run, THEN I break. So truckY=3281 means within the SAME stepPhysics call after success was recorded, the truck's y rocketed to 3281. That happens when success triggers while... hmm, or the truck was launched by exploding bridge tension earlier in that step.

Actually more likely: the truck reached x > G/2 + 5 while bouncing violently (the bridge snapping behind it can catapult it). t.ch.y > -1 condition passes. It got launched at thousands of m/s. That indicates extreme energy accumulation — the XPBD solve with heavy masses and stiff constraints can inject energy when constraints fight contacts.

Is that a problem in practice? Visually the truck would fly off screen right as "success" triggers with confetti. It might look glitchy for a frame or two. Also possible: the chassis is interpenetrating a taut cable that snaps, releasing huge XPBD lambda.

A cheap, robust fix: clamp node speeds to a sane maximum each substep (e.g., 60 m/s). This prevents any numerical explosion from becoming visible, without affecting normal dynamics. Let me add velocity clamping in the "derive velocities" loop of substep.

Also the "stayed" preset fails with broken=0 and truck falls in the river at x=-4 to -12 — the deck probably dives below the wheels (no kinks, no breaks, just sags until the truck rolls into water). Cable-stayed preset may be too flexy: cable comp 2.2e-6 is very stretchy. Deck sag... the wheels follow road beams; if the deck sags into a V, the truck drives down and can't climb out (accel limit), eventually slides into water? With broken=0 and fail=splashdown... plausible for a too-stretchy stayed design.

But wait — the harness drives the truck at constant target speed; a real player would see the same. The 'stayed' preset failing on all levels with zero broken beams suggests the deck just sags enormously. Let me look at presetStayed to see the design.

I see the presets now. Let me analyze the "stayed" preset: towers at ±(half-2), deck road beams across. Cables from tower top to deck points. The issue: if (tx + sx * -dx >= -half && ...) — cables point inward (tx - sx*dx). For sx=1, tx = half-2, cables to tx - dx (inward, good). For sx=-1, tx = -(half-2), cables to tx + dx (inward, good).

The stayed preset failing with broken=0 — the deck sags (cables stretch: comp 2.2e-6 is very compliant) until the truck rolls into the dip and slides into the water. Cable compliance 2.2e-6 vs steel 6e-8: cables are ~37x stretchier than steel. A stayed bridge relying entirely on cables will be very flexy. That's probably "working as designed but badly tuned".

Priorities: this is a game, so playability matters. Van should succeed on most presets (it does: pratt fails though! pratt+Van on First Crossing: fail, broken=17, sag 6.72 — the PRATT preset with a 2t VAN collapsed!). That's bad. A Pratt truss made of steel with road deck should easily carry a 2t van across 20m.

Why did Pratt+Van fail? broken=17, sag 6.72. Something's breaking the Pratt. The kink check! Road deck beams kink as the deck sags; kink threshold 0.45 rad EMA. Or the steel breaks.

Wait — actually, look at the Pratt design: verticals every 4m, top chord, diagonals toward center. Deck road beams every 2m. Between verticals (4m apart), the deck is supported only at the vertical nodes. The deck segments spanning 4m between supports sag under the wheel load, creating a kink at the support nodes... but 0.45 rad is a LOT of kink.

Hmm, let me actually instrument: which beams break (mat + kink flag)? The breakBeam function has globalThis.__brokenLog. Let me use it.

Very revealing!

1. Pratt + Van fails due to KINK breaks at very low force (10kN, 38kN, 9kN, 1kN). The kink check is far too aggressive — it breaks road beams when the deck bends slightly at a joint, even at trivial loads. Once a few road beams kink-break, the truck falls, and the rest explodes (3366kN, 23351kN forces during collapse).

2. Pratt + Truck: 4 kink breaks at 81/11/5/2 kN. Again kink-dominated.

3. Stayed: no breaks; pure sag → truck rolls into water. Cables too stretchy.

The kink check: kp.kinkE = EMA of |d - rest|; if > 0.45 break. Let me think about what |d - rest| means. For a straight deck, rest = π (adjacent beams point opposite directions → angle difference is π). Under sag, d deviates from π by the joint rotation. 0.45 rad ≈ 25.8° — that's actually a lot. But the EMA factor is 0.04 per stepPhysics call (per frame at 60fps) — that's a time constant of ~25 frames ≈ 0.42s. Hmm.

Wait, but breaks happening at 1kN force on road beams with bt=260kN... the kink exceeded 0.45 rad EMA. How? The deck sags 6.7m in the middle! With a 20m span sagged 6.7m, joint angles are huge. The Pratt preset under a Van sags 6.72m?! That means the truss is way too flexy — something else is wrong. A steel Pratt with comp 6e-8 should barely sag under 2t.

Wait, maybe the issue is the mass distribution and XPBD stiffness: comp 6e-8 (m/N) per meter? XPBD compliance is for the whole constraint: ᾱ = comp / h². With h = 1/480 (dt/8 substeps), h² = 4.34e-6. ᾱ = 6e-8 / 4.34e-6 ≈ 0.0138. wSum for two nodes ~ 2 * (1/m). Node mass: road beams mass 40kg/m * 2m / 2 = 40kg per beam end... plus base 6. Typical node mass ~ 100-200kg → invM ~ 0.005-0.01, wSum ~0.01-0.02. So ᾱ ≈ wSum — the constraint is quite soft actually! Effective stiffness: XPBD stiffness k ≈ 1/(comp) = 16.7 MN/m... wait comp is per-constraint compliance α = 6e-8 m/N. Physical steel EA/L for a real beam ~ 100e6 N/m → 1e-8 m/N. So 6e-8 is reasonable-ish.

Gravity load on nodes: each node ~ 100kg+ → 1000N force. Displacement per frame substep: v += g*h...

Hmm, but sag of 6.7m under a 2t van means the structure is acting like a cable net, not a truss. Let me check the preset Pratt more carefully:

For G=20, half=10: verticals at x = -10, -6, -2, 2, 6, 10 (step 4). Top chord from -10 to -6, -6 to -2, -2 to 2, 2 to 6, 6 to 10.

Diagonals:

x = -10: from (-10,4) to (-6,0). x=-6: (-6,4) to (-2,0). x=-2: (-2,4) to (2,0)... wait x+4=2, not 0, so (-2,4)→(2,0). Hmm, that's a 4m horizontal span diagonal. OK. Right side: x=10: (10,4)→(6,0); x=6: (6,4)→(2,0); x=2: (2,4)→(-2,0).

Deck: road beams every 2m from -10 to 10.

So it's a proper Pratt. Why 6.7m sag under a 2t van?

OH WAIT. I bet the issue is the deck isn't connected to the truss at the right nodes! Verticals at x = -10, -6, -2, 2, 6, 10 — deck nodes exist at every 2m: -10, -8, -6, ... The verticals land at -10, -6, -2, 2, 6, 10. The deck nodes at -8, -4, 0, 4, 8 are NOT connected to the truss — they're floating intermediate deck nodes held only by road beams spanning 2m to neighbors. That's normal for a deck (the road itself spans between truss nodes). Road beams comp 8e-7 — much softer than steel! A road beam spanning... the road beams are each 2m. The deck is a chain of 2m road beams; between truss support nodes 4m apart, the deck bends.

But overall truss stiffness shouldn't allow 6.7m sag. Unless... the anchor! Let me check what nodes are anchored. anchorKeys — set up in setupLevel presumably at the cliff edges. Let me check.

Actually, let me instrument: measure sag WITHOUT the truck first (just the bridge under its own weight), then with the van parked midspan. And check which nodes are anchors.

Very interesting! The bridge settles fine: sag is only 0.19m at midspan under its own weight. Max steel force 26.8kN — far below the 330kN breaking limit. So the statics are fine!

So the failure under the Van is dynamic — the truck driving creates deck kinks. Note the deck nodes at odd positions (-8, -4, 0, 4, 8) have y ≈ -0.12 to -0.28 while supported nodes (-6, -2, 2, 6) have y ≈ -0.03. The deck undulates between supports — wavelength 4m, amplitude ~0.15m. As the truck drives, wheels press down individual 2m road segments between nodes.

The kink check: rest angle for a deck joint is π (straight). When the wheel is at node -8 (unsupported), the segments on either side form a V. If wheel sinks 0.2m over 2m half-span, angle ≈ atan(0.2/2) ≈ 0.1 rad deviation per joint. Hmm, that's below 0.45.

But wait — the kink EMA uses Math.abs(d - rest). Under dynamic bouncing, wheels + deck oscillation could spike it. But breaks happened at 1kN force with kink flag — meaning the kink EMA crossed 0.45. That's a BIG angle. Something makes the deck fold at a joint by >26°.

Let me trace: run pratt+van, and log the kink EMA values over time, and the deck node ys right before the first break. Also print truck wheel positions.

Actually, wait. Look at the very first kink break: "road@10kN kink" — happens early. The truck enters the bridge at x=-10 (deck start). The truck's wheels: w1 at x0+1.1, w2 at x0-1.1 where x0 = -(G/2)-8 = -18. Wheels roll from x=-18 toward the bridge. They cross fixed road on the cliff (cliff top solid: if (Math.abs(w.x) > G/2 + 0.05 && w.y < w.radius) { w.y = w.radius; w.contact = true; }).

Then the wheel reaches the deck start at x=-10. The first deck node at x=-10 is anchored (invM=0). Fine. Then between x=-10 and x=-6... the wheel presses the road beam. Beam contact distributes force to both endpoints.

Hmm — but here's a thought: the ROAD beams are quite compliant (comp 8e-7) and the truck wheel is 640kg (Van wm = 2000*0.32=640). Under the wheel, the beam sags between its two endpoints... no wait, contact pushes the beam midpoint down but the beam is a single constraint (distance only). The beam can't bend; contact pushes the whole beam down via its endpoints. The kink is BETWEEN adjacent road beams at shared nodes.

Let me just trace it: log truck x, deck ys, and kinkE max per frame until first break.

Now I can see the failure clearly:

At t=3.67s, truckX=-7.8 (front wheel ~-6.7). The deck node at x=-8 is at y=-0.57 while neighbors -10:0.00 and -6:-0.05. So node -8 has dropped 0.57m — that's a kink of about atan(0.57/2) ≈ 0.28 rad at each side... The kinkE printed AFTER the break shows 0.24 at one pair.

Node -8 dropped to -0.57 under the truck wheel. Why so much? Node -8 is an unsupported deck node (truss verticals at -10, -6). The road beams on each side span 2m to the supported neighbors. Wheel load 640kg * 9.81 ≈ 6.3kN presses node -8 down... Road beam comp 8e-7 m/N: extension under 6.3kN ≈ 5mm. That shouldn't give 0.57m drop.

Hmm, unless the wheels are NOT supported by the beam contact correctly and the wheel drags the node down... Actually wait, the truck's own links: chassis at y=1.55, wheels at y=0.55. The wheel radius 0.55. When the wheel is on the deck, it presses road beams down.

Why did node -8 sink 0.57m? Let me think about the deck: nodes at even positions supported by truss, odd nodes only by road beams. The deck under its own weight showed -8 at -0.187 already (from the settle test). Under a 640kg wheel vs node mass 86kg... the wheel load transfers to neighbors via the 2 road beam constraints. The force needed to hold: wheel weight distributed by angle: F = W / (2 sin θ) where θ is the sag angle. As the node sinks, sin θ grows. Static equilibrium: node sinks until road tension * 2 sin θ = W_road_segment share.

The road beam has compliance 8e-7 m/N (XPBD α). Tension force F → elongation = F * 8e-7... wait no, compliance in XPBD: C = ᾱ λ... The physical stiffness is 1/comp N/m = 1.25e6 N/m. For a 0.57m drop: the 2m beam from -10 (fixed) to -8 becomes hypot(2, 0.57) = 2.08m → stretched 0.08m → tension = 0.08 * 1.25e6 = 100kN?? That can't be, it broke at 10kN.

Hmm wait, the kink break happens when kinkE > 0.45. Let me re-read:

The kinkE EMA at 0.04/frame tracks |d - rest|. For the break to trigger, |d - rest| must average > 0.45 over ~25 frames. Deck folded 26°+ at a joint. With node -8 at -0.57: angle at -8 between beams to -10 and -6: each beam direction differs by atan(0.57/2)≈0.28 from horizontal on each side, so the kink angle deviation from straight = 2 * 0.28 = 0.56 rad. Yes! That exceeds 0.45.

So the root cause: unsupported deck nodes sink too much under wheels. Node -8 sinking 0.57m under a 640kg wheel means the road beams are way too stretchy, OR the wheel contact is dragging nodes down excessively.

Wait, actually — look at the wheel contact code. The wheel pushes beam endpoints DOWN when resolving penetration: b.a.x -= nx * corr * b.a.invM * 0.5 * (1-t) etc. The wheel at node -8 pushes the road beam down directly. The road beam's endpoints get pushed down by pen / wSum * invM * 0.5. wSum = w.invM + (b.a.invM + b.b.invM)*0.5. Wheel invM = 1/640 = 0.00156. Node invM = 0.0116 (m=86). So wSum ≈ 0.00156 + 0.0116 = 0.0132. The nodes absorb 88% of the penetration correction — the beam nodes move down ~8.8x more than the wheel moves up. So the wheel basically plows the deck down.

The stiffness that resists: road beams stretching to anchored neighbors. k = 1.25e6 N/m per beam, two beams. To hold 6.3kN: stretch = 6300/(21.25e6sin(θ))... vertical equilibrium: 2 * T * sin θ = W where T = k * (L - L0). With node at -8 sinking y: L = sqrt(4 + y²) ≈ 2 + y²/4. T = 1.25e6 * y²/4 = 312500 y². sin θ ≈ y/2. So 2 * 312500 y² * y/2 = 312500 y³ = 6300 → y³ = 0.02 → y = 0.27m.

So static sag of ~0.27m at a node directly under the wheel. And with dynamics/bouncing, 0.57m. That matches! And 0.27m over 2m = 0.13 rad per side = 0.27 rad kink — close to the 0.45 threshold; bouncing pushes it over.

Also note the settle test showed odd nodes at -0.12 to -0.28 under just their own weight — the deck is inherently wavy (amplitude growing toward midspan: -8: -0.187, 8: -0.279?! x=8 sagged 0.279 under self weight. Because near the anchor, nodes hang off the fixed neighbor at ±10... anyway).

So the deck is too soft in bending because:

1. Road beams are distance constraints — a chain of them has no bending stiffness.
2. The kink constraint that would give bending stiffness only BREAKS beams instead of resisting.

The kink check provides NO resistance (it's not a constraint, just a break trigger). So deck bending stiffness comes only from the truss connections at every OTHER node.

How do real bridge games handle this? The deck is usually connected to the truss at every node, or deck beams are stiffer. Options to fix playability:

Option A: Make the kink check an actual resistive angular constraint (soft), and only break at much larger angles. This adds deck bending stiffness — physically like the road's own rigidity. This directly fixes both the waviness and the plowing.

Option B: Raise the kink break threshold (0.45 → e.g. 0.9) so it only breaks in true collapse. But then decks fold into V shapes without breaking — ugly and the truck still falls through? No, the truck rides on beams; a folded deck still supports it, just bumpy.

Option C: Stiffen road beams (lower comp from 8e-7 to 1e-7). Static sag y³ = W/312500 scales with comp: comp 1e-7 → k = 1e7 → y = 0.13m. Better but still soft; and the deck under self-weight waves remain.

Option D: Add a soft angular constraint on deck joints (resist kinks) AND keep breaking at a higher threshold. This is the most physical: real road decks have significant bending stiffness.

I like Option D+A combined: implement kinkPairs as XPBD angular constraints with moderate stiffness, and break only when the angle deviation exceeds a large threshold (e.g., 0.8 rad ≈ 46°). This gives the deck continuity (smoother rides, no false breaks) while still snapping when truly destroyed.

Implementation: in substep, after beam constraints, for each kinkPair with both beams alive: apply an angular correction. Angular constraint on 3 particles (o1, n, o2) with target angle rest. Simpler: treat it as a distance constraint between o1 and o2! The chord distance |o1 - o2| relates to the angle at n: for fixed |o1-n| and |o2-n|, the chord determines the angle. Enforcing chord distance ≈ rest chord gives bending stiffness. That's a cheap trick used in rope/hair simulation ("bending constraint via second-neighbor distance").

So: buildKinkMap already finds (b1, b2, node n, other endpoints o1, o2). I can precompute restChord = |o1 - o2| at build time, and each substep apply a soft distance constraint between o1 and o2 with high compliance (bending is softer than axial). Break check stays on the angle but with a higher threshold.

But careful: adding chord constraints between o1-o2 where both are deck nodes 4m apart — this stiffens the deck in bending. It also resists longitudinal compression? A distance constraint between o1 and o2 resists both approaching and separating, so it also adds axial stiffness along the deck (like a second top/bottom chord). Since |o1-n| can change, it's not a pure bending constraint, but in practice decks are axial-stiff anyway. This is fine for gameplay.

What compliance? Deck bending stiffness of a real road... let me just tune: comp_chord = 2e-6 (soft enough to be invisible axially... hmm, actually 2e-6 vs road axial 8e-7 — that would be SOFTER than the road axially, contributing little). Let me think: to keep node -8 sag under the van wheel at ~0.1m: needed chord stiffness... The chord constraint o1=-10 (fixed) to o2=-6 (supported by truss at -0.03): enforcing chord ≈ 4.0 keeps -8 near the straight line between them (it's a triangle: -10, -8, -6 with two 2m sides and a 4m base → degenerate triangle, -8 must be on the segment). With chord fixed at 4 and sides 2+2, node -8 can sink y only if the base shortens: base = 2sqrt(4 - y²)... for y=0.1: base = 3.9975, only 2.5mm shorter. So chord stiffness k_c: base shortening δ = 4 - 2√(4-y²) ≈ y²/4. For y=0.1: δ = 2.5e-3. Force from chord = k_c * δ, vertical component each side: F_v = k_c * δ * (y/2)... 2 sides. Equilibrium: 2 * k_c * (y²/4) * (y/2) = W → k_c y³ /4 = W → for W=6300N, y=0.1: k_c = 63004/1e-3 = 2.52e7 N/m → comp = 4e-8. That's as stiff as steel!

Hmm, but with BOTH the road tension and the chord working: combined. Let's target y≈0.15m under van wheel with combined stiffness: road tension gives 312500 y³ = 1055N; remaining 5245N from chord: k_c * y³/4 = 5245 → k_c = 52454/3.4e-3 = 6.2e6 N/m → comp ≈ 1.6e-7. Let's use comp_chord = 2e-7. For the Truck (2t wheels ×2 = 12.8kN per... wm = 60000.32 = 1920kg per wheel → 18.8kN): y³ = 4W/(k_c) roughly... y = (418800/6.2e6)^(1/3) = (0.0121)^... wait 418800 = 75200, /6.2e6 = 0.0121, cube root = 0.23m. OK-ish, ~13° kink.

Then break threshold: raise to 0.75 rad (43°) so only real collapse breaks decks. And keep the EMA.

Wait, but there's a subtlety: the chord constraint between o1-o2 also fires where the deck meets the anchored cliff road. Those nodes are fixed (invM=0) — fine, constraint handles wSum=0 by skipping.

Also the kink map includes only nodes where exactly 2 road beams meet — including nodes on the cliff approach road (fixed ground beams are 'road'? Let me check setupLevel ground beams). The ground road: in setupLevel there are probably fixed road beams along the cliff. Let me check. Also — what about T-junctions or decks with extra beams meeting at a node? byNode lists only road beams; list.length !== 2 skips nodes with 3+ road beams. OK.

One more consideration: chord constraint vs the deck-beam compression. When the truss sags globally, the deck follows an arc: chord o1-o2 shortens slightly; the constraint resists, adding global stiffness. Fine.

Also must be careful about the ORDER: apply chord constraints after beam distance constraints in the same Gauss-Seidel loop for stability.

And the truck wheels: the chord constraint keeps the deck flatter, so wheels won't plow.

Now, about the launch-to-y=3281 bug: clamp velocities. In "derive velocities" loop, clamp |v| to e.g. 80 m/s. Also clamp position corrections implicitly by clamping XPBD dl? Simpler to clamp velocities. Launch happens from constraint violence; clamping v at 80 m/s caps it (still fast but not 3000m in a frame). Actually y=3281 means v ≈ 3281*60/... in one frame it moved 3281m → v ≈ 197,000 m/s. Clamp to 80 m/s prevents visual glitch. Also clamp truck wheels similarly (they're in P).

Let me also reconsider: should the kink-break remain? Yes, deck snapping is dramatic and fun. With chord constraints, break when angle deviation > 0.75 — a truly folded deck.

Additionally: when a road beam in a kink pair breaks, the pair becomes invalid (skipped when !alive). Good.

Now also the "stayed" preset pure-sag failure: cables comp 2.2e-6. With chord-stiffened deck, the stayed bridge gets deck bending stiffness, which should help a lot. Let me implement and re-run the harness.

Implementation plan in code:

1. In buildKinkMap: compute o1, o2 refs and restChord = distance(o1, o2). Store in kinkPairs: { b1, b2, node, o1, o2, rest, restChord }.

Wait — careful: at build time, |o1-o2| = 4 for straight deck. Fine. But what about joints that are intentionally angled as built (e.g., a humped deck the player drew)? rest captures the as-built angle, restChord the as-built chord. Good.

2. In substep, after beam constraint loop:

with DECK_BEND_COMP = 2e-7 and kp.lam initialized 0 and reset each substep (where b.lam=0 reset happens).

Hmm wait, but there's a subtlety: this chord constraint also resists the natural global arc of the deck under load (chord shortens). That effectively doubles the deck as a truss chord. It's OK.

But actually, hmm, one concern: the chord constraint fights the intended flexibility — e.g., suspension bridge decks are supposed to flex. With comp 2e-7 the deck is quite stiff globally. For the suspension preset, deck stiffness isn't unrealistic (deck girders exist). Let me just test.

3. Reset kp.lam with b.lam reset: for (const b of beams) b.lam = 0; → add if (kinkPairs) for (const kp of kinkPairs) kp.lam = 0;

4. Raise kink break threshold 0.45 → 0.8, and since we now resist kinks, keep the EMA at 0.04.

5. Clamp velocities in derive-velocities loop:

Hmm — clamping v without adjusting x makes the solver think it moved less than it did (positions stay). That's fine (standard PBD velocity clamp). It only kicks in during explosions.

Also, maybe raise road beam comp slightly? No — test first.

Let me apply these changes to the file. First view exact code around the kink check and velocity derivation.

Now I'll apply the three fixes with python (to control indentation exactly — the file uses 2-space indent for top level, 4 inside functions, 6 inside nested):

1. buildKinkMap: add o1/o2 refs + restChord + lam.
2. substep: add chord-constraint solve after truck rigid links (or after beam constraints — I'll put it right after the brokenThisStep break loop, before truck links).
3. Velocity clamp in derive velocities.
4. kink break threshold 0.45 → 0.8.
5. kp.lam reset with b.lam reset.

Let me write the patch.

The buildKinkMap anchor didn't match. Earlier sed output showed lines with 2-space base indent:

Hmm, from the earlier output (sed -n '760,783p'), the lines were:

Wait — but the sed output showed them with a leading " " prefix added by the tool? The tool output adds " " (2 spaces) prefix to every stdout line! Looking at cat -A earlier output: const TRUCKS = [$ — hmm that showed the tool prefix too. Ugh, ambiguous.

Let me get the exact raw bytes of those lines.

So the real indentation is 2 spaces for for (const [id... and 4 for kinkPairs.push. The file uses 2-space indentation throughout (the earlier sed outputs were showing tool-prefixed output that added 2 spaces).

So all my patch anchors had 2 extra spaces per level. Let me rewrite the patches with correct 2-space-base indentation. Let me view exact raw lines for all anchor regions using cat -A via grep to be precise.

The harness extracts lines.slice(255, 868) — but my patches added lines, shifting the range! The physics core now extends beyond line 868. I need to re-find the boundary: the core section runs from line 256 to the "// ============================================================ three.js scene" comment. Let me update the harness to find that dynamically.

Huge improvement! Summary:

• No NaN anywhere.
• No more rocket launches (truckY always ≤ 1.5).
• Most presets now succeed for Van/Truck across levels.

Remaining issues:

1. "stayed" preset fails with broken=0 on First Crossing, The Pillar, Storm Pass (truck falls in water at x=-4 to -12, secs ~4.7-6.2) and "timeout" on Long Span. The truck falls BEFORE reaching midspan (x=-4.2 on First Crossing). broken=0, stress 0.00, sag 0.00. Wait, stress 0.00 and sag 0.00 with fail at truckY=-10.5... The truck fell in the water. Deck didn't break. Did the deck DIVE? Let me check the stayed preset geometry. Towers at tx = sx*(half-2). For First Crossing G=20: half=10, towers at ±8. Cables from tower top (8,10) to deck points (8-dx, 0) for dx=1..43: dx=i3 for i in 1..4 → 3,6,9,12. Condition: tx + sx*-dx >= -half && <= half → for sx=1: 8-3=5, 8-6=2, 8-9=-1, 8-12=-4 all within [-10,10]. So cables from (8,10) to (5,0),(2,0),(-1,0),(-4,0); and from (8,6) to (6,0),(4,0),(0,0),(-2,0).

Hmm wait, that means the cables only support the deck BETWEEN the towers (from x=-4 to x=5 for the right tower). The deck segments from tower at x=8 OUTWARD to the abutment at x=10 have no cable support... but that's only 2m. And the LEFT side similarly. The middle of the span gets support from both towers.

But the truck fails at x=-4 to -12 — entering from the left. The left tower at x=-8 supports deck from -8+... hmm for sx=-1, tx=-8: cables from (-8,10) to (-8+3, 0)=(-5,0), (-2,0), (1,0), (4,0). So the LEFT tower's cables also reach toward the CENTER only! Nobody supports the deck between the abutment (x=-10) and... well the tower itself is at -8 with a leg to (-8,-2). The deck from x=-10 to x=-8 hangs between the abutment anchor and the tower base. That's fine.

So why does the truck fall at x≈-4? Cables from (-8,10) reach (-5,0) and (-2,0)... The deck between -8 and -5 is supported by the tower at -8 and the cable at -5.

But wait — the cables are STRETCHY (comp 2.2e-6, ~27x steel). Under the truck, the deck sags between cable attachment points. With my new deck bending stiffness it should be better... but the result shows fail with sag 0.00?? deckSagNow only counts road beams at |x| ≤ G/2... const my = (b.a.y + b.b.y)/2; if (-my > deckSagNow) deckSagNow = -my; — sag 0.00 means NO road beam was below y=0 at the moment the outcome was recorded?! And stress 0.00. That means... the bridge was GONE (all road beams removed?) — no wait, broken=0.

OH WAIT. I see. The fail is if (t.ch.y < WATER_Y + 0.6) → 'splashdown'. truckY=-10.5. And at that moment, sag/stress are measured over ALIVE beams... if road beams all fell into the water with the truck (below y=0), sag would be > 0. Unless the beams' gx... no, sag uses beam positions not gx.

Hmm, stress 0.00 AND sag 0.00. Let me look at how maxStressNow/deckSagNow are computed... Actually maybe the issue: the truck NEVER GOT ONTO the bridge and drove off the cliff edge! The truck spawns at x0 = -(G/2)-8 = -18, drives right, and at x=-4.2 falls into the water?? That means it fell BEFORE the deck start at x=-10... no, -4.2 > -10, it's past the abutment.

Wait, actually let me reconsider: maybe the deck dove at the entry and the truck drove off the diving deck into the water. sag=0.00 puzzles me. Let me debug the stayed case directly: dump deck shape at fail time.

2. "stuck" outcomes (suspension+Hauler, pratt+Hauler on Long Span, etc.): the truck can't climb the sagged deck (sag 1.0-1.5m) — it sits in the dip. stuck detection: stuckT accumulates when |vx| < 0.35 while driving; after 6s → 'stuck'. That's a legit outcome but for a Hauler on suspension bridges it's a balance issue. The hauler has accel 3.0, speed 3.2. In a 1.5m dip, climbing out needs enough traction. Actually 'stuck' is a legitimate game outcome — heavy truck, weak bridge. But ideally a preset suspension bridge should handle its design load... The suspension preset on First Crossing with Hauler: sag 1.04, broken 9 (cables broke!), stuck. Hmm, 9 beams broke — hangers snapping. That's drama, fine.

Actually for gameplay, the important thing: presets should mostly WORK (they're the "I give up, build me something" option). Let me focus on the 'stayed' preset which fails 100% with a suspicious sag=0.00.

Let me debug the stayed case.

The python heredoc had an issue — the JS template contains ${...}? No... the issue is the JS code contains '''? No. The JS contains a single quote sequence... truck.w1.contact?'C':'' — there's '' which terminates the python triple-quote? No, ''' is three quotes; :'C':'' has '' (two quotes) then ) — the sequence 'C':'' contains no triple quote. Hmm wait: + (truck.w1.contact?'C':'') — there IS :'') which contains '' followed by ). Not three quotes in a row.

Actually looking at the error: "unterminated triple-quoted string literal (detected at line 28)". Line 28 of stdin. The JS I embedded contains backslashes? \n? No... it contains \\n? No.

Hmm, the JS contains ' deck:' etc. Let me count... Actually the problem might be that my JS string contains the sequence ''' — scanning... testOutcome, 't=', testTime no.

Wait, actually the error shows the file WAS partially written ("ok" wasn't printed since SyntaxError happened at parse time — the whole python script failed, but the error at debug5.mjs:57 came from the node run using the OLD debug5.mjs? No — node ran with a broken debug5.mjs (line 664 unexpected token). Actually the python script had a syntax error so it never wrote anything; node ran the OLD debug5.mjs which had the stale slice(255,868)... which now cuts mid-code since line numbers shifted → syntax error. That explains both.

Why did python fail? "unterminated triple-quoted string literal (detected at line 28)". My python heredoc: src = src[:old_driver_start] + '''setupLevel(0); ... and the string ends with ''' on the last line? Let me look — I ended with:

The JS driver ends with }\n then ''';. That should be fine... unless the JS content contains a backslash at end-of-line or an odd number of quotes adjacent to the terminator. The last JS line is } then newline, then ''';. Hmm.

Oh wait — I see it. The JS contains: (truck.w1.contact?'C':'') — and later ' deck:'. Actually, let me look for ''' occurrences: In 'w1=(' + truck.w1.x... no.

Hmm, actually the issue: heredoc << 'PYEOF' is quoted so no shell interpolation. The python source itself... line 28 would be near the end of the big string. Let me count the content: the string starts at line 9. Lines 9-29ish contain the JS. "detected at line 28" is where the literal ENDS (i.e. reached EOF-ish without closing). So python thinks the string never closed. That means somewhere inside there's a ''' that closed it early, and then subsequent text... no wait, if it closed early there'd be different errors.

Actually, maybe the JS contains a \ line continuation inside a python string: console.log(' deck:', ...) no backslashes. Hmm, wait — (i/60).toFixed(1) + ' truck=(' ...

Let me just write the JS driver to a separate file with cat and assemble with node instead of fighting quoting. Simpler: rewrite debug5.mjs entirely via cat with a quoted heredoc.

Now it's obvious! The deck only has nodes at -10 and 10! The stayed preset's road beams don't exist!

Look at presetStayed:

That should create road beams... but the deck only shows nodes at ±10. So the road beams were never added! Why?

applyPreset → addBeam(a, b, m, { free: true }). addBeam checks: if (!opts.fixed && len > MAX_SPAN + 0.01) return null; — road beams are 2m, fine. Then... wait, but the truck drove from x=-18 to -10 on solid cliff (contact=true until x=-9.6), then fell into the gap at x=-9.6! So there are NO road beams across the span.

Why? The stayed preset also adds steel towers and cables. Are all beams missing or just road? Deck filter only shows gy≈0 nodes. Cables from (-8,10) etc. would have nodes at gy=10. Let me count total beams: the earlier debug run on stayed wasn't counted. But the road beams clearly missing.

AH WAIT. I bet it's the applyPreset budget check or... no, other presets' roads work (pratt deck had nodes every 2m).

Hmm, actually wait: look at applyPreset for stayed... presetStayed() generates the list. Road beams: for (let x = -half; x < half; x += 2) L.push([k2(x, 0), k2(x + 2, 0), 'road']); — same as pratt. So roads should be in the list...

Unless! In addBeam, the road beam from (x,0)-(x+2,0) is REJECTED because beamMap.has(key) — a duplicate! The stayed preset adds L.push([k2(tx, 0), k2(tx, -2), 'steel']); (tower leg below deck) — that's not a duplicate of road.

Wait, no. Let me recount: in the harness, applyPreset('stayed') is called AFTER setupLevel(0). setupLevel adds ground road beams on the cliffs (fixed). Then applyPreset does clearPlayer(false) then adds preset beams. The deck road beams should be added...

Let me just count beams after applyPreset('stayed') and list materials.

Found it! The stayed preset exceeds the budget ($18,963 vs $15,000 for First Crossing) — so applyPreset refuses to build it and toasts "Preset exceeds this budget". In the harness (and in the game), clicking "stayed" on First Crossing does nothing — the truck then drives off the empty cliff and splashes. So in the harness, "stayed" results were just "empty level" runs. Not a physics bug — the preset is too expensive for the budget!

So the stayed preset works as coded, but it's too pricey for level budgets. The cable material: cost 15/m, road 95/m, steel 150/m, wood 45/m. The stayed preset has towers (steel, 10m tall ×2 + legs) ≈ 2*(10+2)*150 = 3600. Road deck 20m * 95 = 1900. Cables: from tower top (8,10) to (-4,0) = hypot(12,10)=15.6m, etc. Total cable length ≈ several long diagonals... each ~11-15m, 8 long cables + 8 short = ~100m * 15 = 1500. Hmm that's ~7000 total, not 19k.

Wait, cost = 18963. Let me recompute. Towers: for (let y = 0; y < th; y += 2) L.push(steel) → 5 segments of 2m per tower = 10m steel per tower, ×2 = 20m × 150 = 3000. Legs: 2×(2m steel) = 4m ×150 = 600. Cables per tower: i=1..4, dx=3,6,9,12:

• cable from (tx,10) to (tx∓dx, 0): lengths hypot(3,10)=10.4, hypot(6,10)=11.7, hypot(9,10)=13.5, hypot(12,10)=15.6 → sum ≈ 51.2m per tower
• plus from (tx,6) to (tx∓(dx-2),0): hypot(1,6)=6.1, hypot(4,6)=7.2, hypot(7,6)=9.2, hypot(10,6)=11.7 → sum ≈ 34.2m per tower Per tower: 85.4m cable ×2 = 170.8m × 15 = 2562. Road: 20m ×95 = 1900. Total ≈ 3000+600+2562+1900 = 8062. But computed 18963?!

Hmm, my estimate is way off from 18963. Let me recheck... OH WAIT. The cables: L.push([k2(tx, th), k2(tx - sx * dx, 0), 'cable']); — but ALSO there might be an issue with k2 rounding? No...

Actually hold on, maybe the cost function: MATS[m].cost * Math.hypot(...) with GRID=2! k2 takes GRID coordinates — k2(gx, gy) where x = gx * GRID. presetStayed uses k2(x, 0) with x in GRID units: for (let x = -half; x < half; x += 2) — half = G/2 = 10 GRID units = 20m world. So coordinates in the preset are GRID units; world length = hypot(dx_grid, dy_grid) * GRID = 2x my estimate! I forgot GRID=2.

So real cost: road deck: 10 segments × (2 grid = 4m world)... wait no. x += 2 steps of 2 grid units = 4m world each?? But the deck needs beams every 2m! Road beams from (x,0)-(x+2,0) in grid units = 4m world span. Hmm wait, but MAX_SPAN: road max span... let me check MATS: road span 2.1? In grid units or world? if (!opts.fixed && len > MAX_SPAN + 0.01) return null; where len = hypot in grid units * GRID (world meters). MATS road span... Let me check the MATS definitions again.

Now I have the real material costs: road 170/m, steel 115/m, wood 50/m, cable 75/m. And MAX_SPAN = 8m.

So the stayed preset cost estimate: towers 20m steel ×115 = 2300, legs 4m ×115=460, cables 170.8m ×75 = 12810, road 20m ×170 = 3400. Total ≈ 18970 ≈ 18963 ✓. The cables are the expensive part (170m of cable!).

For level budgets: First Crossing 15000, Long Span 23500, The Pillar 17500, Storm Pass 17000. The stayed preset at G=20 costs 18963 — over budget on 3 of 4 levels (Long Span at G=30 would cost even more: cables scale up).

So the "stayed" preset as designed is too expensive. Fix options:

1. Make the preset cheaper: fewer/shorter cables. The current design has 8 cables per tower including a redundant lower row. I could slim it: one cable row from tower top to 4 deck points. That halves cable length → ~85m × 75 = 6400 + towers 2300 + road 3400 = 12.5k. Under 15k ✓.
2. Or scale: reduce tower height th=10 → 8, dx spread tighter.

Let me redesign presetStayed to be budget-appropriate:

• Towers at ±(half-2), height th=8 (4 segments of 2m).
• Cables from tower top to deck at dx = 2, 4, 6, 8 (toward center) — 4 cables per tower: lengths hypot(2,8)=8.25, hypot(4,8)=8.9, hypot(6,8)=10, hypot(8,8)=11.3 → 38.5m per tower, 77m total ×75 = 5775.
• Towers: 2×8m = 16m ×115 = 1840 + legs 4m ×115 = 460.
• Road: G meters × 170 = 3400 (G=20). Total G=20: ≈ 11,475 ✓ under 15000. G=30: road 5100, cables: same tower config (dx capped by span)... roughly 12.5k ✓ under 23500 and 17500 ✓ and Storm Pass (G=24) ≈ 11.9k ✓ under 17000 ✓.

But will it be strong enough? Cables comp 2.2e-6 are stretchy. With the new deck bending stiffness + 4 cables per tower it should be OK-ish. The previous design failed by sag even WITH 8 cables per tower (on Long Span: timeout, sag 1.22, 12 broken). Hmm, actually on Long Span the stayed preset: timeout with broken=12 — cables/hangers snapping, truck crawling.

Alternatively reduce cable stretchiness: comp 2.2e-6 → 6e-7. Real cable stays are prestressed and stiff. Cables being nearly as stretchy as wood makes cable structures saggy. Let me reduce cable comp to 8e-7 (like road) — cables still only tension (cable flag) and break at 230kN tension. This will make suspension/stayed bridges much more usable. But it also affects the suspension preset (which currently succeeds mostly).

Also the "stuck" outcomes with the Hauler: the truck can't climb out of dips. The accel limit (my new accel values) affects this: Hauler accel 3.0. In a dip of ~1.5m depth over a few meters, grade ≈ 30-50% — a real hauler couldn't climb that either. It's a legit outcome. But for preset bridges, sag of 1.0-1.5 under the Hauler is a lot. Stiffer cables will reduce this.

Plan:

1. cable comp: 2.2e-6 → 7e-7 (stiffer stays/hangers).
2. Slim down presetStayed to fit budgets (single fan of 4 cables per tower, th=8).
3. Re-run harness, iterate.

Also the suspension preset losing 7-12 hangers per run (broken > 0 on success) — hangers snapping one by one as the truck passes (creep). Stiffer cables will raise forces though... hmm, stiffer = higher force for same displacement. Cable breaking force 230kN. Suspension preset breaks ~7-12 cables but still succeeds. That's actually decent drama (partial failures, bridge survives). I'll keep an eye on it.

Let me apply changes.

I'm at 50% time budget. Let me be efficient now.

Quick fixes to apply:

1. Pratt preset: don't apply if over budget (toast + abort).
2. Cables: comp 7e-7 → 5e-7.
3. Then final harness run, quick syntax sanity (node --check equivalent), update index.html description if needed (it's listed already — check), done.

**************************************************************************it.

Results now:

• No NaN, no launches.
• 45/60 success, 12 stuck (all Hauler — heavy truck on a saggy deck is a legit game outcome), 3 "fail" = The Pillar + pratt which is the over-budget guard working as intended (toast, keeps existing bridge → truck splashes).

The Pillar + pratt "fail" rows: budget guard aborts preset → empty bridge → truck falls. That's now expected behavior with the clearer toast. Acceptable.

Stuck with Hauler: legit heavy-truck outcome. The bridge survives (doesn't collapse) — fine gameplay.

I'm at ~50%+ time. Now finalize:

1. Verify the full HTML still parses — run a browser-ish syntax check: extract the whole module script and run node --check on it (as ESM with import lines intact? node --check works for CommonJS; for ESM need --input-type=module... simpler: use new Function won't accept import. Use node's built-in parser: write to .mjs and node --check it).
2. Check the demos index page mentions demo 046 correctly (it exists already since demo shipped).
3. Done → _success.

Syntax OK. But the grep for "046" in index.html returned nothing — the demo isn't listed on the index page! The demo style guidelines say "Maintain a simple index page at /space/demos/index.html" and "When creating a new demo, always update the index page." Demo 046 exists in the folder but isn't in the index. Let me check the index page structure and add it.