A browser-based toolset for Prosperous Universe, built by EoinCuinn.

▶ Live: prun-toolset.onrender.com — open the tool launcher.

No install, no accounts, no backend. Every tool runs entirely in your browser — open a link, paste your FIO API key, and go. Your key is stored only in your browser and talks straight to FIO; it never touches a server of mine. Built to be fast and easy — the tools load instantly and get out of your way.

Built with Claude. I'm not a developer — the research and validation here are mine, the code is AI-assisted. Expect rough edges; bug reports and feedback are very welcome.

Eight single-purpose tools. Click to open:

1. Open the launcher, or any tool link above.
2. When a tool asks for a key, paste your FIO API key. It saves in your browser and pre-fills next time. Nothing is sent anywhere except FIO.

Which key? FIO issues two different keys and they are not interchangeable — each tool asks for the one it needs:

• FIO REST key (rest.fnar.net) — used by most tools (Fleet Repair, HQ Upgrade, Sell Finder, …). Saved as prun_apikey.
• FIO Swagger key (api.fnar.net) — a separate key, used by the Flight Planner (real-fleet mode) and CX Arbitrage's burn filter. Saved separately as prun_swaggerkey, so entering one never overwrites the other.

Getting the REST key — from fio.fnar.net (log in → API Keys).

Getting the Swagger key — there is no web UI for this one; you mint it by calling the API itself. POST https://api.fnar.net/auth/login with {"UserName","Password"} returns a JWT, then POST /auth/createapikey with that Authorization: Bearer <jwt> and a body of {"UserName","Password","ApplicationName","AllowWrites": false} returns the key. GET /auth/listapikeys (with Authorization: FIOAPIKey <key>) lists any you already have. Endpoints are browsable at api.fnar.net/swagger/v1/swagger.json. Every tool here is read-only, so AllowWrites: false is correct.

These are FIO account credentials — not your Prosperous Universe game password — and no keys are ever hardcoded or committed. (Planet Compare additionally uses a PrunPlanner API key; the Flight Log uses a PUNoted token — see those tools.)

The deepest tool: a physics-accurate route planner with per-leg fuel, damage, and shield recommendations across multi-leg journeys. Game flight quantities are deterministic to ~machine precision, so the numbers below are exact, sourced from packet captures — not fitted guesses.

Status: work in progress — actively calibrated. Flight time and take-off/landing/transit fuel land within ~1%, meteor damage R²=0.9989, ship mass/volume 86/87 within 1%, and landing distance is a deterministic ±15% band (exact if the mission seed is known). Known gaps: departure-segment fuel ~6% low, radiation not yet modelled, FTL/gateway routing not yet included. Treat outputs as close estimates, not gospel.

Meteor damage Formula fitted against 19 systems, R²=0.9989:

damage = 7.1692e-6 × dist_km × density^p(ρ)
p(ρ) = 0.683 + 0.223 × log₁₀(ρ)

Density-dependent exponent — star-type multipliers were a sampling artefact, not a real signal.

Landing distance Not a physics quantity — a deterministic PRNG draw, seeded by the missionId the client sends with the flight calc:

d = k(planet) × (13 + 4·r)
r = new java.util.Random(UUID.hashCode(missionId)).nextDouble()

