Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lazy Bastard

Pages: 1 2 [3] 4 5 6 7 8 ... 12
51
Nice; thanks :)

53
Ah; I assumed the world map Z coordinate would either behave the same way you predicted the field Z coordinate would behave (base the model's Z coordinate on the only possible Z coordinate at a given X/Y), which would explain the issue with bridges/etc. However, the hypothesis in this thread seems more satisfying: http://forums.qhimm.com/index.php?topic=12568.15

Also (although they appear to have made a mistake concerning triangle values in fields), Black Chocobo's savemap documentation refers specifically to "Z location on world map".

54
Z is updated in real-time at 00CC1684 written from 0063762D, 00635147, 006359C9
I do not see it in menu memory.  Is this value saved?

This is probably related to the same issue on the world map (inability to save while on bridges, since the game wouldn't know whether you were on the bridge or on the land below when it tried to load your save later). Thus the answer would seem to be "no", though I've done no research to verify this.

Edit: ...which begs the question - is there any spot in a field in which you can normally save, which is directly above another spot at which you can normally walk? If not, I wonder what would happen if I activated Save Anywhere via a GameShark code, then saved in a spot directly above another spot, and tried to load the save...now I'm curious.

55
Cool; thanks. I'll go RAM diving when I get home from work :)

56
Any chance you can provide the original hex values?

57
Thanks. Any simple one would do. Pick a town, enter it, don't move, go into the menu, let me know what the coordinate values are. I'll do the same in the PSX version, take a RAM dump, find those values, and we'll know where it's stored in PSX memory. It could then either be used standalone by those who only own/use the PSX version and want to identify coordinates for a mod, or perhaps I can scheme up a method of automating the process a little more for PSX users, such as a GS code that copies the values from those addresses and displays them in numeric format instead of other values normally shown in-game in the menu.

58
So you're sure the data isn't in the same format, or you're just sure that the person in charge of music was Hidenori Suzuki? I just want to be clear on that, since it's not out of the question that Square continued to use the same format even with another person performing the work...

59
The best way is to use Black Chocobo... it can place you anywhere you want and tells you the exact X Y and Triangle (which BC has mistakenly called Z) values.

If you need me to tell you exact coords for certain places, I don't really have the time.  But if you have PC version it would not be that difficult to find based on this method.

Actually, I was just hoping you'd already recorded something like the initial X/Y/Z/T for Cloud's first placement in MD1STIN (first field in the game). Presumably, the values are the same between PC and PSX versions, so I could simply do a RAM dump and search for those values, rather than hacking coordinate mods using a GS-style hacking utility (CEP/PEC, TSearch, RenegadeEX, ArtMoney, MHS, etc), then determining whether or not the resulting addresses were indeed the ones that contained the values to be recorded upon saving, and in the same format (there are likely multiple places where field coordinates are stored; my experience in RAM-hacking PSX games has been that this is often the case).

As I said, this would make it easier to identify these addresses quickly and with minimal effort, rather than spending time and effort reinventing the wheel. Afterward, others might benefit from knowing where in memory these values are stored for the PSX version.

I think my work in reversing FF7 makes clear that I don't expect anyone to carry my weight or run around taking coordinate samples for me. I just wanted a single sample that would be identical between versions, so I could bridge the gap and make this work of yours useful for both PC and PSX. If grabbing a single set of values for me is a big effort you don't have time for, then I'll just go to the proportionally larger effort of doing it myself on PSX, or, as you said, digging around in Black Chocobo and performing comparisons using the values found there. No matter.


If you take a known fixed location (IE the game stuffs you at that location) and then get his memory dump you can use PSX utilis to scan the memory for a match.

I believe the GTE (PS1) uses data with a 12bit fractions in it's engine (hence why it appears shifted by 12 then they force it to an integer value).
It might take a few tries but it has a somehat fair chance of success.
You might also want to look at the PS1 cheat codes and see if anything is available in them similiar

Cyb

Yep; that would be my second choice. I'm fairly familiar with PS1 cheats, having founded GameHacking.org as GSHI in 1999, back when we exclusively hacked GameShark codes :)  My FF7 codes, along with those of many others, can be found here: http://gamehacking.org/?game=88853  (although we're in the middle of a database revamp, so there's a little tidying up underway still)

60
Since you know where to find these values for the PC version, would you mind providing the values for X/Y/Triangle upon entering a specific field, so I can lazily identify where they're stored in the PSX version?

61
Interesting stuff. Does FFT also use AKAO strings, or is it just something similar?

62
Heh, guess I don't get the reference, so...you're welcome?  ???

63
I have plenty more to ask of you, cause i typed my first python hello world yesterday (trying to convert your PSX Battle Model viewer python script from 2009 to a Noesis plugin myself.) but i'll give time to read about Noesis first. The main idea is you can import and export models to / from Noesis to so many different formats.

FYI, Micky's model viewer script was for field models, not battle models - http://forums.qhimm.com/index.php?topic=8969.msg122920#msg122920

And yes, I agree - Noesis looks quite promising.

64
There's a good deal of documentation concerning AKAO data on the wiki and in a few threads here on the forums, and QGears contains an AKAO decoder/player of sorts, but has anyone successfully imported new AKAO data? I realize we'd be somewhat constrained by instrument limitations (INSTRx.DAT/INSTRx.ALL - although we could probably edit those as well), but it would still be interesting to generate new music and sounds, even if they started primitively and we improved the process later. Makou Reactor now has the ability to import/export AKAO data into \FIELD\*.DAT files, but the AKAO data still has to already exist in the proper format, in some other DAT at least.

I've considered a workaround for adding music to the PSX version, by creating a transparent FMV with a music track, and looping it while allowing normal field activity to continue (that could fairly easily be accomplished via Makou Reactor), but that's a pretty hacky workaround, and it might get size-intensive with several new tracks (not to mention resource-intensive, probably). I'd be much more interested in a way to properly generate AKAO tracks.

Any ideas? Or, has anyone done this before?

65
I've hosted a mirror of StageView's Windows executable on GameHacking.org (with credit, of course), including a quick batch script I wrote to provide a primitive menu system for StageView, in case that's desired by the user: HERE.

The script allows the user to either type the name of the stage file to load, or the word "all", which will load a separate instance of stageview.exe for each valid stage file within a directory (my system could handle loading all stage files simultaneously; who knows how that will act on slower systems). If the user types the name of a valid, existent stage file, but neglects to add the .lzs file extension, the script will append it to the provided file name and try that. If the user types the name of a file that doesn't exist, or that isn't a true stage file, the appropriate message will be displayed, and the user will be asked to try again. After successfully loading one or more stage files, if stageview.exe is closed, the batch script will remain open and allow the user to type another file name (or "all").

Hopefully that's slightly useful to someone.

In case anyone wants to see Micky's app in action:


66
Ah; makes sense. Thanks for the detailed response.

67
Ah, heh.

Well, your work is generally quite impressive, so people are going to listen to your advice whether you like it or not :P

68
Ah, very interesting.

A mentally lazier way to begin that (I do have this moniker for a reason :) ) would be to open BGINMENU.MNU in a hex editor, copy a chunk of unique data from it (preferably near the beginning of the file), run the game in pSX (or another emulator with the ability to dump RAM), make a RAM dump while in the beginning menu, open the RAM dump in a hex editor, and paste the BGINMENU.MNU data you copied earlier into a Search feature. It should be pretty easy to identify where in RAM the file is loaded (that's how I lazily found world map models, as well as several other things); now you have a value to search for when looking for the pointer.

I'll play around with this when I've finished a few other things I'm working on for my mod.

Thanks for the info.

69
Cyberman:

1 - As in, dynamic linking, or it's actually compiled at runtime?

2 - That's some of what I had in mind, along with setting breakpoints on a few addresses I've already identified as "interesting", and finding the encoded text for "NEW GAME" and "Continue" (capitalization inconsistency copied from the game).

3 - Done :)

70
Cyberman: Ah; that explains a lot (and makes me feel less annoyed that I was unable to make heads or tails of the format, heh). I've read that wiki page (also, where did those images go?).

halkun: I may do just that. Time to get knee-deep in r3000 ASM again  :)

