Beginner's Event Editing Written Tutorial (cutscenes, action queues, etc)

Hey guys, well I've been writing this Advanced Event Editing Tutorial for about 6 hours now lolz. It's not completely done, and as long as I keep finding new things concerning events, I'll be updating this file. But thanks for reading it and I really hope it increases the amount of event editing in our games!
xJCSx
Link to Download!
https://www.ff6hacking.com/documents/FF6...torial.rtf
Version 1.0.0
Thanks to Gi Nattak for his table list of all the commands!
Thanks to Lenophis for his tips and telling me about the FD command!
UPDATE:
Hey guys. I'm almost finished updating the file, but I just realized a major error in the tut that I just concerning the FD command.
What I said in the guide is that the FD command, if used to replace an action queue, will make the game pause for however many bytes you placed the FD byte.
Turns out, I was dead wrong.
I apologize immensely guys, but actually the FD command won't even be really read in the game and will just continue to the next few bytes. 
The reason I was thinking it would pause, was just a combination of bad luck and not exactly testing the command out.
You really don't have to read all this but basically just know that if you wish to skip and action queue, just FD the action queue and the game WON'T pause.
Why I messed up:
The reason I was thinking the game would pause was actually b/c the action queues that followed the action queue I FD'd would use the E0,xx byte. 
That byte is saying pause for xx frames.
That's where I started thinking the FD command was pausing. 
It wasn't - the game had already read the FD command and jumped to the next bytes that weren't FD. 
The processor will basically not even do a thing with an FD command and there'll be NO pausing whatsoever!
So yeah guys this pretty much replaces the need for those other 2 methods to "skip" action queues.
So yeah guys, enjoy FD!
xJCSx

This is a nice start. I began reading it and I came across this:

Wait, didn't the text dump say $6B??
It did, it's just a little problem with the event dump. It's a little off - now you're technically right where that map loads, it's just a few lines down. Of course, I'm not gonna tell you to scroll until you see a 6B lol that'd be evil! Here's the solution, and THANK YOU Gi Nattak for telling me this trick.
Now we're on the 31 byte, with the UP ARROW key, go up two lines. A line is a row basically, like this:
http://yfrog.com/g9whatalineisp
Each different color marks a new line. Just wanting you to get that ha.
Okay, now just go up 2 lines just like I said and then do this:
Do CTRL + H (HEX search) and then freeze!
I want you to get this next step. Look back at the event dump and that sequence that we're looking for in Windhex. We're looking for the 6B byte, so in the Hex Search box, type 6B but don't click enter just yet. Here's another tip that will ENSURE that you get to the part of the event dump.
The event dump is saying to load map 17. So right after the 6B command, type 17. That should be enough bytes for you to be guaranteed that you're at the right spot in the hex editor.
Now this is what you should have in the Hex Search Box:
6B17
No spaces, no nothing, just numbers. Click Enter and VOILA, look at where Windhex jumps you to!
http://yfrog.com/htloadmapp
This is the Load Map command for that spot in the event dump! This is how EVERY event will be when you're looking for it. The reason being, is the event dump was a little off by a few offsets, nothing that major. Atleast we HAVE an event dump.
But let's recap, to find an event you should go into the event dump, search for the text nearest to it, and then copy the offset, paste it in the Hex Search Box minus the first C and omitting the '/'. Then, go up two lines and do a hex search for atleast 2 bytes. In this case - 6B and 17. Or 6B17 when you're searching for it!

While this shows an excellent set of problem-solving skills, this is actually misleading information. I personally would have never thought to do a Hex-search to find the correct offsets in such a case.

However, the reason why the EventDump offsets are different from the ROM offsets is because the EventDump was written from an unheadered ROM, while most hackers will be working from a headered ROM (since this is the version that most ROM-editing tools are written for, such as FF3usME).

The header was a section of 200 bytes at the beginning of an SNES cartridge that allowed the SNES console to read the ROM. Modern emulators do not need this header, so modern ROMs often omit it. This is why the EventDump (and most disassemblies, in fact) are written without the headered addresses.

In short, you do not need to do a Hex-search every time you want to find an offset. You simply need to add $200 bytes to whatever offset you're looking for.

However, this Hex-searching technique is a good skill to have, so you might want to mention it in your tutorial still. ...Just not in conjuction with incorrect information.

Ah thanks DjinnandTonic, I should've known that! I've ran some dissemblers before and it would always tell me to get an unheadered ROM. I can't believe I never thought about the guys who ASMed the dump had to use an unheadered ROM. Makes sense now! I'm already revising the file right now, and will include that in this update.
I'm mainly working on getting a bigger table for all the parameters near the bottom and then I'm gonna try getting some advanced custom event stuff. So yeah there'll be some good stuff in the next update.
But thanks for telling me, and trust me, mis-leading information is something I'm definitely not going for lol
xJCSx

I was reading through it and it's very easy to follow and understand, Great Job

I'll definitely have this in mind if I get some time to do event hacking. I have so many ideas I want to work on and so little time to do them

Awesome thanks Angelo! I was going for easy-to-understand.
But yeah event editing IS time consuming definitely. Just as long as you can get some ZSNES saves close to the event you're editing, it'll go by faster.
But I've already added so much new stuff to the file - camera panning, making the screen mosaic and flash, a bigger table at the bottom, and a bunch more. I finally took out all those stupid exclamation marks too! Lol sorry, it probably seemed like I was screaming everything I said. And then some bad typos :p
But yeah just wanted everyone to know, I'll update it tomorrow probably!
Thanks guys
xJCSx

when you can, make a step by step tutorial video explaining how this is done

Cool idea Poco, I enjoy making tutorials actually.
Lol I'll try getting on it tomorrow sometime, if not definitely by the end of this week..thurdays and wednesdays are insanely busy for me
But a quick question, was the video quality in my last vid good enough for me to use in my next video or do I need to get a good program to record? Idk what's considered good quality ha but it looked kinda bad to me xD

0E,09,E0,04,9C,C1,80,83,E0,10,FF
0E,09,E0,04,9C,84,A2,CF,E0,10,FF

I may just be doing something wrong here, but he doesn't go quite off the ledge with this change. Is it supposed to be 83 (walk left) instead of CF (face left)? That seems to make sense.

0E,09,E0,04,9C,C1,80,83,E0,10,FF
0E,09,E0,04,9C,84,A2,CF,E0,10,FF

I may just be doing something wrong here, but he doesn't go quite off the ledge with this change. Is it supposed to be 83 (walk left) instead of CF (face left)? That seems to make sense.

C1 means "Walk really slow", an you changed it by 84 which means "Walk up 2 tiles". Then you have A2, and CF (look in <-- that direction) instead of walking.

What is it that you want to do again?

The tutorial says he is supposed to walk off the edge of the cliff with this code. However, he just walks up a little further, turns left (which doesn't do anything noticeable), and walks down and left. Since he is already at the right side, he doesn't make it off the edge, which is why I'm thinking he needs to walk left one more instead of facing left.