DCFFVII Research Thread


AI Researcher
every time the technical stuff comes up i just sit and blankly stare at what i don't understand, which is all of it


Thanks dude, I appreciate your post. ^_^
I hope you've checked out all the posts in previous pages, which are not nearly as IT-nerdy as this current page. :monster:

I found which files hold the character animations during cutscenes. Knowing this I could affect the positions of the models, distort their poses and in general distort the models.



Shelke moved out of the way. :monster:


Shelke phasing back in.

For contrast, here is Reeve as he normally stands...


...versus what I made him do.


Reeve looking up reminds me of the "MAN-FLESH" scene from The Two Towers. :lol:

The files in question always begin with the header "evmXXX" (where XXX represents a three-digit number) followed by strings that identify the character the animation data belongs to. I reckon evm stands for "event manager".

Observe this section from Chapter 10.


Then see what happens when I corrupt the map data.


Much of the area disappears, but an additional staircase spawns instead. The files in question begin with the strings "mapid...rfd" followed by "mapid...cid".

Every area has multiple Map ID files, representing the different chunks that are loaded (and removed) as you progress through the stage. This partitioning saves on the game's processing load.

I reckon rfd stands for "reference data" and cid stands for "collision data/ID". Corrupting map data like I did above also means that Vincent becomes stuck in place. Other times the corruption may lead to Vincent falling through the floor and into the void.

Unfortunately I have not been able to unlock and reveal the Briefing Room and Character Creation/Selection Room of the Deepground Lobby, as the relevant mapid files don't seem to load upon visiting the area.

As I investigated the "models" folder, in addition to my work with the "misc" folder, I also took the time to identify some 3D objects that I previously wasn't sure of as to their use. Like a certain block......





Object "g028" used for Rosso's death scene. Here I replaced g028 with the Omega Report floppy disc. :monster:

I also at last discovered what the dark-brown sheet "g042" is used for: It's the blanket that represents Yuffie discarding her moogle outfit. Thanks to this blanket briefly covering the screen, the transition from Mysterious Ninja (3D model "n001") to Yuffie (3D model "n002") is more seamless. ...Get it? Seamless? ...Because fabric? :awesome:



3D objects I have not yet confirmed their use of, if any:
*Note: Not counting duplicate models and texture-less objects that may or may not be used in-game*

e110 - Sweeper version 2

g051 - Yellow mine/switch

g052 - Large ground mine, purple

While I suspect I may find references to one or more of the above as I investigate the multiplayer maps, there is one object that I absolutely can't pin down.

g029 - Metal railing, crooked


I've searched for this object in so many places but I've come up empty. Starting to think that the object is unused but I'm hoping that somebody here can prove me wrong.

To end on something completely different: I actually plugged in my computer mouse to my PS2 and checked what would happen as I played. I didn't take any snapshots with the Elgato, but in short Vincent's claw appeared as the mouse arrow, same as I've seen in some screenshots and one video of the online mode.


It felt super weird to actually be using a mouse arrow in Dirge of Cerberus. I never use a mouse when playing on PCSX2 and I have failed spectacularly to unlock Vincent's claw on the emulator as I did on my physical PS2.

I am also amused to see that this version of Vincent's claw remains used even post-JORG.
Last edited:
PHEW! I am quite exhausted.

To have any hope of figuring out the encryption for the TTTT files, I need to read assembly. Already knowing the answer to the KelStr encryption, I set out to read the assembly for it. The goal is to learn the basics via the KelStr example where I already know the answer so that I can then move on to the more advanced level of the TTTT decryption assembly.

Viewing the disassembler has always been a dead-end for me in the past. But I got some good advice and hints from the Cheat Engine forum and then set out to read...
- movlps xmm0,[ecx]
- movlps [edx],xmm0
- mov eax,[pcsx2.exe+609B30]
- shl eax,03 { 3 }
- cdq
- mov [pcsx2.exe+609B30],eax
- mov [pcsx2.exe+609B34],edx
- add dword ptr [pcsx2.exe+609B70],01
- lahf
- sar ax,0F { 15 }
- cwde
- mov [pcsx2.exe+609B74],eax
- mov eax,[pcsx2.exe+609B30]
- add eax,[pcsx2.exe+609B80]
- cdq
- mov [pcsx2.exe+609B30],eax
- mov [pcsx2.exe+609B34],edx
- mov edx,pcsx2.exe+609B20
- mov ecx,[pcsx2.exe+609B30]
- mov eax,ecx
- shr eax,0C { 12 }
- mov eax,[eax*4+0F805030]
- mov ebx,300D894F
- add ecx,eax
- js pcsx2.exe+1FC00C0
- movlps xmm1,[ecx]
- movlps [edx],xmm1
- mov eax,[pcsx2.exe+609B20]
- xor [pcsx2.exe+609B40],eax
- mov eax,[pcsx2.exe+609B24]
- xor [pcsx2.exe+609B44],eax
- mov edx,pcsx2.exe+609B40
- mov ecx,[pcsx2.exe+609B60]
- mov eax,ecx
- shr eax,0C { 12 }
- mov eax,[eax*4+0F805030]
- mov ebx,300D898F { [139] }
- add ecx,eax
- js pcsx2.exe+1FC0280
- movlps xmm2,[edx]
- movlps [ecx],xmm2 <--- THE END!

I am exhausted now because I spent most of today reading through the data related to these actions, one by one, very carefully to try and understand as much as possible. Even reading the "useless" lines was important because I need the time to familiarize myself with assembly.

The end result is actually satisfactory. I can see where the pieces line up and how they interact. There is hope.

Some stuff I learned
- How to use "Break and trace" in Cheat Engine. Using the Tracer is in fact the only function that made it possible for me to make sense of what was happening in the assembly instructions you see in the spoiler tag above. The Tracer shows you a lot more of the data that is being handled during each step.

- How to freeze all processes via Cheat Engine so that I no longer have to stress about data passing by too quickly. Glorious!

- xmm registers do not interact with each other. xmm registers store memory and are used as operands in instructions; they don't do operations. In other words, my previous description of the bytes of xmm0 being filtered filtered through xmm1 is false but it is a convenient way to simplify what's happening.

- A "float" value is only 4 bytes long. This is actually why you will see two "XOR" events happening in the assembly above. What am I talking about?

Recall the flipping of bits described by JBedford. The action taking place here is called XOR: A logic gate.


I knew then that a XOR action should be in the assembly, but I was confused as to why two such events were listed. Now, I was going under the assumption that one XOR action was done all at once for the 8-byte array that becomes the text "gun Bull". Not so. The bitmask is retrieved as float values and a float is only 4 bytes long. The XOR event thus has to happen twice before all 8 bytes can be entered into the xmm2 register and then back into the address(es) where the text finally gets displayed.​

