FF7 PSX: SAVEMENU.MNU's NEW GAME feature

[Lazy Bastard]

Since it seems that .MNU files are chunks of composite TIM/ASM/other data, has anyone figured out exactly where the code is for what should occur if the user chooses NEW GAME?

Presumably, that choice kicks off the initial FMV, then loads field MD1STIN (Sector 1 train station's first field), which then runs its scripts and passes control to the user.

What I'd like to do is cut in before the first FMV is ever loaded, and tell it to go somewhere else (whatever field I happen to be interested in starting off at, with no FMV). Alternatively, I don't mind breaking that initial FMV, or its code, or the script for that first field, if there were a way to do so that would accomplish the same goal and not be apparent to the player...but the more I look at it, the more it seems that won't be possible.

Is my best route going to be making a save state of me accessing the NEW GAME/Continue menu (SAVEMENU.MNU), then changing what choice I'm hovering over...or perhaps even trying to catch the game immediately after a choice is made...and then disassembling it and digging around in the ASM?

Also, the wiki mentions BGINMENU.MNU being the first menu to be loaded (which is correct), but then specifies that the image below is of BGINMENU.MNU, which I believe is incorrect. That's SAVEMENU.MNU, even though it's not technically 'the save menu'...correct?

[Kranmer]

Presumably, that choice kicks off the initial FMV, then loads field MD1STIN (Sector 1 train station's first field), which then runs its scripts and passes control to the user.

Wrong.
Just to let you know after you click on NEW GAME it loads MD1STIN right away and NOT the video, the opening video is loaded from MS1STIN script and can be changed really easily (using Makou Reactor or Hack7).
So all you need to do is load MD1STIN into Makou Reactor and then click
"0 Dir"
in the 2nd column
then in the 3rd column click
"S0 - Main"
then click the + next to
"If $GameMoment == 0 (else jump to byte 213)"
and you should see a line that says
"Set next movie: opening"
this is the line you want to change, i hope this helps.

[Lazy Bastard]

Wrong.
Just to let you know after you click on NEW GAME it loads MD1STIN right away and NOT the video, the opening video is loaded from MS1STIN script and can be changed really easily (using Makou Reactor or Hack7).
So all you need to do is load MD1STIN into Makou Reactor and then click
"0 Dir"
in the 2nd column
then in the 3rd column click
"S0 - Main"
then click the + next to
"If $GameMoment == 0 (else jump to byte 213)"
and you should see a line that says
"Set next movie: opening"
this is the line you want to change, i hope this helps.

That's great news

I must've missed that when I was looking around MD1STIN last night. I'll see if replacing that with a field change will do the trick...but I do want to make sure the user never sees the MD1STIN field in the first place.

So, if I need to edit SAVEMENU.MNU to accomplish the above, does anyone have a clue as to where (an offset, or an ASM snippet, would be wonderful) the relevant data is? Modifying MD1STIN is fine if that's my only option, but what would be better is to force NEW GAME to jump straight to the field I want it to.

[Kranmer]

Sorry i am not sure how to edit the game to load a different file then MD1STIN when clicking NEW GAME (i don't actually know that much about the PSX version, most of my work is on the PC version but some of this stuff is the same), but there is a workaround which would work (i have tested this before on the pc version), instead of the line
"Set next movie: opening"
in MD1STIN change it to something like
"Jump to map jail3 (No478) (X=0, Y=0, triangle id=0, direction=0)"
and this will make it so as soon as you click NEW GAME it will instantly jump to the field "jail3" instead of playing the opening movie (this is just an example, you could use any map).
This way the user will never seen MD1STIN.

[Lazy Bastard]

Nice; I'll check it out a little later.

Still, it would be nice to be able to use the original MD1STIN at some point in the game, if desired. I guess one way might be to create an If Then statement that referenced some variable I could set one way or another based on whether the user just began the game or not. Optimally, I'd like to know the correct way to change the initial field...so anyone with that info, please do share it.

If not, I'll  begin by using the method mentioned. Either way, thanks again, kranmer

[Lazy Bastard]

Yep, that worked (although I'd still like a way to edit the initial field to be loaded). Thanks.

I've also noticed that files edited in Makou Reactor can't be opened in Hack7. Something must be getting corrupted unintentionally. I've read somewhere on these forums that Hack7 also causes some sort of corruption, but that there's a pseudo-fix for this involving yet another utility to un-corrupt said data...couldn't we build such a thing into one of these apps?

[Kranmer]

I'm glad it worked, i asked a friend who knows slightly more about the psx version then myself and he mentioned the FIELD files are read from the LBA (so it probably doesn't use the filename but uses where on the disc it is) which is apparently decided in the file FIELD.BIN (which is in the FIELD folder) and that is Gziped, i don't know how correct this information this is but it may be a good place to start.
I wasn't aware that Hack7 couldn't open modified files (i have only ever used it to extract Jap Font files from window.bin), you may want to ask the creator about it and see if he can add support for modified files. I also wasn't aware of any corruption in hack7 latest version but if there is you could also report that to the creator and just stick to Makou Reactor for now.
Anyway i hope this helps.

[Lazy Bastard]

I'm glad it worked, i asked a friend who knows slightly more about the psx version then myself and he mentioned the FIELD files are read from the LBA (so it probably doesn't use the filename but uses where on the disc it is) which is apparently decided in the file FIELD.BIN (which is in the FIELD folder) and that is Gziped, i don't know how correct this information this is but it may be a good place to start.

I guess it makes sense that SAVEMENU.MNU would load FIELD.BIN, which would in turn load MD1STIN.dat. If that's the case, SAVEMENU.MNU probably passes some argument to FIELD.BIN to identify that it should be loading MD1STIN.dat (or just directly access the component of FIELD.BIN that does that). This would mean that even if I edited FIELD.BIN to load a different field on NEW GAME, I'd still most likely be effectively hosing its ability to ever use that field (MD1STIN) properly. Thus, the most desirable method would still be to tell SAVEMENU.MNU to either call a different part of FIELD.BIN, or pass a different argument. Still, just as with the "edit MD1STIN.dat" method, I could always create a work-around involving an If Then-style decision (based on flags, some variable I set, etc).

I wasn't aware that Hack7 couldn't open modified files (i have only ever used it to extract Jap Font files from window.bin), you may want to ask the creator about it and see if he can add support for modified files. I also wasn't aware of any corruption in hack7 latest version but if there is you could also report that to the creator and just stick to Makou Reactor for now.

Yeah, I should probably do that. Also, I wish Makou Reactor had the ability to cram files back into a disc image, like Hack7 does. As it stands, you have to couple it with an app like Mass Field Dialogue Extractor/Importer, which is fine, but it's an extra step that would be nice to bypass. The only reason it's of any consequence at all is that Makou Reactor's interpretation of FF7's script system is more human-readable (in my opinion), while Hack7's interpretation is more powerful and versatile (again, in my opinion)...hence, both apps are worth using. This is also why it would be nice to be able to pass files back and forth between the two apps, making modifications in the method most intuitive.

After having some fun starting the game in hilarious places, I can now get around to beginning some work on this: http://forums.qhimm.com/index.php?topic=13303.0

[lasyan3]

Hi,

I'm glad it worked, i asked a friend who knows slightly more about the psx version then myself and he mentioned the FIELD files are read from the LBA (so it probably doesn't use the filename but uses where on the disc it is) which is apparently decided in the file FIELD.BIN (which is in the FIELD folder) and that is Gziped, i don't know how correct this information this is but it may be a good place to start.

That is correct.

I wasn't aware that Hack7 couldn't open modified files. I also wasn't aware of any corruption in hack7 latest version but if there is you could also report that to the creator and just stick to Makou Reactor for now.

Me neither! Thanks for the feedback, I'll get the last version of Makou Reactor and see how to solve this corruption matter ASAP.

[Lazy Bastard]

FIELD.BIN doesn't seem to make ff7dec very happy (it spits out an error stating that FIELD.BIN isn't a gzip file). I've followed the instructions and used the command:

Code: [Select]

ff7dec d field.bin
...but, no dice. I'm tempted to try it manually (destroy first 8 bytes, then treat it like a normal gzip file).

[sithlord48]

oddly enuff if you edit your save and make your gamemoment 1 you skip the video and start right on the train platform.(go ahead try it with Black Chocobo.)this is why i think that when new game is clicked it first creates a dump of the new game data  in the kernel to created the start of your save data. about 1/2 the data is in the kernel the rest is filled w/ 0's. then it loads up the field and so on..

[Lazy Bastard]

oddly enuff if you edit your save and make your gamemoment 1 you skip the video and start right on the train platform.(go ahead try it with Black Chocobo.)this is why i think that when new game is clicked it first creates a dump of the new game data  in the kernel to created the start of your save data. about 1/2 the data is in the kernel the rest is filled w/ 0's. then it loads up the field and so on..

There is definitely a bunch of character/party initialization stuff at the beginning of MD1STIN.dat, which might be skipped when you use Black Chocobo to make a custom save.

[Lazy Bastard]

lasyan3: Another issue with Hack7 is that when I choose "Others", it throws a General Exception error (although it doesn't crash or close, so I can just click OK and try something else):

Code: [Select]

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.IO.FileNotFoundException: Could not find file 'C:\Users\LB\Desktop\FF7 Modding Tools\Hack7v3b\Others.DAT'.
File name: 'C:\Users\LB\Desktop\FF7 Modding Tools\Hack7v3b\Others.DAT'
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at System.IO.File.ReadAllBytes(String path)
   at soldier.CFieldManager.Load(String pIsoFile, String pFieldFile, eLoadValues pWhat, eLoadFromValues pFrom, Boolean pDecodeFlow)
   at soldier.CFieldManager.LoadFromFile(String pFile, Boolean pDecodeFlow)
   at Hack7.FrmMain.tvFiles_OpenFile(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnDoubleClick(EventArgs e)
   at System.Windows.Forms.TreeView.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4971 (win7RTMGDR.050727-4900)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
Hack7
    Assembly Version: 3.0.2.0
    Win32 Version: 3.0.2.0
    CodeBase: file:///C:/Users/LB/Desktop/FF7%20Modding%20Tools/Hack7v3b/Hack7.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4977 (win7RTMGDR.050727-4900)
    CodeBase: file:///C:/windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4971 (win7RTMGDR.050727-4900)
    CodeBase: file:///C:/windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4974 (win7RTMGDR.050727-4900)
    CodeBase: file:///C:/windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
soldier
    Assembly Version: 1.2.0.0
    Win32 Version: 3.0.2.0
    CodeBase: file:///C:/Users/LB/Desktop/FF7%20Modding%20Tools/Hack7v3b/Hack7.exe
----------------------------------------
Puzzle.SyntaxBox.NET3.5
    Assembly Version: 1.4.10.12969
    Win32 Version: 3.0.2.0
    CodeBase: file:///C:/Users/LB/Desktop/FF7%20Modding%20Tools/Hack7v3b/Hack7.exe
----------------------------------------
System.Web
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4971 (win7RTMGDR.050727-4900)
    CodeBase: file:///C:/windows/assembly/GAC_64/System.Web/2.0.0.0__b03f5f7f11d50a3a/System.Web.dll
----------------------------------------
soldier
    Assembly Version: 1.2.0.0
    Win32 Version: 3.0.2.0
    CodeBase: file:///C:/Users/LB/Desktop/FF7%20Modding%20Tools/Hack7v3b/Hack7.exe
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

[Gemini]

Exactly, what's this corruption issue you guys are talking about?

[Lazy Bastard]

I don't know if it's corruption, or just Hack7's inability to handle files that have already been modified by Makou Reactor. Basically, once a file has been edited by Makou Reactor, Hack7 can't load it.

[sithlord48]

There is definitely a bunch of character/party initialization stuff at the beginning of MD1STIN.dat, which might be skipped when you use Black Chocobo to make a custom save.

I can assure you that its not skiped when you use "New Game" or "New Game +" in Black Chocobo.

What I'd like to do is cut in before the first FMV is ever loaded, and tell it to go somewhere else (whatever field I happen to be interested in starting off at, with no FMV). Alternatively, I don't mind breaking that initial FMV, or its code, or the script for that first field, if there were a way to do so that would accomplish the same goal and not be apparent to the player...but the more I look at it, the more it seems that won't be possible.

This can be done by editing a save and loading it. In Black Chocobo Start by making a new game.
If want to start on the platform. Set your main progress value to 1 to skip the First FMV.
If you want to start somewhere else you only have to edit your loacation. there is a list of *most* the save points in the game that you can choose from. You can also manually enter the map id location id and your x,y,z coords of where wish to start. you should be warned that forcing to load on some maps will automaticly trigger some events on those maps. Others could be broken in part or in whole due to what your save data contains.

[Lazy Bastard]

This can be done by editing a save and loading it. In Black Chocobo Start by making a new game.
If want to start on the platform. Set your main progress value to 1 to skip the First FMV.
If you want to start somewhere else you only have to edit your loacation. there is a list of *most* the save points in the game that you can choose from. You can also manually enter the map id location id and your x,y,z coords of where wish to start. you should be warned that forcing to load on some maps will automaticly trigger some events on those maps. Others could be broken in part or in whole due to what your save data contains.

I'm aware of that. However, I'm working on a mod, of which this is just the beginning.

[DLPB_]

Welcome to the never ending frustration in the world of a modder. 

[Lazy Bastard]

Heh. I can't complain. I'm several layers of abstraction away from hex-editing for every change

Any app is better than no app, especially if it can actually make changes and not just tell me things (which in itself is something useful).

[lasyan3]

Exactly, what's this corruption issue you guys are talking about?

I just sent MP to Lazy Bastard, but FYI it's not really corruption: it's about jump recalculation of the IF commands in the script after you add or change it (the jump values are not recalculated automatically in Makou Reactor, but you can check if you see some red lines in the script, it tells you something is wrong with your script flow). Since Hack7 does the recalculation job, it can tell if there is an error in the flow (in this case, the "target event not found" means that the target of the jump value for a IF command was not found).

[Lazy Bastard]

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:







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).

[Lazy Bastard]

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.

[Gemini]

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.

[lasyan3]

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 :

[Lazy Bastard]

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.