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 ... 12
26
So, meesbaker and I schemed about this for a little while. I verified via Akari's source how to pull palettes:

    int offset_to_clut = GetU32LE( 0xc ) + face_id * 32;

So, looking at a decompressed copy of FIELD.TDB, if I grab the 32-bit little-endian value at 0xC (0x0000FE10), and add (face_id * 32), I'll get 0x0000FE10 (Cloud's face id is zero, and zero times 32 equals zero). That means Cloud's CLUT data should be at 0x0000FE10.

Doing the same for Cid, if his ID is 05, would yield 0x0000FE10 + (5d * 32d = 160d = 0xA0) = 0x0000FEB0.

...but his source confuses me when it comes to actual face image data:

        for( int i = 1; i < face_row[ face_id ].size(); ++i )

        int offset_to_image = GetU32LE( 0x8 ) + face_row[ face_id ][ i ] * 512;


So, we started looking at actual offsets for face image data, and the offset we expected via 0x10 + (face_id * 0x200). For example:

Cloud face id is 0x0 or 0d
offset 0x0010
should be 0x10
difference is 0.

Tifa's face id is 0x03 or 3d
offset 0x3010
should be 0x610
difference is 2A00

cid 0x5 or 5d
offset 0x5010
should be 0xA10
difference 4600

Zack 0x9 or 9d
offset 0x9010
should be 0x1210
difference 7e00

sephiroth's face 0x15 or 21d
offset - 0xCC10
should be 0x2a10
difference is a200


difference between a200 and 7e00 is 2400.

2400 divided by 200(512d) equals 12.
12 is the number of models between Seph (21d) and Zack (9d).

So, every model increase, the difference between the supposed offset and the real offset increases by 0x200 (512d).

But, it turned out this didn't hold up for models before Zach.

A few more attempts at figuring out what was going on yielded this:

The first 10 models (0x0 - 0x9) are at offsets of 0x1000 bytes each. To get any of those, simply multiply 0x1000 * face_id, and add 0x10 for the header at the beginning. Cid is face_id 5, so 0x1000 * 0x5 = 0x5000, + 0x10 = 0x5010.

But after model 0x9, each model is only 0x400 bytes after the last. To get any of these, simply multiply 0x400 * (face_id - 0xA), and add 0xA010. Sephiroth is face_id 0x15, so (0x400 * (0x15 - 0xA = 0xB) =  0x2C00, + 0xA010 = 0xCC10.

It should be noted that we're still not clear exactly what data is in between.

What's interesting about this is that the first 10 models are all main characters, who have BCX files, etc...except Zach. This seems to imply that when they were making FIELD.TDB, they still considered Zach to be a main character.

meesbaker: I'm pretty tired, so let me know if I've missed anything.

27
Great work, meesbaker :) And, vayneruel's handiwork in color modding comes in handy again. Now we're finally getting somewhere with FF7 PSX modding.

28
Releases / Re: [REL FF7/PSX] Better Field Models
« on: 2013-09-21 00:28:06 »
Well done :)

29
Nicely done.

30
Updated 'Model Section', Header to include "Total data size of bones+parts", thanks to meesbaker's discovery :)

Also, added this information to a new page on the wiki (guess I forgot to add it, or we lost it in one of the wiki crash/backup fiascos).

31
Graphical / Re: PSX/PSP Sephiroth and Shinra MOD
« on: 2013-08-17 19:17:34 »
Glad I could help :)

Amazing work, man.

32
NFITC1: Great framework info. Thanks very much for jumping into this.

xLostWingx: Though I've been very busy with the new house I just moved into, I haven't at all dropped my intention to continue this thread (my email inbox is always kept clean of everything but items of the utmost importance, and the notification concerning this thread is currently one of only three items therein), until its information is useable in simplifying my custom playable character battle models. I'm finally starting to get back on track with some free time for projects like Adamant, so hopefully I'll take a few hours to sit down and map some things out more extensively very soon. In the meantime, anyone with a little free time and interest is encouraged to do the same.

33
I finally managed to spend at least a few minutes taking a look at another battle model (TIFA.LZS), though I still haven't had any time to modify anything and test the results. For interest's sake, here's Tifa's "Model Settings Data":


Model Settings Section [at offset 0x000073DC]:


Note: The byte size of the first (Unknown) sub-section of this section seems to be consistently 0x68 bytes.



Model Settings [at offset 0x000073DC]:


Unknown:

Code: [Select]
02 00 80 00 2C 01 00 07 00 07 00 00 00 00 E0 FC
7C FC 01 00 00 00 00 00 20 1B 03 00 03 16 0F 00
00 00 00 00 FC 03 00 00 FC 03 00 00 FC 03 00 00
FC 03 00 00 FC 03 00 00 FC 03 00 00 FC 03 00 00
FC 03 00 00 80 01 32 01 80 01 00 00 89 03 98 FC
77 FC 00 00 12 FE 00 00 7D 00 58 FD 06 FB 00 00
D2 FD 00 00 2C 01 00 00


Relative offsets (from the beginning of Model Settings Data) to animation scripts:

Code: [Select]
90 01 00 00
94 01 00 00
9C 01 00 00
A0 01 00 00
B0 01 00 00
C0 01 00 00
C4 01 00 00
CC 01 00 00
D0 01 00 00
D4 01 00 00
E4 01 00 00
E8 01 00 00
EC 01 00 00
F0 01 00 00
F4 01 00 00
00 02 00 00
FC 01 00 00
10 02 00 00
04 02 00 00
98 01 00 00
6C 02 00 00
88 02 00 00
6C 03 00 00
84 03 00 00
10 03 00 00
24 03 00 00
30 03 00 00
3C 03 00 00
4C 03 00 00
10 02 00 00
20 02 00 00
30 02 00 00
44 02 00 00
58 02 00 00
94 02 00 00
94 02 00 00
6C 02 00 00
88 02 00 00
B4 02 00 00
C4 02 00 00
D4 02 00 00
D4 02 00 00
EC 02 00 00
EC 02 00 00
04 03 00 00
04 03 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
90 01 00 00
9C 03 00 00
B4 03 00 00
C0 03 00 00
CC 03 00 00
D8 03 00 00
E4 03 00 00
F0 03 00 00
00 04 00 00
04 04 00 00
FC 03 00 00
90 01 00 00
94 03 00 00
90 01 00 00
90 01 00 00


Animation scripts:

Code: [Select]
-00 FE C0 00
-01 FE C0 00
-10 FE C0 00
-06 F1 00 00
-B3 F9 03 ED E3 EE B2 F9 03 B1 03 B1 E3 EE 00 00
-B3 F9 04 E4 E3 EE B2 F9 04 B0 04 B0 E3 EE 00 00
-0F F2 E5 EE
-10 11 F2 E5 EE 00 00 00
-12 F2 E5 EE
-05 E5 EE 00
-AB 90 01 00 00 08 F4 0F F3 FA E5 A6 EE 00 00 00
-13 E5 EE 00
-18 19 E5 EE
-B4 02 F1 00
-95 07 FE C0
-C4 90 01 06 07 FE C0 00
-04 FA E5 EE
-E7 00 F1 00
-E5 C4 90 01 06 12 E7 00 F1 00 00 00
-E8 FC 03 ED E6 EA 0C 0D EC 0E 04 FA E5 EE 00 00
-E8 FC 03 ED A4 EA 0C 0D EC 0E 04 FA E5 EE 00 00
-E8 FC 03 ED A5 EA 0C 0D EC F4 0F F3 0E 04 FA E5 EE 00 00 00
-E8 FC 03 ED D8 06 15 00 09 EA EB F4 0A F3 04 FA E5 EE 00 00
-E8 FC 03 ED D8 06 15 00 0A EA EB F4 0A F3 04 FA E5 EE 00 00
-FC F0 D8 00 1A 00 1A D1 2C 01 00 00 06 F0 1B BE 02 BE 08 C2 08 1E 1C FA F0 1D E5 EE
-FC 03 ED F7 12 22 04 FA E5 EE 00 00
-FC F0 D8 00 1A 00 1A D1 2C 01 00 00 06 F0 1B F7 04 D8 04 D6 02 16 F4 06 F3 1C FA F0 1D E5 EE 00
-E8 FC 03 ED F7 12 14 F4 3C F3 04 FA E5 EE 00 00
-E8 FC 03 ED F7 12 14 F4 5A F3 04 FA E5 EE 00 00
-FC F0 D8 00 1A 00 1A D1 2C 01 00 00 06 F0 1B F7 04 17 1C FA F0 1D E5 EE
-FC F0 D8 00 1A 00 1A D1 2C 01 00 00 06 F0 1B F7 08 1F 1C FA F0 1D E5 EE
-FC 03 ED 15 F7 01 04 FA E5 EE 00 00
-FC F0 D8 00 1A 00 1A D1 2C 01 00 00 04 F0 1B F7 02 1E 9E 00
-E5 BD 2C 01 00 00 F0 F7 06 20 9E 00
-E5 BD 2C 01 00 00 F0 F7 08 21 9E 00
-E5 BD 2C 01 00 00 F0 F7 02 1E 1C FA F0 1D E5 EE
-FC F0 D8 00 1A 00 1A CC 06 CB FF E8 03 FE FE 00 08 08 F0 1B 1E F7 03 F4 06 F3 1C FA F0 1D E5 EE
-FC F0 D8 00 1A 00 1A D1 2C 01 00 00 04 F0 1B BE 02 BE 08 C2 08 1E 9E 00
-BE 02 BE 08 C2 08 20 1C FA F0 1D E5 EE 00 00 00
-FA F0 1D E5 EE 00 00 00
-E8 FC 00 E0 EA F4 19 F3 EC 1A D1 2C 01 00 00 06 F0 1B 9D 00 2C 9E 00 00
-EA E5 BD 2C 01 00 00 F0 9D 01 2D 9E
-EA E5 BD 2C 01 00 00 F0 9D 02 2E 9E
-EA E5 BD 2C 01 00 00 F0 9D 03 2F 9E
-EA E5 BD 2C 01 00 00 F0 9D 04 30 9E
-EA E5 BD 2C 01 00 00 F0 9D 05 31 9E
-EA E5 BD 2C 01 00 00 F0 9D 06 32 9E
-00 00 00 00
-00 00 00 00
-00 00 00 00