71
Cyberman: Good tips; thanks very much. I'll keep those in mind in the future.

Micky: Awesome; it works :)  Mind sharing the current source as well?

72
Yeah, wrote it the wrong way around.

...in this recent post, or in the first post? If so, was NFITC1 also mistaken? I just want to clarify, since I haven't dived into this aspect of FF7 modding yet.

73
Cool; hopefully you can figure something out. If so, I'll add it to the GameHacking.org Downloads section, for posterity.

Not sure what you mean by "stepping over load_lzs". In the first post after yours, I set a breakpoint on load_lzs, and stepped through it...did I miss something?

74
Wait, if you're using Visual Studio in Windows, couldn't you just compile a copy of the program?  :)  That's all I'm shooting for here (sure, playing with source is fun, but my goal is to get the app working).

75
In case it's of interest, I've also done so for load_background and main:

Code: [Select]
$ gdb stageview
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\MinGW\msys\1.0\home\[USER OMITTED]\stageview.exe...done.
(gdb) b load_background
Breakpoint 1 at 0x401a62: file stageview.cpp, line 217.
(gdb) r C:\MinGW\msys\1.0\home\[USER OMITTED]\stage04.lzs
Starting program: C:\MinGW\msys\1.0\home\[USER OMITTED]\stageview.exe C:\MinGW\msys\1.0\home\[USER OMITTED]\stage04.lzs
[New Thread 1124.0xf7c]