Next step: Read the assembly for the TTTT decryption process. That one is almost three times longer than the KelStr process. :wacky:
Last edited:


A fan of Betas/Demos
What I've been wondering, while I also don't understand anything of that too (xD), it's the purpose of those decryption purposes ? :O
Is it to find out about hidden datas in the game, or simply a way for you to get to know how the game itself works in general ? ^^

Anyway, thanks though for your dedication ! :D
the purpose of those decryption purposes ? :O
Is it to find out about hidden datas in the game, or simply a way for you to get to know how the game itself works in general ?
Both, but I'm hoping that the aforementioned TTTT files employ the same type of encryption as in the Text Preview files. If this is the case, then unlocking the TTTT files would also unlock all the game text. Currently though we just don't know.

While I haven't solved the encryption yet, I have been able to peer deeper into the changes that occur when the encrypted TTTT values become their final, decrypted values. In short...the complexity is multiple levels beyond that of the KelStr encryption.

I'll show what I have studied so far.


Above are the encrypted values of the TTTT file, known as "file18379.raw" in the Noesis extraction done on the JP International version of Dirge. Ergo, I am studying the same scene as before: The Online Mode Ending Credits.

The memory region I'm studying is 20A04EF8 &#8594; 20A04EFF, an array of eight bytes.


Above are the final decrypted values, showing references to the background music in use and the strings that determine what text is shown in the ending credits.

30 00 00 49 44 5F 43 52
0  .  .  I  D  _  C  R

What changes do this memory region undergo from the initial encrypted array of bytes to the final, decrypted array of bytes? Quite many.

The game decrypts each eight-byte block from top to bottom, left to right. As I use break and trace on 20A04EF8 and then freeze the game, I can see how this block and all subsequent blocks are still encrypted. All preceding blocks have been decrypted.

I have confirmed that over a span of at least 60 blocks, the encryption key doesn't "loop". Each eight-byte block is unique. In comparison, KelStr had looping encryption keys where you could apply the exact same key over a column of bytes.

The block we are looking at, 20A04EF8 - 20A04EFF, begins with this array of bytes.
16 BA B3 E6 8A AA F6 BA

The change begins with the first offset from the left: 20A04EF8. The byte will change 9 times before 20A04EF8 gets left alone and the next offset, 20A04EF9, changes.

So 20A04EF8 goes through these values:
16 → 6D → E4 → B8 → 9F → 31 → 56 → B9 → 80 → 73

Once address 20A04EF8 becomes the hex value 73, 20A04EF9 goes through its set of changes.

BA → AC → 23 → F7 → DE → 70 → 95 → F8 → BF → B2

And so on!

B3 → 09 → 80 → 54 → 3B → CD → F2 → 55 → 1C → 0F

E6 → 55 → CC → A0 → 87 → 19 → 3E → A1 → 68 → 5B

8A → 6C → E3 → B7 → 9E → 30 → 55 → B8 → 7F → 72

AA → 20 → 97 → 6B → 52 → E4 → 09 → 6C → 33 → 26

F6 → 5C → D3 → A7 → 8E → 20 → 45 → A8 → 6F → 62

BA → 4C → C3 → 97 → 7E → 10 → 35 → 98 → 5F → 52

How does one know beforehand which value changes will happen? I do not know...yet.

The block 20A04EF8 - 20A04EFF becomes this array of bytes, as you can read from the list above:
73 B2 0F 5B 72 26 62 52
This array of bytes is then almost instantly transformed into...

45 FB D2 B4 63 15 B1 CC

...and FINALLY...
30 00 00 49 44 5F 43 52
0  .  .  I  D  _  C  R

We at last have the decrypted values. These steps where the entire block changed at once appears to involve xmm registers and XOR actions (among others) in the same vein as KelStr.

Essentially we can divide the decryption of the TTTT files into two halves: The first half where each individual byte goes through nine changes and the second half where xmm registers and logic actions are employed.

Hopefully, as I learn more about how to use the Cheat Engine tools, I will be able to solve the mystery of this rather roundabout encryption.
Last edited:
Final Fantsy YouTube (who up until recently was named Final Fantasy YouTube, iirc) just uploaded an amazing movie version of Dirge of Cerberus in 1080p, 60fps. This has got to be the highest quality upload of the single player cutscenes, all in one, that I have ever seen. Japanese audio, embedded English subtitles. The subtitles are taken directly from the official localization.

The FMVs remain at 30fps, though in an earlier upload they experimented with somehow faking 60fps in the Midgar Battle cinematic. The end result looked surprisingly good so I wonder why they didn't use that for the full game-movie upload.
I wanted to investigate how much Dirge of Cerberus depends on the memory card so yesterday I did a full playthrough without any memory card inserted in the console.

The playthrough was on the International version (SLPM-66629), Hard mode, Vincent always on Level 1 and scope set to manual. At this point I have a reputation to protect! :lol: No auto-lock for me.

OBSERVATIONS: "No memory card" playthrough

- The game tries (and fails) to create save data every time you start a new playthrough, reach a new checkpoint, when you try to create a Tempsave, destroy a memory capsule or change configuration settings. On top of this there are of course the data saves attempted when finishing a playthrough and when doing Extra Mission stuff (though this final example did not enter into my play session, as we shall soon see).​
You will in other words quite often get the text message "Failed to create save data." where you are then asked if you want to proceed anyway.​
- After defeating Omega Weiss, the final boss, the game tries to create save data five times. Once after the ending credits FMV, once before the "G" scene and three times after the G scene.​
- Without a memory card, clearing a playthrough will not unlock any cutscene categories/folders in the Event Viewer (which would be empty anyway, since the game fails to create save data even when you destroy a memory capsule) nor will the first Extra Mission be unlocked. Your choice of difficulty modes will remain between Normal and Hard: Ex Hard is not unlocked. It will be as though you just quit the game and with no progress made.​
- Thankfully, during a playthrough, the game keeps the config settings you chose. The game complained that it could not save the settings into a memory card but that doesn't stop the setting from happening.​
- If you quit the playthrough, everything will be lost. There will be no checkpoints to browse between in the "Game Start" menu. You'll have to start a new game.​
- "Restart" and "Game Over" function the same as with a memory card and these options won't delete your progress. The game remembers your last checkpoint in this context. Just don't quit the playthrough or everything will be lost.​
- The game will never even attempt to create any save data while you're playing the Tutorial Mode.​

I speculated the possibility that if you played without a memory card that the "Accumulated Results" screen, after defeating Omega Weiss, would not display the correct values. I was shown that the game does in fact keep all the stage results in the console's memory which is why the final rankings screen displayed the values it was supposed to.


I enjoyed seeing how the timing of the "Failed to create save data." message popping up would differ from checkpoint to checkpoint. I reckon that if you wanted to investigate why some areas are more likely than others to create corrupt save data, you would look at how the timing of save data creation might influence the likelihood of save file corruption.
Last edited:
While trying to get a better grasp on how damage is calculated in Dirge of Cerberus, I observed what appears to be a "base damage" associated with attacks inflicted upon Vincent.

