Author Topic: Tech File Parser Analysis  (Read 756 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4740
Tech File Parser Analysis
« on: January 03, 2016, 06:09:54 AM »
I was looking through the tech file parsing code in Outpost 2 and thought I'd note the following things:
  • There is a max of 256 techs. (Static buffer limit, unchecked)
  • There is a per tech max of 32 REQUIRED_TECH tags. (Static buffer limit, unchecked)
  • There is a per tech max of 32 upgrade tags (UNIT_PROP, PLAYER_PROP, FUNCTION_RESULT). (Static buffer limit, unchecked)
  • Quoted strings have embedded newline and tab characters stripped. (Allows formatting in tech file)
  • Quoted strings must fit within a tag specific static buffer limit. (Excludes tabs and newlines, string will be null terminated).
  • Tech name must not exceed 100 characters. (Static buffer size 101 bytes)
  • Tech teaser, description, and improvement description must not exceed 800 characters. (Static buffer size 801 bytes)
  • Numbers can take an optional leading minus sign. (No positive sign allowed)
  • Numbers must fit in a static buffer of 32 bytes, including the leading sign. (Static buffer, checked, Parse error)
  • Numbers must be representable as a 32-bit signed integer. (Unchecked, Undefined behaviour)
  • The techLevel = techNum / 1000, must not be 0. (Checked, Parse error)
  • The techId (and techLevel) should not be negative. (Unexpected values)
  • The armour (level) property must be set from 0..5 (inclusive). (Unchecked, Undefined behaviour)
  • The game supports 4..18 (inclusive) max scientists on a research topic. (Unchecked, Undefined behaiour)
  • The game sets MAX_SCIENTISTS to 1 for the Tiger speed modification in multitek.txt. (Avoids undefined behaviour by not researching in a lab)
  • The game sets MAX_SCIENTISTS to 1 for Children's Module and Evacation Module in edentek.txt and ply_tek.txt. (Avoids undefined behaviour by not researching in a lab)
  • The game sets MAX_SCIENTISTS to 1 for 5 techs in tutortek.txt. (Avoids undefined behaviour by not researching in a lab)
  • The lab value should only be set to 1 = BasicLab, 2 = StandardLab, 3 = AdvancedLab. (Unchecked, Unexpected values)
  • The lab value is typically not set for free and disabled techs. (Convention for built in techs)
  • Either COST is present, or both EDEN_COST and PLYMOUTH_COST are present. (Unchecked, possibly undefined behaviour)
  • The COST values should either be -1 (disabled), 0 (free), or a positive value. (Unchecked, possibly undefined behaviour)
  • Each BEGIN_TECH must be paired with END_TECH. All other tags are optional. (Checked, Parse error)
  • Single value tags will overwrite their previous values if used more than once. (Unchecked, excludes REQUIRES, UNIT_PROP, PLAYER_PROP, and FUNCTION_RESULT)
  • Every tech typically specifies at least CATEGORY and COST. (Convention for built in techs)
  • The REQUIRES tag should specify a valid techID. (Unchecked, possibly undefined behaviour)
  • The PLAYER_PROP, and FUNCTION_RESULT tags are not used by the standard tech tree files, and are basically useless.

There are 4 main components the parser deals with:
Comments: Starts with a ";" and runs until the next newline character
Tokens  : An un-quoted sequence of characters (generally uppercase by convention) and underscore
Strings : A quoted sequence of characters (tabs and newlines are stripped)
Integers: An optional minus sign followed by a sequence of digits

The parser scans for the following tokens and parameters:
Code: [Select]
BEGIN_TECH      string:techName    int:techId
CATEGORY        int:category
DESCRIPTION     string:description
TEASER          string:teaser
IMPROVE_DESC    string:improveDesc
REQUIRES        int:requiredTechId
COST            int:cost    [edenCost = plymouthCost]
EDEN_COST       int:cost
PLYMOUTH_COST   int:cost
MAX_SCIENTISTS  int:maxScientists  [4..18]
LAB             int:lab     [1 = Basic, 2 = Standard, 3 = Advanced]
PLAYER_PROP     token:propName    int:newPropVaue
FUNCTION_RESULT token:propName    int:funcParam    [__fastcall func(int playerNum, int funcParam)]
UNIT_PROP       token:unitTypeName    token:propName    int:newPropValue

The following property tokens are supported:
Code: [Select]
Hit_Points        [Units, but generally Vehicles]
Armor             [Units, but specifically: GuardTower, Lynx, Panther]
Production_Capactity  [Buildings, both factory build rates, and capacity for others]
Move_Speed        [Vehicles]
Sight_Range       [Units, but specifically: LightTower, GuardTower, Weapons]
Rate_Of_Fire      [Weapons]
Build_Time        [Not used in standard tech files]
Power_Required    [Buildings, but specifically: GORF, Smelter, Rare Smelter]
Storage_Capacity  [Specifically: University train rate]
Storage_Bays      [Not used in standard tech files]
Production_Rate   [Vehicles, mostly colony building and repair]
Concussion_Damage [Weapons]
Penetration_Damage  [Weapons]
Improved          [Unit specific: Mine, RareMine, Smelter, RareSmelter, GORF, Observatory]
Workers_Required  [Buildings, but specifically: DIRT]
Common_Required   [Units, but generally vehicles]
Rare_Required     [Units, but generally vehicles]
Turn_Rate         [Not used in standard tech files]
Build_Points      [Not used in standard tech files]

The PLAYER_PROP and FUNCTION_RESULT tags quite are useless. The standard tech tree files don't use either of these two tags. The PLAYER_PROP can set the Ore (common) for a player as a research result. Note that it sets the ore, not adds the ore. I don't see a whole lot of use for it. The Test_Function which is called is just a no-op, and no other functions are available, making FUNCTION_RESULT quite pointless.