34
So I put my mind to it yesterday and I found out quite a bit about those elusive **ab files in the battle.lgp archive (I don't know the PSX equivalent).

The PSX equivalent is the actual battle model (*.LZS) file section named Model Settings Data by Akari (a nomenclature I carried over into my battle model breakdowns on the forums and wiki).

I didn't get a chance to dig around at all last night, but I'll try to make time to do so tonight. This will certainly make custom battle models with proper animations much easier to create. Glad I could nudge you into uncovering a crucial part of the battle module :)

35
[...] the opcodes range from 8E - FE and their functions are defined at 0x4248C2 and are called from 0x41FDDB. More coming later...

Are these offsets in the PC version executable? Or the PSX ELF (SxxS file)? Or something else?


If you wanted to 'swap' things like that you would likely need to expand the indexes and number of animations in the file. For reference I would recomend going from cloud to aireth tifa or cid. As these all have similiar animation.  It should include the victory animation also. You likely can find that when the battle ends normally. Prod Clod I remember being helpful as it abused each character (heh). Erstwhile I'm sure you can figure it out faster than I can. Apart from playing each animation after decoding the data in Q-gears on the character in battle I'm not sure what else you could do.  That is once nice thing, about Q-gears as it can let you do just what I suggested as you have complete control via LUA scripting to do just that.

Granted it's an incredibly boring way to do it ... but that's just me. I believe the battle results are also scripted as part of the battles.  You may wish to examine that for your plans. Although it might be more or less work with a tool you are potentially unfamiliar with. If so hopefully you have a better route.

Cyb

Actually, I've already made functional custom models; I'm just handling a few annoying animation transitions. For example, as NFITC1 mentioned above, some actions call a series of animations, in sequence (jump forward, throw an item, jump back, for example). If I want to replace these three actions with a relevant animation for the new custom character, and I only want to use a single animation rather than three, I'll need to change the index NFITC1 pointed me to earlier in this thread. Otherwise, I'll have to try to fill two of the three animations with animations that flow smoothly with the animation I really want to use, which is quite difficult, if not impossible in most cases. The character still functions, but looks glitchy during certain animation sequences.

36
Interesting.

I've broken down the ENEMY338 (Goblin)'s Model Settings Data as an example:

