Proto commits in xaya/taurion_gsp

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-04-21

WIP: introduce superblocks

2025-09-23

Enable burns on Polygon. Enable burns on Polygon (for minting credits). Burning is not directly supported by the EVM Xaya framework (especially on Polygon), as we do not want the "burnt" coins to remain sitting in the Polygon bridge forever. Instead, "burning" for the purpose of the game is done by sending to another special address. This burn address is also controlled by the Xaya team, but with the understanding that coins received there will be bridged back to Ethereum and burnt there from time to time.

The documentation is generated from this commit.

2021-03-17

Proto and config data for skills. For the upcoming feature of skills, XP and character progression, this adds some basic protocol buffer config data. In particular, we define an enum for skill types, and for each type, a config proto that can be looked up through RoConfig. For now, the config data only contains the skill's name, to be used with game-state JSON as field names. In the future, we might have skill-specific constants, e.g. defining how that skill maps raw XP count to "level".

2020-11-27

Move-processor updates for building config. Update the move processor for delayed update of building configuration: Instead of updating the building data directly for moves, create the corresponding ongoing operation with delay (120 blocks / one hour on mainnet, 10 blocks on regtest).

Sub-message for building owner config. Move the owner-configurable values of a building into a new and dedicated sub-message (service fee and DEX trading fee). The new sub-message is also reflected in the building game-state JSON. Instead of having "dexfee" and "servicefee" directly in the building JSON, they are now moved into a "config" object. This will allow us to implement a general mechanism for building updates (and delays for it with an ongoing-operation), independent of the particular config fields updated / supported.

Ongoing operation for building config updates. This defines a new ongoing operation for delayed updates to building configuration. When it "expires" (gets processed at its set block height), the owner-configurable data in the associated building is updated from some value set inside the operation. In the future, when a building owner issues a move to update the building configuration, we will schedule such an update rather than change the config immediately. This protects users in the building from frontrunning.

2020-11-25

Only use test safe zones on regtest. In regtest mode, only use the testing safe zones (rather than adding them on top of the normal ones). This makes the setup even more predictable, especially if we are doing more changes with safe zones in the future (like disallowing to build buildings in them).

2020-11-24

Enable arena support in protocol buffers. Turn on arena support (with option cc_enable_arenas) in all our .proto files, so we can use arenas for more efficient proto usage in the future.

2020-11-19

Restrict building construction by faction. This associates a faction to some building types, based on the name prefix of the type (i.e. "r vb" is red, while "huesli" has no faction). This is done through RoConfig magic, similar to how bpo or prize items are constructed. Further, if a building has such a faction, it can only be constructed (founded) by a character of the same faction. In other words, a Reubo can no longer found a Jodon vehicle bay, for instance.

Define factions for fitments/vehicles. Add a new field to the ItemData roconfig proto, which can specify the faction for faction-specific fitments and vehicles. For fitments, it is explicitly set in the roconfig data as appropriate. For vehicles, the faction will be deduced at runtime from the name prefix, e.g. "rv st". In the future, these factions will be used to apply certain restrictions (e.g. Jodon fitments can only be placed on Jodon vehicles).

2020-11-11

Configuration of DEX fees. Each trade on the DEX will cost a certain fee paid by the seller from the Cubits they receive. There will be a 3% base fee that is configured in the ro params and just burned (to protect against spam and wash trading). In addition to that, the owner of each building can configure a building DEX fee in basis points up to 30% max, which is paid to the building owner by the seller of each successful trade inside the building. The building DEX fee is returned as a new field "dexfee" in the building state JSON, and can be set with a new building-update move (similar to setting the service fee): {"b": {"id": 42, "xf": 350}} This would set the dex fee in building 42 to 350 bps, i.e. 3.5%.

2020-10-29

Sort TargetKey same as targets/fighters. Explicitly make the sorting order of TargetKey instances match the order in which some database queries (TargetFinder::ProcessL1Targets and FighterTable::ProcessWithAttacks) return targets, namely first buildings and then characters (and within each group by ID). For now, the sorting order of TargetKey is irrelevant, as it is just used for direct lookups. But in the future, we can then use it to sort targets for processing, matching the direct DB queries (e.g. for parallelisation of some things in combat).

2020-10-22

Age data for buildings. In the building proto data, store the block heights when a building was founded and when it was finished. This is useful for the competition prizes, but may also be useful in general for some other things in the future game.

Age data for buildings. In the building proto data, store the block heights when a building was founded and when it was finished. This is useful for the competition prizes, but may also be useful in general for some other things in the future game.

