Info about the field scripting language goes here.

  • Thread starter Thread starter halkun
  • Start date Start date
Status
Not open for further replies.
Since Items and materia aren't stored in the same data space, it might be a hold over.

That is they may have originally had SET REMOVE and GET Materia commands (obligatory nuisances), then removed them and rolled them into the ITEM code.  Now this brings up a bit of a problem, if materia is fetched using the item code how do the specify what the item is? Since Materia and item codes are completely different?

Cyb
 
Nonono, materia and items are still handled completely separately. Sorry for any confusion. All I'm saying is that the commands for the two share certain similarities. Now DM-TRA and CM-TRA are non-functional in the PC version. It's possible there's another command replacing them, but I haven't found one; probably the commands are just never used, and the developers didn't bother implementing them. That, or they just forgot :P

One point I figured the DM-TRA and CM-TRA commands would be used is when you touch the huge materia to replace your mastered materia with a Master Magic (or similar) materia. Probably there's a special command for that though, or it would have to rely on the dysfunctional ones...
 
Yea it's probably a SPECIAL() command that talks directly with the kernel.

That bad boy has 256 sub commands and it seems to be a bunch of hard-coded last minute commands that were put in because the opcode matrix was full.
 
Yea it's probably a SPECIAL() command that talks directly with the kernel.

That bad boy has 256 sub commands and it seems to be a bunch of hard-coded last minute commands that were put in because the opcode matrix was full.
Click to expand...
Argh.. I hate when they do that, it reminds me of programing for microcontrollers the idiot designers didn't design with enough for thought.  I should shut up on that, I really want to strangle some engineers on ocassion, but then I am probably as guilty as they are!

So I suppose the big thing would be to document the SPECIAL matrix next then?

Cyb
 
So I suppose the big thing would be to document the SPECIAL matrix next then?
Click to expand...
Yeah, I'll get on it right after I finish documenting those pesky REQ instructions...
 
So I suppose the big thing would be to document the SPECIAL matrix next then?
Click to expand...
Yeah, I'll get on it right after I finish documenting those pesky REQ instructions...
Click to expand...
Well I suppose I ought to start working on the script viewing stuff as well.  I have to rewrite my software almost completely (sigh) in some section.

The 'dumb' question where are the NAMEs you are giving this OPCODES coming from? Laysan3's script dumper? or are they listed someplace in FF7's various data files?

Cyb
 
They are coming from Lasyan3's script dumper, but Qhimm is renaming them.

I'm going to hold off on the field scripting bit till Qhimm's done with his side. However, I'm done with the MENU section of Gears, and I'm going to finish KERNEL tonight, after that, I'm going to move on to the FIELD section and flesh out the mechanics of that.

I'l also re-vamping the way I have my sections set up to improve readability. However, Openoffice can't export it's bookmarks into PDF format so I'm still looking for a soultion.

Maybe, when gears is done, some soul with Acrobat can put in the bookmarks for me.
 
The names I've given to the opcodes are listed in the field.bin file of ff7 PSX. Here is the file, I think it will be useful :

[MOD: LINK REMOVED][/i]
 
The names I've given to the opcodes are listed in the field.bin file of ff7 PSX. Here is the file, I think it will be useful :
Click to expand...

Please don't post files from the game disk here. I'm pretty sure most everyone has a copy of FF7 for PSX. Saying that it's in Field.bin is enough for us to take a look for ourselves.
 
I see. Sorry for the trouble.
Click to expand...
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
 
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]
Code: 
// 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?
 
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.
 
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)
 
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.
 
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]
Code: 
06D9   if ()[06] == 01 { //06E006DF   return06E0   }06E0   if ()[06] == 02 {//06F7

into this

Code: [Select]
Code: 
06D9   if TempVarByte[06] == 01 { //if not go foreward to 06E006DF   return06E0   }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]
Code: 
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.
 
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?
 
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
 
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.
 
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).
 
Status
Not open for further replies.
Back
Top