When playing as Vincent in his normal form, an exploding drum can midway through Chapter 10 will only cause damage in multiples of 8. Even when maxing out Vincent's defense with the use of cheats, the damage would not go below 8.


In the same way, the Materia Cannon fired by the Black Widow in Chapter 5 only caused damage in multiples of 18. The S-Mines in the mission "Badlands" inflicted damage in multiples of 7 and so on.

This base damage affected how effective defense-boosting equipment was. See below the defense-boosting values associated with the three forms of Cerberus Relief.

Cerberus Relief = +7 Defense
Cerberus Relief β = +11 Defense
Cerberus Relief γ = +15 Defense

Note: The defense value above does not have a 1:1 relationship with Vincent's DEF stat as viewed in the status menu.

When equipped with the first-form Cerberus Relief, the damage inflicted from the exploding drum midway through Chapter 10 was reduced by 56. 7 times 8 equals 56. The defense-boosting value multiplied with the base damage gave us the final reduction in damage.

Thusly, Cerberus Relief β caused 11*8 less damage and Cerberus Relief γ caused 15*8 less damage compared to having no Cerberus Relief equipped.

When transforming into Galian Beast, the associated base damage would be lowered. The base damage of Black Widow's Materia Cannon was reduced from 18 to 3. The base damage of the exploding drum was reduced from 8 to 1.

Another detail I confirmed is that no matter how ridiculously high you make your defense, you can't receive 0 damage. When you take a hit, you always receive the base damage AT LEAST. To receive 0 damage you need to be invincible, like the temporary invincibility when you are revived with a Phoenix Down or when you employ the unused "Hero Tonic" item.

Using the example of the Chapter 10 drum can, here is a graph showing the damage received in relation to Vincent's DEF stat. No defense boosting equipment (Cerberus Relief or Guard N Barrel) was equipped.


Open in separate tab for full size

Without cheats you may only experience a natural DEF stat ranging from 4 to 100, but for the sake of completeness I checked all byte values 0 - 255.

The seemingly consistent pattern of Vincent receiving the same damage for three stat values (like receiving 792 in damage when his DEF stat is 1, 2 or 3) is actually broken twice. He receives 608 in damage over four DEF stat values, 70 - 73. He then receives 352 in damage across the DEF stats 167 - 170. This breaking of the pattern also happens for Galian Beast at the exact same DEF stats.

Any damage formulas extracted from the charts above will only be approximate and do not reveal the actual algorithm used in-game. For fun though, here are approximate damage formulas.

Vincent Valentine: Damage Received = (-8/3) * DEF Stat + 800
Galian Beast: Damage Received = (-8/15) * DEF Stat + 160

In the case of Vincent Valentine, the damage given from this formula will usually have to be either rounded up or rounded down to the closest multiple of 8 in order to match the in-game value. The inconsistency with when you should round up or round down is why the formula above is not useful and not true to the in-game calculations.

Though I've only used integers in the calculations above, some of the unexpected values I've found make me think that the intermediate calculations use floats (in short: decimal values). While player and enemy HP is expressed in integers, using 4-byte addresses, the actual damage calculations might still employ floats.
Last edited:
Almost definitely now solved the TTTT encryption! I just need to generate some more tables and do some more tests before I can be confident enough to request that JBedford (or anybody who might be willing, really) write up a decryption program. Since I can't code, I can't write the program myself. The day will come when I can take care of programming myself but this is not that day.

The timing of me getting to the near-end of this encryption/decryption adventure at the end of March is perfect. April is going to be a very busy month for me and I'll have to take two steps away from Dirge of Cerberus during that time.

I'll be gone for the weekend due to visiting family, but sometime next week you can look forward to a lengthy post about the ridiculously roundabout encryption of the TTTT files.

On a less technical note, the "TTTT" header reminds me of the "TTT terminal" found in Tutorial Mode.




The file header probably isn't a reference to the TTT menu but I'd be amused if it was.

The acronym TTT in the tutorial might stand for "Turks Tactical Training", "Tactical Training Tutorial" etc. The acronym might even contain the word "terminal" even though that word is sometimes added after the acronym.

Happy Easter everyone!


AI Researcher
now i want to know what ttt means

i looked at a video of the japanese version and that line doesn't use a word for terminal, just 'ttt'
So far it is appearing that the TTTT encryptions are not used for the Text Preview files. Even so, I am proud to reveal the full key for the TTTT files.

Before reading the rest of this post I recommend that you read the post from two weeks ago where I show some basics.

Each TTTT file begins with this 8-byte array, hence the name.
54 54 54 54 00 00 2E 00
T  T  T  T  .  .  .  .

This file type is divided into blocks of 8 bytes each. The header seen above is a block that remains untouched during our decryption. In actuality the header changes from "TTTT" to "SSSS" after all the other blocks have been decrypted, but that's not important for our purposes.

Yet again file18379.raw, the TTTT file for the Online Mode Ending Credits, is the example we shall observe.

Including the header, the file has a total of 959 blocks, each one 8 bytes in length. The blocks are devoted to making sure that the decryption of the TTTT file runs smoothly and that the ending credits roll successfully.

To visualize, here are the first 14 blocks.

54 54 54 54 00 00 2E 00 62 36 11 4B 88 59 A7 32
6B 6F 0A 5B 51 71 1A E3 68 61 4B A9 E6 54 7E 8F
CE 74 BE 8D 5E 24 C7 0E 2D 86 5D 14 6B BC 3E C3
82 E5 D8 26 33 19 8C 77 5D E7 EA 94 43 7A 8F 7F
8C 5F 69 9A E5 CF 18 A5 58 3A 3D 75 CD 2B 61 A7
1C B9 A0 4A D7 5E FE 12 87 9A B0 E9 38 81 05 AC
6F EA 83 A9 A2 08 29 77 8E 4A 53 34 1B 43 68 B4

For the decryption, as mentioned before, the header block does not count. The first block that counts is the one immediately after and it is defined as the 0th block. We shall henceforth refer to these numbered TTTT blocks as T-Blocks. As such...

T-Block 0:   62 36 11 4B 88 59 A7 32
T-Block 1:   6B 6F 0A 5B 51 71 1A E3
T-Block 2:   68 61 4B A9 E6 54 7E 8F
T-Block 3:   CE 74 BE 8D 5E 24 C7 0E
T-Block 4:   2D 86 5D 14 6B BC 3E C3
T-Block 5:   82 E5 D8 26 33 19 8C 77
T-Block 6:   5D E7 EA 94 43 7A 8F 7F
T-Block 7:   8C 5F 69 9A E5 CF 18 A5
T-Block 8:   58 3A 3D 75 CD 2B 61 A7
T-Block 9:   1C B9 A0 4A D7 5E FE 12
T-Block 10:  87 9A B0 E9 38 81 05 AC
T-Block 11:  6F EA 83 A9 A2 08 29 77
T-Block 12:  8E 4A 53 34 1B 43 68 B4
T-Block 957: 75 50 90 AF 12 DA 99 67

