I'm going to talk out loud, then go to bed. Let's take the following command.
set byte(50)[07]=14
In this case the [07] means code 7, which selects bank 5 at a "depth" of 16 bits.
Don't look at the disassembled script for this. Look at the *Op Codes* and associated data. So what you really wanted to say was:
80 50 07 14, which becomes, properly:
set byte (5)[07] = (0)14
This means: Put the Constant 0x14 into the Byte at Offset 0x07 using ID 5 (which refers to the Temporary Bank and only dealing with bytes).
So what's the difference than doing this?
set byte(50)[0F]=14
I believe you want for your example:
set byte (6)[07] = (0)14
This means: Put the Constant 0x14 into the Byte at Offset 0x07 using ID 5 (which refers to the Temporary Bank and only dealing with words). Which... isn't exactly the most sensible of code... you don't *really* want to mix opcodes dealing with bytes and telling the script engines variable handling subroutine that you want to store it in a word. Who knows what might be put into that spare byte?
Wait, I have the sentax wrong. I guess I simply don't know how to read the opcodes... I've been playing with the ones that don't deal with memory at all, like BATTLE, PRTYP, GOLD+ and others like that. I think you tried to explain it above, but you started tossing around terms like "nybbles" (I honestly thought this term was made up hacker speak for the 4 bit upper/lower half of a byte. Even on an 8 bit 6502 you can't split a register in half, everything aligns on a 8 bit byte or 16 bit word.) The script dumps also align on 8 bit bytes and 16 bit words.
You're thinking about this too much. If I want to check a single bit, do I use a command to *only* get that bit? (Assume we're working in Assembler; the script engine has comparisons to check single bits) No: I grab the whole byte and store it in one of the 4-byte registers, then I'll AND it with the bit I want to check, and then test it against 0. It's the same with nibbles (which, yes, is another term for a half-byte, and is reasonably old in terms of when it was defined); I used it at the time because I thought it strange that, say: Random (05, 6D) and And (50, 6D, 01) would be associated with the same address. It was only later that I was able to parse them as:
99 05 6D: Random (5)[6D]
8F 50 6D 01: And (5)[6D], (0)01
I guess the script dumper is displaying memory locations in a pretty unintuitive way. I'm used to seeing explicit memory address ($0000-$FFFF), "zero-page" offsets ($00-$FF), or immidatle accessors (LDA #10)
Could you use give me some examples on how I'm supposed to properly parse these things? Thanks....
They're not that unintuitive. See, the script doesn't *know* all the addresses. It doesn't have nearly as much control you give it credit for. It has, as we've stated, access to 5 main banks of permenant variables, and 1 bank of temporary variables. (Please note: VARIABLES. We are currently ignoring stuff like XYZI which are specific commands that FF7 will go and do its own business with.) The permenant variables contain stuff that will be saved out in FF7's save file. Stuff like the number of Chocobos you have, or the last time you fought at Fort Condor, or how many battles you've been in since the start of the game. Temporary variables change and are reset from scene to scene and are used and thrown away as and when they're needed.
All you really have to know about the addresses is the following:
B/W
(1/2)[xx]: Bank 1
(3/4)[xx]: Bank 2
(B/C)[xx]: Bank 3
(D/E)[xx]: Bank 4
(F/7)[xx]: Bank 5
(5/6)[xx]: Temporary Bank
The 5 Banks are sequential sets of 256 addresses, and in v1.0, they start at 00DB1EC4 in memory, which starts with the Plot Progression Variable I've made note of several times.
The Temporary Bank is a set of 256 addresses that start at 00CB2B80 in v1.0, and are reserved for the script engine's use alone.
To put it simply: the scripts are interpreted by FF7, and FF7 itself will eventually convert (2)[00] to Word(0x00DB1EC4) when it's asked by the script engine to grab that particular address. Script writers are not expected to know exactly where in memory all this is going to eventually be placed... all they need to know is their offset from the start of the Global or Temporary areas.
