Info about the field scripting language goes here.

[Cyberman]

I see. Sorry for the trouble.

I don't think you'll be lynched for it Lasyan, it was an honest mistake.

Ok field.bin has the opcode names, odd that hmmm I have to finish a paying project before I start work on recoding TV, so I am thinking things through at least (heh me think things through that's an interesting statement).

So much to do and so little time. Mumble.

Cyb

[Qhimm]

I figured it was time for a small update, so...

I've been working mostly on mapping out the arguments for individual commands (which is proving a bit complicated for some commands like the REQ family). I've also spent some time on my soon-to-be script viewer and trying to transform the simple assembly-like commands into more readable code (particularly conditional jumps).

http://www.qhimm.com/script.gif

Still quite a way to go, but I'm getting there. In the mean time, I'm documenting the commands as best as I can in C++ header files, like this:

Code: [Select]

// Random() is actually not very random at all, it merely consists of
// picking values from a 256-byte array containing all values between
// 0 and 255 in shuffled order.
BEGIN_COMMAND(0x99, RANDOM, 3)
COMMAND_NAME("Random")
SPECIAL_SYNTAX(Arg(1) + " = Random()")
DESCRIPTION("Sets the operand to a random value between 0 and 255. Operates on unsigned bytes only.")
BEGIN_ARGUMENTS()
    REFERENCE_UByte(op1, ONE|2)
END_ARGUMENTS()
END_COMMAND()
The above code is directly used by the script viewer as its source of information on script commands, as well as being decently human-readable. For example, the first line designates the op-code, name and length of the command, the other lines specify a special user-friendly syntax used in the script viewer, a description, and informs us that the function takes one argument, a non-constant variable, with the bank/type specifier stored in argument nibble 1 and the bank offset in argument byte 2. Easy as pie?

[halkun]

Ah, no wonder I was having a hard time with REQ family. That looks absolutly wonderful though.

I wonder, should we set varible names for known vars in the savemap? We can probably have that as an external file that can be edited by the user.

JUMPMAPs should also be mapped to what field file they call. I bet the look up table is in field.bin. (That is, if the PC version has one). I'm going to do a quick compare just to see if the bin files are the same.

I've been procrastonating on the kernel section of Gears. It kinda sucks when you make a breakthrough on a file format, only to open it up and find about 27 file formats inside. I really got stalled out menu and on window.bin, and that was just TIM files. I was hoping that kernel.bin would hold tim files. Boy was I wrong. That's the item/spell/materia resource for the game. Even though it's cool I found it, if forces me to stay in Kernel a little longer than I'd like.

[sfx1999]

I'm guessing we will never see a Linux port of that. You know what happened last time I tried to compile your code with GCC... (I use MinGW, BTW)

[Qhimm]

I've anticipated the need for named variables as well, support is already built into the viewer, so that "<1>[00]" might be displayed as "plotProgression" or similar. The only thing I've been wondering is how they should be displayed in the viewer, as simply text, or with some special syntax, like "<plotProgression>", or "(plotProgression" had it been of byte size... Oh yeah, this is how I mark up unnamed variables right now:

Byte-sized variable in bank n: (n)[offset]
Word-sized variable in bank n: <n>[offset]
Byte-sized temporary variable: ()[offset]
Word-sized temporary variable: <>[offset]

Does this system work? I'd appreciate comments and suggestions to make it more readable and intuitive...

And no, no Linux port by yours truly at least, but the actual script parser should be reasonably portable; only the display classes/functions will have to be rewritten.

[halkun]

These is a difference between making it intuitive and readable as opposed to what *we* are used to.

What the matter with changing this...

Code: [Select]


06D9   if ()[06] == 01 { //06E0
06DF   return
06E0   }
06E0   if ()[06] == 02 {//06F7


into this

Code: [Select]


06D9   if TempVarByte[06] == 01 { //if not go foreward to 06E0
06DF   return
06E0   }
06E0   if TempVarByte[06] == 02 {//if not go foreward to 06F7



Now how about user defned vars? how about this as an example

Code: [Select]


if <plotProgression> == 931 {//if not jump to 7BCA

You have tooltops, so why not have it so that when you hover over the <plotProgression> var the tooltip will display <1>0000.

This also solves how to disply correct program flow becuase, if I remeber, the if-type commands can either roll foreward, back, or to an implicit jump.

Here's another tip. You are making a *READER* not a compiler, yes? We can leave that to other toolmasters. To make an engine, you just need to be able to read data in a cohearent mannor that both human and computer can read.

[Qhimm]

Yes, currently it is just a reader. I am however trying to write it so that making an actual editor/compiler won't be that much of an extra step. Thus I'm trying to make the code->text translation as "strict" as possible to further help making the work of writing the compiler easier by having a well-defined language structure. One bit of extra type information you might want to display is to differentiate between signed and unsigned words, for example. I read earlier in the thread where Terence used the following form: SWord(1)[55]. I think it would be easier to read, but I'm very open for feedback.

In the mean while, how many permanent script variables have actually been mapped?

[halkun]

Lots

I have them in my new Gears upload, (Under menu), I even split up the save map to show the bank boundires (They are in orange) I'm pretty proud of what I have in there so far. However, I can't verify the vilidity of some of those vars. Some of them seem to be misplaced, like the penned chocobo field data

[Terence Fergusson]

I really don't think there's a distinction, Qhimm; SWord and UByte were just what the lasyan's script dumper produced, but we already know the bank system and we know that the script itself only really knows the difference between words and bytes.  I think signed/unsigned is a possible factor with a few of the If statements too.  Maybe.  Not looked at the disassembly to be sure.

I'd be interested in hearing what the difference is between INC/DEC and INC!/DEC! though.  I assume it's something to do with either signed numbers or overflow, but can't spare the time to test.

[Qhimm]

Yes, while signed/unsigned matters very little in most respects of the script (only operand size is stored with arguments), a couple of commands are specific to one of the two. The best example would be the If statements which have specific forms for signed/unsigned words. I'm theorizing that the actual script language (before compilation) kept this type distinction and warned about mismatches during compilation.

You are correct in both aspects regarding the "!" forms; they are designed for UBytes and SWords (not UWords), and they have overflow control, also known as saturated addition, subtraction, etc. That is, if you add 10 to a UByte containing 250, the result is 255. Or, it you add 10,000 to an SWord containing 30,000, the result is 32,767. The engine is not very careful about this though, and only checks in one direction. Thus is you PLUS2! a variable containing -30,000 and a variable containing -10,000, overflow will occur and the result will be 25,536. The normal PLUS/MINUS operators don't care about overflow at all and thus works on either SWords/UWords, but other operators like MUL, DIV and MOD are definitely designed for SWords (and UBytes, of course).

So based on what I've seen so far, it seems that SWord is the primary data type for 16-bit variables (all arithmetic operators work on SWords), while UWords are primarly intended for bitwise operations and such (theory).

[Kero]

Commands
64 = SCR2D | 6  - screen 2 destination - change center of screen immidietly
I have no idea what first two bytes doing, everytime I tried to change theri values into something other than 0, ff7.exe crashed. After that is short (2 byte int) determining destination x in the picture. Last short is y value determining destination in picture
66 = SCR2DC | 9 - screen 2 destination - change center of screen in time in line,  trajectory is not uniformly divided, you speed is increasing at the start and decreasing in the end. Agan, first  2 bytes unknown, short y, short x and last short is time you have on move.
68 = SCR2DL | 9  - screen 2 destination - change center of screen in time on line,   move uniformly (speed is constant). Parameters same as in SCR2DC.

coordinates x and y are absolute, center is probably in the center of backgound/foreground image. - moves you to right/up, + to the left/down.

Maybe useless, It seems to me that some people have already decoded most of commands.  If I try to decode some more commands, will it be usefull?
I will soon write some text on section 1 based from script_dump.src
Can someone plz explain about sections and scripts? To me it seems that one section is in fact for one object in field. Line One for treasure chest, one for soldier, one for chocobo and so on. But what about scripts in one section? When are they running? Normally i would thought that you have one section and one script for one object. You have to run  them, but how? First section 1, script1, sec1,script2...sec1,script 5, sec2 script1,sec1 script2.... and so on in eternal loop?

I have seen a lot of parts like this one
****** Section n°2 (ba) Script n° 1 ******
000 : [00] - RET
where is absolutly nothing usefull, can someone explain?