Where T-Block 957 is the final, 959th block of the file.

We shall now observe, step by step, how T-Block 574 is decrypted.

T-Block 574 is seen below in the memory region 20A04EF8 → 20A04EFF.


As mentioned in the post from two weeks ago, the value of the first byte in the array is changed 9 times before the next byte is handled and goes through 9 changes, then the same thing happens to the next byte and so on until the 8th, final byte goes through its series of value changes.

16 → 6D → E4 → B8 → 9F → 31 → 56 → B9 → 80 → 73

BA → AC → 23 → F7 → DE → 70 → 95 → F8 → BF → B2

B3 → 09 → 80 → 54 → 3B → CD → F2 → 55 → 1C → 0F

E6 → 55 → CC → A0 → 87 → 19 → 3E → A1 → 68 → 5B

8A → 6C → E3 → B7 → 9E → 30 → 55 → B8 → 7F → 72

AA → 20 → 97 → 6B → 52 → E4 → 09 → 6C → 33 → 26

F6 → 5C → D3 → A7 → 8E → 20 → 45 → A8 → 6F → 62

BA → 4C → C3 → 97 → 7E → 10 → 35 → 98 → 5F → 52

...and now T-Block 574 has transformed into this array:
73 B2 0F 5B 72 26 62 52

How do we know which values each byte will take on? I'll show you. Remember that the Calculator likely available on your computer can be set to "Programmer" and that, among many other things, you can do calculations in Hex, Dec and use the Xor function.

Before the first byte received its first change, this calculation happens:
45 XOR [T-Block ID]​

T-Block 574, in hex, is T-Block 23E.

45 XOR 23E = 27B

Only the two low-order digits are used for the subsequent calculation, so we are left with 7B.

Note that the above calculation, using the constant 45, only happens in preparation for the first change to be done to the very first byte in the block. The constant isn't re-used for later calculations in the block.

In the next step, the result we got from...
45 XOR [T-Block ID]​
...is XOR'd with the start-value of our first byte, in the offset 20A04EF8.

In other words...
7B XOR 16 = 6D

16 → 6D

For convenience, we can move ahead and show how the first change occurs in each subsequent offset, 20A04EF9 all the way to 20A04EFF.

To get this change, the formula is...
[Start-value of previous offset] XOR [Start-value of current offset]

We know that the start-value of 20A04EF8 is 16. The start-value of 20A04EF9, the offset we are now calculating, is BA. Thus, the new value of our current offset is 16 XOR BA = AC.

You can test this yourself in a calculator and confirm that the pattern repeats.
16 → 6D
  {45 XOR [T-Block ID]} XOR 16 = 6D

  16 XOR BA = AC

B3 → 09
  BA XOR B3 = 09

E6 → 55
  B3 XOR E6 = 55

8A → 6C
  E6 XOR 8A = 6C

AA → 20
  8A XOR AA = 20

F6 → 5C
  AA XOR F6 = 5C

BA → 4C
  F6 XOR BA = 4C

We have thus covered the ground of the first value change that happens in each offset. The remaining eight value changes are done quite differently.

A series of decryption keys, each key block being an array of 8 bytes, are present in memory during this process. There are in total 32 of these key blocks, or "K-Blocks". Like with the T-Blocks, the first block is numbered 0.

K-Block 0:  99 E0 CD 84 0D 90 97 72
K-Block 1:  FD 62 05 98 43 D0 F5 3C
K-Block 2:  F1 EE 1A F8 51 11 CD 30
K-Block 3:  B5 AA 86 D8 99 56 01 F4
K-Block 4:  89 55 A1 3A 01 B1 06 C4
K-Block 5:  AD AB 26 25 06 75 21 D4
K-Block 6:  61 5A C1 B9 1E 49 A7 24
K-Block 7:  E5 C3 C6 A0 99 6D 44 B7
K-Block 8:  79 D3 E1 23 00 24 56 94
K-Block 9:  5D 21 69 B3 00 B4 AE E5
K-Block 10: D1 A6 0D 81 03 84 69 7C
K-Block 11: 15 42 44 85 11 94 0F 6E
K-Block 12: 69 4A 55 9A 57 E4 4D 26
K-Block 13: 0D 74 AA 03 B6 75 85 BF
K-Block 14: 41 44 54 12 8E 4C 9B BD
K-Block 15: 45 55 A5 5B C6 7E 08 B4
K-Block 16: 59 AA 3A CA DF 79 2A 84
K-Block 17: BD 53 25 F3 5E 61 D4 94
K-Block 18: B1 A2 BA BF DA E6 25 E8
K-Block 19: 75 2D A5 BE 45 82 BD 88
K-Block 20: 49 E3 39 B9 5C 8B B3 AB
K-Block 21: 6D 70 21 9E CF B8 81 5A
K-Block 22: 21 32 A7 16 0E 9C 88 C4
K-Block 23: A5 FA 43 71 46 0C AB D6
K-Block 24: 39 E5 53 36 60 3D 57 31
K-Block 25: 1D 7A A3 0F E1 32 B4 F6
K-Block 26: 91 62 31 4E 65 FE 84 D1
K-Block 27: D5 EC F6 86 FA F7 98 17
K-Block 28: 29 A0 D2 A2 E4 D7 FC 75
K-Block 29: CD 20 1D 2E 77 37 F0 4D
K-Block 30: 01 A4 91 E6 53 15 B1 85
K-Block 31: 05 34 D8 80 A3 6A 75 9C

Each T-Block only uses one particular K-Block for its decryption/encryption. The K-Block in use is especially easy to spot for the first 32 blocks, since the block IDs match each other.

T-Block 0 will use K-Block 0. T-Block 1 will use K-Block 1. T-Block 2 will use K-Block 2 and so on.

Once T-Block 31 has been decrypted with help of K-Block 31, we move on to T-Block 32 which will use K-Block 0 for the decryption. Thus, the game continuously cycles through the 32 K-Blocks. See examples below to visualize.

T-Block 0   ←→ K-Block 0
T-Block 32  ←→ K-Block 0
T-Block 64  ←→ K-Block 0
T-Block 96  ←→ K-Block 0
T-Block 128 ←→ K-Block 0

T-Block 1   ←→ K-Block 1
T-Block 33  ←→ K-Block 1
T-Block 65  ←→ K-Block 1
T-Block 97  ←→ K-Block 1
T-Block 129 ←→ K-Block 1

