Items & Materials

Source of truth: Taurion Game State Processor (the GSP source tree). Display names: the names shown in the official web client; the item codes are what appears on-chain and in the GSP API.

New here? In plain words. Everything you carry or store in Taurion is a stacked item. You mine rock to get ore (e.g. Trimideum, raw a). You refine ore in a refinery building into materials (e.g. Agarite, mat a) — the raw ingredients for crafting. To craft anything you need a blueprint: you get the first one by reverse-engineering an artefact (an ancient relic found while mining), which turns it into a blueprint original (bpo, reusable) you can then copy into one-shot copies (bpc). Feeding a blueprint plus the right materials into a construction building builds the finished thing — a vehicle (your ship) or a fitment (a bolt-on module: weapon, shield, engine, mining drill, etc.). Each item also costs cargo space to carry. Every item has a short internal code (in code font) and a player-facing display name (in bold) — both are shown side by side throughout this doc. Real costs are paid in vCHI (the game's currency). Jargon used below: fungible = stackable/interchangeable (1 unit is identical to any other of the same type); complexity = a tier number that scales how expensive and slow it is to copy/build an item; bpo/bpc = blueprint original/copy; fitment = equippable module; AoE = area-of-effect (hits everything in a radius). The rest of this doc is the exact, complete catalog backed by source-code citations for client developers.

This document is the authoritative catalog of all consumable / fungible items in Taurion: ores, refined materials, artefacts, blueprints, fitments (equippable modules), and prizes — plus the rules for refining, reverse engineering, blueprint copying, item construction, and cargo space. The complete fitment catalog (all 104 fitment item types, their codes, complexity, faction/size/slot constraints and construction recipes) is in §4A. Vehicles are catalogued in detail in their own doc (Vehicles); here vehicles appear only where they are the output of a blueprint or construction. The combat semantics of weapon/support fitments (damage math, AoE, hit/miss, syphon, self-destruct, mentecon) are in the combat doc (Combat §10); this doc gives the item-level data (what each item is, costs to build it, where it slots).

Money note. All in‑game costs in this doc are denominated in vCHI (the game currency, an ERC‑20-style asset on the Xaya/Polygon stack). Service "base costs" are burnt (removed from circulation). Service "fees" go to the building owner. See Costs, fees and burning.

---

1. The fungible-item model#

Every stackable item in Taurion is a fungible item identified by a short internal string code (e.g. raw a, mat c, art ur, sword bpo). They are stored as (itemType → count) maps in inventories (building inventories and character cargo).

The hardcoded data for each item type is the ItemData proto (proto/config.proto:222-277). Key fields:

Exactly one of the following "type" oneof branches may be set (config.proto:251-275):

1.1 Auto-generated item types (proto/roconfig.cpp:314-386)#

Several item codes are never written into the config files — they are synthesized on demand by ConstructItemData from a base item:

• bpo (blueprint original): for any base item with with_blueprint: true. space = 1, is_blueprint{ for_item: <base>, original: true }, inherits faction. (roconfig.cpp:320-331, suffix constant roconfig.cpp:249)
• bpc (blueprint copy): same, original: false. (roconfig.cpp:333-344)
• prize: for any string "<name> prize" where <name> matches a configured prospecting prize. space = 0, prize{}. (roconfig.cpp:346-360)
• Vehicle faction: vehicles get their faction from the name prefix rv →r, gv →g, bv →b. (roconfig.cpp:259-265, 371-383)

BLUEPRINT_SPACE = 1 (roconfig.cpp:257).

1.2 Cargo space#

Cargo space consumed by an inventory is the sum over all items of count × space (database/character.cpp:229-240). A character's free space is vehicle.cargo_space − used (character.cpp:242-249).

Almost every consumable has space: 1 (ores, materials, artefacts, blueprints). The exceptions are prizes (space: 0) and vehicles/fitments (which have their own large space, used when they are sitting in cargo as items rather than equipped/active).

Design implication. 1 unit of ore and 1 unit of refined material both take 1 cargo space, but refining always reduces total unit count (see §3), so refining never overflows cargo. The engine relies on this explicitly (services.cpp:256-266).

---

2. Ores (raw resources)#

There are exactly 9 ores, raw a … raw i, all defined in proto/roconfig/items/materials.pb.text:61-210. Each has space: 1 and a refines block. Ores are obtained by mining prospected regions (mechanics in the mining doc); the artefacts that can be found alongside each ore are in §5.3.

Display names are the ones shown in the game UI. (The game UI's icon for raw f uses the spelling "Voltan" vs the display name "Voltar" — see Open questions.)

For all 9 ores: input_units = 10000 and cost = 1 per refining step (materials.pb.text:68-71, etc.). I.e. one refining "step" consumes exactly 10,000 units of ore, burns 1 vCHI, and yields the materials in the table.

Ore descriptions (flavour, from the design docs):

• Trimideum — This crystalline ore is deep purple. It is hard to crush when refining and wears on equipment.
• Talon — This brittle ore is dark brown; when crushed it has the consistency of sand.
• Henoix — This ore is pitch black, its impurities sparkling brightly. Raw ore feels like sandpaper to the touch.
• Orchanum — This black ore is mushy at room temperature, with a consistency like wet sand.
• Kalanite — This inert, pink-and-green ore is very light, yet the resource extracted from it is highly reactive.
• Voltar — This blue ore is very heavy, and refining it requires a strong solvent and catalyst.
• Ravolute — This raw ore ranges from bright yellow to deep orange; rare swirled specimens are sometimes cut for jewellery.
• Talgarite — This golden ore is easily separated and refined — soft enough to break in one's hand.
• Liberite — This silver ore sparkles and is highly reflective.

---

3. Refined materials#

There are exactly 9 materials, mat a … mat i, defined in materials.pb.text:4-56. Each has space: 1 and no special type branch (they are plain consumables used as construction inputs).

Display names are the ones shown in the game UI.

Material descriptions (flavour, from the design docs):

• Agarite — A base material used in most construction — light-weight but very strong. Vaporised at very high heat it acts as a catalyst in reactions that produce more specialised materials.
• Borolium — Has many uses, but most commonly it is combined with agarite to create a super-strong alloy. On its own it is used extensively in weapons and energy reactors.
• Chronogen — Crystals with a burnt reddish colour. Used across many applications, but especially in weaponry such as plasma systems.
• DARR-4 — Crystals with a bluish tint. Used widely, but especially in high-tech applications such as disrupter technology.
• Exillium — Dull green crystals. Used across many applications, but especially in structural work such as improving armour.
• FORTON-D — Quite rare. Alloyed with borolium it produces a highly mirrored finish on armour, useful for deflecting laser and plasma weapons.
• Greophite — A super-conductive mineral alloy used in high-voltage applications. It can also be processed into a crystal lattice that is extremely hard — prized for armour and armour-piercing projectiles.
• Helion — An inert gas used in high-capacity energy cells and reactors, and during the construction process for many applications.
• I-77E — Incredibly rare and extremely precious — though only small amounts are needed. Used in high-precision laser lenses, high-explosives, and as an intermediary catalyst in manufacturing.

3.1 Refining mechanics#

Implemented by RefiningOperation (services.cpp:68-266).

• Step granularity. One step = input_units ore (10,000 for all real ores). The move specifies an amount n; it must be an exact multiple of the per-step input or the op is invalid (services.cpp:197-225, esp. 206). GetSteps() = amount / inputUnitsPerStep (services.cpp:107-111).
• Output. For each step, every entry in refines.outputs is added: steps × output_qty (services.cpp:248-266).
• Cost. Base cost = steps × refines.cost vCHI, all burnt (services.cpp:128-133). For real ores cost = 1, so refining 10,000 ore = 1 vCHI; refining 50,000 = 5 vCHI.
• Balance check. You must hold amount of the ore in the operating inventory (services.cpp:214-222).
• Where. Either inside a building offering the refining service (services.cpp:115-120) or with a mobile refinery-fitted character (services.cpp:122-126, see §3.3).

3.2 Move schema — refining in a building (t: "ref")#

Parsed by ServiceOperation::Parse → ParseItemAmount<RefiningOperation> (services.cpp:1217-1218, 1147-1167). The object must have exactly 4 keys (services.cpp:1154):

{
  "t": "ref",
  "b": 100,
  "i": "raw a",
  "n": 30000
}

Service moves are submitted under the account-level svc array in a Taurion move (an array of service-operation objects). Example refining 30,000 raw a (3 steps → mat a×3000, mat b×900, 3 vCHI burnt).

Pending JSON emitted for this op (services.cpp:227-246):

{
  "type": "refining",
  "building": 100,
  "input": {"raw a": 30000},
  "output": {"mat a": 3000, "mat b": 900},
  "cost": {"base": 3, "fee": 0}
}

Test-config example (uses fictitious test ore: input_units:3, cost:10, outputs bar×2, zerospace×1, items/test.pb.text:22-36). Refining n:3 → base cost 10, output {bar:2, zerospace:1} (services_tests.cpp:131-150).

3.3 Mobile refining (refinery fitment, no building)#

A character with a Mobile Refinery (vhf refinery, "Mobile Refinery") fitted can refine in the field. The fitment carries refining{ input{ percent: 100 } } (fitments.pb.text:2602-2622).

• The input modifier is a StatModifier applied to input_units. Applying percent: 100 doubles the requirement: effective = base + base×100/100 = 2×base (modifier.hpp:79-92, services.cpp:96-101). So a mobile refinery is half as efficient — it consumes twice the ore per step for the same output. (Confirmed by MobileRefiningTests.MultipleSteps: with the per-step input doubled from 3 to 6, n:18 → 3 steps, services_tests.cpp:597-608.)
• No service fee is ever charged for character-based ops (services.cpp:991-997), only the burnt base cost.

Move schema — mobile refining (ServiceOperation::ParseMobileRefining, services.cpp:1245-1275; object must have exactly 2 keys, 1254). This is submitted inside a character command rather than the account svc list:

{
  "i": "raw a",
  "n": 20000
}

Pending JSON (services_tests.cpp:669-687): building: null, character: <id>, type: "refining", with the same input/output/cost structure.

---

4. Blueprints (bpo / bpc)#

Blueprints are how vehicles, fitments, and (in test data) any with_blueprint item are produced. They are auto-generated item types (§1.1), never listed in config files.

4.1 Original vs copy#

Construction consumption (services.cpp:886-934): when building n items, an original consumes exactly 1 bpo (kept afterwards, 931-932); copies consume n bpc (933-934). The pending/ongoing record stores original_type only when built from an original (services.cpp:949-950, services_tests.cpp:1432,1462).

4.2 Blueprint copying (t: "cp")#

BlueprintCopyOperation (services.cpp:601-735). Takes one original, produces n copies of the same base item.

• Cost = bp_copy_cost × complexity × n vCHI, burnt (services.cpp:630-635).
• Time = bp_copy_blocks × complexity blocks per copy; copies are produced one by one (GetBpCopyBlocks, services.cpp:739-751; scheduling 714-735). The original bpo is removed from inventory immediately when the op starts (services.cpp:720-721) and returned later (it is not destroyed — copies are made from it).
• Requires a building offering the blueprint_copy service (services.cpp:623-628).
• The original must actually be a bpo (services.cpp:656-667); copying a bpc, a bare item, or a non-owned blueprint is invalid (services_tests.cpp:1124-1170).

bp_copy_cost / bp_copy_blocks (per complexity):

Move schema (4 keys, services_tests.cpp:1095-1103 shows extra keys → invalid):

{
  "t": "cp",
  "b": 100,
  "i": "rv s bpo",
  "n": 10
}

Pending JSON (services.cpp:699-711):

{
  "type": "bpcopy",
  "building": 100,
  "original": "rv s bpo",
  "output": {"rv s bpc": 10},
  "cost": {"base": 100, "fee": 0}
}

4.3 Item construction (t: "bld")#

ConstructionOperation (services.cpp:763-960). Consumes a blueprint + the base item's construction_resources to build n units of the base item.

• Cost = construction_cost × complexity × n vCHI, burnt (services.cpp:790-796).
• Time = construction_blocks × complexity blocks per item (GetConstructionBlocks, services.cpp:955-960).
• Resources consumed = for each construction_resources entry, qty × n (services.cpp:869-883, 925-929).
• Blueprint consumed: 1 if bpo, n if bpc (§4.1).
• Service required: vehicle_construction if the output is a vehicle, otherwise item_construction (services.cpp:833-843).
• Faction lock: if the output item has a faction, the account's faction must match (services.cpp:854-867; services_tests.cpp:1334-1361).

construction_cost / construction_blocks (per complexity):

Move schema (4 keys):

{
  "t": "bld",
  "b": 100,
  "i": "rv s bpo",
  "n": 5
}

Pending JSON (services.cpp:903-915):

{
  "type": "construct",
  "building": 100,
  "blueprint": "rv s bpo",
  "output": {"rv s": 5},
  "cost": {"base": 50, "fee": 0}
}

(rv s has complexity 10, so building 5 costs 1×10×5 = 50 vCHI on mainnet.)

4.4 What each blueprint builds — construction recipes#

Every with_blueprint: true item gets a bpo/bpc. The full set of real blueprintable items: all 33 non-starter vehicles (11 roles per faction × r/g/b; the 3 starter vehicles *v st are not blueprintable, so the world has 36 vehicle types in total but only 33 you can build — verified: 33 top-level keys in vehicles_others.pb.text, 3 in vehicles_starter.pb.text) and all 104 fitments (catalogued with full recipes in §4A). Below are the vehicle recipes (materials per single unit, complexity, and the resulting cargo space). All vehicle items have item-space: 10 and with_blueprint: true (proto/roconfig/items/vehicles_others.pb.text). The recipe is identical across the three factions for a given size/role; only the equipment-slot layout differs (see vehicles doc).

(Materials abbreviated by their letter, e.g. a = mat a Agarite. Source rows in vehicles_others.pb.text, e.g. rv s 1-29, rv vla 329-364; faction copies follow. Starter vehicles *v st are not blueprintable and are in vehicles_starter.pb.text.)

All 104 fitments are blueprintable too (e.g. the Mobile Refinery vhf refinery, complexity 2000, item-space 1000, recipe a 36,000 · b 36,000 · c 6,000 · d 6,000 · e 6,000 · f 18,000 · g 6,000 · h 4,800 · i 1,200 — fitments.pb.text:2600-2623). The complete fitment recipe catalog — every code, complexity, faction/size/slot constraint and per-tier recipe — is in §4A below.

---

4A. Fitments (equippable modules) — complete catalog#

Fitments are the equippable modules that customise a vehicle: weapons, shields, engines, cargo expanders, mining/prospecting tools, the mobile refinery, etc. They are ordinary fungible_items whose ItemData carries a FitmentData (config.proto:151-217). Unlike vehicles, a fitment's faction is set explicitly in the config (not inferred from the name; config.proto:245-246).

All fitments live in proto/roconfig/items/fitments.pb.text — exactly 104 top-level fungible_items entries across 29 families. Naming convention: a size-tier prefix + family suffix, e.g. lf gun = Light Rail Gun, vhf missile = Very Heavy Missile Launcher. Tiers (fitments.cpp):

25 families exist in all four tiers (100 items); lf pick (Tritanian Drill) and lf scanner (Graviton Spectrometer) are Light-only; vhf mentecon (Targeting System Disruptor) and vhf refinery (Mobile Refinery) are Very-Heavy-only. That is 100 + 2 + 2 = 104. Display names are the ones shown in the game UI.

4A.1 Shared item-level properties (true for every fitment)#

These hold for all 104 entries (verified across fitments.pb.text):

Construction recipe is identical for every fitment within a tier. All lf fitments share one recipe, all mf another, etc. (verified: each tier has exactly one distinct construction_resources set across all its families). So the recipe is a function of the tier only, while the complexity varies by family. Materials per single unit:

Tier	Recipe (per unit, mat … abbreviated by letter)	Source
lf	a 2,500 · b 2,500	fitments.pb.text:9-10
mf	a 4,500 · b 4,500 · f 1,000	fitments.pb.text:39-41
hf	a 24,000 · b 24,000 · f 9,000 · g 3,000	fitments.pb.text:70-73
vhf	a 36,000 · b 36,000 · c 6,000 · d 6,000 · e 6,000 · f 18,000 · g 6,000 · h 4,800 · i 1,200	fitments.pb.text:102-110

(a=mat a Agarite, b=Borolium, c=Chronogen, d=DARR-4, e=Exillium, f=FORTON-D, g=Greophite, h=Helion, i=I-77E — see §3.) Build cost on mainnet = construction_cost(1) × complexity × n vCHI burnt, taking construction_blocks(1) × complexity blocks per unit (§4.3). E.g. a single lf gun (complexity 2) costs 2 vCHI + 2,500 mat a + 2,500 mat b, in 2 blocks; a single vhf refinery (complexity 2000) costs 2,000 vCHI + the full vhf recipe, in 2,000 blocks.

4A.2 Complexity by family and tier#

Complexity per <tier> <family> item. Where a cell is "—" the item does not exist. Fac = faction lock (— = neutral); Slot = slot type; SzLock = vehicle_size lock (— = mounts on any size). For families that span all four tiers, Fac/Slot are constant across tiers; SzLock for size-locked families tracks the tier (lf→LIGHT, mf→MEDIUM, hf→HEAVY, vhf→VERY_HEAVY). All values from fitments.pb.text.

Notes:

• Faction-locked families (10 items each unless noted): laser/selfdestruct are Red (r), hitred/mentecon are Blue (b), plating/lowhpboost are Green (g). All other families are faction-neutral and fit any faction's vehicles. (mentecon is Blue and Very-Heavy-only; one item.)
• Size-locked families (SzLock = size): the fitment carries vehicle_size matching its tier, so e.g. an lf shield only fits a LIGHT vehicle, hf shield only a HEAVY one. Families with SzLock = — (all high-slot weapons, turbo, hitred, mentecon, refinery) have no size restriction.
• retarder/longretard are the only families whose complexity differs from the generic 2/40/100/400 ladder (they are 3/50/120/500).

4A.3 Effect summary per family#

Each fitment's FitmentData sets exactly one effect mechanism. Stat modifiers are StatModifier{percent|absolute} (modifier.proto:28-42); they are summed across all fitments and applied once, non-compounding (fitments.cpp:165-292). Combat attacks/self-destructs/low-HP-boosts are added to the vehicle's combat data (a vehicle has no base weapons — every attack comes from a fitment). Full combat math is in the combat doc (Combat §10); the table below is the item-level effect each family applies and the proto field it sets.

armourregen absolute values (the only family using absolute rather than percent): lf +2000, mf +4000, hf +8000, vhf +14000 milli-HP/block of armour regen (fitments.pb.text:2316, 2337, 2359, 2386).

4A.4 Acquiring fitment blueprints#

Like vehicles, a fitment is built from a <code> bpo (reusable original) or <code> bpc (one-shot copy) via the bld service in a building offering item_construction (note: item_construction, not vehicle_construction — fitments are not vehicles; services.cpp:833-843). A bpo is obtained primarily by reverse-engineering an artefact (§5), but not every fitment is in an artefact's reveng list:

• Reverse-engineerable fitments (62 items, 17 families) appear in the artefact possible_outputs (artefacts.pb.text), tiered by artefact rarity:
  • art c (common) → all lf fitments of: retarder, longretard, bomb, missile, pick, scanner, laser, selfdestruct, shield, replenisher, rangeext, turbo, expander, dmgext, multiplier, lowhpboost, plating (artefacts.pb.text:19-35).
  • art uc (uncommon) → the same 15 families in mf (no pick/scanner, which are Light-only) (artefacts.pb.text:58-72).
  • art r (rare) → the same 15 families in hf (artefacts.pb.text:95-109).
  • art ur (ultra-rare) → the same 15 families in vhf (artefacts.pb.text:129-143).
• NOT reverse-engineerable (42 items, 12 families) — never listed in any artefact: every beam, gun, syphon, syphonaoe, allyreplenish, rangered, hitext, hitred, dmgred, armourregen (all tiers), plus vhf mentecon and vhf refinery. Their blueprint-acquisition path is not reverse engineering; the only in-GSP way to obtain such a bpo is to already hold one and construct/copy from it. (Where the first such bpo comes from on mainnet — prize, special seeding, etc. — is not determinable from the config; see Open questions.) Note new characters do spawn with one free equipped lf gun (spawn.cpp:143), but that is the fitment item, not a blueprint.

Cost/time/consumption for fitment construction and copying are exactly as in §4.3 / §4.2 (cost = construction_cost × complexity × n, etc.), using the per-item complexity from §4A.2.

Example — construct 1 vhf refinery (Mobile Refinery) on mainnet:

{
  "t": "bld",
  "b": 100,
  "i": "vhf refinery bpo",
  "n": 1
}

Burns 1 × 2000 × 1 = 2000 vCHI, consumes the full vhf recipe (36,000 mat a + 36,000 mat b + 6,000 mat c + 6,000 mat d + 6,000 mat e + 18,000 mat f + 6,000 mat g + 4,800 mat h + 1,200 mat i), keeps the bpo, and takes 1 × 2000 = 2000 blocks. Pending JSON mirrors §4.3 with output: {"vhf refinery": 1}.

---

5. Artefacts & reverse engineering#

5.1 The 4 artefacts#

Defined in proto/roconfig/items/artefacts.pb.text. Each has space: 1 and a reveng block listing the blueprint originals it can yield. All four use cost: 1 (vCHI per reveng attempt, burnt).

Display names are the ones shown in the game UI. (Artefacts are obtained while mining — see §5.3.)

5.2 What each artefact reverse-engineers into#

The possible_outputs list per artefact (artefacts.pb.text). All outputs are blueprint originals ( bpo). The list spans all three vehicle factions plus faction-neutral fitments; the player's own faction filters it at roll time (§5.4).

art c — common (artefacts.pb.text:1-38): each faction's s, sc, sa vehicle bpos (Looter/Finder/Devourer + Blue/Green equivalents), plus the light fitment line lf …: retarder, longretard, bomb, missile, pick, scanner, laser, selfdestruct, shield, replenisher, rangeext, turbo, expander, dmgext, multiplier, lowhpboost, plating.

art uc — uncommon (artefacts.pb.text:40-75): each faction's m, mt, ma vehicle bpos (Pillager/Blood Carrier/Exterminator + …), plus the medium fitment line mf … (retarder, longretard, bomb, missile, laser, selfdestruct, shield, replenisher, rangeext, turbo, expander, dmgext, multiplier, lowhpboost, plating).

art r — rare (artefacts.pb.text:77-112): each faction's l, lt, la vehicle bpos (Marauder/Bone Carrier/Devastator + …), plus the heavy fitment line hf … (same fitment set as mf …).

art ur — ultra-rare (artefacts.pb.text:114-146): each faction's vlt and vla vehicle bpos (Skull Carrier/Annihilator + …), plus the very-heavy fitment line vhf … (same fitment set).

Notes: each artefact yields 15 fitment families in its tier (17 for art c, which adds the Light-only lf pick Tritanian Drill and lf scanner Graviton Spectrometer). 12 fitment families never appear in any artefact (42 items): beam, gun, syphon, syphonaoe, allyreplenish, rangered, hitext, hitred, dmgred, armourregen, mentecon, refinery. The full reverse-engineerable-vs-not breakdown is in §4A.4. Starter vehicles (*v st) are also not reverse-engineerable. For the non-reveng items the only in-GSP bpo source is constructing/copying from a pre-existing original — see Open questions.

5.3 Which artefacts each ore drops#

When mining (or prospecting) finds an ore, an artefact may be found alongside it. The mapping is in resourcedist.pb.text:4-88 (ResourceDistribution.possible_artefacts, config.proto:412-436). Entries are checked in order; each entry's probability is a 1 / N chance, and the first entry that hits is taken (config.proto:418-431).

Because entries are evaluated in order and stop at the first hit, the effective chance of the rarer tiers is conditioned on the earlier ones missing (e.g. for raw h: P(common) = 1/20; P(uncommon) = (19/20)(1/50); etc.). Rarer ores (deeper in the map, see the areas list resourcedist.pb.text:90-565) are the only source of rare/ultra-rare artefacts.

5.4 Reverse-engineering mechanics (t: "rve")#

RevEngOperation (services.cpp:444-594).

1. Filter by faction. Build the candidate list from possible_outputs, keeping only items that are faction-neutral or match the account's faction (services.cpp:561-573). A green player can never get a red-only bpo, etc. (services_tests.cpp:1015-1061).
2. Per attempt (loop num times, services.cpp:575-593):
   • Pick one candidate uniformly at random (rnd.NextInt(size), 577). Exactly one random pick per attempt — no re-rolls — even if it later fails.
   • Look up how many of that exact blueprint already exist game-wide (itemCounts.GetFound(outType), 580).
   • Success chance = RevEngSuccessChance(existingCount) as 1 / chance (581-582). On success, 1 bpo is added and the global found-count is incremented (588-592). On failure, nothing is produced — but the artefact is still consumed (the num artefacts are removed up-front, 554-555).
3. Cost = num × reveng.cost vCHI, burnt (services.cpp:470-474); for real artefacts cost = 1, so each attempt burns 1 vCHI regardless of success.
4. Requires a building offering reverse_engineering (services.cpp:463-468).

Diminishing returns: RevEngSuccessChance (params.cpp:51-92)

The more copies of a specific blueprint already exist, the rarer the next one becomes. Starting from a base 1/N, each existing blueprint multiplies N by 4/3:

chance(existing) = base × (4/3)^existing      // returned as the N in "1 / N"

with a floor at 1/1,000,000,000 (minChance, params.cpp:55, 84-87).

So on mainnet the first ever copy of a given bpo succeeds at 1/10; after 1 exists the next is ~1/13.3; after 10 exist it is ~1/176; etc. This makes subsequent copies of any blueprint progressively harder, encouraging diversity. (Confirmed by RevEngTests.ManyTries: more sword than bow blueprints found because bow had a 10-blueprint head start, services_tests.cpp:982-1013.)

No "tech levels." There is no separate tech-tier system: item stats are fixed in config, so a blueprint never becomes more powerful, and the global found-count only makes a given blueprint progressively rarer to obtain. The only power ladder is item size (Light → Very-Heavy), climbed by reverse-engineering rarer artefacts (§5.3) — not by accumulating them. (The lone roconfig.hpp:87 "tech levels" comment is unused/dead.) A "Tech 2" tier may be added in a future update, but it is not part of the current rules.

Move schema (t: "rve", 4 keys)

{
  "t": "rve",
  "b": 100,
  "i": "art c",
  "n": 5
}

Pending JSON (services.cpp:534-545) — note it only reports input, since outputs are random and resolved at execution:

{
  "type": "reveng",
  "building": 100,
  "input": {"art c": 5},
  "cost": {"base": 5, "fee": 0}
}

---

6. Prizes#

Prizes are auto-generated items of the form "<name> prize" for each configured prospecting prize (roconfig.cpp:346-360). They have space: 0 and only a prize{} marker — no further mechanics in the GSP (they are partner-game rewards / collectibles handed out by prospecting; see prospecting doc for win odds).

• Mainnet prize list: params.pb.text:54-110 (e.g. "cash", plus dozens of partner rewards like Prison Key Card, Temporal Disrupter, Medium Transport, …). Each entry has name, number (total available), probability (1/N to win).
• Testnet/regtest replaces the list entirely (config.proto:603-611, roconfig.cpp:136): gold/silver/bronze (test_params.pb.text:25-27).
• Display names for partner prizes are the ones shown in the game UI.

Example item code: a winner of the Tritanian Drill Taurion prize holds the item "Tritanian Drill prize" (display Tritanian Drill (Taurion)).

---

7. Costs, fees, and burning#

Every service operation has a base cost (always burnt) and an optional service fee (paid to the building owner). Computed in ServiceOperation::GetCosts (services.cpp:985-1016) and Execute (services.cpp:1127-1145):

• base is the op-specific burnt cost (refining/reveng/copy/construct as above).
• No fee when: the op is character-based (mobile refining), the building is ancient (faction ANCIENT), or the operator owns the building (services.cpp:991-1009).
• Otherwise fee = ceil(base × service_fee_percent / 100) (services.cpp:1011-1016), with service_fee_percent from the building's config.
• The op is rejected if base + fee > account balance (services.cpp:1091-1100).

Service-cost-relevant params:

(Refining and reverse-engineering base costs come from the item config, not from Params.) Armour repair (t: "fix") is documented in the combat/repair doc; it is a service op but produces no items.

---

8. Quick reference — all service moves#

All except mobile refining take b (building id) and are submitted in the account svc list. Mobile refining ({"i","n"}) is a character command (services.cpp:1245-1275).

---

9. Worked example — full ore-to-vehicle pipeline#

Build one rv s (Looter, complexity 10) on mainnet from scratch:

1. Mine raw a (Trimideum) and raw b (Talon). A Looter needs mat a×52,500 and mat b×22,500 (vehicles_others.pb.text:9-10).
2. Refine ore in a refining building:
   • raw a: 1 step (10,000) → mat a×1000 + mat b×300. To get 52,500 mat a you need ≥53 steps of raw a (each step also yields 300 mat b).
   • raw b: 1 step (10,000) → mat a×200 + mat b×800. Top up mat b as needed.
   • Each step burns 1 vCHI.
3. Obtain a Looter blueprint: reverse-engineer art c (common) at a building with reverse_engineering. On success you get rv s bpo (or some other common bpo — it is random and faction-filtered). Each attempt burns 1 vCHI and consumes 1 artefact; first-ever success chance 1/10.
4. (Optional) Copy the rv s bpo into rv s bpc via t:"cp" for mass production (1 vCHI × complexity 10 = 10 vCHI per copy; 10 blocks each).
5. Construct with t:"bld", i:"rv s bpo", n:1: burns 1×10×1 = 10 vCHI, consumes 52,500 mat a + 22,500 mat b, keeps the bpo, takes construction_blocks×complexity = 1×10 = 10 blocks.

---

Open questions#

1. raw f display/icon name mismatch. The game UI gives the display name "Voltar" but its icon for the same ore uses the spelling "Voltan". materials.pb.text has no display-name source; all material names come solely from the game UI. Which spelling is canonical for new UI?
2. Mobile Refinery blueprint origin. vhf refinery is with_blueprint: true (so a vhf refinery bpo exists and can be constructed/copied), but it is not listed among any artefact's reveng possible_outputs. How is the first vhf refinery bpo meant to be obtained on mainnet — prize, special distribution, or initial seeding? (Not determinable from the GSP config alone.)
3. Non-reverse-engineerable fitment blueprints (42 items). Twelve fitment families — beam, gun, syphon, syphonaoe, allyreplenish, rangered, hitext, hitred, dmgred, armourregen (all tiers), plus vhf mentecon and vhf refinery (covered separately in Q2) — appear in the game UI and in fitments.pb.text with with_blueprint: true, but are not in any artefact's reveng possible_outputs (verified against artefacts.pb.text; see §4A.4). Their bpo acquisition path (if any beyond constructing/copying from a pre-existing original) is not specified in the items/refining/artefact code reviewed here. Whether these are intended as drops, prizes, special distributions, or simply "starter-economy seeded" is a design decision not encoded in the GSP config.
4. Cargo space units. Vehicle cargo_space values (e.g. 3,600,000) are raw proto integers; ores/materials cost space: 1 per unit. The doc states the literal relationship (1 ore = 1 space), but the intended display scaling of the large cargo_space numbers (whether the UI divides by 1000, etc.) is a client concern not fixed by the GSP.
5. Refining yield "loss". Refining 10,000 ore yields far fewer than 10,000 total material units (e.g. raw f → 350 mat f). This is intentional mass-loss, but the exact economic intent (sink rate per ore) is a design parameter worth confirming against the burnsale/economy model.