So d ∈ [13k, 17k) — mean 15k, band exactly ±2/15 (±13.3%, the familiar "±15%"). The mean is the planet radius/pressure term (Taiyi's distance work); the planner estimates it as 926 × (radius_m/1e6)^0.96 × (1 + pressure)^−0.42.

The seed is client-generated and echoed verbatim by the server, so a landing is predictable from the wire — but the client mints that UUID with crypto.getRandomValues() (OS CSPRNG), so it is not steerable. Real flights inherit their plan's draw and re-roll per flight, including to an established base — the fixed-tile hypothesis is refuted. Full write-up and verification: research/landing/.

Landing damage Fitted 2026-07-05, 24 points (2 blueprints × 12 planets), R²=0.989:

damage = 1.1322e-4 × dist_km^0.4934 × accel^−0.9441 × pressure^0.9288

Higher acceleration = less damage — exposure time, not speed, drives accumulation. Accel exponent −0.94 is near-perfect inverse. Known outlier: MG-197e (85 atm) over-predicted ~2×, pressure law saturates at extreme values.

Take-off / landing fuel — the same STL burn physics for both legs

fuel     = 336.9 × stlFlowRate × √(dist_km / accel_eff)
accel_eff = min(thrust / mass, maxGFactor × 9.80665)

336.9 is derived, not fitted — it is the closed form (4/0.06) × √(350.11/13.71) (credit: Marcus Licinius Crassus), and supersedes the earlier fitted 354.5. Confirmed across a controlled 5-engine set. The g-force cap only binds for Hyperthrust, the one engine whose raw acceleration exceeds the hull's g-limit; capped, all five engines agree.

Approach fuel

fuel = STL_tank_capacity × 0.491 × fuelUsageFactor

Not distance- or acceleration-dependent — confirmed empirically.

FTL fuel and time

FP_MIN_PER_PARSEC = 28.5
FP_FUEL_PER_PARSEC = 14.2

Empirically calibrated from flight log data.

Ship empty mass and hull volume — derived from the blueprint dropdowns, not fitted

operatingEmptyMass = Σ(component weight × count)          # exact, 87/87 blueprints
totalVolume = 438 + 1.05 × cargo_capM3
              + engineΔ + stlTankΔ + reactorΔ + ftlTankΔ  # 86/87 within 0.5%

Empty mass is exactly the bill of material — no baseline, no hull offset. The hard part was totalVolume, the hull-envelope figure the game sizes plating and structure from: it is not the sum of component volumes (0/87) and has no constant packing factor, but it is additive over five of the twelve selectable fields and driven by the cargo bay's m³ capacity (not its weight or tonnage). The 1.05 is structure feedback — capacity demands space, and the plates enclosing it eat ~5% more.

With volume known the whole ship follows: plates round(0.535 × V^0.655), structural components round(0.0478 × V), crew quarters by volume band, command bridge by FTL-reactor tier. Hypothetical mode now computes empty mass from the dropdowns instead of a fitted aggregate — volume 86/87 within 1% (mean 0.002% over the 86 non-vortex ships; the single miss is the vortex ship BP-CLNY-0000), mass 82/86 within 1% (mean 0.199%). Full write-up: research/openmass/.

Note for anyone reproducing this: a regression over these fields is confounded and returns confidently wrong coefficients (R²=0.992 while reporting the Quick-Charge reactor at −77 m³ where a controlled pair gives +7). Every delta was measured from one-field-change blueprint pairs.

• Radiation damage — Confirmed real (2026-07-08). Accumulates on TRANSIT segments only; scales as k·AU⁻²·distMkm, k≈0.045 %·AU²/Mkm (O-class, two ships, pre-registered prediction confirmed). Implementation parked — path integration along the transfer ellipse is non-trivial, and star-class dependence is uncalibrated outside O-class. Anti-rad plate is non-functional (not net negative — zero measurable effect across nine captures). No radiation term in active code.
• DEP fuel — ~6% low, departure thrust term not yet fitted.
• FTL/Gateway routing — Phase 6, ready to start.

• Real fleet — pulls your ships direct from FIO Swagger API (api.fnar.net). Prefills blueprint, mass, thrust, flow rate, condition.
• Hypothetical — component selector. Mix and match any hull/engine/tank/shielding combination to compare builds before committing. Empty mass and totalVolume are derived from the selections (see above) and shown alongside the plate/structural counts, so a build can be spot-checked against the in-game blueprint tester. A lookup of 61 captured blueprint combinations is kept as a secondary cross-check; any disagreement over 1% is flagged in the UI.

• planet_data.json — planet physics (radius, pressure, gravity, OrbitSemiMajorAxis in metres)
• systemstars.json — star luminosity and meteoroid density, sourced from Taiyi Bureau's universe map (MIT)
• ephemeris.json — 4,199 planets. Supplied by Marcus Licinius Crassus.
• station_data.json — HRT and ANT orbital parameters fitted from captured SYSTEM_TRAFFIC data
• prun_universe_data.json — star systems with 3D coords and jump connections
• gateways.json — gateway links, used alongside the above for BFS jump-distance routing
• material_data.json — material ticker/ID mapping and item properties

All live in public/. Read material properties from material_data.json rather than hardcoding them.

Reverse-engineering write-ups behind the planner's physics — game flight quantities are deterministic to ~machine precision, so these quote exact numbers sourced from packet captures. Index: research/.

Each workstream ships the same doc set: a peer SUMMARY, a findings_public technical write-up, and a short post_channel version for Discord.

• public/ — the standalone tool pages. Every one is self-contained vanilla HTML + JS with no build step; edit them directly.
• src/ — the React star map (Vite). App.jsx holds the data loading and state, MapView.jsx the D3 rendering, plus Sidebar / SearchBar / FilterPanel / RoutePanel. Route-finding is Dijkstra over prun_universe_data.json + gateways.json.
• research/ — reverse-engineering write-ups (see above).

npm run dev serves the React app on http://localhost:5173; the tool pages are reachable under / from the same server. The live site is a Render static site (npm run build → dist/), auto-deployed from main — see render.yaml.

Kept for refinement, reachable by direct URL but not linked from the launcher:

Non-obvious things that cost real time to work out, kept here so they aren't rediscovered.

XIT ACT JSON export (Base Repair, Fleet Repair, Infra Upkeep, Quick Orders, HQ Upgrade, CX Arbitrage)

• type must be "CX Buy" — with a space, not an underscore.
• A top-level global: { name: "..." } field is mandatory. Without it PrUn imports the action as broken/red.
• groups[].materials is an object {ticker: amount}, not an array.
• A buy-only package won't import — the game needs the matching MTRA transfer action alongside the CX Buy (origin = the source station's warehouse, dest = "Configure on Execution"). This mirrors PRUNplanner's working useXITAction export; confirmed in-game.

