Messages

76

Scripting and Reverse Engineering / Re: Need help finding tab spacing data.

« on: 2011-05-30 15:11:33 »

Ok, so:

Code: [Select]

0011fae9 + 0x400C00 = 0x5206E9
00231127 + 0x400C00 = 0x631D27The second address is the spacing for E0 we already know, and the first one holds this line:

Code: [Select]

005206E7  |.  83F8 0A       |CMP EAX,0A                              ; // 0x50No doubt, that loop executes 10 times, but there is a comparison before the loop - something is compared with 0x50. How did you connect it to E0?

As for the cursor - the second address fits with the worldmap part of the ff7.exe (before the chocobo stuff) - you might want to check that.

77

Scripting and Reverse Engineering / Re: Need help finding tab spacing data.

« on: 2011-05-28 14:59:40 »

Can't be sure, because I can't run FF7, but it should be:
Here for E0:

Code: [Select]

00631CF4  />  0FBF55 08     MOVSX EDX,WORD PTR SS:[EBP+8]            ; // E0
(…)
00631D25  |.  83F8 0A       |CMP EAX,0AAnd here for E1:

Code: [Select]

00631C5A  />  0FBF45 08     MOVSX EAX,WORD PTR SS:[EBP+8]            ; // E1
(…)
00631C8B  |.  83F9 04       |CMP ECX,4

78

Scripting and Reverse Engineering / Re: FF7 in-battle RNG (algorithm) ?

« on: 2011-05-03 07:35:13 »

Yeah, just shooting in dark - even if it's first being read from, then written into, it might do that multiple times in each frame, and that would be often.

79

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-05-03 07:27:30 »

You seem to have removed some content, so no quotes for those parts.

I highly doubt it.

Oh, but I do! I'm sorry for thinking that you can actually be smarter than a debugger. The "fancy operator" I used is being taught in one of the firsts classes of C (in case of bit logic and/or operator precedence, whichever comes first). From now on, I'll be sure to double-check if the provided data is in way you'd understand.

