A Visual Combat Recording is, other than its name implies, not a video recording. It's just a list of the starting parameters of the battle. The VCR program runs the battle using the same algorithm as the host.
+0 WORD Number of VCRs. For PHost, see below. +2 n BYTEs Records of 100 bytes each +x 10 BYTEs Signature 2.
A VCR record:
+0 WORD `init' Random Number Generator initial value.
Host: Must be in range 1..119. VCR's random number
generator uses a table of 119 "random numbers"
used in sequence and scaled to the needed range.
Host actually generates 1..111 (111 is very rare).
PHost: any value is possible.
+2 WORD Signature (first battle only):
Host: must be zero
PHost: must be `48879-init' (modulo 65536). Zero on
subsequent battles.
c2nu: must be 21838 ("NU" in ASCII).
+4 WORD Host: Temperature code of planet for a Ship/Planet battle
PHost: Capability flags (first battle only):
Bit 0 "Death rays" (new weapon possibilities of
PHost 4.0: weapons with Expl=0 in use, or
ShieldKillScaling!=0)
Bit 1 "Ship experience levels" (experience
system of PHost 4.0 is in use)
Bit 2 "Beams" (behaviour of beams that prefer
the enemy ship over fighters, as well as
fighters moving too fast to place all
their strikes, PHost 4.0k+)
Bit 15 Valid bit. If zero, the value of this
word is undefined and should be treated
as zero.
+6 WORD Type of battle
0 Ship/Ship
1 Ship/Planet
+8 WORD Mass of left object
+10 WORD Mass of right object
+12 42 BYTEs Left object (Ship)
+0 20 BYTEs Name. Note that many PHost versions store
this field as a zero-terminated string.
+20 WORD Damage at beginning
+22 WORD Crew
+24 WORD Id Number
+26 BYTE Owner
+27 BYTE Host: zero (Host addresses +26 as a WORD)
PHost: race number, 0 if equal to owner,
or in older PHosts. This is used to ensure
that the VCR player knows the correct
value of the `PlayerRace' option.
+28 BYTE Picture. This field contains the picture
number (RESOURCE.PLN) only, palette
rotations as done by the Planets program
are not reported. So the Alchemy Ships look
exactly the same as a Super Transport
Freighter. The Nebula Class Cruiser usually
has picture #16. However, when it has
Transwarps (type 9), THost assigns it #30
for no apparent reason (easter egg?)
+29 BYTE Host: zero (Host addresses +28 as a WORD)
PHost: hull number of ship, 0 for planets
or in older PHosts.
+30 WORD Type of beams
+32 BYTE Number of beams
+33 BYTE Host: zero (Host addresses +32 as a WORD)
PHost: experience level of object [PHost 4
and later]
+34 WORD Fighter Bays
+36 WORD Torpedo Type
+38 WORD Number of Fighters/Torps
+40 WORD Number of Torpedo Launchers
See below for notes about this field.
+54 42 BYTEs Right object (Ship/Planet). The same format as for the left
one.
+96 WORD Shields of left object
+98 WORD Shields of right objectSecondary Weapons
The "Fighter Bays" (+34) or "Number of torpedo launchers" (+40) field determines whether a ship has fighter bays or torpedo launchers.
If the player has set the `NTP' friendly code, hosts set these fields as follows:
- THost: both are zero. However, the other fields -- torpedo type and ammunition count -- are set to their correct values(!);
- PHost: PHost reports `NTP'ing ships as having the correct number and type of bays/launchers, but no fighters/torps.
Thanks to Akseli M㤫i for pointing this out.
Planets
A planet is always the second (right) object in a battle. In this case, the picture given in the VCR record is ignored. VCR uses a generated picture, see also description of RESOURCE.PLN. For this calculation, the planet temperature is needed.
For planets, the Crew field indicates whether the planet has shields or not. If it is zero, the planet starts with 0% shields, otherwise the maximum possible value (100%).
In PVCR, planets may have torpedoes and fighters, if the configuration says so. In this case, the fields at +34 and later are set as follows:
+34 WORD Fighter Bays
+36 WORD Torpedo Type
+38 WORD Number of Fighters
+40 BYTE Number of Torpedo Launchers
+41 BYTE Number of TorpedoesWhat VCR?
A battle record is said to "bear the PHost signature" if the WORDs at +0 and +2 add up to 48879 as described above. Rumors claim that PHost 3 also uses the value 65261, but I've never seen these in the wild.
If the first battle bears the PHost signature, the file was generated by PHost, otherwise it was made by THost.
Once you know you're dealing with a PHost VCR, you need to tell what version it is:
- If the file contains only one battle, it's PHost 3 or 4.
- If the file contains two battles, and the last one has owner fields zero, the player has used CORR (see below), and the file contains one PHost 3 or 4 fight.
- If the last battle record contains a PHost signature and the "battle type" field is zero or one, it is a VCR.HST file. You can't tell the version from those.
- If the last battle record contains a PHost signature and the "battle type" field is two or larger, it is a PHost 2 player VCR file and the last record is in fact the configuration record.
PHost 3 and 4 can be told apart using the "Capabilities" field. That field contains a bitfield of features needed to play the file. The most significant bit must be set to tell that this field is valid; if it is clear, it should be treated as all-bits-zero. If there are capability flags set which the VCR player doesn't know, it can't play the recordings. PHost versions before 3.4d usually set this field to zero. PHost 4 combat with all capabilities zero is identical to PHost 3 combat; they can't be distinguished.
VPA & CORR
VPA (up to 3.60e) has a bug: when it receives a PHost 3 VCR file with exactly one battle, it displays no battle at all. There is a program CORR.EXE which works around this problem by adding a dummy battle. This dummy battle can not be played. It can be detected because it has almost all fields -- in particular, the owner fields -- are zero.
PHost Configuration
PHost's VCR is configurable. That's why each VCR file generated by PHost 1.x or 2.x contains a configuration record. The file contains one battle less than said in the header, the last battle record is the configuration:
+0 WORD Signature (random value)
+2 WORD Signature. This value plus the one at offset +0 gives
48879 (modulo 65536).
+4 BYTE ("Temperature/Capabilities" field) Major version of PHost.
If this is anything other than 1 or 2, you should ignore
this record: PHost 3 and later never use it.
+5 BYTE Minor version of PHost
+6 WORD ("Battle type" field) Number of valid bytes in the following
structure, 64 in all known versions (3.15.1.1 to 3.2.2.13).
--- Start of Configuration Structure ---
+8 WORD `BayRechargeRate'
+10 WORD `BayRechargeBonus'
+12 WORD `BeamRechargeRate'
+14 WORD `BeamRechargeBonus'
+16 WORD `TubeRechargeRate'
+18 WORD `BeamHitFighterCharge'
+20 WORD `BeamHitShipCharge'
+22 DWORD `TorpFiringRange'
+26 DWORD `BeamFiringRange'
+30 WORD `TorpHitOdds'
+32 WORD `BeamHitOdds'
+34 WORD `BeamHitBonus'
+36 WORD `StrikesPerFighter'
+38 WORD `FighterKillOdds'
+40 WORD `FighterBeamExplosive'
+42 WORD `FighterBeamKill'
+44 WORD `ShipMovementSpeed'
+46 WORD `FighterMovementSpeed'
+48 WORD `BayLaunchInterval'
+50 WORD `MaxFightersLaunched'
+52 WORD `AlternativeCombat'
+54 DWORD `StandoffDistance'
+58 WORD `PlanetsHaveTubes'
+60 WORD `FireOnAttackFighters'
+62 WORD `TorpHitBonus'
+64 WORD `TubeRechargeBonus'
+66 WORD `ShieldDamageScaling'
+68 WORD `HullDamageScaling'
+70 WORD `CrewKillScaling'
--- End of Configuration Structure ---
+72 n BYTEs unusedPHost 3 relies upon the PCONFIG.SRC file and omits the "configuration battle". Due to the "arrayized" (per-player configurable) battle parameters, the parameters wouldn't fit in one battle record.
The `PlayerRace' option is transmitted within each VCR, in the high byte of the Owner field: if an owner field is 0205hex, it names a ship owned by player 5 who plays race 2.