Two FIO keys — REST (rest.fnar.net, raw Authorization: <key>, stored prun_apikey) and Swagger (api.fnar.net, Authorization: FIOAPIKey <key>, stored prun_swaggerkey) are different keys and not interchangeable. Keeping them in separate localStorage slots is deliberate — they used to share one slot and overwrite each other.

FIO repair-material field names — the nested fields are RepairMaterials[].MaterialTicker and .MaterialAmount, not Ticker / Amount. Storage matching is the other trap: store.AddressableId can be a SiteId UUID rather than a planet natural ID, so resolve SiteId → PlanetNaturalId from the sites list. Matching on type === 'BASE' matches every base at once and is wrong. And ship-cargo stores (SHIP_STORE) are stale-prone and not usable for repair — exclude them from "have" inventory.

Plot capacity — cap = floor(208 + radius_km / 36.1), where radius_km = planet.Radius / 1000 (FIO reports radius in metres). A planet with site_count >= cap is full for regular players; starter planets exceed the cap because new players bypass it.

Exchange system natural IDs — IC1→VH-331, NC1→OT-580, NC2→UV-351, CI1→ZV-759, CI2→AM-783, AI1→ZV-307.

Star map planet-condition bands, matching the in-game classification — gravity low <0.25g / high >2.5g; temperature low <−25°C / high >75°C; pressure low <0.25atm / high >2atm.

This project would not exist without:

• Marcus Licinius Crassus — definitive flight dynamics papers: duration law, speed-cap, rendezvous-floor, FTL-jump laws, ephemeris methodology. Also the landing-distance PRNG law (d = k·(13+4r)) and the closed-form TO/LND fuel constant 336.9. The theoretical foundation the flight planner is built on.
• Taiyi Bureau — takeoff/landing distance formulas, independent flight planner, universe map data (systemstars.json, MIT licensed). The landing-distance mean (15k) is their distance work; the ±13.3% band around it is the PRNG.
• Raylu — pruncalc — take-off/landing pressure and radius handling, ship repair calculator.
• SAGANAKI — FIO galaxy star/system data gathered and shared.
• Zillatron27 — drydock — the ship component data the Ship Builder was originally built from.
• Aem | SR — radiation damage formula, ~60-point landing damage dataset, KI-439 70-flight fuel log. Empirical backbone of the damage calibration arc.
• xflasar (xSupeFly on Discord) — PUNoted, the live flight-data API (api.punoted.net) that powers the Flight Log tool — ships and in-progress flights with exact timestamps.
• Jan Placht — PRUNplanner (MIT) — the HQ upgrade cost table was cross-checked against it, and the XIT ACT export format used across the buy/transfer tools follows its working implementation.

MIT