T-Block 18  ←→ K-Block 18
T-Block 50  ←→ K-Block 18
T-Block 82  ←→ K-Block 18
T-Block 114 ←→ K-Block 18
T-Block 146 ←→ K-Block 18

Which K-Block will our T-Block 574 use? With a little bit of math, we know that it is...

K-Block 30: 01 A4 91 E6 53 15 B1 85

From here, the game will use the bytes in the key-block to calculate the subsequent value changes in the current offset. The value is changed eight times, matching the eight bytes in the array above. So the formula can be expressed as...

1st calculation:  Current Byte Value + 78 - 01 = [COLOR="pink"]New Byte Value[/COLOR]
2nd calculation:  [COLOR="pink"]Current Byte Value[/COLOR] + 78 - A4 = [COLOR="Lime"]New Byte Value[/COLOR]
3rd calculation:  [COLOR="lime"]Current Byte Value[/COLOR] + 78 - 91 = [COLOR="Cyan"]New Byte Value[/COLOR]
4th calculation:  [COLOR="cyan"]Current Byte Value[/COLOR] + 78 - E6 = [COLOR="DarkOrchid"]New Byte Value[/COLOR]
5th calculation:  [COLOR="darkorchid"]Current Byte Value[/COLOR] + 78 - 53 = [COLOR="Teal"]New Byte Value[/COLOR]
6th calculation:  [COLOR="teal"]Current Byte Value[/COLOR] + 78 - 15 = [COLOR="SandyBrown"]New Byte Value[/COLOR]
7th calculation:  [COLOR="sandybrown"]Current Byte Value[/COLOR] + 78 - B1 = [COLOR="DarkRed"]New Byte Value[/COLOR]
8th calculation:  [COLOR="darkred"]Current Byte Value[/COLOR] + 78 - 85 = [COLOR="LemonChiffon"]New Byte Value[/COLOR]
Color coding to emphasize that what becomes the New Byte Value on one row/calculation is used as the "Current Byte Value" on the next row/calculation. The number 78 is a constant and is the same for all T-Blocks and offsets. Observe how the column that reads "01 A4 91 E6 53 15 B1 85" are the bytes from K-Block 30.

Remember that we previously advanced our first offset from the hex value 16 to the hex value 6D.

16 → 6D

Thusly, 6D is the "Current Byte Value" we use for our first calculation. Using the calculations for our offset 20A04EF8, we get...
6D + 78 - 01 = [COLOR="pink"]E4
E4[/COLOR] + 78 - A4 = [COLOR="Lime"]B8
B8[/COLOR] + 78 - 91 = [COLOR="Cyan"]9F
9F[/COLOR] + 78 - E6 = [COLOR="DarkOrchid"]31
31[/COLOR] + 78 - 53 = [COLOR="Teal"]56
56[/COLOR] + 78 - 15 = [COLOR="SandyBrown"]B9
B9[/COLOR] + 78 - B1 = [COLOR="DarkRed"]80
80[/COLOR] + 78 - 85 = [COLOR="LemonChiffon"]73[/COLOR]
We see that this calculated progression of value changes matches what is spotted in-game.

16 → 6D → E4 → B8 → 9F → 31 → 56 → B9 → 80 → 73

Note that whenever a calculation leads to a value of three digits or more, only the two lowest-order (or "rightmost") digits are used.

The same formula is applied for all other offsets in the T-Block. If you have any doubts, you can use the formula to confirm how these value changes come about.

BA → AC → 23 → F7 → DE → 70 → 95 → F8 → BF → B2

B3 → 09 → 80 → 54 → 3B → CD → F2 → 55 → 1C → 0F

E6 → 55 → CC → A0 → 87 → 19 → 3E → A1 → 68 → 5B

8A → 6C → E3 → B7 → 9E → 30 → 55 → B8 → 7F → 72

AA → 20 → 97 → 6B → 52 → E4 → 09 → 6C → 33 → 26

F6 → 5C → D3 → A7 → 8E → 20 → 45 → A8 → 6F → 62

BA → 4C → C3 → 97 → 7E → 10 → 35 → 98 → 5F → 52

Just remember that different K-Blocks are used for different T-Blocks, so a more general formula for calculating these eight value changes could look like this:
1st calculation:  Current Byte Value + 78 - [K-Block 1st Byte] = [COLOR="pink"]New Byte Value[/COLOR]
2nd calculation:  [COLOR="pink"]Current Byte Value[/COLOR] + 78 - [K-Block 2nd Byte] = [COLOR="Lime"]New Byte Value[/COLOR]
3rd calculation:  [COLOR="lime"]Current Byte Value[/COLOR] + 78 - [K-Block 3rd Byte] = [COLOR="Cyan"]New Byte Value[/COLOR]
4th calculation:  [COLOR="cyan"]Current Byte Value[/COLOR] + 78 - [K-Block 4th Byte] = [COLOR="DarkOrchid"]New Byte Value[/COLOR]
5th calculation:  [COLOR="darkorchid"]Current Byte Value[/COLOR] + 78 - [K-Block 5th Byte] = [COLOR="Teal"]New Byte Value[/COLOR]
6th calculation:  [COLOR="teal"]Current Byte Value[/COLOR] + 78 - [K-Block 6th Byte] = [COLOR="SandyBrown"]New Byte Value[/COLOR]
7th calculation:  [COLOR="sandybrown"]Current Byte Value[/COLOR] + 78 - [K-Block 7th Byte] = [COLOR="DarkRed"]New Byte Value[/COLOR]
8th calculation:  [COLOR="darkred"]Current Byte Value[/COLOR] + 78 - [K-Block 8th Byte] = [COLOR="LemonChiffon"]New Byte Value[/COLOR]
The K-Block bytes are here counted from left-to-right and with the block bytes printed in "little-endian" (backwards) style. We'll get back soon to the topic of little-endian (backwards) versus big-endian (forwards).

And that is how T-Block 574 gets transformed from its initial array of byte values...
16 BA B3 E6 8A AA F6 BA
...to the following array of bytes.
73 B2 0F 5B 72 26 62 52

Let's take the decimal value 7777. If you enter this value into your calculator and then transform it into hex, it becomes written as 1E61. This style is "big-endian" (or as I like to call it, "forwards") where the bytes are arranged in the order you'd expect them to from calculations both manual and on a calculator.

When changing from big-endian to little-endian ("backwards"), 1E61 becomes written as 611E. They both still mean the decimal value 7777, just written differently. I prefer to write little endian with spaces between the bytes, so 611E becomes "61 1E", as that is also how the bytes are displayed in hex editors and in the Cheat Engine memory viewer.

I talk about endianness because in order to get the calculations right, we need to change some "little-endian" array of bytes to "big-endian" style.

