Bug Fixes

If you are stuck in the Dunan Unification Wars; or wish for more details on the gameplay systems, this is the place.
Omnigamer
Posts: 282
Joined: Wed Feb 13, 2013 11:48 am

Re: Bug Fixes

Postby Omnigamer » Mon May 02, 2016 7:04 pm

I've come across a crash on the PSN versions of the game in Greenhill. It may be a bug with the emulator (likely) or an error that's innocuous on original PS1 hardware (possible), but I figured it's at least worth reporting. You can find a video of it here: https://www.twitch.tv/omnigamer/v/64213530

I did a small bit of testing to reproduce it, and it comes up 100% of the time that I accidentally select Option 2 when Nanami is asking you to save Teresa. I don't think I've encountered this bug otherwise. Pay no heed to the literal BSOD, I'm running an injected version of the game that expands the base psp emulator features and debug reporting a bit.

borjitasstoi
Posts: 48
Joined: Wed Mar 23, 2016 6:11 pm
Contact:

Re: Bug Fixes

Postby borjitasstoi » Wed Jul 13, 2016 5:16 pm

only in scrolls shop? in my file crashes in lebrante s shop

User avatar
Pyriel
Webmaster
Posts: 922
Joined: Wed Aug 18, 2004 1:20 pm

Re: Bug Fixes

Postby Pyriel » Fri Jul 15, 2016 12:30 am

Care to elaborate?

Edit: OK, I worked up the initiative to play through Greenhill again, and I get the same thing. It actually happens sooner for me the more times I respond "But..." When I do it once, it crashes the emulator between the first and second battle, but if I do it half-a-dozen or so times, it crashes before the first battle. I'm guessing the script either calls a custom routine, or is somehow broken as it tries to set a flag for use in later dialogue. That's just a guess, though. It's throwing an illegal op code at 0x10DCAC, which is part of a debug string, and would indeed be an invalid (for PSX) Double-word Add operation if it was executed as code.

There's a function in here that seems to be geared toward sorting out who the women in the party are, and probably picking one to respond and throw out a line. If you take dudes, do they not comment on Riou's sudden cowardice, or do they have different lines? Does anyone know? Anyway, this will probably take some serious debugging.

User avatar
Pyriel
Webmaster
Posts: 922
Joined: Wed Aug 18, 2004 1:20 pm

Re: Bug Fixes

Postby Pyriel » Fri Jul 15, 2016 4:58 pm

OK, Omni, I think I've found the culprit, but not the reason. If you want to play around with it, start replacing bytes at 0x80165EBA when that set of events is running, and overwrite with 0x09 0xB9 0x02 0x09 0xB9 0x04 0x2E 0xFF 0xFE 0x00 0x00. It'll short circuit the script when you choose "But..." and the events should run normally, minus the skip.

There's a script command in there that I think was added to the main action script engine for this area alone, 0x78. The purpose of it seems to be to pick dialog from an array based on who the character in a given slot is. It takes 4 arguments, the first two of which appear to be Slot (within the area presumably, though I doubt you'd get good results going beyond 5) and the index of the text table the dialogue should be retrieved from. The third one is, I think, a "sub-block" number within the text pointer array. That one array holds all or most of the custom lines for different characters you can pick. I don't know what the fourth one is. The mere fact that this command runs once during those events seems to be sufficient to crash the game.

If you pick "But..." once, it runs the command for the person in slot 4 of the room as sort of a preload for a while loop, and sets bit 1 of flag byte 0xB9 on. If you choose the other option, it also sets bit 2. Then the control is withheld and the background engine checks more condition scripts. Having bit 1 on but not bit 2 causes a second script to run that does Nanami's repetitive line, followed by slot 5, then repeats for slot 6, and slot 4 if you keep hesitating. Then of course this second active script is repeated until you make the right decision. I tried bypassing it, but even if I set bit 2 on right after running 0x78 in the first script, the game still crashed. So far only eliminating that command has fixed the issue with choosing the second response.

Edit: Eilie got a little more irritated than usual with Riou.
Image

Edit 2: As ever lately, it appears to be a missing script command. When you first pick "But..." that script runs a command that sets bit 0 of 0x80025664 on. The next script that round-robins the responses should unset it. Otherwise the state of all the event flags—Flag-0xB9 & 0x10 is true after Flik says "Don't be ridiculous!", and Flag-0xB9 & 0x20 is still false—and that particular control bit being on, satisfies the background script conditions for a script that will load another file in place of one the game currently needs. I'll have to check the Japanese version to see what's there. It may be a different set of events is supposed to unfold, and the localization broke it, but I sort of doubt it. I think somebody would have mentioned it by now.

If you can poke memory at all, just unset the least-significant bit of that address after the first battle, or even after Flik responds when you agree to fight.

It's another one of those scripts without much padding, so I'll have to write a proper patch and test before I can claim to know a good fix for it.

Omnigamer
Posts: 282
Joined: Wed Feb 13, 2013 11:48 am

Re: Bug Fixes

Postby Omnigamer » Sat Jul 16, 2016 12:47 am

Wow, sounds like somebody messed up pretty big in writing that function. Just to confirm, it happens regardless of whether you have somebody present in slot 4/5/6 or not? I never take other characters in my runs, but I'd be pretty surprised that it hasn't been noted until now unless it has some other conditions to it.

User avatar
Pyriel
Webmaster
Posts: 922
Joined: Wed Aug 18, 2004 1:20 pm

Re: Bug Fixes

Postby Pyriel » Sat Jul 16, 2016 10:01 am

