Bugfixes and Queries

  • Thread starter Thread starter DLPB_
  • Start date Start date
Status
Not open for further replies.
The issue is entirely the actual data.  Starting 326D in chocobo.wat (found on chocobo.lgp), the list of values with 82 should be 81. If your list above is right, it seems that there is also a sequence of 00 as opposed to 80.  Which is a bit strange?

Hmm and I think all those 01s at the start of the short map should be 02s (to stop river but not mountain)

It depends whether that "outer space" part at the end of short course is meant to stop river but not mountain. It isnt a water area...  so I'd have to go hill.
 
Last edited:
It depends whether that "outer space" part at the end of short course is meant to stop river but not mountain. It isnt a water area...  so I'd have to go hill.
Click to expand...
Well, if you're into map editing then you should just disable handicap bits for that part, as it's neither water nor uphill (as downhills are in the other part of both tracks and they don't slow chocobos down).

Second thought: Actually, if you think of it - water chocobos are able to cross rivers and shallow waters, so places with no solid ground. It might be that the space was supposed to be that "not-that-solid" ground.

Third thought: How the chocobos behave on PSX? The maps were probably converted from some other format, there might be a difference.

Oh, and the highest bit (0x80) is supposed to mark some places on the map, as it's checked in the code, but dunno what. It's not connected with 0x01 & 0x02 though, so just don't change that bit and you should be fine.
 
I would say that the space area is meant for the black and golden Chocobo.
 
That's an interesting idea. Technically, if the slowing down would be done the way it is done now, given one blue and one green chocobo, one would be slowed down by 25% (the one affected by 0x01 bit) and the other by 50% (the one affected by 0x02 bit). Yellow chocobos would be slowed down by 75%.
 
The psx data does appear to be different.  I don't think the "chocobo.dat" file is compressed - and its contents bear no resemblance to "chocobo.wat". I'd have to look at the PSX game and see if they fixed this error there already.
 
I had the same thought for a moment, technically  space is not water, and maybe space was meant to favour Blacks and Golds only, or even just Golds only.
Like:
Blue's strength: Water..  Green's: Hills..  Black's: Water and Hills..  Gold: Water, Hills and Space.

Green is already a better choice than Blue overall for racing (more hills than water), and with space not being water, it'll be even more true.

So what will this mean from a player's pov..
Do I choose the short course? Nope, I have no Gold Chocobo yet. So, the long course where we have water.. but more hills than water..
So we'll end up always choosing the long course with a Green Chocobo. Then later, always the long course with a Black.
Then bingo I've got my Gold, it's finally become a thing to choose the short course.

I'm not saying it's especially a bad thing.
The only thing I find meh, is to unbalance even more Green/Blue, but the unbalance has more to do with both tracks being often hilly, and that's the original game.
 
I'd disagree with space for gold only because the black chocobo ridden by Joe is meant to be difficult to beat across all classes - and that would kill the competition. I'd say short is meant to be harder since you are being lazy.
 
I agree.
Here's what I come up with. It's balanced.
Each number represents the %age of handicap. For the best, we can assume that the handicap from a big hill = from water = from space (the only change is which colour(s) will be unaffected).

small Hill         Gold&Black:0   Green:0   Blue:25  others:25
big Hill            Gold&Black:0   Green:0   Blue:50  others:50
Water              Gold&Black:0   Green:50  Blue:0   others:50
Water+smallH  Gold&Black:0   Green:50  Blue:25  others:75
Space              Gold&Black:0   Green:50  Blue:50  others:50
Space+smallH  Gold&Black:0   Green:50  Blue:75  others:75


Big hills are the ones like in the spiral, in opposition to the slighter slopes.
 
I encountered an odd bug. When you have to sleep in Aerith house and are out to leave, but think “Hey, why not move before her door and do some run action? :-D” (and do this of course) Aerith will come out and surround you like a bee a flower, endlessly. I guess I blocked her point with Cloud. The script needs an alternative point if it is blocked.
 
That was fixed, I think.  I'll recheck when I get time.
 
Last edited:
I am working on fixing quite a few things (for example Game Over and Credits are being limited to 60fps), but first I needed to document the module calls. I've got everything I need now, but I guess I should share...

Code: [Select]
Code: 
Modules  Main Jump at 40919Eebp-10 Main loopebp-C Mouseebp-8 keyboardebp-18 Enterebp-14 (?)ModuleEnterAddress Enter call at 666CDAModuleMainAddress  Main call at 67DD8A              ENTER     MAIN LOOPNA MAIN       408FA6    NA00 FIELD      60E0BD    60E5B701 BATTLE     41B300    41BAB302 WORLD      74BAF5    74BE4903 NOT USED04 MENU       6CD3B0    6CC62305 G-BIKE     650310    65041206 CHOCOBO    76D597    76DBD1070809 SUB        77D030    77DF720A COASTER    5E8D49    5E8E7E0B0C0D SNOWBOARD  722C10    722CCF0E NOT USED0F10 BAT MENU   See 04    See 0411 NOT USED1213 TITLE SCR  See 04    See 041415 NEW GAME   See 00    See 0016 SWIRL      40164E    4021E917 NOT USED1819 GAME OVER  406367    4064D71A CREDITS    7A776F    7A7A331B1C1E1F20 Same as 1F21 Same as 1F22232425}
 
