This page follows a player technology from acquisition to a usable ship. The steps are knowledge, component definition, class, industrial admission, physical completion and live capability. It explains why these transitions are separate, and where an improvement can affect existing assets without rebuilding their components. The examples are synthetic. They imply no database values, running-game observations or test results.

The central rule is that knowing a technology, owning a blueprint, owning a manufactured component and operating an equipped hull are different facts. A particular window list or research event establishes only the matching fact. The transitions below decide the resulting changes, not the names of technologies. Those transitions are the common technology completion step, the component design calculation, shipyard task creation and ship creation at task completion.

Phase Fact established Gate or what uses it What remains separate
Base technology available An unknown technology appears as a research candidate. The ordinary project list on the Research tab of the Economics window checks knowledge, prerequisites and project and queue state. It has not been acquired or installed.
Technology acquired The race holds a knowledge entry for it (a row of FCT_RaceTech). Completion can apply direct effects and cascade acquisitions. Custom hardware may still need designing and development.
Component preview A pending definition holds calculated performance and cost. The selected source technologies and the design inputs. Preview does not start research or manufacture stock.
Normal custom Create Component and technology definitions are registered. The Create button of the Create Research Project window. The custom technology normally remains to be researched.
Prototype available Prototype knowledge permits experiments in the Class Design window. Visibility filters and the prototype state. Ordinary hull construction rejects prototype components.
Class assembled Installed definition IDs and quantities describe a hull. Catalogue visibility, installation rules and summary recalculation. No physical hull or embarked loadout exists.
Class locked Structural edits in the Class Design window are blocked. The Lock Class button, retooling or project admission. The lock is not enforced by every game action that changes a class.
Build or refit task admitted The task records work, resources and target references. Yard tooling, capacity, source hull and component checks. Work and completion stores are outstanding.
Work progressed BP and minerals have been charged in proportion. Population and yard processing in each construction cycle. A partial task is not a fractional operational ship.
Hull completed or refitted A new ship exists, or an existing ship now belongs to the target class. Task completion. Fuel, MSP, ordnance, shields and readiness have independent state.
Operational capability queried A game rule uses the current class, damage and ship state. A live capability calculation or a simulation phase. Nominal class totals are not universal live values.

Each gate belongs to a particular path. For example, the class catalogue can show a captured component stored at any colony the race owns, while construction at another colony fails its local stock test. Likewise, a design summary warning is not automatically a hard rejection when a shipyard task is admitted.

Acquire knowledge and distinguish its effects

Section titled “Acquire knowledge and distinguish its effects”

The ordinary available-project list requires prerequisite knowledge. A queued prerequisite does not count as known. Existing obsolete knowledge still satisfies the prerequisite check. The list and the act of starting a project are separate layers. Starting a project does not repeat all the prerequisite, scientist and capacity validation of the list. Research and scientific personnel gives the full eligibility and RP rules.

Acquisition normally runs through one common completion step. It normally adds a knowledge entry that is not obsolete, clears matching research state when cascades are enabled, and applies the technology’s supported direct effects. Completing an already-known technology normally does nothing. Converting a research prototype at a real population is the deliberate exception. Acquisition is not a general command to regenerate every component or class.

Technology effect kind Existing definitions and assets When the improvement takes effect
Source input, for example ordinary Engine Technology (DIM_TechType 40) Player engine performance stays in the fields of the component created earlier. A newly calculated component uses the selected input.
Fixed catalogue component unlock A previously unavailable definition may become selectable. Catalogue rebuild and explicit class editing.
Direct race rate, for example Improved Shipbuilding Rate (DIM_TechType 30) The race’s shipbuilding rate (ShipBuilding in FCT_Race) becomes the technology’s AdditionalInfo (in FCT_TechSystem). No replacement engine or hull is required. A population recalculates its shipbuilding modifier, then a yard computes its task rate.
Crew Quarter Design (DIM_TechType 285) The race’s crew design efficiency (CrewDesignEfficiency in FCT_Race) becomes the technology’s AdditionalInfo. Classes also carry their own efficiency (CrewDesignEfficiency in FCT_ShipClass). Update CDE on an unlocked class, and a special quarters rule that reads the current race factor when planned deployment is below three months.
Armour (DIM_TechType 84) acquisition Existing class armour stays selected while its entry exists. Update Armour removes it, so the next recalculation chooses again.