See here our current array for T-Block 574:
Little-endian: 73 B2 0F 5B 72 26 62 52
Big-endian:    [COLOR="Lime"]52622672[/COLOR][COLOR="LemonChiffon"]5B0FB273[/COLOR]

We will also need our K-Block, K-Block 30, in big-endian.
Little-endian: 01 A4 91 E6 53 15 B1 85
Big-endian:    [COLOR="lime"]85B11553[/COLOR][COLOR="lemonchiffon"]E691A401[/COLOR]

Notice the color coding. What we are going to do is subtract the first half of (big-endian) T-Block 574 with the first half of (big-endian) K-Block 30. The result will then be XOR'd through a special key.

We will also subtract the second half of T-Block 574 with the second half of K-Block 30. The result will be XOR'd through its own special key.

The two results from the calculations above will be splashed together to form our new array for T-Block 574.

52622672 - 85B11553 = FFFFFFFFCCB1111F

5B0FB273 - E691A401 = FFFFFFFF747E0E72

We are only interested in the eight rightmost digits, so we can ignore all those Fs. These results are going to be XOR'd through two special keys.

Special Key 1
This key will be XOR'd with the result we got from calculating the first halves of our big-endian T-Block & K-Block arrays.

The following formula creates the first Special Key:
[T-Block ID in Hex] multiplied by 2
The T-Block ID in decimal is 574. In hexadecimal it is 23E.
23E * 2 = 47C. Thusly...

Special Key 1 = 47C

Special Key 2
This key will be XOR'd with the result we got from calculating the latter halves of our big-endian T-Block & K-Block arrays.

Special Key 2 for T-Block 0 is the following value:

Special Key 2 for T-Block 1 is the following value:
 A1652347 + 802008 = A1E5434F

Special Key 2 for T-Block 2 is the following value:
 A1652347 + 802008*2 = A2656357

In other words, the value of Special Key 2 is expressed by the following formula:
A1652347 + 802008 * [T-Block ID in hex]

What then is Special Key 2 for T-Block 574 (hex 23E)?

A1652347 + 802008 * 23E = 1C0ACF537

We only want the eight rightmost digits, so we can discard the 1 generated in the leftmost spot above.

Now we just refresh our memories of the subtractions we perform earlier and XOR these through their corresponding keys.

52622672 - 85B11553 = FFFFFFFFCCB1111F

CCB1111F XOR 47C = CCB11563

5B0FB273 - E691A401 = FFFFFFFF747E0E72

747E0E72 XOR C0ACF537 = B4D2FB45

Our new array of bytes in big-endian is thusly...

Or written in little-endian...
45 FB D2 B4 63 15 B1 CC

That was the heavily complicated way that T-Block 574 changed from the array...
73 B2 0F 5B 72 26 62 52
to its penultimate set of byte values.
45 FB D2 B4 63 15 B1 CC

We are close to the finish line!

We actually don't need to rewrite the arrays to big-endian for the calculations done in this step but I included the big-endian form simply because the previous decryption step conditioned me to. :wacky:

The current array of bytes for T-Block 574 as written in both endian forms.
Little-endian: 45 FB D2 B4 63 15 B1 CC
Big-endian: [COLOR="Orange"]CCB11563[/COLOR][COLOR="Plum"]B4D2FB45[/COLOR]

Below is, again, K-Block 30. Match the color codings of T-Block 574 and K-Block 30 to know which values will be XOR'd together.
Little-endian: 01 A4 91 E6 53 15 B1 85
Big-endian:    [COLOR="Orange"]85B11553[/COLOR][COLOR="Plum"]E691A401[/COLOR]

CCB11563 XOR 85B11553 = 49000030

B4D2FB45 XOR E691A401 = 52435F44

The final twist is that we do NOT combine 49000030 and 52435F44 to form 4900003052435F44. What you must do here is to have the two halves switch places.


Rewriting the value above to little-endian we get our final, decrypted values and the text that is associated with T-Block 574.

30 00 00 49 44 5F 43 52
0  .  .  I  D  _  C  R


...and that is how it's done.

Last edited:

Clement Rage

Pro Adventurer
So, I played the Dirge tutorial today, and the voice over said 'Good day, Mr. Valentine'. I swear every other time I've done it she said 'good evening'. Am I delusional?
While browsing the Dirge of Cerberus screenshots on a Spanish gaming website I found a (to me) new screenshot from the beta phase of the multiplayer.


The screenshots on the site are watermark nightmares! I am amused by how I was able to instantly spot that among the over 800 screenshots I have from the beta testing phase that this image was not among them. Naturally, because the brain is an imperfect storage device, I made sure to browse all my folders before saying with 100% certainty that this snapshot is indeed new. The original source is unknown though it's probably from a deleted Japanese blog.

I really should do a better job at browsing websites that are in neither English nor Japanese. So many treasures could be hiding out there in plain sight simply because I'm not bothering to google translate search terms for Spanish/Portuguese/French/Italian/German/Dutch/Russian etc.
I made searches in German and I was rewarded accordingly. Found great treasure on a website I am actually quite familiar with: CetraConnection!

What did I find? Two of the long-sought video recordings from the beta phase of Dirge's online mode!

Download link: gameplayonline_1.wmv
Length: 5m15s
Team Battle in the Kalm Streets.
Resolution: 208x160​
Observe the beta-style timer in the top-middle and the beta icon to the top right. Reference photo below from Haggy's blog to help you know what you're looking for:

Notice also that nobody can shoot in mid-air since that feature wasn't available in the beta. After the battle is won the player receives the Slayer Medal which is rewarded to the player with the most enemy kills.

Download link: gameplayonline_2.wmv
Length: This video is meant to be 3m50s, but it is only 9 seconds long. Probably due to an error when the video was uploaded.
Resolution: 320x240

We can make out the player name "Topix" in the second video. I am familiar with this player name from other archived media and websites about the online mode! :D


There are three beta recordings that I know of.
- Collector's Mind Mission. Original file name: up0023.
- (Kalm) Church Team Battle. Original file name: up0025.
- Kalm Streets Team Battle. Original file name (probably) : up0044.

up0044 is accounted for with gameplayonline_1.wmv. It is unknown if a higher resolution version exists/existed. The second downloadable video, if we had it in its entirety, would probably prove to be up0025.

I am so thankful to CetraConnection for uploading these files to their own servers! The original Japanese servers were quickly lost, followed by the loss of RapidShare and FileFront where the English-speaking fans had reuploaded these videos.

EDIT: I shall let this classic theme express my feelings for me. :D So happy right now due to finally having recordings from the beta testing phase!

Last edited:
The more I look at the Beta Kalm Streets Team Battle video the better it gets. Add to that I have the documentation to provide plenty of context to what we see.

- The point-of-view player character is "Guin" and I recognize them from multiple comments on monster_78's blog and from one comment on Bonnie's blog. Both are from the 2005/beta era.

Bonnie's blog, October 31 entry