Last edited:
The "teleport bug" is fixed.  I am not sure why exactly these bytes need to be reset to 0 - but they do.  If they aren't the game is instructed (after a world map battle + jump to a field flag) to jump back to the previous field that is still in memory. Once these bytes are zeroed, the bug will go away.

More fixes made:

1. Sound effects are also terminated on battle game over.
2. field and battle vars that need zeroing to prevent issues are now zeroed (these include teleport bug, countdown timer in world map battles bug, and others).
 
Last edited:
I am currently fixing up the credit screen to look like it did on the PSX.  Here are the differences:

1. Programming error on the part of the porting team. Text is traversing a distance 2x what it should be (because it's starting position is outside of 2 screen widths instead of 1). That's why there is a huge pause between each credit. Each text has its own starting X / Y and other data, which is part of a large table.

2. PSX black text is faster than the white text, but in the PC version, both texts are the same speed. This may explain 1. I can;t be sure yet, but perhaps the reason 1 is the way it is is because the black text, now running at same speed as the white, has been corrected to move 2x the distance so the timing works.  I will check.

3. Text size is wrong.  PSX appears to the eye to be 2x larger. This is because the text is being displayed at 320 * 240.  This may prove to be a real pain in the arse to correct - and if I do, a lot of the table data will  need correcting also to start the text X ending pos to be further left (or text will be chopped).

I really shouldn't give a shit about the credit screen, but it's been annoying me for years.
 
Last edited:
I've added a few that I have documented:

Code: [Select]
Code: 
ENTER     MAIN LOOPNA MAIN       408FA6    NA00 FIELD      60E0BD    60E5B701 BATTLE     41B300    41BAB302 WORLD      74BAF5    74BE4903 NOT USED04 MENU       6CD3B0    6CC62305 G-BIKE     650310    65041206 CHOCOBO    76D597    76DBD107 same as 0D08 CONDOR     5F47B5    5F4A4709 SUB        77D030    77DF720A COASTER    5E8D49    5E8E7E0B CDCHANGE   404688    4047F60C WUTAI        N/A       N/A0D SNOWBOARD  722C10    722CCF0E NOT USED0F Force battle? N/A       N/A10 BAT MENU   See 04    See 0411 NOT USED12 End_Game    N/A       N/A13 TITLE SCR  See 04    See 0414 Load Game   N/A       N/A15 NEW GAME   See 00    See 0016 SWIRL      40164E    4021E917 NOT USED18 Play Ending Movie19 GAME OVER  406367    4064D71A OPCREDITS  7A776F    7A7A331B ENDCREDITS 7A776F    7A7A33}
Past these values are nothing.

The Wutai event apparently has several sub events related to materia including:
-Stealing materia at the beginning of the quest
-Returning materia at the end of the quest
-Granting master materia
-Granting bahamut zero
 
Last edited:
Ah, cheers for that NFITC! ;)  Very nice.  Why nothing after 1B?  I remember jumps to code exist,  This code doesn't do anything?

