Rates and quantities are formatted at a fixed number of decimals, so small-but-nonzero values collapse to 0.00 and large values are hard to scan. Precision should adapt to the magnitude of the value, and there should be a user-toggleable compact form for large numbers.
Problem
Most displays hard-code 2 decimals. A block whose goal is 0.001/s shows almost every import, ingredient, product, and machine count as 0.00, even though none of them are actually zero — the true values are just below the truncation floor. This is common in Py: keep-in-stock / trickle chains and slow decay steps run at tiny per-second rates.
Two concrete failure modes:
- Small values vanish. A
0.001/s goal makes the whole Block Balance read 0.00 (imports, the recipe row rate, machine counts, products). The user cannot tell a genuine zero from "too small to show". - Large values are noisy. Big figures print in full (
200000) where a compact 200K would scan far better.
Desired behavior
- Never show
0 for a nonzero value. Pick enough significant figures to reveal the smallest nonzero quantity on screen (e.g. show 0.001, or fall back to a couple of significant figures / scientific-ish notation for extremely small numbers) rather than truncating to a fixed 2 decimals. - Scale precision to magnitude. Large numbers need few or no decimals; small numbers need more. Roughly: more decimals as the value shrinks, fewer as it grows.
- True zero stays
0. A real zero should read as 0, visually distinct from a rounded-down small value. - Compact large numbers, user-toggleable. Offer
200K / 1.5M style abbreviation for large values, with a setting to switch between compact and full (200,000) form. Default TBD.
Where this bites today
Formatting is duplicated across several ad-hoc helpers, all fixed-precision, so this needs a shared utility rather than patching one spot:
src/routes/block.$id.tsx:177 — num(), the Block Balance / import chips (the 0.00 in the report below).src/routes/block.$id.tsx:181, :394 — sibling fixed-precision formatters.src/lib/recipe-card.tsx:366 — fmtRate (/s display), :655fmtNum, :364 bare formatter.src/components/logistics-menu.tsx:101 — belts/inserters counts.
Proposed: a single adaptive formatQty / formatRate helper (magnitude-aware precision + optional compact notation), used everywhere these ad-hoc ones are today.
Acceptance criteria
- A
0.001/s goal shows real nonzero values everywhere instead of 0.00. - A genuine zero still shows as
0. - Large numbers can render compact (
200K) or full (200,000) per a user setting. - The scattered fixed-precision formatters are replaced by the shared helper.
Report
A 0.001/s fluid-mining block: the goal is set to 0.001/s, but every import, ingredient, product, machine count, and the recipe row rate itself displays as 0.00, because the formatter truncates to 2 decimals.
Related: #10 (rate windows / units — the other half of "make the numbers readable").
Rates and quantities are formatted at a fixed number of decimals, so small-but-nonzero values collapse to
0.00and large values are hard to scan. Precision should adapt to the magnitude of the value, and there should be a user-toggleable compact form for large numbers.Problem
Most displays hard-code 2 decimals. A block whose goal is
0.001/sshows almost every import, ingredient, product, and machine count as0.00, even though none of them are actually zero — the true values are just below the truncation floor. This is common in Py: keep-in-stock / trickle chains and slow decay steps run at tiny per-second rates.Two concrete failure modes:
0.001/sgoal makes the whole Block Balance read0.00(imports, the recipe row rate, machine counts, products). The user cannot tell a genuine zero from "too small to show".200000) where a compact200Kwould scan far better.Desired behavior
0for a nonzero value. Pick enough significant figures to reveal the smallest nonzero quantity on screen (e.g. show0.001, or fall back to a couple of significant figures / scientific-ish notation for extremely small numbers) rather than truncating to a fixed 2 decimals.0. A real zero should read as0, visually distinct from a rounded-down small value.200K/1.5Mstyle abbreviation for large values, with a setting to switch between compact and full (200,000) form. Default TBD.Where this bites today
Formatting is duplicated across several ad-hoc helpers, all fixed-precision, so this needs a shared utility rather than patching one spot:
src/routes/block.$id.tsx:177—num(), the Block Balance / import chips (the0.00in the report below).src/routes/block.$id.tsx:181,:394— sibling fixed-precision formatters.src/lib/recipe-card.tsx:366—fmtRate(/sdisplay),:655fmtNum,:364bare formatter.src/components/logistics-menu.tsx:101— belts/inserters counts.Proposed: a single adaptive
formatQty/formatRatehelper (magnitude-aware precision + optional compact notation), used everywhere these ad-hoc ones are today.Acceptance criteria
0.001/sgoal shows real nonzero values everywhere instead of0.00.0.200K) or full (200,000) per a user setting.Report
A
0.001/sfluid-mining block: the goal is set to0.001/s, but every import, ingredient, product, machine count, and the recipe row rate itself displays as0.00, because the formatter truncates to 2 decimals.Related: #10 (rate windows / units — the other half of "make the numbers readable").