Final Fantasy VIII

2011-05-01 08:36:30 pm

If you're not in a rush try to walk through walls...
There are three(?) known shortcuts.
The one on the train, one one in space and the one in the past (that doesn't save time)

If you could glitch into the dollet bar early that might be interesting. (save time vs. having siren)

DarkKobold

2011-05-02 12:20:30 pm

RPG TASer

Quote from gyth:

If you're not in a rush try to walk through walls...
There are three(?) known shortcuts.
The one on the train, one one in space and the one in the past (that doesn't save time)

If you could glitch into the dollet bar early that might be interesting. (save time vs. having siren)

I don't know these glitches. Also, is there any confirmation if you get into the Dollet bar, you can skip all of dollet?

Poxnor

2011-05-02 12:26:00 pm

Moo! Flap! Hug!

Quote from DarkKobold:

I don't know these glitches.

The glitch on the train is that you can walk through the person blocking the door, prior to naming Rinoa. It saves about two minutes:

The glitch on the space station is that when you are first thawed out (right when you arrive on the space station), you can go through the door at the top of the screen when it opens to admit the doctors. You skip a bundle of dialogue that way.

I don't know what the third glitch is, but if it saves no time, that's no biggie.

Quote from DarkKobold:

Also, is there any confirmation if you get into the Dollet bar, you can skip all of dollet?

I think gyth was theorizing? I've never seen that glitch.

Sush

2011-05-02 12:46:24 pm

If you meant entering the bar when running from the Spider it's not a glitch but lets you skip the last escape FMV saving a good bit of time.

DarkKobold

2011-05-02 01:54:58 pm

RPG TASer

Quote from Sush:

If you meant entering the bar when running from the Spider it's not a glitch but lets you skip the last escape FMV saving a good bit of time.

I think he meant glitching into the bar after the 2nd G-soldier fight, thereby skipping all of the XATM-092 and Elvorett fight (hence why he said missing Siren).

I'll try at some point in the future to see if I can do some memory editing on character position, and see what happens. I'm more curious to see what would happen if you could get past the traffic jam in Dream Sequence 1, and go into Caraway's Mansion as Laguna. My guess is the game would crash, but a Timber/TVStation/DreamSequence2/GalbadianGarden skip would be freaking ridiculous.

You wouldn't lose anything of value (32 AP, 1 SeeD level, possible Spd-J scroll in Disc 3), and you'd save over an hour.

Poxnor

Edit history:

Poxnor: 2011-05-02 10:49:26 pm

Poxnor: 2011-05-02 10:46:24 pm

Poxnor: 2011-05-02 10:44:04 pm

Poxnor: 2011-05-02 08:09:57 pm

Poxnor: 2011-05-02 07:46:08 pm

Poxnor: 2011-05-02 07:45:12 pm

2011-05-02 07:04:02 pm

Moo! Flap! Hug!

Quote from DarkKobold:

Poxnor: Did you get the script running?

I can confirm that the card game uses more than eight bits of entropy. I dumped 256 hands for Trepie 1; then, went back to a save state before engaging him, ran around a little bit (opened the menu, left the room, etc), came back, and dumped another 256 hands. And I got a completely different set of hands dumped (not just a reordering of the hands, but truly different hands). I'll try to see if I can determine how much entropy is actually used, but it's crazy that its more than 8 bits...

I've attached a slightly simplified version of your script (it's what I used to dump).

Now, the mystery is, just how much entropy is it using? 9 bits? 16 bits?

Code:

handsToDump = 1000;
updateProgress = 100;
filename = "CardDump.txt"

function secondsToTime(seconds)
    local hours = math.floor(seconds / 3600);
    seconds = seconds - hours * 3600;
    local minutes = math.floor(seconds / 60);
    seconds = math.floor(seconds - minutes * 60 + 0.5);
    return string.format("%d:%02d:%02d", hours, minutes, seconds);
end

function outputProgress(startTime, done, total)
    local secondsElapsed = os.time() - startTime;
    if done ~= 0 and done ~= total then
        local remaining = secondsElapsed * total / done - secondsElapsed;
        print(string.format("%d / %d (%.2f%%) -- %s elapsed (ETA: %s)",
                            done, total, done / total * 100,
                            secondsToTime(secondsElapsed),
                            secondsToTime(remaining)));
    else
        print(string.format("%d / %d (%.2f%%) -- %s elapsed",
                            done, total, done / total * 100,
                            secondsToTime(secondsElapsed)));
    end
end

function dumpCards()
    local saveSlot = savestate.create();
    savestate.save(saveSlot);
    local outputFile = assert(io.open(filename, "w"));
    emu.speedmode("maximum");
    local startTime = os.time();
    for onHand = 0,handsToDump-1,1 do
        if onHand % updateProgress == 0 and onHand ~= handsToDump-1 then
            outputProgress(startTime, onHand, handsToDump);
        end
        savestate.load(saveSlot);
        emu.frameadvance();
        savestate.save(saveSlot);
        joypad.set(1, {["x"]=true});
        for i = 0,16,1 do
            emu.frameadvance();
        end
        outputFile:write(string.format("%d %d %d %d %d\n",
                                       memory.readbyte(0x001A2C48),
                                       memory.readbyte(0x001A2C49),
                                       memory.readbyte(0x001A2C4A),
                                       memory.readbyte(0x001A2C4B),
                                       memory.readbyte(0x001A2C4C)));
    end
    outputProgress(startTime, handsToDump, handsToDump);
    outputFile:close();
    emu.speedmode("normal");
end

dumpCards();

Edit: Now getting serious about dumping massive numbers of cards to try to find the cycle. The 1000 value is a placeholder. Think more like 131072 Wink

[quote="DarkKobold"] Poxnor: Did you get the script running?[/quote]
I can confirm that the card game uses more than eight bits of entropy.  I dumped 256 hands for Trepie 1; then, went back to a save state before engaging him, ran around a little bit (opened the menu, left the room, etc), came back, and dumped another 256 hands.  And I got a completely different set of hands dumped (not just a reordering of the hands, but truly different hands).  I'll try to see if I can determine how much entropy is actually used, but it's crazy that its more than 8 bits...

I've attached a slightly simplified version of your script (it's what I used to dump).