Also, I've worked out where the porting team's mistake was. They assumed the bl;ack and white text was the same speed.  When they came to port the game, they couldn't make the timing work because they were under this assumption. To compensate for their own mistake, they made the black text travserse 2x the distance.  What they really needed to do was half the speed of white text.

As I have here:

Code: [Select]
Code: 
99C57C = 0299C58C = 0299C538 = FE99C540 = 0299C548 = 0299C550 = FE99C584 = FE99C594 = FE
I now have to alter all black text starting X / Y pos - so the timing again works.  Some white text pos will also need fixing.
 
Last edited:
Ah, cheers for that NFITC! ;)  Very nice.  Why nothing after 1B?  I remember jumps to code exist,  This code doesn't do anything?
Click to expand...
Jumps exist and they do things, but they're used by the Wutai event. The actual event driver variable (0xCBF9DC) has a max value of 1C, but is subtracted by 1 when the event is selected. If that subtracted value is greater than 1C it goes to a non-event. In practice, this never happens. Quite strange and I'm not really sure what the point of subtracting by 1 is. It's only ever dynamically assigned in three places: loading a game (including new game), exiting the main menu and changing CDs. That's only to redirect it back to the world map and the field. As a matter of fact, this might be the source of the Yuffie warp glitch. I can't confirm that right now, however.
 
Last edited:
I've seen this subtraction nonsense a lot actually.  I'm thinking it may have been the compiler that did it.  I know that when I look at my own code it often uses fancy tricks like that, usually for efficiency.
 
The warp glitch has been fixed by me actually for my dll.  It's caused by some temp vars not being reset on game over - here:

              {reset field vars to stop teleport bug}
              mov dword ptr [$CFF594],$00
              mov dword ptr [$CFFAB2],$00
              mov dword ptr [$CC0B60],$00
              mov dword ptr [$CFFC60],$00

They were a bitch to find and I had to use some nifty comparison trickery to isolate them.

3 of these contain addresses.  If they aren't cleared on game over, then reloading to world map will not clear them either.  After world map battle, it will use these to attempt to jump back to field. When cleared, the behaviour changes and will be correct. As far as I can see, these addresses are used for a simply "jump back to previous field" operation.  And, as I noted, they take precedence over other jump field operations.

Other addresses need to be cleared to stop other bugs.  For example, countdown timer being visible in world map battle after reloading game.  World map / game over / load  do not reset any of the vars.  Only entering a field will. I've added these fixes too.
 
Last edited:
credit screen fix is going well, but I will have to hold off until I have got the original text in place from psx... since a lot of this is a manual changes to the table.

Anyway, here is how it works.  Each text uses 16 bytes.  Four texts to a corner means 64 bytes per fix. And, since there are 29 corners needing repair, that is 29 * 64 bytes in total (1856).
 

99B5E8 = C2 01 00 00 08 00 00 00 80 FF FF FF 08 00 00 00
99B5F8 = 02 01 00 00 00 00 00 00 03 01 00 00 00 00 00 00
99B608 = BB 00 00 00 94 FF FF FF BB 00 00 00 50 01 00 00
99B618 = 00 00 00 00 28 00 00 00 00 00 00 00 29 00 00 00


Red:  Starting X of white text1 and black text 1
Orange:  Ending X of white text1 and black text 1
Blue: Fixed Y of white text 1 and black text 1

Green: Starting Y of White text 2 and black text 2
Brown: Ending Y of white text 2 and black text 2
Purple: Fixed X of white text 2 and black text 2

When in the top right, black text 1 X pos dictates the timing. In this case, 80 FF FF FF (minus 127).

*** These are unused above as top right calculations do not need them.  Two of the corners use these values, while discarding 4 others.
Yellow:  Fixed X of of white text 1 and black text 1
Pink: Fixed Y of white text 2 and black text 2

In order to get the top right working properly, part of the calculation phase also needs amendment:

7A53FB = 90 90
7A554B = 90 90

Another 6 of these will be nopped to fix the other 3 corners.
 
Last edited:
NFITC1.  Why does the World Map not use the main jump at 40919E when calling the menu.  Everything else seems to use this no matter what.
 
Last edited:
Status
Not open for further replies.
Back
Top