Get desktop application:
View/edit binary Protocol Buffers messages
* General data associated to an account.
* The number of characters killed by the account in total.
* The fame of this account.
* Balance of vCHI for this account.
* Balance of vCHI minted through the burnsale, which corresponds to the balance that will be carried over to the full game.
* Data representing an "armour repair" operation in progress.
Used in:
(message has no fields)
* An attack that a character or building has. This data is either hardcoded (for buildings) or derived from other stuff (like equipped weapons). But it is stored in the current form in the game state as a sort of "cache" while processing combat in each round. (It only needs to be updated when an explicit action is done by the owner of a character.)
Used in: ,
* The range of the attack (as L1 distance on our hex grid). This may be zero in which case it affects only enemies on the same tile. If the value is missing entirely instead, it implies that there will not be a concrete "target", which is the case e.g. for AoE effects around the attacker itself.
* The size of the AoE for this attack, around the selected target (if range is present) or the attacker (if range is not present). If this is not present, then it means that only the target itself is affected.
* If this attack does damage, the stats for it.
* If this attack has non-damage effects, the stats for it.
* If true, then HP drained through this attack's damage will be given back to the attacker (if any). This works per HP type, i.e. shield HP drained are added to the shield (if not full) and armour HP are added to the armour (if not full).
* If true, then this attack affects friendlies instead of enemies. This is used for positive effects, like improved shield regeneration.
* Data about the damage a particular attack does.
Used in: ,
Maximum and minimum damage of the attack. The actual damage will be chosen uniformly from the both-inclusive range.
* If this is set, it specifies the factor (as percent) that the attack does damage to armour specifically. If not, 100% (no modification) is assumed.
* The factor (as percent) that this attack does damage to shields.
* "Size" of the attack's weapon for hit/miss chance computation. See target_size on CombatData.
* Data about an ongoing blueprint copy operation. While a blueprint is being copied, it is "removed" from the main inventory, and only given back together with the copy when the operation is done.
Used in:
* The account doing the copying. Also the owner of the blueprints.
* The blueprint item type being copied (the original).
* The item type of the copy that will be produced.
* The number of copies being made.
* Specific data for blueprint items defining the modalities for constructing stuff from it.
Used in:
* The item type constructed from the blueprint.
* Whether or not this is an original. Originals can be copied and can be used an unlimited amount of time, whereas copies (if not originals) cannot be copied themselves and can only be used once to build an item.
* The state of one building on the map. (There is additional data stored for it directly in the database, as well as extra data stored in other database tables like inventories or trade orders.)
* The transformation applied to the building's base shape.
* True if this is just a foundation for now (and not the full building).
* The inventory with materials for construction of the full building, while this is just a foundation.
* If this is a foundation being upgraded to full building right now, then this is the ID of the ongoing operation corresponding to it.
* Static combat data for this building (besides regeneration). This is mostly based on the building type, but may change if the building is upgraded or the account gains skills.
* The current configuration for the building.
* Age data for this building.
* Data about the building age, i.e. the block heights when it was founded and finished.
Used in:
* Block height when it was founded.
* Block height when it was finished.
* Configuration data for a building, which can be changed by the building's owner at will.
Used in: ,
* The service fee that users need to pay to the building owner for using services in the building. This is a percentage of the service's base fee (the burnt amount).
* The fee charged by the building owner for trades on the building's DEX. This is in basis points (1/100 of a percent) and paid by the seller from the received Cubits.
* An operation for changing the owner-configurable building data. This is delayed to prevent frontrunning. At the end of the ongoing operation, the data will be updated in the building itself.
Used in:
* The new configuration data.
* An operation to finish building construction (i.e. upgrade it from a foundation to the full building).
Used in:
(message has no fields)
* Hardcoded data defining a type of building.
Used in:
* The enter/exit L1 radius of this building. Characters can enter the building if they are within this L1 radius of the centre coordinate, and when exiting, they will appear on a random spot within that radius.
* All tiles that make up the building's shape, in the basic, untransformed way. The coordinates are relative to the building's centre.
* Combat data for the foundation of the building alone.
* Combat data for the full building (after construction is done).
* The data for constructing this building.
* Services this building type offers.
* Combination of combat and regen data for a building or the foundation.
Used in:
* Required resources and other data for constructing the building.
Used in:
* Resources (keyed by item type, value is the quantity) required to lay the foundation.
* Resources for upgrading the foundation to the full building.
* Number of blocks the construction (from foundation to full building) takes for this type.
* The faction of this building type. If this is set, then only players with a matching faction can build it. This is inferred from the building name in roconfig data and only set at runtime.
* The set of services offered by a building. Since "false" is the default value for a boolean field, only those services that are offered need to be listed in the actual config data.
Used in:
* A stage in the burnsale schedule.
Used in:
* Amount of vCHI to be sold in the stage.
* Price of one coin in CHI satoshi.
* The state of one character in the game. Note that this does not include data fields that are stored directly in database columns, namely those on which the database keeps indices.
* The vehicle (as item type) this character is using.
* Fitments placed on the vehicle.
* Active movement of the character, if any.
* Static combat data for thie character. That data is derived from other information (e.g. equipped weapons, current vehicle), but it is cached here for easy computation of combat. The data here changes only through explicit actions done by the owner.
* If the character is currently busy, then this is the ID of the corresponding ongoing operation.
* The character's mining data, if it can mine.
* The character's prospecting rate, if it can prospect. This is the number of blocks it takes them to finish prospection.
* Movement speed of the character.
* Total cargo space the character has.
* If this is set, the character can do mobile refining (and the stats for it are given here).
* All data related to combat that a fighter entity (character or building) has. This only includes basic properties of the fighter and not more dynamic data like the current target or the current HP, nor specific data that is frequently accessed like HP regeneration.
Used in: , , ,
* The offensive attacks the figher has.
* Any low-HP boosts for the fighter.
* Any self-destruct attacks this fighter has.
* Reduction applied to any damage received (e.g. from the "armour hardener" upgrade fitment).
* Modification (e.g. boost) to the hit chance of any attacks made by this fighter.
* "Size" of the fighter as a target, i.e. for hit/miss chance computation. If this is missing or at least as large as the corresponding size of the attack, then the base chance (without any modifiers) is 100%. If the target size is lower, the chance is proportionally lowered.
* Modifications done to a combat entity's stats due to attacks (e.g. slowing or range reduction).
Used in:
* Modification to the speed.
* Modification to the range.
* Modification to the hit chance of attacks from this fighter.
* Modification to the shield regeneration rate.
* If set, then the affected fighter ignores the friendly/enemy classification and just considers everyone a valid target for both normal and friendly attacks (and similarly affects everyone with AoE attacks of either type).
* The hardcoded "configuration data" for Taurion. This includes all data that describes read-only aspects of the game, like known item or vehicle types and stats for them. An instance of this proto is populated from text format encoded in roconfig/<files>.pb.text and made available to all parts of the code.
* Known types of fungible items.
* Known types of buildings.
* Distribution of resources for prospecting.
* Initial buildings (ancient buildings and starter zones).
* Safe and starter zones.
* Basic parameters.
* The testnet-specific configuration data. This is merged into the main configuration when running on testnet or regtest.
* The regtest-specific configuration data. This is merged into the testnet data by the RoConfig-helper class when running on regtest. Safe zones and prizes in there will completely replace the values in the mainnet config, instead of being added to them.
* Data specific about items that are fitments.
Used in:
* The type of slot this requires.
* If set, then this fitment can only be placed on a vehicle of the (exact) given size.
* An attack this does.
* Modification to the cargo space.
* Modification to the movement speed.
* Modification to max armour HP.
* Modification to max shield HP.
* Modification to shield regeneration rate.
* Modification to armour regeneration rate.
* Modification of all attack ranges (and AoE area sizes).
* Modification of all attack damages (min and max).
* Modification to the received damage (e.g. armour hardening).
* Modification to the self hit chance.
* Modification to the vehicle's allowed fitment complexity.
* Modification to the vehicle's prospecting blocks. Since a larger number of blocks is worse, a fitment will likely have a negative modifier here.
* MOdification to the vehicle's mining rate (min and max).
* Low-HP-boost this fitment provides (if any).
* Self-destruct ability of this fitment (if any).
* If this is a mobile refinery, the stats for it.
* Small utility message to hold stats about HP (both the permanent armour-based ones and the regenerating shield).
Used in:
* The "permanent" armour-based HP.
* The regenerating, shield-based HP.
* Partially regenerated HP in 1/1000 HP units. When it reaches 1000 for shield or armour, the "actual" HP are incremented accordingly. This field is only present for the current HP of a fighter, not the maximum HP in its RegenData.
* A coordinate on the hexagonal map. The coordinates are encoded in the "axial" format, as used everywhere in the backend as well.
Used in: , , , ,
* Data for a building that is initially on the map. All of them are ancient and indestructible.
Used in:
* Type of the building.
* Centre of the building.
* Shape transformation of the building.
* Data about loot "somewhere". This can be the inventory of a character, it can be the assets of an account in a building, and it can be the loot on the ground at a certain coordinate.
Used in:
* Data about fungible assets held. This is simply a map from item types (which are hardcoded strings) to the amount of each type. The amount is an integer number, representing some smallest fraction of the item.
* Data about an ongoing item or vehicle construction. If it is based on an original blueprint, then the blueprint will be taken away temporarily and given back together with the constructed items. Blueprint copies and resources required for the construction are always just removed when the operation starts (and thus not related to the operation state). Construction from an original produces the items "in series", which means that we schedule an update for each single item finished and give them out one after the other while the operation is still going on. If constructing from blueprint copies, all of them are done in parallel, and just one update is done after the construction time and all items are given out at once.
Used in:
* The account doing the operation, which will receive items when done.
* The constructed item.
* The number of items still to be constructed. If this is done based on an original blueprint, we will update the operation after each produced item, give that item out, decrement the number here, and re-schedule an update.
* If this construction is based on an original blueprint, then this is the blueprint type used. After it is done (or if the building is destroyed), one item of this type is also given back.
* Hardcoded data defining a type of fungible item.
Used in:
* The cargo space it uses per unit.
* For items that have one, the complexity level.
* Whether or not this item has an associated blueprint.
* The resources required to construct one of this item type, assuming there exists a blueprint for it.
* If this item is a fitment or vehicle and specific to a particular faction, then this field indicates that faction. May be null for faction-neutral items, e.g. most fitments. For fitments, this has to be explicitly set in the roconfig data. For vehicles, it is deduced from the name prefix (e.g. "rv ") via the RoConfig logic.
* If this type of item can be refined, then the stats for doing so.
* If this is a blueprint, the associated data.
* If this is a prize, the associated data.
* If this can be reverse engineered (i.e. is an artefact), the configuration data specifying the corresponding stats.
* If this is a vehicle item, the specific stats for that.
* If this is a fitment, the specific stats for that.
* Stats for a boost to combat stats that is in effect when a character has low armour HP (i.e. "final breath" attack).
Used in: ,
* The percentage of armour HP at which it activates.
* Boost to damage.
* Boost to range.
* Data about the mining state of a character.
Used in:
* The mining speed parameters.
* Set to true if the character is currently mining.
* Stats about the speed for mining (which is random based on a distribution from these parameters).
Used in: ,
* The minimum units per block.
* The maximum units per block.
* Data about mobile refining capabilities of a character.
Used in: ,
* The "inefficiency factor" of mobile refining. Refining in a mobile refinery costs the same vCHI fee and produces the same outputs as a normal refining step, but uses up more input ore per step. This is specified by the modifier here.
* An "active" movement of a character. Movement is specified by a list of waypoints, which will be visited in order and have to be apart only by principal directions.
Used in:
* The waypoints that will still be visited. While they are traversed, already visited points are removed from this list. In other words, the first element will always be the current target of the character. When this list becomes empty, then it stops moving.
* If set, then the character chooses to travel at the minimum of this value and its actual speed. This can be used to reduce travel speed for faster vehicles to stay around slower ones in a convoy.
* Data about an ongoing operation.
* The block height when the operation started. This is useful for the frontend to show (e.g. calculate progress).
* The ongoing operation itself, which can be one of several types.
* Data representing an on-going prospection by a character.
Used in:
(message has no fields)
* Basic parameters of the game.
Used in:
* The amount of CHI to be paid for a character.
* The maximum number of characters per account.
* Number of retries of a blocked movement step before the movement is cancelled completely. Note that this is really the number of *retries*, meaning that movement is only cancelled after N+1 blocked turns if N is the value here.
* The number of blocks for which a character stays on a damage list.
* The number of blocks after which a region can be reprospected (if there are no other factors preventing it).
* The number of HP that can be repaired per block.
* Cost (in 1/1000 vCHI) for repairing one HP of armour.
* Cost (in vCHI) for copying a blueprint, per complexity.
* Number of blocks for copying a blueprint, per complexity.
* Cost (in vCHI) for constructing an item, per complexity.
* Nubmer of blocks for constructing an item, per complexity.
* Delay (in blocks) until an owner-initiated update to the building configuration takes effect.
* Base fee (which is burnt) paid by sellers on the DEX in basis points.
* Minimum units of ore found in a prospected region.
* Maximum units of ore found in a prospected region.
* The address to which developer payments should be sent.
* The address to which burn payments should be sent.
* Whether or not god mode is enabled.
* Spawn areas for the factions (with the "r", "g", "b" string as key).
* Data about the burnsale schedule.
* Prospecting prizes. They are just a list and not a map, because the order matters (it is the order in which winning is checked). This field has a special rule when merging in the regtest configuration: It is replaced rather than concatenated (which would be the default behaviour for proto merge).
* Specific data for prize items.
There is no specific data we need to define for prize items, this is just a placeholder to mark them as prizes.
Used in:
(message has no fields)
* Definition of the configuration for one prospecting prize.
Used in:
* Name for the prize (used in the game state and also for constructing the item name by appending " prize").
* Number of prizes of this type available.
* Probability to win this prize as 1 / N.
* Data about the prospecting outcome of a region.
Used in:
* The Xaya name of the user who prospected the region. This has no impact on the game play, but can be useful for display purposes.
* The block height at which the region was prospected.
* The type of resources that can be mined on the current region. The amount left is stored directly in a DB column (because it may be updated frequently while the region is being mined). Every prospected region has some type of resource assigned, although there may be very little of it minable (or all might already have been taken).
* Data about the ability to refine items of this type to other item types (i.e. raw materials into refined resources).
Used in:
* Number of instances going into one "refining unit".
* Base cost (burnt) in vCHI for one refinement step.
* The outputs (as item type, amount) for one refining step (i.e. "input_units" input units).
* Data relevant for HP regeneration. This is split out from the main combat data, because it needs to be accessed for every fighter all the time to figure out if they need regeneration.
Used in: ,
* Maximum HP of the fighter.
* Regeneration rate of HPs in "milli HP per block".
* All data stored about a particular region on the map.
* The character ID who is currently prospecting here (if any).
* If already prospected, the outcome.
* Data for the resource distribution on the map (when prospecting). This is based on multiple "areas" where one or two resources occur. Each area has a central x/y coordinate. Then within a core L1 radius around this area, those resources appear with "full chance". Towards an outer radius, the chance falls off to zero linearly. If multiple areas overlap (or there are two resources in one), then we pick between them based on their chances as weights. The radii themselves are just constants in the source code. The proto data in this message holds the more complex things, like the list of areas and also how the ores correspond to artefacts.
Used in:
* Resource areas.
* The artefacts that can be found with each ore type.
* One area where resources can be found.
Used in:
* The centre coordinate of the area.
* The type(s) of resources to be found here.
* Data specifying the artefacts found together with a particular ore in a region.
Used in:
* Entries for all the artefacts that can be found with a given ore in a region. They are checked in order until the end or the first artefact is discovered.
* Entry for one artefact with its chance of finding it.
Used in:
* The artefact's item name.
* The chance as 1 / N.
* Data about the ability to reverse-engineer an item to obtain blueprints.
Used in:
* Cost (in vCHI) for a reveng attempt.
* Types of items (most likely blueprint originals) that can be obtained from this through reverse engineering.
* Data for a safe zone. They represent both the general no-combat zones as well as the faction-specific starter areas.
Used in:
* Centre of the zone.
* L1 radius of the zone.
* If this is a faction starter zone, the faction as string ("r", "g" or "b"). If this is a general no-combat zone, then the field is unset.
* Stats for the self-destruct ability of an entity (when the entity is destroyed, AoE damage is dealt to enemies in range).
Used in: ,
* The AoE range of the attack.
* The damage done.
* A geometrical transformation applied to the building's shape (e.g. for rotating it on the map). This does not include the shift of all tiles to the building's centre.
Used in: ,
* Number of clock-wise rotation steps about 60 degrees the base shape is rotated around the building centre. This can go from 0 to 5.
* Definition of a spawn location.
Used in:
* The building ID into which new characters are spawned.
* General modification something can give to an existing numerical value, e.g. an increase to a vehicle speed or combat damage.
Used in: , , , ,
* Relative change to the base value, in percent. This is added (or subtracted if negative), so not a multiplicative factor.
* Absolute change to the base value.
* Identifier for a target of attacks. This can be either a character (in a vehicle on the map) or a building.
* The type of this target.
* The database ID of this target entity (based on its type). Absence of this field means that the target is "empty" / null / there is no target.
* Different types of target. The type determines where the data is stored in the database and how it is accessed.
Used in:
The numeric values below are used to sort TargetKey instances, which are expected to match the sorting order used in some DB queries.
* Data specific about items that are vehicles.
Used in:
* Base cargo space of this vehicle.
* Base movement speed (in milli-tiles per block).
* Basic regeneration data and max HP.
* Basic combat data (including attacks mostly).
* Base mining speed for the vehicle.
* Base prospecting rate (if prospecting is possible).
* Size of the vehicle for fitment purposes.
* Number of equipment slots of each type. The slot types are just strings which have to be matched between here and the fitment configs. The valid values are "high", "mid" and "low". Unfortunately we cannot use enum values as they can't be keys in protocol buffer maps.
* Size of a vehicle.
Used in: ,
* Additional data for movement, which is stored separately in the database and not as part of the broader "character proto". This is the data that is expected to change frequently, e.g. potentially on every turn without explicit moves being sent by the player.
* Partial progress towards the next tile.
* Number of turns for which the character has been blocked by an obstacle in its (already computed) path. This is used to stop movement after a certain number of tries, rather than trying forever.