And about .NET (C# in your case) not having anything to do with spoiling people (can't quote you now) - it does. Microsoft had made a very successful attempt to provide people with a programming language where everything* can be done with a few lines of code. It spoils people in a way that they EXPECT that everything they need is out there, somewhere (in a C# and VB.NET version).

*everything - everything that they've thought you'd need

And, as far as I know the CPU just executes the code, the compiler makes all the optimizations, not the CPU. So it doesn't look like that, ever, except in your little delusional mind.

Right about the first sentence. Let's see what we've established: CPU doesn't do optimization, just executes the code.

If it looked like that anywhere, it would show up in IDA\Debugger, it doesn't.

IDA doesn't do that elsewhere, there are plenty of places where the code uses bit shifting, but you're right, just for this one function, it decided to change the code to be easier to read. 

Second one (after removing the sarcasm): IDA will not make any attempt at providing user with more-friendly data.

Now let's produce some code with that famous opcode part. To the right you'd see a disassembled line, and to the left - actual machine code.

Code: [Select]

FF140D A0559000        CALL DWORD PTR DS:[ECX+9055A0]
FF144D A0559000        CALL DWORD PTR DS:[ECX*2+9055A0]
FF148D A0559000        CALL DWORD PTR DS:[ECX*4+9055A0]
FF14CD A0559000        CALL DWORD PTR DS:[ECX*8+9055A0]The only byte that changes is the 3rd one (0x0D -> 0x4D -> 0x8D -> 0xCD). In binary:

00001101
01001101
10001101
11001101

You'd expect it to be 1, 2, 4 & 8, but that's actually 0, 1, 2 (SHL 2 equals *4 ) and 3 (SHL 3 equals *8 ), so it actually does a bit-shift. So, "just for this one function, it decided to change the code to be easier to read"? No way! (disclaimer: not saying that's bad).

(And how do you think IDA get's the code, it executes it, and reads what happened on the stack\registers, that's what it saw occur, so that's how the machine code really looks.)

LoL No, Mister Ignorant It interprets it, at it's best, parse maybe, but sure as hell does not execute it. That would be a big security hole if it just "oh, lets run it and see what it does, yay!". Machine code is the hex codes you see next to each disassembled line

I don't appreciate being confronted over bullsh*t, especially when it was your own mistake that caused the issue to begin with. Had you explained yourself clearly, in a straightforward manner, I would have used your info, you didn't, so I didn't, end of f*cking story.

---

Even if it does that at some low level, I've mentioned that bit shifting isn't something I understand well. What I asked for was accurate info, not math lessons. I'll figure that out on my own time, as it becomes necessary. So your excuse for doing so, ie, helping me out, is BS.

Regardless, everyone else managed to give me info that lined up with the debugger\disassembler, you didn't. That's why I used their info, and not yours.

In short:
The only mistake I did was assuming that you actually did understand the "thing" (no, it wasn't me who started explaning it to you) - I was giving you info in a manner I thought that you'd surely understand now. I stand corrected.

80

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-05-02 22:31:51 »

Right. Sorry for that.

81

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-05-02 22:23:10 »

That's what your debugger showed you.

It looks like this in my debugger..

Call Near DWORD PTR [EAX*4+9055A0]

Your debugger sucks, it's a structure, this is how structures are used in ASM.

You don't pay attention - I was talking about machine code - debugger is just nice and shows it as *4 (mine does too). And it's not a structure. At it's best you could call it an array.

//---

PS: It's not an array, it's a structure, learn the difference. It's C code, not C++, the port was done in C++, not this, it's the original C code. (Only the graphics, etc, are using C++, ie port specific code.)

Didn't pay attention one more time - I actually said "FF7 (for PC)". Doesn't matter anyway, bit-shifts are not C++ - specific.

And as for the scruct thing - prove it. Write a C listing (a simple one) that would compile into such code - then we'll talk.

82

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-05-02 22:09:29 »

Ok, so from the top:

When did I say that?

Here.

I asked for help in my very first post, and I accepted help, and integrated values NFITC1 told me about. But I also said I would decode what I have to.

I will discover things on my own if I have to, but I'd rather not do work, that's already been done.

As for why I would go ahead and do it on my own, that's because I'm working on a project, I want to accomplish my goals, not sit around and wait for answers that might come.

Nothing wrong with doing things on your own. That's for sure.

Your answer was wrong (...)

No it wasn't.

(...) maybe shift right 2 equals 4

... shift left, but yes, it does equal *4. Of course it does.

(...) but why tell me answers in a format the game doesn't use?

FF7 (for PC) was written in C++, and "<<" is a C/C++ operator explicitly convertable to SAL/SHL, also...

The game explicitly says eax * 4, not << 2...

No it doesn't. That's what your debugger/disassembler shows to you. The machine code actually says 0x9055A0 + EAX SHL 2. That's how the CPU will compute it.

That's why I didn't use your info, it didn't match up with anything I was seeing. (And since we're bringing up 2 pages ago, you KNEW I had trouble understanding bit shifts, so intentionally change a simple multiplication formula to use a bit shift?)

YES. That's exactly what I did - I intentionally used a bit shift operator. But if I didn't - you'd still get an answer with an array of function pointers.

So try being less fancy, and being more correct, and someone might trust your data.

I stand correct. And << is actually pretty important operator.

I'm not your enemy, just wanted to make sure that you understood the shifting thing. In the source code, it looked something like this:

Code: [Select]

...
fieldOpcodesPointer[scriptOpcode](args)
...Still, no *4 in here - that's because compiler is smart enough to know that a function pointer in a 32bit app is 32bit long, so the whole array has a 4-byte alignment. Multiplications are actually pretty slow - in oppose to bit-shifts. That's also a reason why you'd see some unreferenced 1-byte field between other, larger structs  - the alignment is important and the game speeds up when the addresses are 4-byte divisable and the CPU can do just "address + eax << 2".

//---

I understood the bit shift with AddItems, because the game uses that formula, I could see it, and knew what you were talking about. (ie, It didn't require me to go out and learn binary to decode your answer. Decoding the game is enough work, I don't need\want to decode your answers as well, so I ignore anything you say that doesn't match up with the actual code.)

That's why I hate .NET/Java. It spoils people.

83

Scripting and Reverse Engineering / Re: FF7 in-battle RNG (algorithm) ?

« on: 2011-05-02 20:56:42 »

If by freezing you mean using some external program to write into those locations constantly - maybe FF7 is quicker than that (sometimes)?

84

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-05-02 20:52:59 »

I just figured out how to find the opcodes, you basically, take an opcode.

MPu\IncreaseMP = 0x45
Opcode Structure = 0x009055A0

(0x45 x 4) + 0x009055A0 = 0x009056B4 [MPu\IncreaseMP]

(...)

That 0x9055A0 (argh... address that's been burned into my memory...) is a base for all Script Op handlers. When a game gets an Opcode, it calculates the offset where a pointer to that function is stored (in a fashion: 0x9055A0 + Opcode << 2), and just calls it.

2 pages back. You're saying that you don't want to discover things on your own if it's already decoded, and asking for people to step in and share, and then you just do it on your own anyway? Why bother asking...

85

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-04-29 15:55:02 »

One tip - character records are 132bytes (0x84) long in the savemap - check if it's actually a savemap you're looking at (IIRC, savemap address for FF7 Save begins with 0x00DBxxxx, but don't remember the exact number). Savemap is the best place to modify data.

86

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-04-26 16:08:36 »

That 0x9055A0 (argh... address that's been burned into my memory...) is a base for all Script Op handlers. When a game gets an Opcode, it calculates the offset where a pointer to that function is stored (in a fashion: 0x9055A0 + Opcode << 2), and just calls it.

To find other stuff - get a debugger that helps you find references to a static memory address - it will save you a lot of time. For example, Exp is stored for each character, but if you search for a function that modifies it, you'll see something like 0xDB0000 + x * 0x84 - only Cloud's Exp is referenced, because Barret's can be calculated as an address that is 0x84 bytes higher than Cloud's Exp. If you then search for that specific const, you'll get EVERY SINGLE point in ff7.exe where it's accessed. Leave out all the reading accessors, and you'll end up with a short list of points where it's actually being written to.

Also, most global structures are referenced like that (so with the above method you can check all the subfields for writing). There are usually some unique values connected to each meaningful record, so debugging is really easy - even if the record is passed as a reference, it's structure remains intact (of course), and if the subfield was named szCharacterName, you'll get to know it as 0x234 and a single reference search for that const will get you a list of addresses where it's being accessed. Sometimes it's a mixed mode (so a subfield is referenced by global address and by subaddress somewhere else, but there aren't many cases like that).

Also, it helps how the FF7 was actually built - with absolute minimum optimization.

87

Scripting and Reverse Engineering / Re: FF7 Field Messages

« on: 2011-04-25 19:26:30 »

No biggie It's your time, and I was out anyways

88

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-04-25 19:24:59 »

Just some extra info:
STITM
CKITM
Functions are already there, so all that is left is to use them

Reading through the Field Script Opcodes is a good idea. Reading through them while checking the disassembly is a great way to expand your knowledge about inner workings of FF7. It'll take a big amount of time, but it's worth it (and you'll admit it only after you've done it ).

And to be a technical purist - inventory does not work like a stack! You can clear/replace items in the middle of it, so it's basically a random-access array (or just "an array").

89

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-04-24 13:16:11 »

You've read the value from different index, so you've mixed it up

If that function is backed up with a save-map then it's an array. Empty line is a 0xFFFF, it shows up in order you see it in-game. Just calculate counts for first 10 items and see where they are in-game.

90

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-04-24 13:01:22 »

65535 (or 0xFFFF) is a slot-empty indicator, so you've most likely mixed the indexes.

91

Scripting and Reverse Engineering / Re: FF7 Field Messages

« on: 2011-04-24 10:48:27 »

Hi Aali

I've been checking these boards from time to time, mostly unlogged, just to see what's going on (btw. gratz on your Graphics driver ), but never actually felt the urge to post anything back. Now that the FF7 VoiceOverProject has been revived (again), I'm back, just to show that I'm on (the) board.

No time to do anything new, though... Wish I had... Saw few interesting ideas that could easily be done, but... No time for new things...

92

Gameplay / Re: [WIP] Custom Game Settings (FF7)

« on: 2011-04-24 08:50:43 »

Edit: Can you explain what this formula means?

Code: [Select]

((Count << 9) + Item Index)


<< is the SHL you've been asking about somewhere on the board. So... Having an item record, to get the actual count, you do a SHR (by 9 bits) and that means dividing by 512.

So a 0x0601 (1537 in decimal and 0000011000000001 in binary) means (/ is an integer-division, % is the modulus)
 - 1537 / 512 = 3 - actual count
 - 1537 % 512 = 1 - item id (might be a potion, don't remember)

A quicker way - you get the higher byte (in our example - 0x06) and divide it be 2, discarding the remainder. 6 / 2= 3.

dziugo

93

Scripting and Reverse Engineering / Re: FF7 Field Messages

« on: 2011-04-24 08:09:18 »

Hi,

The 0x40 (MESSAGE) Opcode (info here) displays a message Y (in your case 34) in window X (in your case - 0). Window is created with 0x50 (WINDOW) Opcode (info here).

The messages are held in script file (info here) - more precisely, in it's dialog subsection. Each script file corresponds to one location in game (in your example it's elmtow - Kalm "town"). Every time a location changes, new script file is loaded into memory and provides a look-up table for the messages - so all you have to do is to request a dialog with specific ID and point to a (previously created) window and it will show-up. As simple as that.

To create custom messages on-the-fly (without modifying field.lgp), you can:
 - Possess an unused Message-Id and use it to feed any text data to a requested window (all you have to do is to redirect one ID in the look-up function to a memory address of your choice).
 - Copy the 0x40 function and only patch the lookup call (so it actually returns your pointer) - you'll have your own function, independant of the original one.
 - Make a distinction on the higher byte of Window-Id or Message-Id. Game only uses 8 lower bits, but it's still pushing to stack 16-bit or even 32-bit values (years have passed since I looked at it, but it's 32-bit executable, so we can safely assume that pushing 8-bit values to stack is not actually a case here). So, use a standard 0x40 function, but feed it with values like 0x102 as Message-Id - patch the lookup function to make a distinction between 0x00-0xFF Messages and 0x100-0xFFFF Messages - in the first case, work as always - in the second case, return a Message from YOUR lookup table.

dziugo

94

Troubleshooting / Re: question about cetra patches

« on: 2010-01-01 10:51:17 »

IIRC Cetra modifies the main executable, so once the patching is done, you won't have to run it again. I'd use Aali's Custom graphics driver though.

my question is if i have it set to windowed mode, will it ALWAYS be in windowed mode or is there a way to make sure it doesn't if i don't want it too

Yes, once the patching is done, it will always run in windowed mode.

95

FF7 Tools / Re: Yet Another Multi-Patcher

« on: 2009-12-30 07:02:47 »

Yeah, a toggle is possible, but the core of the patch must be done correctly (and tested thoroughly) first. The "always-run-mode" would have to be disabled before certain events otherwise, and if it's to done manually, it would still be annoying. Thanks for the idea though!

96

Completely Unrelated / Re: What created these?

« on: 2009-12-26 23:03:41 »

You're welcome

97

Completely Unrelated / Re: What created these?

« on: 2009-12-26 10:14:16 »

That's diablo2oo2's Universal Patcher (a.k.a. dUP).

98

Troubleshooting / Re: question about cetra patches

« on: 2009-12-17 11:16:31 »

IIRC Cetra modifies the main executable, so once the patching is done, you won't have to run it again. I'd use Aali's Custom graphics driver though.

99

Completely Unrelated / Re: Thank You!

« on: 2009-12-04 06:32:32 »

   I just want to thank this community for all the things they have work you guys done for FF7 and even thou its your hobby for you to do such I still feel very grateful to you or making my game better. Have a nice holiday.

Special Thanks to  Aali,ice cold315,Borde,My favorite moderator Halkin and of course Qhimm.

I'm sure Halkin would be pleased

100

Completely Unrelated / Re: I have always wondered...

« on: 2009-08-11 19:18:08 »

YES! How many internets do I win?

Oh! Oh! I knew it too! How many do I win? Wasn't first? Damn...

It sounds a lot like an English "j" to me...

English 'j' would be polish dż (hard dz / [dʐ]). The difference might be very subtle for non-polish speaker. Damn, it's even hardly distinguishable in writing.