Unfinished New Game +
-
- Posts: 26
- Joined: Wed Dec 07, 2016 8:47 am
Re: Trial Road
I'm not quite sure myself. I am not very programming-oriented, so I have to go through trial&error. To start easy, I chose to first check the portraits, and the save state gives the right picture while the decompressed binary gives the left. Hm, I guess I'll simply have to spend some more time and really understand this.
You do not have the required permissions to view the files attached to this post.
- Pyriel
- Webmaster
- Posts: 1232
- Joined: Wed Aug 18, 2004 1:20 pm
Re: Trial Road
What color table did you use for the decompressed one? I have a bunch of stuff like this that I extracted directly from the game, and it came out fine once I found the right CLUT. Another possibility is that you didn't feed it the right array of compressed data. Like maybe you passed in a buffer that still had the compressed size in it? Something like that could cause some compressed block to be recognized properly, while others just come out a mess.
You do not have the required permissions to view the files attached to this post.
-
- Posts: 26
- Joined: Wed Dec 07, 2016 8:47 am
Re: Trial Road
I went back to RHDN's discussion and finally understand what's up with those "frames"! The decompressor was never meant to be applied to portraits!! DUH! No wonder it comes out all strange. I think I've got it as far as sprites are concerned. Oh beauty!
It would be interesting to adjust the routine for portraits, though. In fact, this will be necessary if the Rune has a face. It shouldn't be too hard seeing how the sprites-routine has already done a pretty good job of it.
Anyway, I'll come back when I have dug out some stuff to show
It would be interesting to adjust the routine for portraits, though. In fact, this will be necessary if the Rune has a face. It shouldn't be too hard seeing how the sprites-routine has already done a pretty good job of it.
Anyway, I'll come back when I have dug out some stuff to show
You do not have the required permissions to view the files attached to this post.
-
- Posts: 26
- Joined: Wed Dec 07, 2016 8:47 am
Re: Trial Road
I am checking through file VJ24 from bottom up, and two sprite sheets looked new and interesting. At least, they show sprites that are not seen in the epilogue dungeon where you can walk around without crashing.
The turtle-like design with eight orbs most certainly is a door to the Rune, and each or each pair would probably correspond to the orb-stand that is situated throughout the dungeon.
EDIT: "turtle-like" is just my impression; they are in fact eight snake-heads, each with an orb in the mouth.
I could find only three up to now (marked with a red circle), and I know that two of them were in 09-11 while I found another one when I chose 09-13 as destination (if I remember correctly). Going through 09-14 to 09-17 may lead to more of them (Floors F4 and F5 look suspicious!).
If the palette is correct, there is also a save sphere that is a different color from the usual save spots.
This kind of reminded me of the game "Xenogears", where save spots actually turned out to have a meaning. Maybe in Suikoden also, the save spots' identity might have been low-rank runes of this Rune of Circulating Path (or whatever the name).
Anyway, there were some clouds in addition to all that, so the final location might have been the very top of a tower.
The turtle-like design with eight orbs most certainly is a door to the Rune, and each or each pair would probably correspond to the orb-stand that is situated throughout the dungeon.
EDIT: "turtle-like" is just my impression; they are in fact eight snake-heads, each with an orb in the mouth.
I could find only three up to now (marked with a red circle), and I know that two of them were in 09-11 while I found another one when I chose 09-13 as destination (if I remember correctly). Going through 09-14 to 09-17 may lead to more of them (Floors F4 and F5 look suspicious!).
If the palette is correct, there is also a save sphere that is a different color from the usual save spots.
This kind of reminded me of the game "Xenogears", where save spots actually turned out to have a meaning. Maybe in Suikoden also, the save spots' identity might have been low-rank runes of this Rune of Circulating Path (or whatever the name).
Anyway, there were some clouds in addition to all that, so the final location might have been the very top of a tower.
You do not have the required permissions to view the files attached to this post.
- Raww Le Klueze
- Global Admin
- Posts: 1922
- Joined: Sat Jun 26, 2004 1:38 am
Re: Trial Road
The purple Journeyman Crystal could be the sprite representation of this "rune", but I wouldn't draw any conclusions about it's relationship with the blue ones from that as palette swaps are mostly a time saving thing.
Doctorum Non Urina Singulus.
-
- Posts: 26
- Joined: Wed Dec 07, 2016 8:47 am
Re: Trial Road
You are right about that.
It would be neat, though, since the ordinary "Journeyman Crystal" are also a point where the player changes the future of the game play, which kind of links to the nature of the Rune.
Just an addition about the decompressor: it works on portraits!
Having gone through the routine, one by one (such a cool mechanism, too, it's the first time I've taken a close look at something like this) I realized that the frame size shouldn't matter. It was probably a convenient size to use for character sprite animations, but portraits don't move and so there is really no reason to use a larger frame. So I re-ran the decompressor on the portrait, and the output came out perfect. Puzzled, I went back to the old copy of the project (I had made a new one to work on sprites), and realized that the old project *wasn't producing any output*. Meaning, I was looking at the initial mistake (as Pyriel pointed out, it could be reproduced with the compressed size included) over and over wondering why the routine fails on portrais. DU-UH-UH!!!
I still have no idea why the old project doesn't work, but I must have messed up the environment somehow. Creating too many "test" projects and a sleepy head does that, I guess...
Well, that cleared, I can go hunt for the Rune's face
It would be neat, though, since the ordinary "Journeyman Crystal" are also a point where the player changes the future of the game play, which kind of links to the nature of the Rune.
Just an addition about the decompressor: it works on portraits!
Having gone through the routine, one by one (such a cool mechanism, too, it's the first time I've taken a close look at something like this) I realized that the frame size shouldn't matter. It was probably a convenient size to use for character sprite animations, but portraits don't move and so there is really no reason to use a larger frame. So I re-ran the decompressor on the portrait, and the output came out perfect. Puzzled, I went back to the old copy of the project (I had made a new one to work on sprites), and realized that the old project *wasn't producing any output*. Meaning, I was looking at the initial mistake (as Pyriel pointed out, it could be reproduced with the compressed size included) over and over wondering why the routine fails on portrais. DU-UH-UH!!!
I still have no idea why the old project doesn't work, but I must have messed up the environment somehow. Creating too many "test" projects and a sleepy head does that, I guess...
Well, that cleared, I can go hunt for the Rune's face
-
- Posts: 26
- Joined: Wed Dec 07, 2016 8:47 am
Re: Trial Road
Hm, I went around looking for stuff, and I'm afraid this might be pretty much it.
I checked the SDD and VAB files, consulted the internet (seems like I see your name everywhere, Pyriel!), and found out they are sound files. Why they'd include a 102MB XA file in addition to the sequences, is beyond me. All the compression and decompression - just to make room for Annallee's band, possibly? Well, they must have had their reason.
Anyway, with SDD and VAB files out of the way, there were only BIN files left to look into. I decided to only rip 8bpp sprites, which seemed like a safe route to take, compared binaries, ripped through VJ17 (Sajah), VJ19 (L'Renouille castle outside), VC12 (Sindar ruins) and VC14 (Sindar ruins), but to no avail. 8bpp sprite sheets of VJ18,20-23 looked identical to those included in VJ24 (made visual comparison of bit images), so I didn't bother go through them.
I saw Elza's portrait at the end of VJ17, so if the Rune had potrait data, it should have been in VJ24. Unfortunately, it's not. Another disappointing find is that VJ17 didn't reveal what's inside that hidden cave. If they left a whole dungeon in the game, you'd think they wouldn't care if some additional sprites remained, but no. Of course, it's always possible that they were never made.
Since I don't quite feel like hunting the 210_BOSS folder for a possibly unknown boss (unlikely), I am at a loss for what else could be done
I'm glad I could share some finds, though. Two weeks ago, I would never have thought I'd actually be ripping sprites myself, but it was lots of fun learning this stuff despite the tedious work involved
I checked the SDD and VAB files, consulted the internet (seems like I see your name everywhere, Pyriel!), and found out they are sound files. Why they'd include a 102MB XA file in addition to the sequences, is beyond me. All the compression and decompression - just to make room for Annallee's band, possibly? Well, they must have had their reason.
Anyway, with SDD and VAB files out of the way, there were only BIN files left to look into. I decided to only rip 8bpp sprites, which seemed like a safe route to take, compared binaries, ripped through VJ17 (Sajah), VJ19 (L'Renouille castle outside), VC12 (Sindar ruins) and VC14 (Sindar ruins), but to no avail. 8bpp sprite sheets of VJ18,20-23 looked identical to those included in VJ24 (made visual comparison of bit images), so I didn't bother go through them.
I saw Elza's portrait at the end of VJ17, so if the Rune had potrait data, it should have been in VJ24. Unfortunately, it's not. Another disappointing find is that VJ17 didn't reveal what's inside that hidden cave. If they left a whole dungeon in the game, you'd think they wouldn't care if some additional sprites remained, but no. Of course, it's always possible that they were never made.
Since I don't quite feel like hunting the 210_BOSS folder for a possibly unknown boss (unlikely), I am at a loss for what else could be done
I'm glad I could share some finds, though. Two weeks ago, I would never have thought I'd actually be ripping sprites myself, but it was lots of fun learning this stuff despite the tedious work involved
- Pyriel
- Webmaster
- Posts: 1232
- Joined: Wed Aug 18, 2004 1:20 pm
Re: Trial Road
When I ripped the data for the Bestiary years ago, those files were parsed too. At the time, I wasn't terribly familiar with the game, but nobody ever indicated that we'd dug up an unknown boss. We found the Chimaera in Tenzen, and a couple of other oddities, along with dozens of different Highlands Soldiers, but not much else.
I honestly had a feeling the data was gone, never created, and/or full of placeholders. Given what we know now, it seems odd that any part of the dungeon would be populated with CutRabbits and FurFurs that haven't had their stats bumped much, if at all. So the whole thing was probably scrapped at the point of actually implementing its scenario and integrating the events with the rest of the game. Probably a few people assembled the level, and filled it with placeholder enemies. Then before more appropriate assets could be completed, the place was scrapped for time or because it was too complicated. Given the limitations of the PSX, they might have even scrapped it if what they were planning meant forcing the save to take up another block.
I honestly had a feeling the data was gone, never created, and/or full of placeholders. Given what we know now, it seems odd that any part of the dungeon would be populated with CutRabbits and FurFurs that haven't had their stats bumped much, if at all. So the whole thing was probably scrapped at the point of actually implementing its scenario and integrating the events with the rest of the game. Probably a few people assembled the level, and filled it with placeholder enemies. Then before more appropriate assets could be completed, the place was scrapped for time or because it was too complicated. Given the limitations of the PSX, they might have even scrapped it if what they were planning meant forcing the save to take up another block.
- Celes
- Global Admin
- Posts: 1422
- Joined: Sun Nov 12, 2006 6:25 pm
Re: Trial Road
Did you find any fragments of the actual algorithms which grants the reboot while keeping you stuff?
-
- Posts: 26
- Joined: Wed Dec 07, 2016 8:47 am
Re: Trial Road
Oh, then I'm glad I didn't go into the BOSS folder! lol
Going into the booting algorithm is way too difficult for me, but your suggestion did get me to some further finds:
I see G1LOAD.BIN which obviously loads the S1 data, and BLOAD.BIN which seems to stand for BOOTLOAD, and my first guess would be to load the usual save data. However though, it is intriguing that I see bunch of "clear_event"s in the beginning of the BLOAD. That's something you'd expect for a newgame+.
Also, I notice that the region $23F2C-$30E3F in VJ24 look like copies of $250FC-$3230F in BOOT.BIN.
G1LOAD also shares some part of this: $1B3F4-$260FF in G1LOAD look like $26134-$30E3F in VJ24.
If I had to hazard a guess, I'd say these are all the flags of this game.
The other event BINs from VA-VK don't seem to share this part (I checked VJ17, 18, 20-23 in particular; other than that, I only picked out random files)
What's further intriguing: BLOAD *does not* share this data, either.
So there is definitely something special and bootable about VJ24! - And maybe, just maybe, BLOAD goes with it.
But these are just observations I make by looking at the bit images of these files, and I simply have no idea how to proceed from there. I'd have to start with Assembly Language 101.
Apart from reading Assembly, things that might still be possible are:
plan A) Disable the event at the top level of the dungeon so it doesn't crash, and see everything in action (hopefully)
plan B) Manually recreate the map after the above-mentioned crash-point, just to get the visuals.
I'd have to find out how a map is laid out in the game, though!
EDIT: I made a quick check of the shared regions of VJ24 and BOOT, and although the structure itself is the identical, contents are different. So these might indeed be flags. Analysing the flags of VJ24 (and maybe comparing it to a save file?) might reveal where the newgame+ starts. My first place to check would be the Sindar Ruins
EDIT: One more thing, the region shared by all three of VJ24 and BOOT and G1LOAD are identical, so only $23F2C-$26133 in VJ24 matter.
EDIT: corrected to show address in EN version.
Going into the booting algorithm is way too difficult for me, but your suggestion did get me to some further finds:
I see G1LOAD.BIN which obviously loads the S1 data, and BLOAD.BIN which seems to stand for BOOTLOAD, and my first guess would be to load the usual save data. However though, it is intriguing that I see bunch of "clear_event"s in the beginning of the BLOAD. That's something you'd expect for a newgame+.
Also, I notice that the region $23F2C-$30E3F in VJ24 look like copies of $250FC-$3230F in BOOT.BIN.
G1LOAD also shares some part of this: $1B3F4-$260FF in G1LOAD look like $26134-$30E3F in VJ24.
If I had to hazard a guess, I'd say these are all the flags of this game.
The other event BINs from VA-VK don't seem to share this part (I checked VJ17, 18, 20-23 in particular; other than that, I only picked out random files)
What's further intriguing: BLOAD *does not* share this data, either.
So there is definitely something special and bootable about VJ24! - And maybe, just maybe, BLOAD goes with it.
But these are just observations I make by looking at the bit images of these files, and I simply have no idea how to proceed from there. I'd have to start with Assembly Language 101.
Apart from reading Assembly, things that might still be possible are:
plan A) Disable the event at the top level of the dungeon so it doesn't crash, and see everything in action (hopefully)
plan B) Manually recreate the map after the above-mentioned crash-point, just to get the visuals.
I'd have to find out how a map is laid out in the game, though!
EDIT: I made a quick check of the shared regions of VJ24 and BOOT, and although the structure itself is the identical, contents are different. So these might indeed be flags. Analysing the flags of VJ24 (and maybe comparing it to a save file?) might reveal where the newgame+ starts. My first place to check would be the Sindar Ruins
EDIT: One more thing, the region shared by all three of VJ24 and BOOT and G1LOAD are identical, so only $23F2C-$26133 in VJ24 matter.
EDIT: corrected to show address in EN version.
Last edited by ne__ya on Tue Dec 20, 2016 9:56 am, edited 1 time in total.
-
- Posts: 26
- Joined: Wed Dec 07, 2016 8:47 am
Re: Trial Road
OK, I couldn't drop this stuff so went on investigating.
The comparison of similar regions are summed up below (I hope the table comes out readable):
EDIT: corrected to show address in EN verion
Region A: not a flag region. VJ24 and BOOT have differences, but "A" taken from a mid-game save state had no difference to BOOT.
Region B: All three are identical.
Region C: G1LOAD and BLOAD are almost identical, save for 6 pointers and 2 other places in the binary.
I took a look at memory card data, but the stuff in there didn't seem similar to any of these. I wonder if they are compressed, too? They are such tiny data.
I should have learned by now that things aren't that easy to find!
The comparison of similar regions are summed up below (I hope the table comes out readable):
Code: Select all
VJ24 BOOT G1LOAD BLOAD
--------------------------------------------------------------------------------
Region A $23F2C-$26133 $250FC-$27303 NA NA
Pointers NA $27304-$27603 NA NA
Region B $26134-$30E3F $27604-$3230F $1B3F4-$260FF NA
Region C NA NA $8A9C-$1B3F3 $98E8-$1C23F
Region A: not a flag region. VJ24 and BOOT have differences, but "A" taken from a mid-game save state had no difference to BOOT.
Region B: All three are identical.
Region C: G1LOAD and BLOAD are almost identical, save for 6 pointers and 2 other places in the binary.
I took a look at memory card data, but the stuff in there didn't seem similar to any of these. I wonder if they are compressed, too? They are such tiny data.
I should have learned by now that things aren't that easy to find!
-
- Posts: 2805
- Joined: Sat Apr 19, 2008 9:48 am
- Location: Germany, yeah baby
- Contact:
Re: Trial Road
fyi, you guys are now famous, Pyriel and ne__ya http://kotaku.com/after-18-years-fans-f ... 1790331169
- Nikisaur
- Posts: 462
- Joined: Fri Apr 16, 2010 5:26 am
- Location: New Zealand
Re: Trial Road
Awesome work guys! This is actually so interesting.
I don't know much about code stuff, but from story/world perspective I'm looking at the "Rune of Circulating Paths". Is anyone able to confirm if it's the same as Hikusaak's Circle Rune? My brain is swelling with theories of multiverse/Hikusaak clones and connection to the Sindar Ruins. I also really like the idea of Journeyman Crystals being connected to the Rune of Circulating Paths (canonical saving and NG+?whaaaaat)
Anyway, good job team, I'm sad this didn't actually exist in the final game though
I don't know much about code stuff, but from story/world perspective I'm looking at the "Rune of Circulating Paths". Is anyone able to confirm if it's the same as Hikusaak's Circle Rune? My brain is swelling with theories of multiverse/Hikusaak clones and connection to the Sindar Ruins. I also really like the idea of Journeyman Crystals being connected to the Rune of Circulating Paths (canonical saving and NG+?whaaaaat)
Anyway, good job team, I'm sad this didn't actually exist in the final game though
The only thing Suikoden lacks...is dinosaurs.
- Pyriel
- Webmaster
- Posts: 1232
- Joined: Wed Aug 18, 2004 1:20 pm
Re: Trial Road
What you've found is mostly the LBA listing, which is stuffed into several files on the disc.ne__ya wrote:OK, I couldn't drop this stuff so went on investigating.
The comparison of similar regions are summed up below (I hope the table comes out readable):
EDIT: corrected to show address in EN verionCode: Select all
VJ24 BOOT G1LOAD BLOAD -------------------------------------------------------------------------------- Region A $23F2C-$26133 $250FC-$27303 NA NA Pointers NA $27304-$27603 NA NA Region B $26134-$30E3F $27604-$3230F $1B3F4-$260FF NA Region C NA NA $8A9C-$1B3F3 $98E8-$1C23F
Region A: not a flag region. VJ24 and BOOT have differences, but "A" taken from a mid-game save state had no difference to BOOT.
Region B: All three are identical.
Region C: G1LOAD and BLOAD are almost identical, save for 6 pointers and 2 other places in the binary.
I took a look at memory card data, but the stuff in there didn't seem similar to any of these. I wonder if they are compressed, too? They are such tiny data.
I should have learned by now that things aren't that easy to find!
The PSX stunk at seeking by filename, so games typically built a list of Logical Block Addresses and sizes for files, and wrote it somewhere, so they could seek more directly. In this case, Konami chose to write the list to several somewheres, including the executable (SLUS*, SLES*, SLPM*, whatever), BOOT.BIN, VJ24.BIN, etc., etc. I think it was written to about 20 files in all. The NA patch has a list of them, since resizing the UWASA files requires correcting the listing.
The other data in BLOAD and GLOAD doesn't appear to be compressed. And in a disassembly, the references to the area are pointers to blocks exactly 512 bytes in size, which could be bitmaps 32x32@4BPP. No idea what the color information would be. That's just a guess.
Edit:
Here's where that block of stuff is referenced.
Code: Select all
RAM:80115588 addiu $sp, -0x28
RAM:8011558C li $v0, 0x8007549C
RAM:80115594 move $a0, $0
RAM:80115598 li $a1, 0x6AC
RAM:8011559C sw $s0, 0x28+var_10($sp)
RAM:801155A0 lui $s0, 0x8013
RAM:801155A4 sw $ra, 0x28+var_4($sp)
RAM:801155A8 sw $s2, 0x28+var_8($sp)
RAM:801155AC sw $s1, 0x28+var_C($sp)
RAM:801155B0 jalr $v0
RAM:801155B4 sw $v0, dword_80129F18
RAM:801155B8 move $s2, $v0
RAM:801155BC li $v1, 1
RAM:801155C0 li $v0, 2
RAM:801155C4 sb $v0, 1($s2)
RAM:801155C8 li $v0, 5
RAM:801155CC sb $v0, 0x17($s2)
RAM:801155D0 li $v0, 0x21D0
RAM:801155D4 sw $v0, 0x20($s2)
RAM:801155D8 lui $v0, 0x8011
RAM:801155DC sb $v1, 3($s2)
RAM:801155E0 sb $v1, 0x18($s2)
RAM:801155E4 lw $v1, 0x20($s2)
RAM:801155E8 la $v0, off_80117508
RAM:801155EC sb $0, 4($s2)
RAM:801155F0 sb $0, 5($s2)
RAM:801155F4 sb $0, 6($s2)
RAM:801155F8 sb $0, 0($s2)
RAM:801155FC sb $0, 0xE($s2)
RAM:80115600 sb $0, 8($s2)
RAM:80115604 sb $0, 9($s2)
RAM:80115608 sb $0, 0xA($s2)
RAM:8011560C sb $0, 0xB($s2)
RAM:80115610 sb $0, 0x10($s2)
RAM:80115614 sb $0, 0x29($s2)
RAM:80115618 sb $0, 0x11($s2)
RAM:8011561C sb $0, 0x12($s2)
RAM:80115620 sb $0, 0xC($s2)
RAM:80115624 sb $0, 0x15($s2)
RAM:80115628 sb $0, 0x16($s2)
RAM:8011562C sw $v0, 0x66C($s2)
RAM:80115630 andi $v0, $v1, 0x7F
RAM:80115634 beqz $v0, loc_80115644
RAM:80115638 subu $v0, $v1, $v0
RAM:8011563C addiu $v0, 0x80
RAM:80115640 sw $v0, 0x20($s2)
RAM:80115644
RAM:80115644 loc_80115644: # CODE XREF: sub_80115588+ACj
RAM:80115644 li $v0, 0x800D4CBC
RAM:8011564C lui $a0, 0x8011
RAM:80115650 lw $a1, 0x20($s2)
RAM:80115654 la $a0, aSaveDataSizeD # "save data size %d\n"
RAM:80115658 jalr $v0
RAM:8011565C sw $v0, -0x60E8($s0)
RAM:80115660 move $a0, $0
RAM:80115664 move $v1, $s2
RAM:80115668 li $v0, 0x280
RAM:8011566C sw $v0, 0x1C($s2)
RAM:80115670 sw $0, 0x614($s2)
RAM:80115674 sb $0, 0x628($s2)
RAM:80115678 sw $0, 0x62C($s2)
Files with an LBA listing below. (The startsector property is something the patch process uses later, so it can do raw writes into files that have already been written to the patched image. The fact that it's zero here doesn't mean anything.)
Code: Select all
LBAPatchList= {
{ name="SLUS_009.58", path="/", startsector=0, seekpos=0x7dbbc },
{ name="VJ24.BIN", path="/CDROM/100_ARJ/", startsector=0, seekpos=0x23f24 },
{ name="FURO.BIN", path="/CDROM/140_HONP/", startsector=0, seekpos=0x16de0 },
{ name="HSOUND.BIN", path="/CDROM/140_HONP/", startsector=0, seekpos=0x3cd8 },
{ name="RBATTLE.BIN", path="/CDROM/140_HONP/", startsector=0, seekpos=0x430a4 },
{ name="SNDTEST.BIN", path="/CDROM/140_HONP/", startsector=0, seekpos=0x280a4 },
{ name="IPRG_A3.BIN", path="/CDROM/260_IKKI/", startsector=0, seekpos=0x11504 },
{ name="IPRG_A4.BIN", path="/CDROM/260_IKKI/", startsector=0, seekpos=0x11f54 },
{ name="IPRG_B2.BIN", path="/CDROM/260_IKKI/", startsector=0, seekpos=0x1088c },
{ name="IPRG_D.BIN", path="/CDROM/260_IKKI/", startsector=0, seekpos=0x10e20 },
{ name="IPRG_D2.BIN", path="/CDROM/260_IKKI/", startsector=0, seekpos=0x10e44 },
{ name="IPRG_D3.BIN", path="/CDROM/260_IKKI/", startsector=0, seekpos=0x11364 },
{ name="IPRG_J.BIN", path="/CDROM/260_IKKI/", startsector=0, seekpos=0x10ce4 },
{ name="BOOT.BIN", path="/CDROM/270_BOOT/", startsector=0, seekpos=0x250f4 },
{ name="ENDING.BIN", path="/CDROM/270_BOOT/", startsector=0, seekpos=0x3c40 },
{ name="OVER.BIN", path="/CDROM/270_BOOT/", startsector=0, seekpos=0xbb2c },
{ name="STAFF.BIN", path="/CDROM/270_BOOT/", startsector=0, seekpos=0x3058 }
}, -- end LBAPatchList
And all that stuff about "events" in BLOAD is almost certainly referring to BIOS events.
Edit 3: Yup. Every reference to those strings immediately precedes a call to printf, and immediately follows a call to the BIOS TestEvent() function. They're just debug messages tracking the system's progress and polling for whether or not an error has occurred.
-
- Posts: 26
- Joined: Wed Dec 07, 2016 8:47 am
Re: Trial Road
Oh. That kind of clears it up, then! I'll add that scrolling further down on G1LOAD also showed the "clear_event" stuff, so as you point out, these are not referring to any game events. Them being BIOS events makes a lot of sense. Thank you always for sharing your insights so generously, Pyriel
BTW, do you have any idea what's in the "B" region? This strange structure is very puzzling.
Anyway, looks like it will require digging into the executables and such to find anything meaningful.
(Knowing now that memory card saves only take up $2200 of space, I see how hazardous my guess was. lol)
Contemplating flags raised some additional points:
1) If the newgame+ really starts at White Deer Inn, I wonder if all the prior recruits will be lost, too. Like, the ones you took to the Sindar Ruins? Not that it would matter greatly; you'd go to Muse, then to Coronet and meet Eilie, Rina, and Bolgan. It might come across a bit weird, though.
2) On the other hand, since you'd have the Shield Rune already, there is no need to worry about earlier flags that kept a record of what dialogue you chose in certain places (like when you mark the rock in the very beginning; it replays in Toto when you get the Shield Rune). So you could overwrite all flags without heed. I don't know if that is advantageous at all, but just an observation.
Since it looks like this thread is getting attention, hopefully someone will turn up to help out with the more deep stuff.
>Nikisaur
The "Rune of Circulating Paths" is completely different from Hikusaak's Rune. It's called "めぐる道の紋章" (Meguru Michi no Monshou) in Japanese. Michi is anything like road, way, path. Meguru is a bit more difficult, but means something like going around with circularity and repetitiveness implied. It can be used with things like the four seasons that come and go, your own thoughts that wander around, or even sightseeing going from one place to the next. Monshou is just Rune, "no" means "of".
BTW, do you have any idea what's in the "B" region? This strange structure is very puzzling.
Anyway, looks like it will require digging into the executables and such to find anything meaningful.
(Knowing now that memory card saves only take up $2200 of space, I see how hazardous my guess was. lol)
Contemplating flags raised some additional points:
1) If the newgame+ really starts at White Deer Inn, I wonder if all the prior recruits will be lost, too. Like, the ones you took to the Sindar Ruins? Not that it would matter greatly; you'd go to Muse, then to Coronet and meet Eilie, Rina, and Bolgan. It might come across a bit weird, though.
2) On the other hand, since you'd have the Shield Rune already, there is no need to worry about earlier flags that kept a record of what dialogue you chose in certain places (like when you mark the rock in the very beginning; it replays in Toto when you get the Shield Rune). So you could overwrite all flags without heed. I don't know if that is advantageous at all, but just an observation.
Since it looks like this thread is getting attention, hopefully someone will turn up to help out with the more deep stuff.
>Nikisaur
The "Rune of Circulating Paths" is completely different from Hikusaak's Rune. It's called "めぐる道の紋章" (Meguru Michi no Monshou) in Japanese. Michi is anything like road, way, path. Meguru is a bit more difficult, but means something like going around with circularity and repetitiveness implied. It can be used with things like the four seasons that come and go, your own thoughts that wander around, or even sightseeing going from one place to the next. Monshou is just Rune, "no" means "of".