It's not actually that function. I reviewed it pretty thoroughly, looking for ways it might be stepping on large blocks of memory and found nothing. It does some really quirky things, like the script process control pointer appears to be copied several times for no reason, the copies are incremented and used to replace the global script PC with new values, and then the original value is increased by the number of bytes read for the command, and undoes all of that unnecessary work. But it doesn't seem to do anything harmful.

That whole series of events is setting different flags in byte 0xB9 on, and there's another script with the activation condition I described above (byte & 0x10 AND NOT byte & 0x20). After the first battle that part becomes true right after Flik says, "don't be ridiculous!!" If you selected "But..." instead of fighting right away, that earlier script will have left 0x01 on in 0x80025664. And that bit of script does run even if you have nobody in slots 4-6 of your party. Bit 1 just needs to be turned off somewhere along the line, or that other script needs to be broken. It may be that they planned on a different series of events if you hesitated, but never coded it. I don't know. It'd be weird to use a global bit of data instead of a specific event flag, but it's Konami after all.

The script with the fateful choice in it has a command 0x24 0x01, that sets that bit on. I believe there should also be a 0x25 0x01 later on that unsets the bit. When I was experimenting with the script, not running that command had some wide-ranging and detrimental effects, and I couldn't imagine how setting one bit in a temporary, global variable would cause such problems. If I recall correctly, when I replaced the 0x78 command, I left that 0x24 in there, but by setting extra flags in byte 0xB9 right away, different scripts got run that prevented the file load script from taking off.

bongchoof
Posts: 13
Joined: Fri Dec 23, 2016 7:40 pm

Re: Bug Fixes

Postby bongchoof » Fri Dec 23, 2016 7:43 pm

So how do I use this patch? I compared the file sizes of my iso and the OP and they are the same. I run the batch file and the command window opens for half a second with no text and then closes. Was something supposed to happen? How can I tell?

User avatar
Pyriel
Webmaster
Posts: 922
Joined: Wed Aug 18, 2004 1:20 pm

Re: Bug Fixes

Postby Pyriel » Fri Dec 23, 2016 9:46 pm

Open a command line in whatever folder you downloaded it to (easy way is by going up one directory, holding shift, right-clicking, and selecting "open command window here", and run gs2patcher.bat.

The batch file is just there to check that things haven't been moved or deleted, and then it runs the Lua script that actually does the patching. The command window shouldn't close at all until you're done. You should see the patch configuration dialog, unless some of the files are missing or Lua has some issue with your machine. Which is a possibility with newer versions of Windows. I've never tried this thing on Windows 10, for instance.

bongchoof
Posts: 13
Joined: Fri Dec 23, 2016 7:40 pm

Re: Bug Fixes

Postby bongchoof » Sat Dec 24, 2016 1:12 pm

there was an error loading lua_interface.lua using built-in: Error opening lua_interface.lua for reading: Bad file descriptor
I have windows vista and i remember using this file a few years ago so i dunno

User avatar
Pyriel
Webmaster
Posts: 922
Joined: Wed Aug 18, 2004 1:20 pm

Re: Bug Fixes

Postby Pyriel » Sat Dec 24, 2016 1:25 pm

That's not even really an error. "Bad file descriptor" is typically Lua speak for "file not found", and it's just looking for an optional replacement for the built-in interface file.

If that's all there is, I can't really say. The batch file made it to the point of launching the patch dialog, and it's not spawning or closes immediately for some reason. It could be as simple as the window opening off-screen for some reason. Say if you had dual displays at one point, and moved it to the secondary display. Sometimes Windows defaults to a position that no longer exists after the second display is removed. Or...are you perchance trying to launch it from the compressed folder you downloaded or without extracting all the files?

bongchoof
Posts: 13
Joined: Fri Dec 23, 2016 7:40 pm

Re: Bug Fixes

Postby bongchoof » Sat Dec 24, 2016 2:11 pm

ok so. i extracted the all of the contents into a folder i created near the same places as the iso. when i run the batch file the cmd windows says what i told you up there and the patch window opens. i select the iso and then hit apply patch and then it says verifying disc. how long should this take? because its been verifying for a while now

User avatar
Pyriel
Webmaster
Posts: 922
Joined: Wed Aug 18, 2004 1:20 pm

Re: Bug Fixes

Postby Pyriel » Sat Dec 24, 2016 2:20 pm

The verification step should be basically instant. What you're describing sounds familiar, and if memory serves it's what happens when the source image is one that the Lua library can't read for some reason. Lua itself goes into an infinite loop trying to access the file, and the only way I could work around it is to require a raw image with one specific checksum, which I don't want to do.

Another possibility is that you somehow worked around the checks in place to prevent you from trying to write the patched file to the same file as the source.

bongchoof
Posts: 13
Joined: Fri Dec 23, 2016 7:40 pm

Re: Bug Fixes

Postby bongchoof » Sat Dec 24, 2016 2:26 pm

so would 'finding' another iso maybe help?

User avatar
Pyriel
Webmaster
Posts: 922
Joined: Wed Aug 18, 2004 1:20 pm

Re: Bug Fixes

Postby Pyriel » Sat Dec 24, 2016 2:30 pm

It could. The ones people typically "find" are compressed by having the error correction information stripped out, so if you found the one you're using in the first place you looked, that may be the problem.

bongchoof
Posts: 13
Joined: Fri Dec 23, 2016 7:40 pm

Re: Bug Fixes

Postby bongchoof » Sat Dec 24, 2016 2:41 pm

so how can i tell if its a good one? the one i had matched the file size listed in the op. i guess keep looking till i find one. ill let you know!


Return to “Suikoden II”

Who is online

Users browsing this forum: Google [Bot] and 4 guests