Model Settings Section [at offset 0x00005A2C]:


Unknown:

Code: [Select]
00 00 00 00 5E 01 78 05 78 05 C4 FF C8 00 D0 FD
54 FC 02 00 00 00 00 00 1D 18 02 00 05 13 0E 00
00 00 00 00 94 01 00 00 98 01 00 00 9C 01 00 00
A0 01 00 00 A4 01 00 00 A8 01 00 00 AC 01 00 00
B0 01 00 00 19 01 19 01 19 01 00 00 C0 0B B9 FD
8E 05 00 00 90 FF 00 00 63 FD 39 FE 9D 08 00 00
70 FF 00 00 2C 01 00 00


Relative offsets (from the beginning of Model Settings Data) to animation scripts:

Code: [Select]
E8 00 00 00
EC 00 00 00
F0 00 00 00
F4 00 00 00
08 01 00 00
1C 01 00 00
2C 01 00 00
30 01 00 00
34 01 00 00
38 01 00 00
3C 01 00 00
44 01 00 00
50 01 00 00
5C 01 00 00
64 01 00 00
6C 01 00 00
74 01 00 00
7C 01 00 00
84 01 00 00
8C 01 00 00
40 01 00 00
4C 01 00 00
58 01 00 00
60 01 00 00
68 01 00 00
70 01 00 00
78 01 00 00
80 01 00 00
88 01 00 00
90 01 00 00
48 01 00 00
54 01 00 00


Animation scripts:

Code: [Select]
-A9 C9 00 C1
-01 F6 E5 EE
-0E E5 EE 00
-FC F0 02 D1 4C 04 00 00 08 F0 F7 08 03 04 FA F0 05 E5 EE 00
-E8 FC EA F0 06 D1 F4 01 00 00 08 F0 07 EC 08 FA F0 09 E5 EE
-E8 B6 00 AA FC EA 0A C9 0B CA 0C EC 0D E5 EE 0A
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00
-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Note: The last referenced offset above is 0190, but the size of that script, whether four bytes, two bytes, eight bytes, or larger, isn’t apparent. Whatever’s left over after that script, if anything, is likely filler (as is that script itself, and those “empty” ones preceding it).

It's interesting that the remaining data after 0x11C-0x12B is just padding utilizing zeroes, rather than "null" animation scripts via a null command or something similar. Also, 0x11C ends with EE 0A, and unless there's another "end script" command we haven't stumbled upon yet, this doesn't seem to be a valid script followed by a dummied script or something.


Edit: Looking back at my "Unknown" section:

Code: [Select]
00 00 00 00 5E 01 78 05 78 05 C4 FF C8 00 D0 FD
54 FC 02 00 00 00 00 00 1D 18 02 00 05 13 0E 00
00 00 00 00 94 01 00 00 98 01 00 00 9C 01 00 00
A0 01 00 00 A4 01 00 00 A8 01 00 00 AC 01 00 00
B0 01 00 00 19 01 19 01 19 01 00 00 C0 0B B9 FD
8E 05 00 00 90 FF 00 00 63 FD 39 FE 9D 08 00 00
70 FF 00 00 2C 01 00 00

...it becomes apparent that my "missing" references to four-byte zeroed-out animation scripts after 0x190 are sitting right in the middle of that section:

Quote
00 00 00 00 5E 01 78 05 78 05 C4 FF C8 00 D0 FD
54 FC 02 00 00 00 00 00 1D 18 02 00 05 13 0E 00
00 00 00 00 94 01 00 00 98 01 00 00 9C 01 00 00
A0 01 00 00 A4 01 00 00 A8 01 00 00 AC 01 00 00
B0 01 00 00
19 01 19 01 19 01 00 00 C0 0B B9 FD
8E 05 00 00 90 FF 00 00 63 FD 39 FE 9D 08 00 00
70 FF 00 00 2C 01 00 00

0x1B0 references the last four bytes of the Model Settings Data section of the LZS. As for the bold offsets above, I've no clue what the data before and after them references.

37
Ah.

Still, 1A0 has more than one EE command:

b3 f9 03 ed e3 ee b2 f9 03 b1 03 b1 e3 ee 00 00

38
2E0 looks like an unlinked script.