2020-10-16

Construct items from bpo one by one. When constructing items (fitments or vehicles) from an original blueprint, produce them one by one as they get finished rather than all at once at the end of construction. We still take away the entire cost immediately (to make sure it is reserved) and give back the bpo at the very end, but the constructed items will become available as they are finished.

2020-10-14

Spawn characters in starter cities. Spawn new characters inside their starter-city buildings, rather than directly on the map. This is simpler and more straight-forward. They can then immediately exit the building if they want anyway, which leads to the same result as before (placing them on the map somewhere around the starter building). In particular, this prevents cluttering of the spawn area with characters that may not be used at all, e.g. from free-to-play claims.

2020-09-03

Spawn in starter city after fork. Update the game rules after the "unblock spawns" fork so that new characters will spawn in the starter-city building of their faction, rather than directly on the map. This helps to reduce the amount of idle characters in the starter zones that were created with the f2p "faucet" and never touched; they will now be inside the building, where they are not as annoying.

2020-08-21

Track minted balance for each account. Add a new field with the coins minted in the burnsale to the Account proto and state data. This allows to track the vCHI sale progress during the game, independently of what happens with the vCHI inside the beta competition.

Implement burnsale schedule logic. Define and implement the schedule and stages of the burnsale (i.e. add the stats to roconfig and implement the logic that computes how many vCHI can be bought for a given amount of burnt CHI). It is not used anywhere yet.

2020-07-24

Add hit-chance modifier as effect. Also add a combat effect that reduces the hit chance, and define a matching AoE weapon fitment that has this effect (the "hitred"). As usual, we define the light variant, and the others will be added in with a future, general data update.

Implement fitment to boost one's hit chance. This defines a new fitment, "lf hitext", which boosts the hit chance for one's own attacks. (The other variants will be added in with a future general fitment update from the data sheets.) Also implements general combat logic to apply a modifier to the hit chance, which for now is just based on that self boost (but in the future will also include negative combat effects).

Implement hit/miss chance for attacks. Support a hit/miss chance for attacks (applying damage, not effects). The chance is based on both a "target" and "weapon" size. Small weapons hit large targets with 100% chance; if the weapon size is larger than the target size, the hit chance is proportional to that. Both weapons and targets support also a special property, which just means "hits always" (unless e.g. modified in the future with a tracking disruptor).

2020-07-21

Define "mentecon" effect and fitment. This defines a new combat effect, namely a flag (codenamed mentecon) that disrupts a fighter's enemy/friendly detection. There is also a new fitment, "vhf mentecon", which has this effect on the unit's current target (not AoE). For now, we just apply the effect, but do not take it into account in the actual combat system. That will be done in the next step.

Add allyreplenish fitment. This defines a new fitment "lf allyreplenish", which increases the shield regeneration rate of friendlies in an AoE. For this, we define a new combat effect for modifying the shield regeneration rate, and a flag for attacks to mark them as "affects friendlies" (which is for simplicity only supported with plain AoE). Neither the shield regeneration modifier nor the actual friendly attacks are implemented yet in the combat logic.

2020-07-14