These consumers use the following values. A population’s shipbuilding modifier is the product of the governor’s Shipbuilding bonus, the sector governor’s quarter Shipbuilding bonus, species ProductionRateModifier, race ShipBuilding, race EconomicProdModifier, population Efficiency, the radiation production modifier, stability and the political status ProductionMod. A missing governor or sector governor adds no multiplier. A yard’s task rate is (0.5 + adjusted HS / 200) x shipbuilding modifier BP per year, where adjusted HS is the class size, multiplied by 0.25 for commercial classes. Required quarters capacity is (crew + flight crew berths) x cube root of planned deployment x class crew design efficiency. Below 3 months of planned deployment it becomes (crew + flight crew berths) x cube root of 3 x current race crew design efficiency. When a class has no armour entry, recalculation takes the researched armour definition with the highest cost, or the Structural Shell for a No Armour class.

“Immutable design value” here means a value stored when the design is created and not regenerated automatically by ordinary player research. Definitions are shared records that every class and ship using them points to. Specific editing, creation or special AI paths can write them, and the game gives no universal guarantee that they never change. The engine design calculation assigns engine power, fuel efficiency, cost and the background technology IDs to the component. For an engine those IDs are the engine technology (BGTech1), the fuel consumption technology (BGTech2) and the thermal reduction technology (BGTech3) in FCT_ShipDesignComponents. Copying a class keeps the same shared definitions.

Acquisition need not come from laboratories. For generic technology, technology treaties grant the same technology to the partner race through the same completion step, and that grant can cascade further. Lower-tech distribution has its own cheaper-technology thresholds when the technology type allows it (DIM_TechType.DistributeLowerTech = 1). Allied races receive their cheapest unknown non-automatic technology of that type only when its cost is strictly below the completed cost. Trade-treaty partners below Allied, and contacted non-hostile races with neither treaty whose capital sits on the same body as this race’s capital, use strictly below completed cost / 3, where the division is whole-number division because development costs are whole numbers. Automatic technologies are completed in turn when their Prerequisite1 matches the acquired technology. That cascade does not repeat the second-prerequisite check of the normal candidate list.

Captured hardware and knowledge are separate routes. Stored alien components can enter the class tree through the Use Alien Tech check box without race knowledge, but they must physically exist at the constructing colony. Salvage, disassembly and intelligence may award research knowledge or RP through their own selections and completion paths. A captured class or component does not prove that the race can freely manufacture it. See Intelligence mechanics, Salvage and archaeology and component logistics and recovery.

Special populations are not a universal exception to these distinctions. Generic acquisition can make shipping-line designs obsolete. These named rules do not extend to ordinary player fleets.

Turn source technology into an available component

Section titled “Turn source technology into an available component”

For a custom engine, the player selects source technologies and size and thrust inputs in the Create Research Project window. The engine design calculation then writes a new component’s engine power, fuel efficiency, signature multiplier, recipe and development cost. With size s HS, thrust multiplier t, the engine technology’s AdditionalInfo E, the fuel consumption technology’s AdditionalInfo F and the thermal reduction technology’s AdditionalInfo r:

  • Engine power P = E x s x t, rounded to 2 decimals with an exact half going to the even neighbour.
  • Fuel efficiency = F x t to the power 2.5 x square root of (10 / s) litres per engine-power-hour.
  • Thermal signature multiplier = r, so the thermal signature is P x r.
  • Cost = P / 2, multiplied by the thermal technology’s AdditionalInfo2 when r is below 1 and by t when t is below 1, and at least 5 BP.
  • Recipe: Gallicite equal to the cost.
  • Development cost = truncate(square root of (cost x 5000) x Research Speed / 100) RP. Research Speed is the Research Speed (100 = Normal) option of the Game Information window (FCT_Game.ResearchSpeed).
  • HTK = max(1, whole-number(square root of s)). Crew = s x t rounded to a whole number (an exact half goes to the even neighbour), at least 1.

Selecting better engine technology later does not revise the old output. Other component families have different formulas and dependencies. Use Component design rather than applying engine arithmetic to every family.

