Vehicles

For players (plain language). In Taurion you never walk around on foot — your character (your pilot) is always sitting inside a vehicle, and the vehicle is what gives you all your stats: how much loot you can carry, how fast you move, how tough you are in a fight, and whether you can mine ore or prospect for new deposits. Each of the three factions has its own 12-vehicle line with its own flavour names — for example the Red starter is the Raider, the Green starter is the Scarab, and the Blue starter is the Barracuda. You get one free starter vehicle the moment you create a character; every other vehicle is built from a blueprint using refined materials and a small amount of in-game currency (vCHI — the game's spendable token, also called CHI). Bigger vehicles cost far more and take far longer to build, but carry more, hit harder and survive longer. Stronger gear ("fitments" — the weapons and modules you bolt onto a vehicle) is covered in the items doc. The tables below list every vehicle with both its in-game display name and its internal code.

Jargon, once. GSP = Game State Processor, the server program that runs the game's rules. Fitment = a mountable equipment item (weapon or module). vCHI = the spendable in-game currency (CHI). Blueprint = the recipe item needed to build a vehicle. Block = one step of game time (roughly, one blockchain block).

Source of truth. Every number, slot count, resource cost and rule in this document comes directly from the Game State Processor (GSP) config protos and C++ source. Display names are the ones shown in the official client; the item codes are what appears on-chain and in the GSP API. Where a value is invented or interpreted, it is flagged explicitly.

In Taurion a "character" is a pilot/avatar that is always inside a vehicle. The vehicle the character occupies determines all of its on-map stats: cargo, speed, HP/regen, combat, mining and prospecting capability, and how many fitments (equipment) it can carry. A character cannot exist without a vehicle — when one is spawned it is immediately placed into the faction starter vehicle (src/spawn.cpp:124-145).

There are three faction vehicle lines, each with 12 vehicle types (36 total). The internal code prefix encodes the faction; the GSP infers faction purely from the name prefix (proto/roconfig.cpp:259-265, :371-383):

---

1. How vehicle stats are read and applied#

A vehicle type is one entry in the fungible_items map whose ItemData carries a VehicleData message (proto/config.proto:114-146). The wrapper ItemData fields that matter for vehicles (proto/config.proto:222-277):

VehicleData fields (proto/config.proto:114-146):

Stat derivation at runtime#

When a vehicle is entered or fitments change, DeriveCharacterStats (src/fitments.cpp:296-311) does:

1. InitCharacterStats copies the base VehicleData onto the character: cargo, speed, combat data, regen/max-HP, mining rate, prospecting blocks (fitments.cpp:131-156). A vehicle has no refining ability by default (fitments.cpp:154-155).
2. ApplyFitments sums all fitment stat modifiers (non-compounding) and applies them once (fitments.cpp:162-292): adds attacks/self-destructs/low-HP-boosts, modifies cargo, speed, prospecting (floored at 1 block), mining min/max, max armour/shield, shield/armour regen, attack range/damage, received damage, hit chance, and may add a mobile refinery.
3. Current HP is reset to max (fitments.cpp:310).

Slot-key strings are exactly "high", "mid", "low" (config.proto:138-144). A vehicle with value: 0 for a slot type, or no entry at all, has zero slots of that type.

---

2. Fitment / equipment capacity rules#

The complete fitment catalog (all 104 fitment item types, their codes, complexity, faction/size/slot constraints, construction recipes and effects) is in the items doc (Items & Materials §4A). The combat semantics of weapon/support fitments are in the combat doc (Combat §10). This section covers only the capacity rules that gate which fitments a given vehicle can mount.

CheckVehicleFitments (src/fitments.cpp:34-122) validates a proposed loadout:

• Complexity budget. Sum of fitment complexity must be <= the vehicle's available complexity. Available = base complexity modified by any fitment that itself modifies complexity (fitments.cpp:88-97). For a stock vehicle the budget equals the complexity value in the tables below.
• Slot counts. Fitments are counted per slot type (high/mid/low); a type that the vehicle lacks, or over-subscribing a type, fails (fitments.cpp:99-119).
• Size lock. A fitment with vehicle_size set only mounts on a vehicle of that exact size (fitments.cpp:61-70).
• Faction lock. If both fitment and vehicle declare a faction, they must match (fitments.cpp:76-84). On mainnet all vehicles are faction-bound, so a faction-specific fitment only fits its own faction's vehicles.

Note on complexity dual use. The same complexity value is the fitment budget and the construction time/cost multiplier (see §4). A Looter (complexity: 10) costs 10 × construction_cost vCHI and takes 10 × construction_blocks blocks to build, and can hold up to 10 complexity of fitments.

2.1 What competes for each slot type (fitment families by slot)#

A vehicle's equipment_slots budget is split across three slot types, and each fitment family is hard-bound to one slot type (fitment.slot, fitments.pb.text). This is why the faction slot-skew (§3.4) is meaningful: a Red vehicle's extra high slots only buy high-slot gear, etc. The table groups all 29 fitment families by the slot they consume. Full per-family stats, complexity, size/faction locks and recipes are in the items doc (Items & Materials §4A); combat math in (Combat §10). Faction-locked families are flagged (r/g/b).

Slot/lock interactions for the support & control families (the ones easy to miss because they are not "weapons"):

• Mid-slot support: allyreplenish (Shield Projector) is a friendly AoE that buffs allies' shield regen; rangered (Spatial Blur) and hitred (Tracking Disrupter) are enemy-debuff AoEs; hitext (Tracking Enhancer) buffs the owner's own hit chance. hitred and mentecon are Blue-only (faction: "b") and not size-locked. mentecon (Targeting System Disruptor) exists only as vhf mentecon, complexity 500.
• Low-slot armour: dmgred (Armour Hardener, −5% received damage) and armourregen (Armour Repair, the sole source of armour regen) are size-locked, faction-neutral. plating/lowhpboost are Green-only.
• High-slot drains: syphon/syphonaoe (Syphon / Syphon Field) drain shield only and return it to the attacker; they are size-neutral, so any tier mounts on any vehicle with a free high slot.

---

3. Vehicle stat tables#

Each table column maps to a proto field as defined in §1. HP is shown as armour / shield; Regen is shield-regen in milli-HP/block (no vehicle has base armour regen). Slots is high / mid / low. Speed is the raw milli-tiles/block value (÷1000 = tiles/block). Mine is mining_rate.max (min is always 0). Prosp is prospecting_blocks (— = cannot prospect). Cmplx is complexity.

3.1 Red / Jodon line (rv)#

Source: vehicles_starter.pb.text:1-24, vehicles_others.pb.text:1-364. Display names are the ones shown in the game UI.

3.2 Green / Ephrati line (gv)#

Source: vehicles_starter.pb.text:51-74, vehicles_others.pb.text:731-1094. Display names are the ones shown in the game UI.

3.3 Blue / Reubo line (bv)#

Source: vehicles_starter.pb.text:26-49, vehicles_others.pb.text:366-729. Display names are the ones shown in the game UI.

3.4 Cross-faction observations (load-bearing for design)#

• All three lines share identical base stats for every column except equipment_slots. The only mechanical difference between factions is the slot distribution (and the resulting fitment archetype each faction favours):
  • Red (Jodon) skews high (offensive weapon) slots.
  • Blue (Reubo) skews mid slots.
  • Green (Ephrati) skews low (utility/support) slots.
  • Verify with any matching pair, e.g. rv l (Marauder) = 4/2/4, bv l (Moray) = 3/4/3, gv l (Millipede) = 2/3/5 (vehicles_others.pb.text:86-88, 451-453, 816-818).
• Role families (suffix conventions, same across factions):
  • st = starter (size STARTER, only obtainable by spawning).
  • s/m/l = baseline general-purpose light/medium/heavy.
  • sc = scout (Red Finder / Green Flea / Blue Octo): fastest (speed 5500), zero cargo, cannot mine, best prospecting tier among LIGHT (5 blocks), low HP. Pure recon.
  • mt/lt/vlt = transports (e.g. Red Blood Carrier/Bone Carrier/ Skull Carrier, Green Horse/Ox/Elephant, Blue Cobra/Trident/ Hydra): massive cargo (up to 2.6 billion for vlt), high armour but low shield/regen, weak mining, sparse weapon slots. Logistics haulers.
  • sa/ma/la/vla = attack/assault (e.g. Red Devourer/Exterminator/ Devastator/Annihilator, Green Bee/Wasp/Hornet/Widow, Blue Gorgon/Siren/Poseidon/Leviathan): most weapon slots, highest shield + shield regen, best mining rates, but the fastest-decaying prospecting capability (down to 3 blocks at vla).
• Starters are the only STARTER-size vehicles, the only ones with no blueprint, the only ones whose cargo is 1,000,000 and complexity 2.

---

4. How a player obtains each vehicle#

4.1 Starter vehicles (rv st, gv st, bv st)#

Obtained only by spawning a new character. A character cannot be created without one. SpawnCharacter (src/spawn.cpp:116-152):

• Faction → starter vehicle mapping is hardcoded: RED→rv st (Raider), GREEN→gv st (Scarab), BLUE→bv st (Barracuda) (spawn.cpp:126-142).
• The new character is also given one free lf gun (Light Rail Gun) fitment in its single high slot (spawn.cpp:143).
• The character spawns inside its faction's spawn building (spawn.cpp:147-151; spawn building IDs in params.pb.text:33-47: r→6, g→4, b→5).

Creating a character costs character_cost (10 vCHI on mainnet, params.pb.text:3), with a per-account character_limit of 20 (params.pb.text:4). Starter vehicles cannot be constructed (they have no with_blueprint), and they are not sold or dropped — one per character spawn.

4.2 All other vehicles — construction from a blueprint#

Every non-starter vehicle has with_blueprint: true and a construction_resources map, so it is built via the construction service inside a building that offers vehicle_construction.

Blueprint item codes are auto-derived by appending a suffix to the vehicle code (proto/roconfig.cpp:248-251, 314-344):

Each blueprint occupies space: 1 (roconfig.cpp:256-257).

Construction move (service type "bld") — JSON schema (src/services.cpp:1147-1167, 1226-1228):

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

Field semantics:

The object must have exactly 4 keys or it is rejected (services.cpp:1153-1155; see services_tests.cpp:1235-1262 for rejected malformed examples). This service move is itself wrapped in a top-level account move; the GSP routes by the "t" value.

Construction rules (src/services.cpp:763-960):

1. Building support. The building's offered_services.vehicle_construction must be true for vehicle outputs (services.cpp:833-843). Buildings that offer it: the three ancient hubs (ancient1, ancient2, ancient3), every faction Vehicle Bay *_vb (b_vb/g_vb/r_vb), Central Foundry *_cf (b_cf/g_cf/r_cf), Starter Station *_ss (b_ss/g_ss/r_ss), every *_cc building (b_cc/g_cc/r_cc), and several constructed building tiers (r_c1/r_c5/r_c9/g_c3/g_c7/b_c4/b_c8); building names are catalogued in the buildings doc (Buildings). Grep vehicle_construction: true under proto/roconfig/buildings/ for the full set (22 production building configs offer it as of this writing, plus test-only configs). (Foundations — buildings still under construction — cannot host any service: services.cpp:1200-1205.)
2. Faction lock. The output vehicle's faction (from prefix) must equal the account's faction or the move is invalid (services.cpp:854-867).
3. Resources. The required construction_resources × n of each refined material must be present in the account's inventory in that building (services.cpp:869-883). They are debited on execution (services.cpp:925-929).
4. Blueprint consumption. Building from an original (bpo) requires only 1 original present and consumes it... actually it debits 1 original total regardless of n and the original is not destroyed in the normal sense — the code path debits the blueprint by 1 and the ongoing operation re-disperses it (services.cpp:885-898, 931-934, 939-951). Building from copies (bpc) requires and consumes n copies (services.cpp:887-890, 933-934). In short: originals are reusable, copies are one-shot.
5. Cost (vCHI, burnt as base cost). base = construction_cost × complexity × n (services.cpp:790-796). On mainnet construction_cost = 1 vCHI/complexity (params.pb.text:15); on testnet/regtest it is 100 (test_params.pb.text:10).
6. Time. The ongoing operation completes after construction_blocks × complexity blocks per item (services.cpp:943, 955-960). Mainnet construction_blocks = 1 (params.pb.text:16); testnet/regtest = 10 (test_params.pb.text:11). When building n from an original, the first is dispersed after one item's time and the rest are scheduled subsequently (services.cpp:939-951).
7. Service fee. On top of the burnt base cost, if the building is owned by another player a service fee is paid to the owner: fee = ceil(base × service_fee_percent / 100) (services.cpp:1011-1015). The fee is 0 in ancient buildings and 0 when you use your own building (services.cpp:999-1007).

4.3 Where blueprints come from#

A construction blueprint original (...bpo) is obtained primarily by reverse-engineering an artefact (the rve service). The artefact config lists which blueprint originals each artefact tier can yield (proto/roconfig/items/artefacts.pb.text):

Reverse-engineering is probabilistic: success chance is 1/N where the base N is 10 on mainnet/testnet/Polygon (1 on regtest/ganache) and grows by ×4/3 for each blueprint of that type the player already holds, with N capped at 1,000,000,000 — i.e. the worst-case success chance is 1/1,000,000,000 (minChance = 1'000'000'000, src/params.cpp:51-92). Originals can then be copied into single-use copies via the cp service at bp_copy_cost × complexity vCHI over bp_copy_blocks × complexity blocks (mainnet both = 1; testnet 100/10 — params.pb.text:13-14, test_params.pb.text:8-9, services.cpp:742-749).

"Medium Transport (Taurion)" prospecting prize. The prospecting prize list includes a Medium Transport prize (params.pb.text:104). This is delivered as a generic prize item ( prize suffix, roconfig.cpp:346-360), not a direct grant of a mt vehicle; treat it as flavour/partner reward rather than a construction path.

4.4 Swapping vehicles (the v move)#

Once a player owns multiple vehicle items, the active character can switch which vehicle it occupies inside a building via the character-update v field (src/moveprocessor.cpp:981-1038, 1593-1610).

{
  "c": {
    "id": 1,
    "v": "rv m"
  }
}

(here "rv m" is the Pillager — the v field always takes the internal vehicle code, never the display name.)

Rules: the character must be at full armour and shield HP (moveprocessor.cpp:992-998, 963-977), inside a non-foundation building (moveprocessor.cpp:1000-1019), the target must be a valid vehicle item (moveprocessor.cpp:1021-1026), and the player must own ≥1 of that vehicle in that building's account inventory (moveprocessor.cpp:1028-1035). On swap the old vehicle is returned to inventory (+1) and the new one removed (−1) (moveprocessor.cpp:1607-1610); stats are then re-derived. The v value must be a string; objects/numbers are rejected (moveprocessor_tests.cpp:1506-1542).

4.5 Changing fitments (the fit move)#

{
  "c": {
    "id": 1,
    "v": "rv s",
    "fit": ["lf gun", "lf shield", "lf pick", "lf expander"]
  }
}

fit is an array of fitment codes (moveprocessor.cpp:1040-1092, example moveprocessor_tests.cpp:1488-1494). Same gating as vehicle swap (full HP, in a real building, not a foundation) plus the CheckVehicleFitments constraints in §2. v and fit can be combined in one character update; the vehicle change is applied first, then fitments are validated against the new vehicle. Empty array "fit": [] strips all fitments.

---

5. What the client sees (game-state JSON)#

Per-character output relevant to vehicles (src/gamestatejson.cpp:259-292, :88-166, :205-207):

Display names for any of these codes are supplied by the game UI.

---

6. Mainnet vs testnet/regtest differences#

These affect the economics of obtaining vehicles, not their stats:

Vehicle stats, slots, sizes and construction-resource recipes are identical across chains — the proto text files are not overridden per chain for fungible_items.

---

7. Worked construction example (mainnet)#

Building one Pillager (rv m) — MEDIUM Red transport-class general vehicle:

• Blueprint required: rv m bpo (original, reusable) or rv m bpc (copy, one-shot). Source the original by reverse-engineering an uncommon artefact (art uc, artefacts.pb.text:49).
• Resources (vehicles_others.pb.text:39-41): 260,000 mat a (Agarite), 100,000 mat b (Borolium), 40,000 mat c (Chronogen).
• vCHI base cost: construction_cost(1) × complexity(100) × n(1) = 100 vCHI burnt.
• Time: construction_blocks(1) × complexity(100) = 100 blocks.
• Service fee: 0 if built in an ancient building or your own; otherwise ceil(100 × service_fee_percent / 100) vCHI to the building owner.
• Result: a rv m vehicle item (cargo 11.5M, speed 3500, 100/200 HP, slots 3/1/2). Enter it via the v move inside the building.

---

Open questions#

1. Original-blueprint dispersal nuance. ExecuteSpecific debits the original blueprint by 1 (services.cpp:931-932) and the ongoing operation later re-adds it when items are dispersed (item_construction.original_type is set, services.cpp:949-951). The exact re-credit happens in the ongoings handler (ongoings.cpp), which was not read for this doc; the net effect ("originals are reusable") is confirmed by design intent in the comments (config.proto:75-81, services.cpp:939-942) but the precise block-by-block inventory timing for multi-item original builds is not fully traced here.
2. service_fee_percent range/default. The fee is read from each building's owner-set config (services.cpp:1011-1015); the allowed min/max and default value for that per-building setting live in the building update logic (moveprocessor.cpp:259-278) and were not catalogued in this vehicle doc.
3. Armour regeneration. No vehicle has base armour regen (regeneration_mhp only ever sets shield). Armour regen is purely a fitment effect (fitments.cpp:265); the fitments that grant it are the Armour Repair family (lf/mf/hf/vhf armourregen, armour_regen.absolute = +2000/+4000/+8000/+14000 milli-HP/block), catalogued in the items doc (Items & Materials §4A).