Now, the mystery is, just how much entropy is it using?  9 bits?  16 bits?

[code]
handsToDump = 1000;
updateProgress = 100;
filename = "CardDump.txt"

function secondsToTime(seconds)
    local hours = math.floor(seconds / 3600);
    seconds = seconds - hours * 3600;
    local minutes = math.floor(seconds / 60);
    seconds = math.floor(seconds - minutes * 60 + 0.5);
    return string.format("%d:%02d:%02d", hours, minutes, seconds);
end

function outputProgress(startTime, done, total)
    local secondsElapsed = os.time() - startTime;
    if done ~= 0 and done ~= total then
        local remaining = secondsElapsed * total / done - secondsElapsed;
        print(string.format("%d / %d (%.2f%%) -- %s elapsed (ETA: %s)",
                            done, total, done / total * 100,
                            secondsToTime(secondsElapsed),
                            secondsToTime(remaining)));
    else
        print(string.format("%d / %d (%.2f%%) -- %s elapsed",
                            done, total, done / total * 100,
                            secondsToTime(secondsElapsed)));
    end
end

function dumpCards()
    local saveSlot = savestate.create();
    savestate.save(saveSlot);
    local outputFile = assert(io.open(filename, "w"));
    emu.speedmode("maximum");
    local startTime = os.time();
    for onHand = 0,handsToDump-1,1 do
        if onHand % updateProgress == 0 and onHand ~= handsToDump-1 then
            outputProgress(startTime, onHand, handsToDump);
        end
        savestate.load(saveSlot);
        emu.frameadvance();
        savestate.save(saveSlot);
        joypad.set(1, {["x"]=true});
        for i = 0,16,1 do
            emu.frameadvance();
        end
        outputFile:write(string.format("%d %d %d %d %d\n",
                                       memory.readbyte(0x001A2C48),
                                       memory.readbyte(0x001A2C49),
                                       memory.readbyte(0x001A2C4A),
                                       memory.readbyte(0x001A2C4B),
                                       memory.readbyte(0x001A2C4C)));
    end
    outputProgress(startTime, handsToDump, handsToDump);
    outputFile:close();
    emu.speedmode("normal");
end

dumpCards();
[/code]
Edit: Now getting serious about dumping massive numbers of cards to try to find the cycle.  The 1000 value is a placeholder.  Think more like 131072 ;)