Preview runs the design calculation without registering anything. It leaves a pending technology and a pending component that exist only for the preview. Normal Create registers the named definition and its technology, and normal custom development then requires research. Instant Create is a Spacemaster route that registers the component and completes its research. Registration that the game performs directly, outside the designer window, also registers the component and completes its knowledge, so it is not equivalent to the normal Create button. Preview create research and prototype lists the actions.

The Prototype button registers the component and adds its technology to the race’s knowledge for use in the Class Design window, while keeping a prototype state. The state is stored as Prototype in FCT_ShipDesignComponents, with 0 for not a prototype, 1 for prototype, 2 for future-tech prototype and 3 for research prototype. The Research Proto button of the Class Design window turns a prototype (state 1) into a research prototype (state 3). A research-prototype project can then be offered although its technology is already known. Completion at a population clears that state back to not a prototype. Completion with no population attached does not perform this conversion. Future-tech prototypes and ordinary prototypes are distinct states.

Class catalogue selection normally requires known technology that is not obsolete and excludes shipping-line systems (ShippingLineSystem in FCT_ShipDesignComponents). Prototypes appear only with the Prototypes check box. Refresh Tech rebuilds the catalogue rather than upgrading installed class components. Component manufacturing has a further list. It requires researched technology that is not obsolete and excludes armour, missile engines, shipping-line systems and every prototype state. Knowledge available to class design therefore does not imply that every definition is a component-factory project.

Assemble copy recalculate and lock the class

Section titled “Assemble copy recalculate and lock the class”

A class holds links to component definitions and decimal quantities (NumComponent in FCT_ClassComponent). The normal add and remove actions of the Class Design window reject a locked class with the message “Class cannot be modified while locked”. Installing a component, which other routes also do, does not itself check the lock or racial knowledge. Installation has its own rules. A class refuses a second different definition of an engine, refuelling system, shield generator or jump point stabilisation, and jump drives, jammer families, hangar types and spinal weapons have similar restrictions. Replace an old engine definition rather than assuming that a second engine type can be added alongside it. Adding removing and updating components lists the rules.

For an existing service class, the normal development path is a copy. Copy Class gives the copy a new class ID, appends “ - Copy” to its name, clears its built count, unlocks it, duplicates its component entries and mineral record, and creates new loadout lists. The definitions remain shared. Copying a class does not calculate new components from their recorded source technologies. The ordinary Copy Class keeps the owning race and reproduces the three loadouts. A copy made for another race leaves those lists empty.

Selecting or refreshing a class in the Class Design window runs the full class summary recalculation, and that recalculation changes the class. It can replace quarters, iterate armour, insert a bridge or remove equipment a station cannot carry. Final hull size, cost, minerals and capabilities follow those operations. Replacing a 10-HS component therefore need not leave the final displacement exactly unchanged.

The key calculations are size = sum of (component size x quantity), cost = sum of (component cost x quantity) and the matching sum of the stored mineral recipes. Engine power sums the installed engine values. Normal maximum speed is whole-number(engine power / final HS x 1000), capped at 270000 km/s. Final HS includes the automatic requirements. See Units aggregate totals and recalculation order and armour iteration.

Armour and quarters need special caution when discussing improvements that reach old designs. Existing armour stays until Update Armour removes it. Class crew efficiency is saved, and Update CDE copies the race’s current factor into an unlocked class. Planned deployment below three months instead reads the current race efficiency when quarters are allocated, as (crew + flight crew berths) x cube root of 3 x race factor. Neither rule makes all old designs upgrade. Crew quarters deployment and command spaces gives the allocation.

Locking protects ordinary structural actions in the Class Design window. Construction and refit task admission, industrial fighter and station project creation and shipyard retooling can lock their target class. Normal unlocking requires Spacemaster mode, otherwise the game shows “Classes can only be unlocked in Spacemaster Mode”. Policy settings have their own controls, and some can still be changed on a locked class. A lock does not freeze every possible recalculation of derived values or every live ship state.

The same researched class may enter different production routes. Fighter projects use the industrial size limit of 10 HS or less (Size in FCT_ShipClass). Industrial stations require NoArmour = 1. Both lists keep only classes of the race that are not obsolete and contain no prototype components. Yard construction instead requires the right tooling and capacity and task admission. Station labels and the general main-function label of a class are not substitutes for these tests. Components ordnance and small craft covers the industrial routes.