Breakpoint 1, load_background (filename=..., bg=0x40c020) at stageview.cpp:217
217             bg->vertex_count = 0;
(gdb) n
218             bg->vertex = NULL;
(gdb) n
219             bg->element_count = 0;
(gdb) n
220             bg->element = NULL;
(gdb) n
221             bg->textures = NULL;
(gdb) n
222             bg->shader_count = 0;
(gdb) n
223             bg->shader = NULL;
(gdb) n
224             bg->mesh_count = 0;
(gdb) n
225             bg->mesh = NULL;
(gdb) n
228             int size = load_lzs(filename, (void**)&data);
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x00401414 in get_u32le (buf=0x0) at stageview.cpp:45
45              return ((u8*)buf)[0] | (((u8*)buf)[1]<<8) | (((u8*)buf)[2]<<16)
| (((u8*)buf)[3]<<24);
(gdb)


Code: [Select]

$ gdb stageview
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\MinGW\msys\1.0\home\[USER OMITTED]\stageview.exe...done.
(gdb) b main
Breakpoint 1 at 0x402c41: file stageview.cpp, line 477.
(gdb) r C:\MinGW\msys\1.0\home\[USER OMITTED]\stage04.lzs
Starting program: C:\MinGW\msys\1.0\home\[USER OMITTED]\stageview.exe C:\MinGW\msys\1.0\home\[USER OMITTED]\stage04.lzs
[New Thread 3776.0x1ac]

Breakpoint 1, main (argc=2, argv=0x3e26f8) at stageview.cpp:477
477     {
(gdb) n
478             if (argc != 2) {
(gdb) n
483                     getcwd(cwd, sizeof(cwd));
(gdb) n
485                   string path;
(gdb) n
486                     if (argv[1][0] != 0 && argv[1][0] != '/' && argv[1][1] !
= 0 && argv[1][1] != ':' && argv[1][2] != 0 && argv[1][2] != '\\') {
(gdb) n
491                     glutInit(&argc, (char **) argv);
(gdb) n
492                     glutInitWindowSize(640, 480);
(gdb) n
493                     glutInitDisplayMode(GLUT_SINGLE | GLUT_RGBA | GLUT_DEPTH
);
(gdb) n
494                     glutCreateWindow(argv[0]);
(gdb) n
495                     glutDisplayFunc(MainRenderLoop);
(gdb) n
496                     glutIdleFunc(MainRenderLoop);
(gdb) n
497                     glutReshapeFunc(ReshapeWindowFunc);
(gdb) n
498                     glutKeyboardFunc(KeyboardHandler);
(gdb) n
499                     glutSpecialFunc(SpecialHandler);
(gdb) n
502                     load_background(path + argv[1], &battle);
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x00401414 in get_u32le (buf=0x0) at stageview.cpp:45
45              return ((u8*)buf)[0] | (((u8*)buf)[1]<<8) | (((u8*)buf)[2]<<16)
| (((u8*)buf)[3]<<24);
(gdb)


...but as you can see, it's the same issue.

Pages: 1 2 [3] 4 5 6 7 8 ... 12