FF8 lover

2011-05-03 04:57:57 am

Quote from DarkKobold:

I'm more curious to see what would happen if you could get past the traffic jam in Dream Sequence 1, and go into Caraway's Mansion as Laguna. My guess is the game would crash, but a Timber/TVStation/DreamSequence2/GalbadianGarden skip would be freaking ridiculous.

That would pretty surely crash the game. Anyway I tried it since I have a save for almost every part of the game, but I haven't manage to pass through the blocks. I found anyway that the game let you go to the Gateway and let you take the door and the ladder who leads you to the underground of Deling City. Anyway you can't do anything there. You can neither activate the lever who close the Gateway and start the FMV, of course. Squaresoft has not been so stupid XD

Rakuen

2011-05-03 10:34:56 am

Weegee Time

Just a thought, but doesn't Dream Sequence 1 and the exit point of this skip occur on separate disks? Maybe you'd have to swap the disks at some point so the lever is actually usable?

ButtersBB

2011-05-03 10:38:10 am

Wow, seems that they put much more effort into the card game than I thought. Guess when it comes down to it, nothing really changes, still best to go with the Treppie in the cafeteria, and still need to get really lucky with Zell's Mom.

FF8 lover

2011-05-03 10:40:21 am

@Rakuen: The first dream and the Gateway event (before fighting Edea) are both on disc 1.

Poxnor

2011-05-03 11:06:50 am

Moo! Flap! Hug!

*sob* I just dumped 131072 hands from Trepie 1 (over 2 hours). There was no cycle in the dump. That's 17 bits of entropy and no cycle. How much entropy are they drawing on!?

Rakuen

Edit history:

Rakuen: 2011-05-03 11:45:16 am

Rakuen: 2011-05-03 11:44:17 am

2011-05-03 11:41:36 am

Weegee Time

Well, if it's 17 bits already then I'd imagine it's probably an int. It certainly allows for a great amount of randomness, and it's convenient. There's a small possibility it's a long, but that would be INSANE. I'd probably find the person who programmed it and punch him in the face at that point.

Quote:

@Rakuen: The first dream and the Gateway event (before fighting Edea) are both on disc 1.

Ah, okay. It's been about 10 years since I played this, so everything is foggy. At least it was a thought.

Poxnor

2011-05-03 11:48:22 am

Moo! Flap! Hug!

It just makes no sense, because every other random number in this game is 8 bits. I was hoping they used a 16-bit PRNG for the card game (i.e., a pair of 8-bit PRNGs) and I'd therefore see a cycle in the 17-bit output, but that is not the case. So yeah, it's probably either a 24-bit PRNG (I've seen 24-bit primitives on the SNES, but I don't know if they exist on the PSX) or a 32-bit PRNG. And there's no way that I can dump 32 bits of hands (it would take 8.5 years to run, unless someone can make that script much faster).

I suppose at least I could dump 17 or 18 bits for all the Trepies, and actually do some real statistical analysis of which one is best to play in an SS.

DarkKobold

2011-05-03 01:12:52 pm

RPG TASer

Quote from Poxnor:

*sob* I just dumped 131072 hands from Trepie 1 (over 2 hours). There was no cycle in the dump. That's 17 bits of entropy and no cycle. How much entropy are they drawing on!?

That should be enough to get pretty accurate statistics.

I wonder if there is some variable we aren't seeing. How can it use a 32 bit RNG, yet every other (more important) RNG is only 8 bit? This is confusing.

DarkKobold

2011-05-03 01:18:39 pm

RPG TASer

Quote from Rakuen:

Just a thought, but doesn't Dream Sequence 1 and the exit point of this skip occur on separate disks? Maybe you'd have to swap the disks at some point so the lever is actually usable?

The level occurs at the end of Disc 1, to drop the gate on Edea. The dream sequence occurs during the train ride to timber. Basically, all of Galbadia for the plot is taken care of in Disc 1, so no disc swap would be required.

Poxnor

2011-05-03 01:59:14 pm

Moo! Flap! Hug!

Quote from DarkKobold:

I wonder if there is some variable we aren't seeing. How can it use a 32 bit RNG, yet every other (more important) RNG is only 8 bit? This is confusing.

A completely off-the-cuff theory: could it be using the game timer as its entropy source?