Normal yard targets are the yard’s assigned class and eligible compatible alternatives. An alternative must fit capacity / 50 HS, belong to the race, not be obsolete, not be a shipping-line class, not be a class of another race (OtherRaceClassID zero), and be commercial at a commercial yard. Its size must be 80% to 120% of the assigned class size. The refit BP from the assigned class to the alternative must be at most assigned class cost / 5. Retooling is a separate development activity of the yard, with its own resources and time. Its candidates belong to the race, have no shipping-line owner, are not obsolete, fit capacity / 50 and differ from the assigned class, commercial yards need commercial classes, and none may contain a prototype component. Player admission and tooling compatibility and activity costs give the details.

Construction admission checks the selected target class, the required alien hardware in local stock, the absence of prototype components and the destination, a fleet or, with Use Admin checked, a naval administrative command. It then locks the class. An ordinary known component does not require premanufactured stock, because construction with minerals and BP can supply it. Unknown alien hardware is the important stock exception.

Refit admission also needs a selected existing ship, different source and target classes and a previewed cost above zero BP. A previewed cost of zero BP shows “Cannot create refit tasks that have zero cost”. Source selection on the Shipyards tab of the Economics window lists local ships that fit the yard, have no armour or component damage and have no task. Its class list keeps classes that fit capacity / 50 HS, lie within 80% to 120% of the assigned class size and have at least one ship of the race at the colony, and it does not apply the cost rule of the target list. A class comparison marked as suitable is therefore not a complete refit admission verdict.

The list of eligible refit source classes for a class uses a threshold of target cost / 5. The refit comparison display uses source cost / 5 with matching commercial status. Compatibility with the original yard tooling uses assigned class cost / 5. See Locking copying upgrades and refit compatibility for the exact directional distinctions.

Construction starts with the class BP and a copy of the class mineral vector. A refit prices positive increases by component ID, not by net tons or functional equivalence. Replacing two old engines with two newly designed engines charges the two new definitions in full even when their size matches. Removed engines give no negative BP credit.

For added-component BP A, source HS S and target HS T:

refit BP = A x 1.2 + abs(T - S) / S x A.

Refit minerals price the positive additions with quantity differences rounded to one decimal. BP uses the unrounded differences. The 20% overhead and the size surcharge add no further minerals. Costs and mineral vectors covers the other task types.

Use Components consumes stock at once when the task is created. It subtracts the component BP and mineral recipes for each used component, where used = min(amount of the first matching stock entry, quantity needed). With the box unchecked, the task skips known components but still consumes the required alien hardware. Stock credits on a refit leave its calculated overhead and size premium in place. The credit takes the first matching stock entry, while alien validation sums all matching entries.

Physical completion does not follow from having all the stock. Fully stock-credited construction can have a TotalBP of zero, and the shipyard task step divides the interval’s build points by TotalBP before it checks whether the task is complete. The game then shows error Function #2097 and ends that population’s shipyard task step for the cycle. The task stays active, and the tasks after it in that population’s order get no work in that cycle. See the stored-component caveat.

Each pass of the shipyard task step recalculates the yard rate for the task’s class, or for the refit target class for refits and automatic refits. The rate is (0.5 + adjusted HS / 200) x population shipbuilding output modifier BP per year, using the modifier as last recalculated, with adjusted HS = class size x 0.25 for commercial classes. The proposed interval BP is the rate x elapsed years rounded to four decimals. The work fraction and the mineral-limited fraction are rounded to four decimals as well. Each of these roundings sends an exact half to the even neighbour. Available minerals limit the fraction before completion is checked, and each shortage lowers it to available amount / full task requirement. This step has no treasury affordability test. Scheduling, rounding and shortage behaviour gives the full sequence.

Manufacturing separate physical components is optional for known shipyard hardware, but its output is real local stored components, unlike component development. Fuel, maintenance supplies and ordnance are separate products. Class recipes do not include a free full load of each. See Production components and small craft and shipyard work.

Complete a hull or transition an existing hull

Section titled “Complete a hull or transition an existing hull”