Entries on monster_78's blog where Guin wrote comments:
October 4
October 6
October 7
October 9
October 20
October 23
November 1

- Guin belonged to the beta version of Team2ch, one of the top dominant teams of the online mode. The players Unicorn and Jeil, visible here only in chat, played faithfully in Team2ch throughout the 2006 era. Since Team2ch was affiliated with Area/Sector 3 of the Deepground Lobby in the beta phase, the players could acquire and equip the Tonberry Mask. There is no sign of Guin playing the online mode during the 2006 era. If they did, they probably did so under a different player name.

- The presence of the player SQEX-Soldier12 pretty definitively dates the recording to be from the beta's final day: October 31, when the Square Enix staff joined the other testers for a "Last Shooting" event. The staff did the same on September 29, 2006, just before the servers were shut down for good.

- Judging by the ammo round caps, and the fact that this is the beta, we can tell that Guin has equipped the handgun Caballerial, the rifle Caol and the machine gun Ullman or Smith. The barrels match their respective gun type: Medium/Normal for handgun, long barrel for the rifle and short barrel for the machine gun. No materia equipped. Guin is wearing the Tonberry Cap and the Sniper Suit.

- At the bottom left of the screen there are normally the numbers "123" with one number being highlighted to show which of the weapon slots you are using.


There are exceptions, like when the online mission "Silent Killing" restricts you to only one weapon slot, the numbers "123" aren't displayed.

In the beta the weapon slot numbering isn't present at all in the bottom left corner!

This was already strongly indicated via screenshots from the beta but now we get to see it definitively in both beta videos.

- Mako Point at 0:21! These were not present in the 2006 version of the online mode. You can hear other players stepping on the Mako Point but for some reason Guin doesn't step on it. On one hand Guin doesn't have any materia equipped, on the other hand you could use MP to trigger limit breaks in the online beta. For whatever reason Guin doesn't prioritize limit breaks.

- Guin starts out with an X-Potion [エクスポーション] and later picks up a Hi-Potion [ハイポーション]. Both these items went unused in the online mode of 2006, seeing as they were overkill when it came to HP restoration. The standard Potion was already potent enough.

At 3:23, Guin picks up a Phoenix Pinion [フェニックスの羽根] and proceeds to use it. This generates a two-winged icon at the bottom left.


When you use a Phoenix Down, it generates two wings with a halo on top.


Going back to the video, we get a wonderful confirmation at the very end. Guin is KO'd...but is not revived! The two-winged icon, or the "Phoenix Pinion status effect", is removed while Guin waits to be respawned at a standard spot.

So what just happened? This is the description to the Phoenix Pinion item:
戦闘不能時に 50%の確率で自動的に復活し、HPを全回復する。
Instantly restores all HP when
user is KO'd. Has a success
rate of 50 percent.

Thus we see that Guin was not revived because the dice did not roll in their favor. The reason I am so ecstatic to see this 50-percent mechanic in effect is because it is not present on the game discs. If you unlock the Phoenix Pinion, use it and then get killed, you ALWAYS get revived but only at 10% of your max HP.

The beta recording proves that, for the online play, the item had been fully programmed to match its in-game description.

The Phoenix Pinion would become an unused item after the 2005 beta.

- Team Ifrit wins with a score of 30-24 (win by kill count), with Guin being on the victorious side. By receiving the Slayer Medal Guin also receives 80 Ranking Points. This leads to a total RP of 108595! As a reference point, you needed 70000 points in the 2006 era in order to qualify for the Tsviet exam mission.

Guin has 214953 gil at the end. Quite a large amount!

I hope that one day I can get one or more people to transcribe and translate all the chat messages in these recordings. So much more life and detail is lost on me because I don't know what is being said. Thankfully my deep knowledge of the game makes it possible for me to enjoy the recordings regardless.
Last edited:
Finding the beta video reawakened my transcribing obsession. I've been transcribing the majority of the Japanese text from doonkonishi's and Northern Kingdom's videos, with some help here and there from hito and X-SOLDIER. Many thanks to these guys!

It's been fun to confirm what type of messages the game chat is usually filled with. Most of chat contains stock phrases for greetings, hyping up for battles and thanking people for a good session. Some stock phrases in chat will appear when the player uses emotes.

After one of the "Deepground Assault" tournament matches, specifically the Team2ch vs Rabid match where the latter got quite slaughtered, the SQEX judge writes "Both teams were awesome". To this Muimui, member of Rabid, writes a chat message to their own team that basically reads "Yeah...except we were utterly defeated:wacky:".

The additional observations I've made while, yet again, applying a fine-tooth comb to the online mode are too many to count in full. Here are some of these observations.

- After joining Team Shiva, the player arrow on the menu map turns blue. No doubt it turns red when you join Team Ifrit.

- Recall that the FA Mode, at least in name, is a battle mode that was never available for players. In the DC Complete Guide, which contains screenshots that represent a development phase after beta but before retail, I suddenly saw this on page 238 and 241...



What a tease! :lol:

- Thanks to a screenshot from page 247 of the DC Complete Guide, I can guess with confidence what the equivalent screen in the low-resolution beta recording is saying.







Compare this then to the end of the beta video that I analyzed in my previous post.


The 敗北 from the guide screenshot will here be 勝利, since the former is a lost battle and the latter is a victory. The 勝利 kanji are derived from the text used for the "Combat Results" screen in the retail 2006 era.

Translation said:

Combat Results

Number of enemies killed     20 x10   200 pts
Number of times KO'd in battle  -10 x2   -20 pts
Number of NPCs destroyed    5 x0     0 pts
Victory in battle          50     50 pts

Total 230 pts

Ranking Points: 108515 pts
NPCs here refer to enemies such as DG Beasts, Bull Heads, Dual Horns etc. I have only seen references to these "NPCs" appearing in Team Battles during the beta phase so it's possible the feature was disabled for the 2006 era.

The "Combat Results" screen text for TBT changed a bit for the retail era:





Google Translate said:

Combat Results

Number of defeated
Times KO'd
I made my allies unable to fight
Continuous killing bonus
Team: Total defeated
Team: Win the battle
Battle Scale Bonus Coefficient


Ranking Points

- Subtitles for the Victory!/Failed screen was removed at some point during 2006.


Team Shiva Wins by Kill Count

The screenshot above is from ITmedia's review of DoC, uploaded on February 8, 2006. Sometime after this point, the row of text below Victory!/Failed (for TBT at least) was discarded.


PlayOnline image from 2005, beta (or slightly after or before beta)

Flan Wins by Mako Capsule Count

End of 5-minute beta recording

Team Ifrit Wins by Kill Count

DC Complete Guide: Page 247

Team Shiva's Base Captured
Last edited:
It is a wonderful shock each time to find "new" blog entries about the online mode. In today's case, blogger zerohour_co made two posts about Dirge's multiplayer.
- January 27, 2006
- January 29, 2006