Is it possible that it's simply part of 2C8? Or, have you worked out more of the format than you've specified above?

39
It's interesting to note that the section you refer to as:

Code: [Select]
Related to Camera Scripts? File size; Not stored elsewhere
38 04 00 00
38 04 00 00
38 04 00 00
38 04 00 00
38 04 00 00
38 04 00 00
38 04 00 00
38 04 00 00

...effectively points to the first byte after this Model Settings Data (the first byte of the first actual animation data). This is the animation for doing "nothing" (standing/bouncing around while awaiting the next turn or attack from an enemy).

Edit: This may be of no importance, since as you mention, this is also the "file" size of this data, irrespective of what's "next" in the model data.

40
Ack, I just saw that in your data above. It's really:

Code: [Select]
E8 FC 03 ED D8 06 15 00 09 EA EB F4 0A F3 04 FA E5 EE 00 00

Though that doesn't matter from a reverse-engineering standpoint (it doesn't do anything), it's critical from a reconstruction standpoint (if it's excluded, the result won't work).

41
Also, two things:

1. Nitpicking, but the script you referenced is specifically "Using an item on yourself/your teammates"; using an item on an enemy, even if it's a Potion, is slightly different in that the item is thrown forward rather than up, hence it will have its own separate script.

2. Glancing at adjacent data, I think the preceding two bytes of zeroes (at least, in the LZS for PSX...though I doubt it's different on PC) are part of the script, hence what you posted above should be:

Code: [Select]
00 00 E8 FC 03 ED D8 06 15 00 09 EA EB F4 0A F3 04 FA E5 EE

42
I did change that highlighted 03 to a 09 and Cloud did the throw animation twice. After the first throw he teleported forward from where he was to the position on the battle field where he WOULD have ended up if he had hopped forward. The actual action happened after the second throw. I've got his whole file parsed into scripts, pointers, and where the data ends up. I just don't know what much of it does.

Cool; sounds like a hack-job waiting to be done (and I'm just the one to break everything systematically and identify what does what) :)  To save me some time, any chance you could share that data?

43
The animation indexes to use are hard-coded in the exe. Give it command 13 and it will do animation 2D (or something like that). I made a table a long time ago and posted it here (I think), but I'm not searching through nearly 2000 messages to find it right now.

You'd have to change this for each command, but that'd screw up all the other characters as well.

EDIT:
OK, not quite. Aali's got the closest answer to this. I do have a list of commands with scripts to play, but the animations are in chunks that the game will determine which to play for how long before doing the next one.

Ex.
The Item command initiates animation script 21h. This does at least three things: 1. Hop forward (animation 3) 2. Throw the item upward (animation 9) 3. Hop back to starting position (animation 4).

Here's how Cloud's animation script 21h looks like:

Those are the animations he takes  at certain times. The 03 is the hop forward, the 09 is the throw item, the 04 is the hop back.

Awesome; that's exactly what I was looking for. As I half-guessed above, that data is within what Akari called Model Settings Data, within the LZS model file itself. I'll do some testing later. Thanks :)

44
You misunderstand...I'm fully acquainted with the model format; I'm the one that wrote the breakdowns on the wiki page you linked to :)

I know where the individual animations are. I want to know where it is delineated as to which action corresponds to which animation. As in the example I made above, when the player tells Playable Character 1 to Steal, Character 1's animation 2B initiates. If the player tells Playable Character 2 to Steal, Character 2's animation 3A initiates.

Proud Clod seems to have the ability to affect the animation index of the various enemies ("If enemy does BrainBlast, do animation 09", etc). But I haven't seen any reference to doing the same with playable characters.