Construction completion creates the ship from the task class at the current game time. A new hull starts with the full class crew, morale 1, overhaul and shore-leave dates set to the current time, and shields at zero and switched off. Player yard construction gets no free fuel or maintenance supplies. Fuel up to the class fuel capacity, or the class MinimumFuel for a tanker, and MSP up to the class maintenance supply capacity are withdrawn from the local colony. Desired missiles are withdrawn when available, so an intact new ship can be underprovisioned. Completion-time supplies and destination fleets covers the withdrawals.

Refit completion keeps the ship and changes its class. The task step reduces the maintenance age by (current game time - last overhaul) x (task TotalBP / old class cost), clears the weapon recharge state and makes officers disembark when the new class has a different rank requirement. The class change then clears damage and weapon and fire-control assignments, adds one to the target class count and recomputes fleet speed. This is a real hull transition, not a catalogue refresh.

For ships , the refit transition sets shields to zero and switches them off, sets the crew to the target class crew, and balances fuel and MSP toward the target capacities, drawing on local supplies or returning the excess. Ordnance uses the stock and template handling rather than granting arbitrary ammunition. The transition does not return removed source components to stock. The ordnance withdrawal has a caveat for a class with no ordnance template, described in ordnance rearming and consumption.

Automatic refit is another path. A successor inherits the previous task’s already-discounted BP and shares its mineral list, then applies further stock credits. It does not recompute an independent clean baseline or repeat every initial source admission check. It is abandoned when the yard no longer supports the target class. These accounting limits stop the single-ship example below from extending to a whole automatic series. Completion, automatic succession and cancellation describes the successor.

Class engine power, cost and capacity describe the installed hardware. The live capability of a ship counts only surviving components, class quantity - damaged number. Selected module capabilities also apply commander bonuses and an understaffing factor of current crew / class crew when the crew is short. Fuel, magazine contents, maintenance state and current shield charge remain the state of each ship. A new class rating is not evidence that all those states are ready. See design capability and independent live state.

Refresh Tech changes the component tree. A class-view refresh recalculates a class. Task processing spends work. A ship’s live capability is worked out when a rule asks for it. These are four different actions. Saving and loading is a fifth operation. No single refresh performs all of them.

In a population production tick, the capacity and output modifiers are calculated first. Mining and industry come before yard modifications and tasks. Player research runs after the yard tasks and fuel production. A shipbuilding technology completed by that colony’s research cannot speed up the yard work it has already processed. A later refresh or tick can use the new race value. Another population processed later can see the changed race state, and the order of colonies is not sorted by such dependencies. Production dispatch and order lists the full order.

Strategic work runs at its clock boundary. A time-button request is not an immediate production award. Earlier and later sub-pulse and end-of-increment effects have their own timing. See Game time and state refresh and Ship power, class and detection for operational recharge and the movement and detection consumers.

All values below are synthetic inputs, not a recovered saved-game design. Assume an ordinary player race, valid researched source technologies, no prototypes, a correctly tooled naval yard with sufficient capacity and slipways, no stock credits, adequate minerals and final recalculated hull values as stated.

  1. Acquire an engine technology with AdditionalInfo 20, a fuel technology with AdditionalInfo 1 and a thermal technology with AdditionalInfo 1. Knowledge makes them usable source inputs. It does not create the named engine automatically.
  2. Design size s = 10 HS and thrust t = 1. Engine power = 20 x 10 x 1 = 200 EP after rounding to 2 decimals. Fuel efficiency = 1 x 1 to the power 2.5 x square root of (10 / 10) = 1 litre per EP-hour. The thermal multiplier is one. Cost = 200 / 2 = 100 BP, with Gallicite 100, crew 10 and HTK 3. At Research Speed 100, development is int(square root of (100 x 5000)) = 707 RP.
  3. Normal Create registers the engine technology and definition. Finish its 707 RP through research. It is then ordinary researched hardware rather than a blueprint awaiting development. Refresh Tech shows it under the normal catalogue rules.
  4. Copy a locked old class whose two old 10-HS engines each supply 100 EP and cost 50 BP. Remove those entries and add two new engines. Assume that automatic quarters and armour produce a final target of 100 HS, old and target final costs of 600 BP and 700 BP, and unchanged recipes for everything except the engines. Target engine power 400 gives 4,000 km/s against the old 200 EP giving 2,000 km/s at the same 100 HS.
  5. The new pair costs 200 BP and Gallicite 200. A completely new target hull costs its full 700 BP and the full class recipe. Refitting an old hull charges the positive new IDs. A = 200 and equal sizes give refit BP = 240, with Gallicite 200 plus any other positive class additions. Removing the old pair gives no credit.
  6. A yard still tooled to the 600-BP old class cannot treat this 240-BP change as a compatible alternative, because 240 exceeds 600 / 5 = 120. Retool to the target before using that target as the assigned class, assuming the other source and target admission conditions hold.
  7. Assume the resulting task’s calculated build rate is 100 BP per year. A one-year interval proposes 100 BP. The task fraction rounds 100 / 240 to .4167, so nominal BP becomes 100.008 and the Gallicite debit 83.34. This is the rounded accounting of the shipyard task step, not an exact continuous 100 / 240 allocation. Later intervals cap work to the remainder and finish.
  8. Completion changes the old ship to the target class and recomputes fleet speed. Shields restart at zero and switched off. If target fuel capacity is 100,000 litres and the resulting fuel aboard is 30,000 litres, the 400 EP engines at efficiency 1 have 75 full-power hours of fuel, not the nominal 250 hours. Other motion conditions are assumed ideal. The nominal figure is fuel capacity / (engine power x fuel efficiency).