Rakuen

Edit history:

Rakuen: 2011-05-03 02:02:29 pm

Rakuen: 2011-05-03 02:02:03 pm

2011-05-03 02:01:08 pm

Weegee Time

Quote from Poxnor:

It just makes no sense, because every other random number in this game is 8 bits. I was hoping they used a 16-bit PRNG for the card game (i.e., a pair of 8-bit PRNGs) and I'd therefore see a cycle in the 17-bit output, but that is not the case. So yeah, it's probably either a 24-bit PRNG (I've seen 24-bit primitives on the SNES, but I don't know if they exist on the PSX) or a 32-bit PRNG. And there's no way that I can dump 32 bits of hands (it would take 8.5 years to run, unless someone can make that script much faster).

I suppose at least I could dump 17 or 18 bits for all the Trepies, and actually do some real statistical analysis of which one is best to play in an SS.

I did a little digging, and it looks like the Playstation used 32-bit registers:
http://psx.rules.org/system.txt

So it's reasonable to assume the PSX had 24-bit and 32-bit primitive types. Considering that Trepie Fan #3 has 44 unique cards in that dumped list, it also seems reasonable to assume they would need a larger RNG for the card game than for anything else. I don't think 256 possible combinations would effectively represent 44 cards.

I've got a different angle to think from as well. What if the game generates a hand, then shuffles the cards in the hand? For example, take these two hands:

1 2 3 4 5
4 2 3 5 1

Both of these hands contain the same cards and would be generated by the same value from the RNG. However, the game places the cards into the array at random so they appear to be generated differently. If that were the case, there might be a cycle, but it's just not obvious because the game would be obfuscating it.

Just throwing ideas out there.

Quote from Poxnor:

Quote from DarkKobold:

I wonder if there is some variable we aren't seeing. How can it use a 32 bit RNG, yet every other (more important) RNG is only 8 bit? This is confusing.

A completely off-the-cuff theory: could it be using the game timer as its entropy source?

Use an emulator with frame advance to check?

[quote="Poxnor"]It just makes no sense, because every other random number in this game is 8 bits.  I was hoping they used a 16-bit PRNG for the card game (i.e., a pair of 8-bit PRNGs) and I'd therefore see a cycle in the 17-bit output, but that is not the case.  So yeah, it's probably either a 24-bit PRNG (I've seen 24-bit primitives on the SNES, but I don't know if they exist on the PSX) or a 32-bit PRNG.  And there's no way that I can dump 32 bits of hands (it would take 8.5 years to run, unless someone can make that script much faster).

I suppose at least I could dump 17 or 18 bits for all the Trepies, and actually do some real statistical analysis of which one is best to play in an SS.[/quote]
I did a little digging, and it looks like the Playstation used 32-bit registers:
http://psx.rules.org/system.txt

So it's reasonable to assume the PSX had 24-bit and 32-bit primitive types.  Considering that Trepie Fan #3 has 44 unique cards in that dumped list, it also seems reasonable to assume they would need a larger RNG for the card game than for anything else.  I don't think 256 possible combinations would effectively represent 44 cards.

I've got a different angle to think from as well.  What if the game generates a hand, then shuffles the cards in the hand?  For example, take these two hands:

1 2 3 4 5
4 2 3 5 1

Both of these hands contain the same cards and would be generated by the same value from the RNG.  However, the game places the cards into the array at random so they appear to be generated differently.  If that were the case, there might be a cycle, but it's just not obvious because the game would be obfuscating it.

Just throwing ideas out there.

[quote="Poxnor"][quote="DarkKobold"]I wonder if there is some variable we aren't seeing. How can it use a 32 bit RNG, yet every other (more important) RNG is only 8 bit? This is confusing. [/quote]
A completely off-the-cuff theory: could it be using the game timer as its entropy source?[/quote]
Use an emulator with frame advance to check?

Poxnor

Edit history:

Poxnor: 2011-05-03 03:50:06 pm

2011-05-03 03:10:53 pm

Moo! Flap! Hug!

Quote from Rakuen:

Use an emulator with frame advance to check?

Well, it's not the game timer; I was wrong.

Starting when the Trepie is asking "How 'bout a quick game of cards?", I ran the following:

Code:

function startGame(delayBeforeChallenge, delayBeforePlay)
    for i = 0,delayBeforeChallenge-1,1 do
        emu.frameadvance();
    end
    for i = 0,5,1 do
        joypad.set(1, {["x"]=true});
        emu.frameadvance();
    end
    for i = 0,delayBeforePlay-1,1 do
        emu.frameadvance();
    end
    joypad.set(1, {["x"]=true});
    for i = 0,16,1 do
        emu.frameadvance();
    end
    print(string.format("%d %d %d %d %d\n",
         		memory.readbyte(0x001A2C48),
                        memory.readbyte(0x001A2C49),
                        memory.readbyte(0x001A2C4A),
                        memory.readbyte(0x001A2C4B),
                        memory.readbyte(0x001A2C4C)));
end

function testTheory()
    local saveSlot = savestate.create();
    savestate.save(saveSlot);
    startGame(0, 600);
    savestate.load(saveSlot);
    startGame(50, 550);
    savestate.load(saveSlot);
    startGame(50, 600);
end

testTheory();

The first and the third outputs were the same, but the second output was different. So not the game timer.

Edit: Here's something interesting. At 0x001A2C6C, there's a dumb 32-bit counter of how many frames it has been since the start of the Triple Triad screen. However, that's not the entropy source used (or at least not the only one); otherwise, you'd be able to manipulate a given player to play the same cards twice in a row by making that counter the same both times.

[quote="Rakuen"]Use an emulator with frame advance to check?[/quote]
Well, it's not the game timer; I was wrong.

Starting when the Trepie is asking "How 'bout a quick game of cards?", I ran the following:
[code]
function startGame(delayBeforeChallenge, delayBeforePlay)
    for i = 0,delayBeforeChallenge-1,1 do
        emu.frameadvance();
    end
    for i = 0,5,1 do
        joypad.set(1, {["x"]=true});
        emu.frameadvance();
    end
    for i = 0,delayBeforePlay-1,1 do
        emu.frameadvance();
    end
    joypad.set(1, {["x"]=true});
    for i = 0,16,1 do
        emu.frameadvance();
    end
    print(string.format("%d %d %d %d %d\n",
         		memory.readbyte(0x001A2C48),
                        memory.readbyte(0x001A2C49),
                        memory.readbyte(0x001A2C4A),
                        memory.readbyte(0x001A2C4B),
                        memory.readbyte(0x001A2C4C)));
end

function testTheory()
    local saveSlot = savestate.create();
    savestate.save(saveSlot);
    startGame(0, 600);
    savestate.load(saveSlot);
    startGame(50, 550);
    savestate.load(saveSlot);
    startGame(50, 600);
end

testTheory();
[/code]
The first and the third outputs were the same, but the second output was different.  So not the game timer.

Edit: Here's something interesting.  At 0x001A2C6C, there's a dumb 32-bit counter of how many frames it has been since the start of the Triple Triad screen.  However, that's not the entropy source used (or at least not the only one); otherwise, you'd be able to manipulate a given player to play the same cards twice in a row by making that counter the same both times.

DarkKobold

2011-05-03 08:26:43 pm

RPG TASer

Quote from Poxnor:

The first and the third outputs were the same, but the second output was different. So not the game timer.

This is sort of weird - just so you know, the RNG in normal circumstances only advances once every other frame. For example, when I am manipulating starting ATB/HP values, my script skips every other frame, otherwise I get a list of identical pairs. I believe it is because the GPU runs at 30Hz during the standard gameplay, and 60Hz in menus/card games. (This would also explain why the timer runs twice as fast in these areas, in certain versions).

gyth

2011-05-03 09:44:21 pm

Quote from Poxnor:

The first and the third outputs were the same, but the second output was different. So not the game timer.

Try waiting longer, when angelo searching the system eats an rng every 13.33 seconds, maybe something like that is coming into play.

Poxnor

2011-05-03 10:14:30 pm

Moo! Flap! Hug!

Quote from gyth:

Try waiting longer, when angelo searching the system eats an rng every 13.33 seconds, maybe something like that is coming into play.

Nah, that's not it. I was thinking that the entropy source may have been the game timer, because the cards that an opponent will play change every frame between when the TT background appears and when you choose "Play." However, the experiment I did was:

(a) From a saved state, immediately start a TT game, and wait 600 frames before choosing "Play";
(b) From the same saved state, wait 50 frames before starting a TT game, then wait 550 frames before choosing "Play"; and,
(c) From the same saved state, wait 50 frames before starting a TT game, then wait 600 frames before choosing "Play."

Because (a) and (c) produced the same cards, but (b) was different, we can decisively conclude that the game timer is not the entropy source.

Rakuen

Edit history:

Rakuen: 2011-05-03 10:20:46 pm

2011-05-03 10:18:03 pm

Weegee Time

But since A and C produced the same cards, and you waited 600 frames before choosing Play on both of them, isn't it possible that the entropy source would be a timer that isn't initialized until you start a TT game? Seems like you'd need a fourth data point (immediate start, 550 frames before Play).

Poxnor

2011-05-03 10:31:39 pm

Moo! Flap! Hug!

Quote from Rakuen:

But since A and C produced the same cards, and you waited 600 frames before choosing Play on both of them, isn't it possible that the entropy source would be a timer that isn't initialized until you start a TT game?

That's certainly part of the entropy source, but it's not the only input to the algorithm that determines which cards are played. If it were the only input to that algorithm, then I would be able to play two consecutive card games against the same opponent, wait the same number of frames after the TT game starts before selecting "Play," and expect the opponent to play the same hand both times. However, if I do so, the opponent will play two different hands.

One interesting test would be, from a New Game, if you go to the same opponent and wait the same number of frames after starting TT but before selecting Play, will they always play the same cards (regardless of what you do before in-game before that first TT game)? Is it possible that the frame counter is the only entropy source, but there's some sort of table in memory that changes deterministically after each game?

Quote from Rakuen:

Seems like you'd need a fourth data point (immediate start, 550 frames before Play).

That would produce the same set of cards as (b).

[quote="Rakuen"]But since A and C produced the same cards, and you waited 600 frames before choosing Play on both of them, isn't it possible that the entropy source would be a timer that isn't initialized until you start a TT game?[/quote]
That's certainly part of the entropy source, but it's not the only input to the algorithm that determines which cards are played.  If it were the only input to that algorithm, then I would be able to play two consecutive card games against the same opponent, wait the same number of frames after the TT game starts before selecting "Play," and expect the opponent to play the same hand both times.  However, if I do so, the opponent will play two different hands.

One interesting test would be, from a New Game, if you go to the same opponent and wait the same number of frames after starting TT but before selecting Play, will they always play the same cards (regardless of what you do before in-game before that first TT game)?  Is it possible that the frame counter is the only entropy source, but there's some sort of table in memory that changes deterministically after each game?

[quote="Rakuen"]Seems like you'd need a fourth data point (immediate start, 550 frames before Play).[/quote]
That would produce the same set of cards as (b).

Poxnor

2011-05-03 10:48:29 pm

Moo! Flap! Hug!

Quote from Rakuen:

I've got a different angle to think from as well. What if the game generates a hand, then shuffles the cards in the hand? [...] Both of these hands contain the same cards and would be generated by the same value from the RNG. However, the game places the cards into the array at random so they appear to be generated differently. If that were the case, there might be a cycle, but it's just not obvious because the game would be obfuscating it.

Good thinking. Here's some post-processing results on the Trepie #1 dump:

Code:

Total hands processed: 131072
Unique ordered hands processed: 124853
Unique unordered hands processed: 26100
Hands with level ten card: 39339 (30.01%)
Average card strength: 4.48
Average card strength when level ten played: 4.81
Average card strength when level ten not played: 4.33

So, when the order of the cards doesn't matter, there were only 26100 unique hands played.

Rakuen

2011-05-03 10:53:22 pm

Weegee Time

Quote from Poxnor:

One interesting test would be, from a New Game, if you go to the same opponent and wait the same number of frames after starting TT but before selecting Play, will they always play the same cards (regardless of what you do before in-game before that first TT game)? Is it possible that the frame counter is the only entropy source, but there's some sort of table in memory that changes deterministically after each game?

Posit the game starts with some default value in a variable X. X is combined with the frame where you press Play and the result is stored back in X. This combination occurs every time you press Play. That would make every hand a function of all previous hands. It would actually be a fairly easy way to randomize, if it were indeed the case. It would also be difficult to prove though, because the initial value could be randomized at the game's start...