This means two new screenshots to my gallery. New screenshots and blog discoveries are few and far between these days.


I've been transcribing Japanese text from the DC Official Complete Guide like a man possessed. No OCR, all manual. Firstly OCR is too unreliable, secondly by doing it manually I feel more motivated to *actually* try to learn and remember a few symbols. Naturally I am focusing all my efforts on the pages about the multiplayer mode.

Mistakes are inevitable but I AM improving!

From page 244:

Google Translation said:
It is a mode that achieves the clear condition such as
"Destroy 50 DG Soldier", the mission accepted by the class
is different. Unlike other modes, enemies who appeared in
Single Player mode such as Guard Hound are opponents. Even
a single person can play, but there are also missions with a
high level of difficulty that require cooperation of more than
one person.
This seemingly confirms my suspicion that after the beta, NPC enemies like Guard Hound and Dual Horn would not appear in Team Battles. They became limited to the missions in the 2006 era.

Recall that new players in the 2006 era (I have never seen this mentioned for the beta phase) had a beginner's mark next to their player name.

Page 240:

Beginner's Machine
Google Translate said:
Beginner's Machine
Terminal installed only in E-8 of Deepground Area 3. When you examine it,
"Beginner's Machine menu" is displayed, you can erase the beginner's mark
(see page 2) and hear advice on battle. By the way there are several advice,
so please check it over and over.

Page 241:

TIPS 初心者マークを消すには?

E-8にある「Beginner's Machine」を調べて「初心者
Google Translate said:
TIPS How to erase the novice mark?
For players who have just started Multiplayer mode,
"Beginner Mark" is displayed next to their names.
This means that the player is a brand-new soldier.
To eliminate this, check "Beginner's Machine" in E-8 of
Deepground Area 3 and choose "to graduate beginner"
or 20 battle to defeat it.
That's neat to know you had two options for removing the beginner's mark: Select the option via the Beginner's Machine or do 20 battles.

On the same topic, I learned that the battle mode "Beginner Match" is only available to those who still have the novice mark.

Page 244:

Google Translate said:
Beginner Match
Mode in which only a brand-new player with a
beginner's mark can participate. Since only
the beginners can participate in this mode,
even if you are not accustomed to playing the game,
feel free to join in. Let's build the experience of
the battle here and hone our skills. If you improve
to a certain extent it is usually a challenge to play against.
This knowledge adds more context to my analysis of the Battle Entry menu.
Last edited:

Each Unit creator decided on their own emblem which was created using the game's templates, combining a "shield" and a pattern to have on said shield.

I sincerely hope that the emblem graphics are still on the game disc. This is yet one more aspect of the online mode where we lack complete documentation, as we don't know all the shields and patterns one could choose.

Here are all the sources we currently have of said graphics.


From Kupoa's blog, their Unit's progression from 0 ranking points to 63431 points.





Unless I'm forgetting some brief moment in a video recording that showed Unit emblems, these are all the sources we currently have. ...Actually, there might be one more.

From the post-JORG game: Extra Features &#8594; Art Gallery &#8594; Shinra Building &#8594; Shinra Building Subterrane 3


After showing artwork for the gate to Deepground that was used in the final game, we see this concept art for alternate versions of the gate.

One of the gates show a mirrored version of the unicorn/lion/chimera that we saw earlier. The two are not identical but I'm willing to bet that we're seeing more Unit emblem patterns in this concept art.



So which Deepground Unit are you? Midgardsormr? Leviathan? Chimera? Phoenix? The concept art does trigger the imagination.

If you were to create a Unit in Dirge of Cerberus, what would you name it? I sometimes fantasize about what units TLS members would create if they played the online game.

"The Lifestream"
"Shilly Shally"
"Dilly Dally"
"Cookie Monsters" :monster:
Cloud_S has just shared their treasure trove of recordings from the online mode. I am absolutely stunned by the amount of new stuff. You can download it all here. I can't thank Cloud_S enough. Stunned with gratitude, I am.

Translation said:
Officer-East: I am the one who is responsible for the level promotion exams. If you want to raise your level, you need to pass through all the exams given by us, the officers.

*Then Officer-East goes into a thinking posture.*

Officer-East: ……Is this the first time that I’ve met you? No, in fact, before I bother remembering your face, there are many others who die before their face is worth remembering as well. And then naturally, I’ve abandoned all effort in trying to remember them. Let me know if there is anything wrong.

*Officer-East goes back to his normal posture again.*

Officer-East: Well then, you’d probably know by now, in Deepground, strength is everything. You have the right to keep on winning in order to prove your survival in Deepground, and that way, the roads will be opened for you. That is the rule of this world. It is good thing to know this from the start.

*Scene cuts as to another angle of Officer-East.*

Officer-East: Then hurry up and complete the following battle three times. We will know whether if you can go on and continue here from the results you get from your tests. For everything, the “beginning” is essential. First, go to “Beginners’ Battle” and fight, and then you will probably be used to how everything works around here. If you’re not confident enough in yours skills yet, then try out the “Mission Mode” and train yourself from there.

*Scene cuts to a Terminal with a DGC Sturm standing in front of it.*

Officer-East: Go and head towards the battle entry from that terminal. For a more detailed description, it is a good idea to talk to the DGC Sturm standing next to it.

*Scene goes back to Officer-East.*

Officer-East: Hail P.S.!!
- Translation Source

The folder also contains cutscenes from the online mode but with a different player character from what we've had saved before. We also get confirmed here that the player character Argento is talking to, in this familiar scene, is Mana3.

Would write more but I gotta go. Just had to share this before I leave for work. :D
Last edited:
An apparent solution to the "corrupt save data" problem that I'm now posting here as a reminder for whenever I replay Dirge.
That glitch in the Extra Missions that I posted a few months ago, well I fixed it. I just replayed EXtreme mode and the error messages that told me my files were corrupted dissappeared. My awsome weapons also returned to the Extra Missions inventory such as the Ultima Weapon and such. Now I plan on finishing these extra levels to unlock what is almost impossible almost.... ^_^ Wish me luck.​

So replaying Extreme Mode is the key? hmmmm imma try that, thanks anyway.​
Yes, I am currently browsing ALL the threads on the DoC GameFAQs board. :mon:


A fan of Betas/Demos
Those new discoveries about the online mode are impressive. And yeah, old articles in other languages can have their own little exclusive contents too ^^
For example, for Zelda OOT 64, some exclusive beta screenshots were only available in a french magazine. You are doing well to expend your researches like that :)

As for the video footages, nevermind, I messaged you before thinking checking this thread ... my mistake lol
Thanks to the person who recorded these, maybe one day, you'll find a way to play those missions yourself, who knows. I'm not loosing hopes on you :P
Top Bottom