FF7 PSX: SAVEMENU.MNU's NEW GAME feature

  • Thread starter Thread starter Lazy Bastard
  • Start date Start date
Status
Not open for further replies.
To be completely clear, I've taken a screenshot before and after the change in question (which is merely a test that destroys the initial FMV load upon NEW GAME, and replaces it with a hop over to the pickup truck scene with Zack and Cloud), as well as a screenshot with If statements collapsed:

Before.png


After.png


Collapsed.png


If I understand correctly, you're saying that "else jump to byte 213" refers to "213 - Control the group cl (No1)". Is this correct? Then, with Makou Reactor, users need to manually change various jumps and other related commands to match the new 'byte' reference numbers?

Shouldn't Hack7 still load the file, but just let you know there's a problem? As it stands, it won't even load the file at all...

This is especially true since, in this case, there would never be a need to come back to this field, and hence the jump never occurs (GameMoment does equal 0; this is a new game).
 
Last edited:
Actually, to answer my own (first) question, I corrected two jumps that were affected by modifications made in Makou Reactor, and this allowed Hack7 to open the MD1STIN.dat correctly. Still, I think Hack7 should be able to open the files, and complain about issues afterward if desired...

I didn't write the app, so I have no place to complain. It would just be a nice feature.
 
Still, I think Hack7 should be able to open the files, and complain about issues afterward if desired...
Or Makou could regenerate jumps automatically. I'm not sure why it's still working internally with byte positions:
1) it's error prone like hell, using labels instead of addresses would void the problem in an instant;
2) makes editing unnecessarily complicated, especially if there are several jump opcodes in a function.
 
Hack could eventually just show a warning and ask the user to let it correct the jump by choosing the command just before or after the bad value, but Makou Reactor has already a kind of solution by displaying the incorrect lines in red :
 
Or Makou could regenerate jumps automatically. I'm not sure why it's still working internally with byte positions:
1) it's error prone like hell, using labels instead of addresses would void the problem in an instant;
2) makes editing unnecessarily complicated, especially if there are several jump opcodes in a function.
Yes, that would be even better. I've PM'd the author (myst6re) and pointed to this thread.

Hack could eventually just show a warning and ask the user to let it correct the jump by choosing the command just before or after the bad value, but Makou Reactor has already a kind of solution by displaying the incorrect lines in red :
Making Hack7 auto-correct in that manner could still be prone to errors. It might be best just to issue a warning message, then let the user decide to what to do, if anything. As in my example, sometimes it won't matter at all what jumps are pointing at, if the jump decision is never reached.

In any case, I don't want to seem like a whining user. Hack7 is awesome, and so is Makou Reactor.
 
I've thought about using labels, by the way I made it on another program (Deling). This will in the next version perhaps, what is certain is that it will be possible to save the iso.
 
Status
Not open for further replies.
Back
Top