The Event Bits (https://docs.google.com/spreadsheets/d/1hO_rd9-PmAsFNl1Z8V4K01Ro4XzrVFZRaXSXR4z4GJY/edit#gid=132917877)

Overview: There are a set of flags stored in RAM that govern whether or not you've seen a specific event. Other aspects will check these flags to allow or disallow certain things. We need a full map of these, what triggers them to change, and what they govern.

Example: The first one I've found is at 7E0A16, and it's the lowest bit of that byte (00000001). This bit gets set after picking up Galuf right at the start of the game. I've played around with it, and for instance if you set that bit before talking to Galuf, you can leave the meteor and go trigger the cutscene with the ground falling out and Butz flying off of Boco. You can fight those encounters with Lenna still in your party as well (she usually leaves with Galuf there). Hopefully this illustrates what I mean when I say "what they govern."

Task: http://erick.guillen.com.mx/Codes/SNES%20Final%20Fantasy%20V.txt on this page, at the bottom (section 1.17) there is a list showing the banks that track these flags, and it's partially completed. We need the rest of this completed. Note that the Galuf event isn't listed there, so under 7E0A16, in the first row (01) we could add, say ("Wake up Galuf at meteor").

More advice: the way to narrow these down is to open a hex editor and point it to these values, either in the cheat viewer in a normal version of Snes9x or with a more extensive RAM viewer in a debugging emulator. Make a savestate before some event happens (this could be ANYTHING, small as the spring cutscene, to big as the whole crystal shatter cutscene). Watch the event, note any changes to flags in those bytes, and narrow down which is doing which. Another cool strategy is flip the flag BEFORE the cutscene, and see how it changes. Usually I'd imagine you'd softlock because you can no longer trigger the cutscene to move on, but who knows.

Reading Hex Values: If you're unfamiliar with how to read this stuff, here's a really quick overview. A hex value is a number between 0-15, represented with the digits 0-9, A=10, B=11, C=12, D=13, E=14, F=15. For these flags, it's less valuable to think of them as actual hex numbers, but rather that each Hex Digit is 4 bits (0000).
+========+
|0 = 0000|
|1 = 0001|
|2 = 0010|
|3 = 0011|
|4 = 0100|
|5 = 0101|
|6 = 0110|
|7 = 0111|
|8 = 1000|
|9 = 1001|
|A = 1010|
|B = 1011|
|C = 1100|
|D = 1101|
|E = 1110|
|F = 1111|
+========+

So every set of two hex numbers (which is how data is stored in SNES architecture) will simply be two of these back to back (for instance E3 = 11100011.

Basically, each bit represents one flag. Using our example from above, the final bit of this byte would refer to waking up Galuf at the meteor. So any set of hex values that includes the final bit being set to "1" would indicate this flag. For instance, if this byte was A6 (10100110), this flag has not been set, but if the byte was 61 (01100001) it would.

The implication of this is that it might be a bit difficult to determine which bit is tracking what once a bunch of the flags or set. Let's look at an example.

Let's say we have a byte that's checking a few flags. We're halfway through the game so many flags are already set. Our byte right now is 5D (01011101). This means 5 of our 8 flags represented by this bit are "set".

Now say we're moving to a new event, and while watching the hex we see our 5D turn into 5F (01011111). Notice that only 1 bit changed, the second to last one. In essence, the change from 5D to 5F indicates that the event you just watched flipped the "02" bit. The numbers walk backward ascending. The rightmost bit will be 01, then working leftward: 02, 04, 08, 10, 20, 40, 80.

Hopefully this makes enough sense to get started, ask me if you have any questions.