Duke4.net Forums: Extracting CON Files from Duke 64 and Total Meltdown - Duke4.net Forums

In August 2017, Fox alerted me that he had discovered what looked like CON bytecode inside the executable file on the Total Meltdown disc. We set to work reverse engineering this data into a format that could be used in his mod. During the process, he also found bytecode in the Duke 64 cartridge.

I ended up writing a small program, decon, that can take a Duke PS1 executable or a Duke 64 cartridge dump and output functional CON files, albeit lacking the names of all defines, states, actions, AIs, and moves, as well as any comments in the code, and the exact formatting.

DUKE3DCON.BIN # output of dosdukecon
Duke Nukem 64 (E).z64
Duke Nukem 64 (F).z64
Duke Nukem 64 (Prototype).z64
Duke Nukem 64 (U).z64
SLED_010.27 # France Demo
SLES_007.03 # Europe
SLES_009.87 # France
SLPS_015.57 # Japan
SLUS_003.55 # USA
SLUS_123.45 # Prototype

The key to studying this process and getting reproducible output is a companion utility I wrote, dosdukecon, which compiles 1.4+ CONs to the bytecode format as stored in memory on the PC version. It turns out that only minor changes were made between this structure and what was stored in the respective console ports.

The utilities I wrote to do this, the source code for them, and the resulting output can be found at the following link.

http://hendricks266.duke4.net/stuff/duke3d_con_decompiler_20200211.7z

You can drop in your own copies of the input files and let the tool work, or look at the extracted CONs if you're really curious. This release is mostly about documentation.

The very last step in making this tool was testing that I could 1) compile the 1.5 CONs with dosdukecon, 2) decompile them with decon, 3) recompile them with dosdukecon, and 4) re-decompile them with decon, and make sure that the output of step 1 matched step 3 and that step 2 matched step 4. In doing this, I discovered a bug in the original DOS version's CON parser that has exactly one effect on gameplay.

state checkboss1seekstate
  ai AIBOSS1SEEKENEMY
  ifspritepal 0 nullop
    else   // a fake way of doing a ifspritepal NOT.
      move PALBOSS1RUNVELS seekplayer
ends

state checkboss2seekstate
  ai AIBOSS2SEEKENEMY
  ifspritepal 0 nullop
  else   // a fake way of doing a ifspritepal NOT.
    move PALBOSS2RUNVELS seekplayer
ends

state checkboss3seekstate
  ai AIBOSS3SEEKENEMY
  ifspritepal 0 nullop
  else   // a fake way of doing a ifspritepal NOT.
    move PALBOSS3RUNVELS seekplayer
ends

The bug is that if an "else" is followed by a "//" comment on the same line (before any "{", if applicable), the parser will treat the // as the command to execute instead of whatever follows the else. Because of this, the bosses always move at the slower speeds intended for their miniboss forms.

This bug was inadvertently fixed in EDuke32 somewhere along the line as part of massive upgrades the CON system has received to support all our modding capabilities. I have no plans to reintroduce the bug, because it would involve ripping the parser to pieces, and at least our current behavior has the benefit of being what the developers intended.

The CON files are identical between the U, E, and Prototype versions of Duke 64, and between the US and EU versions of Total Meltdown. The F version of Duke 64 only differs in that some of the internal sound IDs have been changed around, particularly for Duke speech. The JP release of Total Meltdown is slightly more interesting, thanks to some censorship.

The full extent of the changes in that version are:

