Implementations

← Gotcha Force

This section is a work in progress.

Research is still needed and some paragraphs may be wrong.

Implementation of the game elements

Borg

Borgs GET system

CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:

• The GET value
• The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:

• Galactic Emperor

The rest has no GET value:

• Cyber Death Dragon (Fusion Borg)
• Machine Dragon
• Cyber Machine Seiryu (Fusion Borg)
• Cyber Machine Suzaku (Fusion Borg)
• Cyber Machine Byakko (Fusion Borg)
• Cyber Machine Genbu (Fusion Borg)
• G Red (One of the borg we have)
• Neo G Red (One of the borgs we have)
• G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available on github.

Files and operation

Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). One theory would be that part of the duplicate files would be used to load enemies and the other part allies.

For each borg we have:

plxxxx.pzz
├─ 000 file plxxxxdata.bin  -> always present
├─ 001?                     -> often not present
├─ 002 file plxxxxhit.bin   -> always present
├─ 003 file plxxxxmot.bin   -> often not present
├─ 004 file plxxxx_mdl.arc  -> always present
├─ 005 file plxxxxb_mdl.arc -> always present -> blue model
├─ 006 file plxxxxg_mdl.arc -> always present
├─ 007 file plxxxxs_mdl.arc -> always present -> silver model
├─ 008 file plxxxxc_mdl.arc -> always present
├─ 009 file plxxxxk_mdl.arc -> always present -> black model
├─ 010 TPL -> name of the borg in Japanese
├─ 011 TPL -> name of the borg in Japanese (small format)
├─ 012 TPL -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> TPL -> name of the borg in the game language (small format)
plxxxxdata.bin -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin   -> always present in the afs_data and pzz
plxxxxmot.bin   -> often absent from the afs_data
plxxxx_mdl.arc  -> sometimes missing from afs_data
plxxxxb_mdl.arc -> sometimes missing from afs_data
plxxxxg_mdl.arc -> sometimes missing from afs_data
plxxxxs_mdl.arc -> sometimes missing from afs_data
plxxxxc_mdl.arc -> sometimes missing from afs_data
plxxxxk_mdl.arc -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - Mot'ion) - It can be observed that for these files, there are references that could make one think of plxxxx_xx_animjoint. The investigation conducted by the Smash Bros Brawl community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain scene_data at the end of the data section, and are ''"Scene" files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite pl0300.pzz' where they have a header with flags as well as an adjustable padding if need be to have more elements For example for pl0629.pzz the amount of flags in the headers is more consistent. The origin of the flags and values in the header is currently unknown but these header fields might constitute a list of available meshes in the file. The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

Unimplemented borgs: pl0803 - pl080b - pl0f07
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)

├─ 000 -> plxxxxdata.bin from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> plxxxxmot.bin from the afs_data
├─ 004 -> plxxxx_mdl.arc of the afs_data
├─ 005 -> plxxxxb_mdl.arc of the afs_data
├─ 006 -> plxxxxg_mdl.arc of the afs_data
├─ 007 -> plxxxxs_mdl.arc of the afs_data
├─ 008 -> plxxxxc_mdl.arc of the afs_data
└─ 009 -> plxxxxk_mdl.arc of the afs_data

Data Crystals

The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

Graphical interface elements

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.