Define mobile refinery. This extends the protocol buffers to support stats for a mobile refinery. A fitment can have those, and then they will be propagated onto a character that equips it (and returned in the character's JSON state). So far, this does not do anything, but actually using it will be the next step. This also defines the "vhf" variant of the mobile refinery as actual fitment, with the real stats. That's the only one that will exist (no lighter ones are possible).

2020-07-13

Implement range reduction combat effect. This adds a new combat effect, which modifies (e.g. reduces) the range of a targeted fighter. This ability is given by a new fitment, rangered, which reduces ranges with AoE style by 15%. For now, we've defined the light variant of the new fitment. Others will be added later with a general data update.

2020-07-09

Add armour regeneration fitment. This adds a new fitment, armourregen, which enables an (absolute) armour regeneration rate when equipped. It is the only way in the game to actually get armour regeneration. For now this defines the light variant; others will be added with a general fitment data update before the competition.

Support absolute changes in StatModifier. Extend the StatModifier (implementation class and proto) to support also absolute changes in addition to relative (percent) changes. This will be used for armour regeneration, which is an absolute change in the respective fitment.

Update protos for regeneratable armour. Update the protocol buffer definitions and roconfig data to allow also armour to regenerate (i.e. the accumulated mhp field is now a general HP message, as is the regeneration_mhp field). The code is not yet updated accordingly (and hence even breaks), nor is there anything that actually *has* regenerating armour for now.

Fitment attribute for damage reduction. This adds a new fitment attribute, which defines a modifier that is applied to received damage. This attribute gets passed through to a character's CombatData, but there it is not yet taken into account when actually processing the combat logic. With this, we define the new "dmgred" fitment type (armour hardening) in the "lf" variant for now.

2020-07-08

Define gain_hp function for fitments in roconfig. This adds a new proto field for attacks, gain_hp. When set, it means that HP from damage of this attack will be added back to the attacker's own HP set. This will be used by the syphon and AoE syphon fitments (with shield-only damage). The change also defines the "lf" variants of the syphon fitments for testing (the other variants will be added in later with a general update of the fitment data). For now the new field has no effect, but it will be implemented in the combat logic in a follow-up.

2020-07-07

Update number of ore found on regions. Instead of specifying a base amount of ore found on a prospected region per type, we just specify a minimum and maximum value to be found (for all types of ore) in the roconfig params. Rare materials will be rare through fewer regions and less output of refinement rather than through less ores on any region. (Although the random span of outcomes is now much larger than before with the [X, 2X] system.) This also updates the numbers to match the new units measured in cm^3, namely to much higher values than before (2M to 100M for now and the upcoming competition).

Movement along principal directions. This revamps how the consensus-layer movement logic works in the GSP: Instead of doing path finding in a local range, we expect the waypoints to be set in principal directions from each other (but with arbitrary distance). Then we simply try to step along that path. This implements the idea described in https://github.com/xaya/taurion_gsp/issues/135 and will make movement processing (which has been the main bottleneck in the past two competitions) much faster in the consensus code. (Path-finding still needs to be done, but only client side to come up with the waypoints to send in a move.)

2020-07-03

Define data for artefact finds when prospecting. Add data about the artefact chances when prospecting (which is based itself on what type of ore is found in the region) to the configuration protocol buffers.

Add armour/shield damage factors to config. Allow the configuration of an attack to contain factors for how damage affects armour and shield differently. Two new fitments (laser beam and rail gun) use this, which are specifically effective against shield and armour, respectively. (So far only the light variants of the new fitments are included; we will update the data file completely in a follow-up.) The new fields are not yet taken into account when dealing damage, which will be the next step.

2020-06-30

Define safe zones in roconfig. Add fields to the roconfig proto for defining safe zones (neutral no-combat as well as faction-specific starter areas). They are not yet interpreted in the game in any way.

2020-06-26

Implement fitment restrictions by vehicle size. Allow to define fitments that can only be placed on a vehicle of a given (exact) size. E.g. we do not want light shield boosters on a very heavy vehicle.

Define size of vehicles. This adds a new field to the vehicle configuration, which defines the "size" of the vehicle (starter, light, medium, heavy or very heavy). It has to be set on each vehicle item type. In a follow-up, we will use this to restrict placing of certain fitments.

2020-06-24

Define initial buildings in roconfig. Instead of hardcoding the initial buildings in C++ code, define them in the roconfig proto and place them in code from there.

2020-06-12

Fitments to boost prospecting and mining. This gives fitments the ability to modify the prospecting blocks and mining rate. It also defines two fitments (plus one test one) that do this, a "pick" and a "scanner" (boosting mining and prospecting by 20%, respectively).

Store prospecting blocks in character data. Instead of defining the number of blocks prospecting needs in the general game params, make it into a property stored for each character and vehicle type. With this, we can have vehicle types that do not support prospecting at all, and we can also have different rates between different types of vehicles. Later on, we can even define fitments that alter the prospecting rate.

2020-06-05

Define self-destruct fitment. This adds in a definition of a new fitment item with the "self-destruct" ability. When added to a vehicle, it will add this ability to the fighter's combat data. The ability is not yet used in the actual combat code, though.

2020-06-03

Auto-generate prize items. Instead of defining the items for prizes in the roconfig, auto-generate them based on the prize data in roconfig (similar to how the blueprint items are defined).

Migrate prizes to roconfig. Move the prospecting prize data from Params to roconfig. This will make it easier to maintain the data, provide it also to the frontend if needed, and will allow us to auto-generate the items for them.

Move dev address to roconfig. Migrate the developer address for character payments from Params to roconfig. This allows us to get rid of the duplicated definition in the Python tests and instead use it directly from the protocol buffer. Since the address differs on testnet from mainnet, we have to add new support for a testnet-specific merge proto.

Move god-mode flag to roconfig. Use the flag for whether god-mode is enabled to roconfig from Params. It is set to false in the main config and overridden to true on the regtest merge.

Define spawn areas in roconfig. Define the spawn areas (centre and radius) in roconfig rather than in the Params class.

Migrate service parameters. Move the service-related parameters (armour repair, blueprint copy and construction cost and duration) from Params to roconfig.

Migrate prospection expiry. Move the prospection_expiry_blocks from Params to roconfig. Since this value is actually different on regtest, we have to introduce the corresponding file with regtest merge overrides.

Migrate some block counts. Move over the damage_list_blocks and prospecting_blocks values from Params to the roconfig.

Migrate movement parameters. Migrate the movement parameters (max_waypoint_l1_dist and blocked_step_retries) from Params to roconfig.

Move character limit to roconfig. Migrate the character limit (per account) from Params to the roconfig proto data.

Expose roconfig to Python tests. This exposes the roconfig proto to the Python tests, and makes use of the character cost parameter from there (rather than duplicating the value in the Python code). Also required some refactoring to how the protocol buffers are built and used to make it work properly with Python modules.

Put character cost into roconfig. Define a new field in the roconfig, which will hold basic game parameters. As a first step, we migrate over the character cost from Params to the roconfig proto.

2020-06-02

Separate roconfig for regtest. Move the test items and buildings into a separate roconfig instance for testing, which is only added to the main configuration when running on the regtest chain.

2020-05-28

Record start height for ongoings. Store the start height whenever an ongoing operation is created, and return both start_height and end_height with the RPC interface. This is useful to show progress in the frontend.

2020-05-27

Define low-HP boosts in combat data and fitments. This adds a new concept of "low-HP boosts" to the fitments and also the combat data of a character that has such a fitment equiped. We also define a fitment item already for it. For now, it does not have any actual effect; in the future, these boosts will increase damage and range of a character when it is low on armour HP.

2020-04-15

Apply effects during combat. When processing combat attacks, also apply effects in addition to applying damage (and reset the effects at the end of processing a block). In addition to the general framework, this also defines two new fitment attacks: A retarder, which slows enemies in AoE, and a longretard, which slows enemies in AoE around a selected target.

2020-04-14

Database storage for combat effects. This introduces a new CombatEffects proto, which will store temporary effects onto a character from combat (e.g. slowing or increased range due to friendlies). The character table has a new column to store those effects, with a quick way to clear all effects (at the end of each turn). The effect data is not yet filled in anywhere or used.

2020-04-10

Move StatModifier to separate file. Split out the StatModifier proto into its own .proto file, and also the source code for it out of fitments. It will be used in the future also for stat modifications due to combat effects.

Restructure damage field in Attack proto. Move the min/max damage fields in the Attack proto into a separate submessage for "damage". This way, we can later on more easily have attacks without damage at all, and with e.g. effects instead.

2020-04-09

Allow AoE around target. This restructures the way attack ranges and AoE ranges are defined in the proto configuration. Instead of having a single range and a boolean "is AoE" field, we now have two ranges. This allows for three main types of attacks: range set to N, area unset: Simple attack with range N. range unset, area set to N: AoE around attacker with range N. range set to R, area set to A: Target within range up to R, and then do AoE around that target up to A tiles away. The third option was not possible before, and is now implemented properly in the core code and also used for some fitment items.

2020-04-08

Link to ongoing construction from building. When a building has an ongoing construction operation, link to the ongoing ID from the building state proto. The ID is also returned in game-state JSON, and "slow validation" verifies those links.

Ongoing operation for building construction. Define the ongoing operation for constructing a building (i.e. taking it from foundation to full building).

Rename "construction" to "item construction". Change the name of the ongoing operation type from "construction" to "item construction". There will be a "building construction" ongoing as well, namely when a building is updated from foundation to full building.

Add construction inventory for foundations. For building foundations, we do not have actual account inventories but just a single (per-building) "construction inventory". Any items dropped in the foundation go towards that, which will later be used to handle upgrading the foundation to the full building.

2020-04-07

Foundation concept in protos. Extend the building protos (configuration and actual game-state data) to include a concept of building foundations. Buildings on the map can now be only foundations, which will be reflected in the game state and returned in JSON. This also defines building roconfig data for how HPs look like in the foundation vs full building, and what the stats (resources and time required) are for building some type of building.

2020-04-02

Restructure ItemData proto with oneof. The ItemData proto has a couple of fields specific to item types (e.g. stats for vehicle items or data about refining the material). These are conceptually already a oneof, but were not in the actual code. This change makes them a oneof. This structures the proto more clearly, and also gives an easier-to-see separation between some fields that are general for items and some that define specific types of items.

Move ItemData proto messages to global scope. Instead of defining the messages for vehicle data or fitment data inside the ItemData proto message, move them to the global scope. This makes the definition easier to read; and the name "VehicleData" (and others) is clear enough even on the global scope.

Check for fitment suitability. Implement the logic that checks if a list of fitments is suitable for a given vehicle. This verifies the complexity levels and also the equipment slots. Also adds a new fitment that increases vehicle complexity and thus allows placing "bigger" (or more) fitments.

2020-04-01

Define some basic fitments. This defines some of the basic fitments / fitment types (additional attacks, boosts to speed/cargo/max hp/regeneration/attack range/attack damage) and implements the logic to adjust character stats for fitments. It does not yet include code to actually place those fitments or to validate which ones can be placed.

Define starter vehicles as items. Instead of defining and initialising the starting vehicle stats in a custom Params function, define them as actual item types in the roconfig data. We also created a function to "derive" the character stats from the character's vehicle item, which we use to initialise them now. At the moment, this just copies some proto fields. In the future, this function will also take fitments into account to modify derived stats accordingly.

2020-03-31

Define construction service operation. This defines a new service operation, which can be used to construct either items or vehicles from blueprints. (These two types of construction are different building services, construction facility vs vehicle bay.) Items can be constructed from a blueprint original or blueprint copy. In either case, they cost a certain amount of resources (defined by the base item type) per constructed item, and a certain amount of vCHI defined by the base item's complexity. Blueprint copies are used up, originals will just be temporarily taken away (and then given back again). When items are constructed from an original, they are done "in series", i.e. it takes Nx the base number of blocks to construct N items (and the base duration depends on the item complexity). When constructed from blueprint copies, the user needs to have N copies available anyway, but then construction is done "in parallel" so it only takes the base number of blocks to do it. The new service can be requested with this move: {"s": [{"b": 42, "t": "bld", "i": "item bpo", "n": 5}]} The "i" field is passed the blueprint that should be used (not the base item). Based on that, the GSP figures out whether or not this is a construction from original, and whether it is a vehicle or fitment (normal item).

Ongoing operation for construction. Define the ongoing operation (proto data and handling of it finishing) for construction, of either vehicles or fitments. If construction is done from a blueprint original (rather than copy), the original may drop if the building is destroyed while the operation is in progress (same as with blueprint copy).

2020-03-30

Building service for blueprint copy. Define the building service for copying blueprints. This takes one original blueprint and produces one or more copies, using up a certain amount of vCHI and taking a certain amount of blocks. The cost and duration are proportional to the blueprint's base item's "complexity" measure. To request this service, the move format is: {"s": [{"b": 42, "t": "cp", "i": "item bpo", "n": 10}]}

Ongoing operation for blueprint copy. Define the ongoing operation type and handling (in game-state JSON and for processing when done) for blueprint copies. For now, these operations cannot be created through normal means (only in tests). That will be changed with the "blueprint copy" building service later on.

Use ongoing operations for character busy. This replaces the "old" busy-concept for characters (used for prospecting and armour repair) with the new "ongoing operations". Characters will now only store the ongoing-ID in their proto to indicate that they are currently busy. Processing of finished operations is now done through the general system instead of the previous DecrementBusy.

2020-03-27

Database and proto for ongoing operations. Define a protocol buffer file and new database table (plus wrapper classes) for ongoing operations.

2020-03-26

Implement reverse-engineering service. The new service type reverse engineers one or more artefacts in a building, with a chance to get a blueprint instead. The cost and the possible outcomes is configured per artefact type. The chance for finding a blueprint decreases with the number of existing blueprints of that type in the game (with a factor of 75% for each existing blueprint). The service can be requested with a move like this (similar to refining): {"s": [{"t": "rve", "b": 123, "i": "artefact", "n": 1}]}

Define artefact config data. Extend the item roconfig data to support defining artefacts (that can be reverse-engineered into blueprints). Also defines a test artefact type that can result in one of two types of test blueprints.

Add constructed blueprint items. Define proto fields for blueprint items, and add logic to construct them on-the-fly in code when requested for supporting base items. (I.e. the blueprints themselves need not be defined in roconfig data, only their base items have to specify that blueprints are possible.)

2020-03-20

Support services fees in buildings. If configured in a building, pay an additional service fee to the building owner when someone else uses services. For neutral buildings and your own buildings, there is never such a fee. For now, the fee is handled by the service logic if configured, but there is not yet a way to actually configure the fee (except in tests). This will come as a next step.

2020-03-19

Implement "repair armour" service operation. The new "repair armour" service operation requests that the armour of the vehicle of a character is repaired, costing some vCHI and taking some blocks to do (both depending on the missing number of HPs). The new service operation can be requested with a move like this: {"s": [{"t": "fix", "b": 10, "c": 20}]} The character (20 in this case) must be owned by the account making the request, and must be inside the building where the service is requested (10 in the example).

Handle "armour repair" busy case. Add a new case for "busy" characters, namely repairing their vehicle's armour. Implement the logic to do so when the busy is done. For now, there is no way to actually *start* this operation; we will add that through the repair building service in a follow-up.

2020-03-17

Add refining data to roconfig. Store offered services (currently only refining is possible, and supported by the three ancient buildings) in the roconfig data of buildings, and stats for refining with items. (Currently 3 "foo" can be refined into 2 "bar" for testing purposes.)

2020-03-04

Add balance field for accounts. Add a new field for vCHI balance to the account proto, utility methods to access / modify it to the database handle, and return it with the account game-state JSON.

2020-02-26

Add combat fields for buildings in the DB. Add combat related fields (attacks, HP, regeneration, target) to the database schema and proto for buildings, and also to the database handle / table classes.

Define dummy turret building. Add a new building type r_rt for a dummy turret (with some attack and HP stats for now), and make sure that new buildings have their proto stats filled in from rodata.

2020-02-21

Make target separate database column. Instead of having the selected target be part of the main character proto and having a separate indexed column for "has target", just make the target a column in the database itself (like HP and RegenData proots). We have an index on this, so we can select by "IS NOT NULL". This will also allow us to easily reuse the same structure and code for buildings, as we then don't need to template on the proto type or something like that.

2020-02-12

Move to specify intent to enter building. A new move can be used to specify the "intent" to enter a given building with some character (or to cancel that intent later). This can be done any time (except when inside a building), as long as the building ID is valid and of an enterable building (not opposing faction). The flag will then stick around until the character can actually enter, e.g. is no longer busy and comes within reach of the building. The move has this form (for setting the intent with a given building ID and for clearing the intent): {"eb": 42} {"eb": null} We also return that intent in the character-state JSON, and track the "enter building" moves while pending.

2020-02-05

roconfig data for buildings. Define roconfig data for building types (for now that is just the radius where one can enter as well as the set of tiles that make up a building's shape). We also define a concrete type already, which can be used for testing.

Add basic buildings to database. This adds a new database table, which holds basic data about buildings on the map. We also define a proto message for building data, and the corresponding accessor classes.

2019-10-22

Implement proper resource distribution. This replaces the dummy distribution of resources that we used so far with a "real" one that we will use in the next competition. We have a list of areas where certain types of resources can be found, and then randomly choose resources based on the current position, how far it is to those areas, and what the "base amount" for each resource type is. See https://github.com/xaya/taurion_gsp/issues/53 for more details.

2019-10-17

Make mining rate random. Instead of a fixed mining rate, choose the amount mined uniformly between some minimum and maximum values. The minimum value may also be zero. With this, we also set the default rate to 0-5, which is what we want to use in the second competition.

2019-10-14

Add mining data to character proto. Add a member to the character proto that will hold mining data (supported rate of mining and whether or not mining is active). The default characters will mine with rate one unit per block for now. The new mining data is also returned in the game-state JSON for characters in a new "mining" JSON field.

2019-10-07

Merge pull request #52 from xaya/prospecting Overhaul prospecting of regions

2019-10-06

Add missing config.proto file. The file is .gitignored by accident, and was thus not included previously.

2019-10-04

Add mine-able resource to region data. Store a type of mine-able resource and the remaining amount of it in the game-state database for regions. For now this is never actually initialised or returned.

Give out prizes as items. Instead of recording won prizes in the region data, give them out as items to the prospecting character's inventory. In the next competition, prizes will need to be "banked" and can also be stolen. This implements https://github.com/xaya/taurion_gsp/issues/49.

Add prospected height to region data. When a region is prospected, store also the height at which prospecting finished with it. This will be used later to allow re-prospecting after all resources have been mined and a certain time interval has passed. We might also want to add a database index on this later and add an RPC that queries for all regions prospected only recently.