Methodology

About the data

Where these numbers come from, which ones to trust, and what this site refuses to calculate.

Everything is patch-scoped

Star Citizen rebalances constantly, so a figure without a game version attached is meaningless. Every ship, component, hardpoint, shop and price row in the database belongs to a specific patch. Adding a new patch inserts a new generation of rows; it never overwrites the previous one, so a hull's history stays queryable and switching versions with the selector in the header genuinely changes which data you are looking at. You are currently viewing Alpha 4.0 — LIVE.

Unknown means unknown

When there is no trustworthy value for a field in a given patch, the database stores NULL and the site prints Unknown. It never substitutes a zero. A zero would be indistinguishable from a real measurement, and a single fake zero propagating into a DPS total would quietly corrupt every comparison that total appears in.

The same rule governs the aggregate figures. Every calculated total records how many items contributed to it and how many were skipped for lack of data; where some were skipped, the figure is marked partial rather than presented as complete. Budget filters exclude hulls with no recorded price rather than treating them as free.

What is verified and what is reference data

The shipped dataset is not a live datamine. It is layered by confidence:

• Identity data — reliable. Ship and component names, manufacturers, roles, sizes, item classes, grades, crew counts, cargo capacity, pledge prices, hull and pad classes. This changes rarely and is stable.
• Hardpoint layouts — reference data. Which slots a hull has, their sizes and their restrictions. Accurate in shape, and worth verifying against the current patch before relying on a specific count.
• Performance figures — reference data. Damage, rates of fire, shield capacity, power output, cooling rates and quantum speeds. These are the numbers CIG changes most often. Each seeded row says so in its own notes field.
• Deliberately absent. Hull HP, SCM and maximum speed, fuel capacities and in-game hull prices are left NULL in the shipped seed rather than guessed, because the flight model reworks have moved them repeatedly and no reliable per-patch figure is held.

If you are running this site yourself, replacing the seed with current data for your patch is the single highest-value thing you can do. The schema is designed for exactly that: import a new patch, and the old one stays intact.

Where the data comes from

This site can be kept current from two community sources: UEX Corp, which tracks the live economy and the build number CIG currently has on live, and Fleetyards, which tracks hulls, hardpoint layouts and imagery. Neither has everything, so where both describe the same ship the figures are merged — and a source that is simply silent about a field never erases what the other one knew.

The import runs as a scheduled job, never while you are waiting for a page. Everything you see was already in this site's own database before you asked for it, which is why the pages keep working when an upstream is down. It also means the data is exactly as fresh as the last import, not live to the minute.

Nothing is invented on the way in. Where an upstream has no value for a field — or offers a placeholder like 0 or N/A — the field stays empty and this site says Unknown, rather than turning a gap into a number that would read as a measurement.

How the simulation works

Four systems decide how a fit behaves, and they constrain each other. The model solves them in that order — power and cooling first, because both produce throttle factors the weapon and shield figures depend on.

Power

The plant feeds everything. Items outside the combat triangle — coolers, the quantum drive — draw first; what is left is the pool the pilot's pips split between weapons, shields and thrusters. A system whose demand exceeds its allocation is throttled by the ratio, which is why a balanced assignment often cannot sustain a full weapons battery and a weapons-heavy one can.

Zeroing shields does not conjure power for the quantum drive: the reserved draw comes off the top before the triangle is split.

Heat

Items generate heat continuously and coolers dissipate it. The always-on systems produce theirs whether or not anyone is shooting, so they are subtracted first; whatever remains is the budget the guns can fire inside indefinitely. Firing past it accumulates heat in the weapons' own capacity until they overheat and drop offline:

time to overheat = weapon heat capacity ÷ (total generation − dissipation)

Weapon capacitors

An energy weapon pays for each shot out of a charge pool that refills at a fixed rate. Once the pool is empty the gun fires at whatever rate the regeneration supports, which is what separates cyclic output from sustained output:

drain = shots per second × cost per shot
sustained rate = min(cyclic rate, regeneration ÷ cost per shot)
time to empty = capacitor ÷ (drain − regeneration)

Ballistic guns have no capacitor. They are bounded by their magazine instead, and once it is empty they contribute nothing — which is why they count towards cyclic output but not towards sustained.

The three DPS figures

• Cyclic — every gun at its rated rate, nothing limiting it. What the first trigger pull delivers.
• Effective — cyclic scaled by the power the guns are actually allocated. Power starvation bites immediately, so this is the real opening figure.
• Sustained — the steady state once the capacitors have drained to their regeneration rate and the heat budget is saturated.

The builder names whichever constraint is tightest. That single word — power, heat, capacitor or ammunition — is the most useful thing on the page, because it says what to change.

Shields

Generators pool their capacity and regeneration; the recovery delays are the worst case across them, since the ship is only back up once the slowest one is. Regeneration is scaled by the shields' own power allocation, so starving them slows recovery.

Physical, energy and distortion damage are absorbed at different rates, which is what makes shield choice a real decision rather than an HP comparison:

effective HP = pool ÷ (1 − resistance)

Resistances are pooled by HP share, so a large weak generator is not averaged away by a small hardened one.

Ordnance

A pylon holds a rack and the rack holds missiles. Choosing the payload sets the salvo damage — capacity × the loaded missile's damage, summed across pylons — and the signal type decides what the missile can lock onto.

Quantum

Travel time is distance ÷ quantum speed plus spool time, against a fixed 30 Gm reference hop for comparing drives. Range is the hull's quantum fuel divided by the drive's fuel rate. Calibration time is derived from the drive's calibration rate.

The shopping route is solved, not guessed

Every shop counter is pinned to a celestial body with orbital coordinates, so the stops have real positions and ordering them is a genuine shortest-path problem. It is solved exactly — Held–Karp dynamic programming over subsets — for any realistic number of stops, and the page says whether the answer is provably optimal. Beyond that ceiling a nearest-neighbour search with 2-opt improvement takes over, and the route is labelled as not provably optimal.

Which counters to visit is chosen separately, and greedily: minimising stops and minimising distance are different objectives, and a player would rather make two stops than five. The optimiser orders whatever that produced.

Distances are straight-line between orbital positions. They ignore obstruction and assume a direct jump, so the travel time is a lower bound. A stop whose body has no recorded position is listed last rather than placed in the ordering, and the route is marked inexact when that happens.

What the model does not claim

The simulation is built from the catalogue figures and the relationships above. Where those figures are themselves reference data, the output inherits that — a precise-looking DPS number is only as good as the alpha damage it was computed from. Two further limits are worth stating plainly:

• Signature and emission behaviour is not simulated. Item classes are recorded and drive the resistance profile, but IR/EM visibility is not modelled.
• Ship handling — thruster authority, manoeuvrability, the effect of the thruster pips on flight — is not modelled. The thruster share exists so the power arithmetic is right, not because the site predicts how a ship flies.

Shared loadouts

A shared build is encoded into the link itself and nothing is stored on the server. When a link is opened, the server re-validates all of it: the patch, the ship, that every slot really belongs to that hull, that every component exists in that patch, and that every part actually fits the slot it claims. Anything that fails is dropped with an explanation and the rest of the build still opens. The browser is never trusted to have checked.