The end result would be the following: if I replace Barret with Zemzelett (which I'm not really going to do, in case you were wondering), I'll need to migrate Zemzelett's animations in place of Barret's (I can't simply swap files, as Model Settings Data is different between playable characters and enemies, and texture data is in the wrong place...not to mention weapon bone data being limited in enemies, etc). When the player tells Barret to throw a potion, the game somehow decides what animation to use for this. This does not appear to be contained in the model file itself. Thus if Zemzelett only has 0x2A animations, and Barret's "item use" animation is animation 0x3C, I can't simply replace Barret's animations en mass - I'll need to not only keep the total number of animations the same, but I'll also have to match up which animations I'd like to be performed for which actions, by fully mapping all animations and their actions. However, if I could modify the animation index itself (what animation each action calls), I could re-map the entire index to only utilize the 0x2A animations, and point each action to the corresponding animation with ease.

Point in fact, however, I'm not really familiar with the fine details of what Akari called Model Settings Data in his reversing work for QGears (and what I've continued to call that same name for consistency). If somewhere therein lies the animation index, please do point it out. Simply swapping the Model Settings data, even if animations are also swapped, results in a crash.

45
Whilst making custom playable characters, I'm faced with the hassle of battle animations. The animations themselves, in this case at least, are not the problem (I'm harvesting them in entirety from other models). The problem is that if I replace an existing playable character's battle model with a custom model that has unique bones, parts, and animations, the original character's animation index (for lack of a better term) still says, "When Steal is initiated, play animation 4B".

A simple, if crude, workaround for this is to identify every animation for the original model, identify every animation for the custom model, then swap the correct animations, leaving the total number of animations intact since the original model, and using a null value (30 1A 00 00) for everything that won't be used.

This works to an extent, but when the original character performs several animations for a particular action and the custom character will only perform one (or less than the original, in any case), I'm forced to jam several animations together and try to still make it look fluid and natural. Moreover, if I intend to use the same animation for more than one action (and the original character didn't also use only one animation for these exact actions), I must duplicate it entirely within the model, wasting space and cluttering the file needlessly.

I've no clue where this data is stored (KERNEL.BIN?), but does anyone have a clue as to where each action of each playable character is assigned an animation number?

46
I remember once joining game hacking ... I think I was working on CC codes that didn't have to do with cheating (LOL). :D I know I'm odd (that's what people tell me anyhow).

:) The best codes are unrelated to cheating (unlocking hidden/disabled features, hijacking other models/sprites, making yourself a giant...the same sorts of things modders love to do, but with RAM).

47
FF7 Tools / Re: [1.5.1] Makou Reactor - a FF7 field editor
« on: 2013-04-12 19:57:24 »
genesis063: He's talking to myst6re.

48
Well, I made a GameShark code that should allow you to print the value of X, Y, Z, or T in place of your current Gil, but it's a bit unwieldy, and about halfway through, I decided I would only finish it because I'd already gone to the trouble of starting it, heh. Here:

L1 - X, L2 - Y, R1 - Z, R2 - T

8009D264 0000

C009AC5C 0004
C2074F34 0004
8009D260 0000

C009AC5C 0001
C2074F38 0004
8009D260 0000

C009AC5C 0008
C2074F3C 0004
8009D260 0000

C009AC5C 0002
C2074F9A 0002
8009D260 0000

Values will be displayed in decimal, so you'll have to convert to hex, then convert from little endian to big endian. If preferred, you could always eliminate the step of endian-ness conversion by replacing the 4, 4, 4, and 2-byte Copy Bytes codes with 16 individual 1-byte Copy Bytes codes, arranged in the right order.

Two immediate problems (aside from the ridiculous hassle this would be to use in the first place) are that some values are so large they run into the word "Gil" and become unreadable, and some emulators don't seem to support the C0 and C2 code types properly.

If you'd rather just keep track of a single variable (X, or Y, or whatever) at a time, simply do something like:

C2074F34 0004
8009D260 0000

...which will force your gil to always reflect your X coordinate.

Using gil as a storage point is just what I came up with on the spot. Anything else would do, as long as there's an easy way to convert it to hex (so, Time would be a bad choice).

At this point, it looks like it would be easier for PSX modders to just use an emulator with a live debugger, (pSX, for example), and just monitor the addresses I mentioned a few posts earlier for their values at a given spot.

49
Heh, actually, I've corrected myself above. I guess it's been a long day, and my brain isn't processing data as accurately as usual :)

50
OK, found the corresponding addresses for the PSX version.

X: 0x80074F34 (4 bytes)
Y: 0x80074F38 (4 bytes)
Z: 0x80074F3C (4 bytes)
T: 0x80074F9A (2 bytes)

Perhaps those will be useful to someone (they'll certainly be useful to me). I'll play around with creating a button-activated code to copy the value of each in turn to something raw and numerical, such as gil, for those who don't feel like looking around in memory all the time.

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