The class is now better equipped because a researched component was selected, admitted, paid for and physically installed by refit. The research event alone achieved only the first part of that chain. Class costing and the component formulas are expanded in Component design, Ship and station design and Shipyard work.

Counterexample and direct-modifier example

Section titled “Counterexample and direct-modifier example”

Suppose the race later acquires an engine technology with AdditionalInfo 30 while the scenario’s ship still uses its two 200-EP engines. Refresh Tech, opening the Class Design window and saving and reloading do not rerun the engine design calculation to replace the stored engine power. The ship’s nominal class engine power stays 400. It does not rise to 600 merely because the source technology improved. A newly designed equivalent 10-HS engine would have 300 EP, but that is a separate definition that needs its own deployment path.

Contrast Improved Shipbuilding Rate. Completion directly replaces the race ShipBuilding value with the technology’s AdditionalInfo. If it rises from 100 to 150 and all other rate factors are unchanged, the next population modifier that includes it is 1.5 times the old value. A yard’s matching task rate likewise rises 1.5 times. Existing tasks can benefit without replacing their class components. This is a rate update for later work, not free past progress or a faster completed ship. For scale, a race starts at 400 and the shipped Improved Shipbuilding Rate technologies run from 560 to 8000.

Saved layer Restored facts Boundary
Technology and component definitions (FCT_TechSystem, FCT_ShipDesignComponents) Development costs, source IDs, stored performance and mineral recipe. Race knowledge (FCT_RaceTech) is loaded separately. Reload does not manufacture a replacement design from the best current technologies.
Class and component entries (FCT_ShipClass, FCT_ClassComponent, FCT_ClassMaterials) Saved derived totals, owner, lock, quantities, component references and material vector. Opening the Class Design window can then recalculate and change the class totals.
Desired loadouts (FCT_ClassOrdnanceTemplate, FCT_ClassSC, FCT_ClassGroundTemplates) Class ordnance, craft and ground templates. These are distinct from the actual embarked units and inventory.
Individual ship (FCT_Ship) Class reference, live stores and state, dates and damage records. Reload reconstructs the saved hull. It does not run new-hull creation to reset its age or stores.
Simulation clocks (GameTime, LastGrowthTime and LastGroundCombatTime in FCT_Game) Current time and the last strategic and ground processing times. Loading alone grants no elapsed production interval.

When a game is loaded, the game restores race-designed technologies and components and race knowledge before classes, class component references, materials and loadouts, then populations, fleets and ships. Loading a class assigns the saved class engine power, speed, cost and efficiency values. It does not force a fresh class summary recalculation. Later window actions and simulation steps may update their own values. See Object identity and reload and save, load and creation dates.

This page covers the ordinary player chain, with the boundaries of captured, shared and special-race material. It does not specify every NPR design policy, every weapon rule in play, or universal technology data values. Design input bounds, window lists and lower-level game rules each validate different things. Exact full-hull arithmetic needs all the component definitions and the automatic hull passes, not only the headline replacement engine.

Related community documentation and developer posts. These may describe a different game version.