1. They added this state after "state tipme" (which controls the game's hand with money "shake it baby" behavior)

state (name_unknown)
{
}
ends

2. They changed all "state tipme" calls to the new empty state without removing state tipme from the code.

3. They made the Geisha statue sprite from E3L1 "cactor STATUE" (itself) instead of "cactor STATUEFLASH" when you press use on it.

They haven't included any new command in the CONs, meaning that you can run them in the DOS version. While the PSX version is 100% functional, some stuff would now work with the N64 version due to changes in the source code.

The actortype[] data that holds the useractor enemy/enemystayput definitions is missing. I was likely removed because it's a waste of space except for modding the games. For the PSX version, I assume they use a picnum check. For the N64, they seem to have added the newbeast to the hard-coded enemies list.

The Japanese version of PSX edited the CON and changed the numbers for art and sounds (along with modified maps) for censorship. This is the same method used by the N64 version. I suspect there was some communication between the teams in this aspect. The sound numbers were also modified for the regional versions.

PSX version:

- Like the art, GAME.CON is a mix between version 1.3d and 1.4.

- There's a "debug 1" line in the CEILINGSTEAM actor, causing the console to spam it on Eduke32.

- There are a few mistaken made in the code of the new enemies, especially when they overlap with the code of old enemies.

- When BOSS1 is spawned, its replaced with another actor with the same sprites. The actor picnum is 4610, which is the same as newbeast, however this may be a coincidence since it's in the start of TILES018.ART. This results in BOSS1 loosing its hard-coded behavior, and they made it be deleted when entering in water sectors.

- There's a code for 3 missing breakable objects (3722, 3743 and 3767). The later one is a arcade screen used as a wall texture in E4L6.

N64 version:

- "gamestartup" was removed, the values are used directly in the source code.

- "addkills" is used to increment the rescued babes stats.

- "strength" resets the actor .htextra, which is used to prevent enemies from carrying the damage to the (now shootable) corpses.

- "ifwasweapon" returns RADIUSEXPLOSION for the RPG. This was likely changed for consistency in the gibbing. However it's why octabrains aren't instantly killed by missiles.

- 4 new actors were added following SHOTSPARK1 for each bullet weapon, however they display the same sequence of frames. These actors also serve as projectiles themselves (but the explosive shotgun is not explosive).

- The 3D boss actions are partially controlled by the model animations, and the sprite palette is used as a variable.

- They heavily modified the states that control the gibbing of enemies.

- There's a code for 2 missing babes (3725 and 3757). An interview with Eurocom before the game release mentions women that would wear T-shirts with the slogans "Eat me" or "Wear fur".

- While the captured babes can't be killed, they start with 6,000 hit points.

Interesting... Any explanation for why the Battlelord's tile numbers were relocated to the ones used by the Protector Drone?

If I had to guess they wanted to downscaled only the minibosses, but it didn't worked out because of their lack of experience with CON coding.

I don't know if it is the right place to ask, but I wonder how this code is processed by the original DOS Duke Nukem, and how it is processed by the current eduke32 executables?
1) No curly brackets (Any errors in this case? Does this execute all code after "ifrnd" or only the first line?)

ifrnd 127
  spawn something_1
  spawn something_2
  spawn something_3
else
  spawn something_4

2) Else w/o if (Is it true that Else branch will never be executed?)

//ifrnd 127
{
  spawn 321
}
else
{
  spawn 123
}

3) Nested Ifs (Is it true that Else branch will be processed after any of those Ifs fails?)

ifp palive
  ifcanshoot
    ifcansee
      ifcansing
        spawn prize
else
  spawn penalty

I'm asking this because some old mods have similar bits of code and I can't be sure if it is a mistake or an intent. I can test is for eduke, but I want to know if there's any difference.

Mere_Duke, on 18 March 2018 - 07:07 PM, said:

In current executables it will spawn something_1 50% of the time, then it will always spawn something_2 and something_3, but never spawn something_4

Mere_Duke, on 18 March 2018 - 07:07 PM, said:

Right, just like in the first example.

Mere_Duke, on 18 March 2018 - 07:07 PM, said:

Yes, the else will execute whenever one or more of the if conditions fails. That is totally normal behavior and I use heavily nested ifs like that all the time, on purpose.

New release: http://hendricks266.duke4.net/stuff/duke3d_con_decompiler_20200211.7z

• Total Meltdown: Added support for France and France Demo. Bytecode identical to US and EU releases.
  
• Total Meltdown: Added support for preview prototype release. Very similar to stock Duke 3D 1.5 with beginnings of the TM content, such as pal 16 LIZTROOPs.
  
• Added "_ANON" anonymous dump type which omits indexes of states, actions, ais, and moves for easier diff comparison.