| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
ff3:ff3us:tutorial:events:basic [2018/05/05 23:04]
lockirby2 |
ff3:ff3us:tutorial:events:basic [2019/02/12 11:20] (current)
|
| Alright, let's actually dive into this now. To practice eventing, we probably want to modify an event that occurs near the beginning of the game (for the sake of convenience). Let's modify the event that occurs if the player tries to leave Narshe at the beginning of the game. Normally, Wedge would yell "The Esper's gotta be in here. Move out!", and the party would walk back into Narshe. We'll modify this event so that Narshe Guards attack the player if they try to leave. To find the event in the event script, follow the process from before: select the event tile in the LE, note that the event is at 29B1D, and convert it to CC/9B1D. Then find the event in the ROM by searching for C9B1D. | Alright, let's actually dive into this now. To practice eventing, we probably want to modify an event that occurs near the beginning of the game (for the sake of convenience). Let's modify the event that occurs if the player tries to leave Narshe at the beginning of the game. Normally, Wedge would yell "The Esper's gotta be in here. Move out!", and the party would walk back into Narshe. We'll modify this event so that Narshe Guards attack the player if they try to leave. To find the event in the event script, follow the process from before: select the event tile in the LE, note that the event is at 29B1D, and convert it to CC/9B1D. Then find the event in the ROM by searching for C9B1D. |
| |
| === Display a Text Box === | ==== Display a Text Box ==== |
| |
| Now we can start modifying this event. We should probably notify the player of what's happening, which can be be accomplished by showing them a text box. We can change text boxes in FF3usME, as you may have seen already. But which text box should we modify? Since we're removing the original cutscene that played here, we know that "The Esper's gotta be in here. Move out!" can be changed to our new text. Open the dialogue editor in FF3usME and modify the text to something fitting. Press Apply and OK to save the text, then press Save in the main window to write the new text to the ROM. Now we have a text box to display. | Now we can start modifying this event. We should probably notify the player of what's happening, which can be be accomplished by showing them a text box. We can change text boxes in FF3usME, as you may have seen already. But which text box should we modify? Since we're removing the original cutscene that played here, we know that "The Esper's gotta be in here. Move out!" can be changed to our new text. Open the dialogue editor in FF3usME and modify the text to something fitting. Press Apply and OK to save the text and then press Save in the main window to write the new text to the ROM. Now we have a text box to display. |
| |
| {{:ff3:ff3us:tutorial:events:before_text_change.png?500|}} {{ :ff3:ff3us:tutorial:events:after_text_change.png?500|}} | {{ :ff3:ff3us:tutorial:events:text_change.png |}} |
| |
| The next step is to figure out which parameters will display this particular text box. In FF3usME, you can see that the text box we modified is at index 11, which is highlighted in the images above. Remember that 11 is in decimal, but our parameters are in hexadecimal. Looking at the Event Command Document, we can see that we will need to convert //12// to hexadecimal if we want to display the text box at index 11. In hexadecimal, this is $C, or $000C. Now we flip this around as we did previously to get 0C 00 as our parameters. I see no reason to either move the text box to the bottom of the screen or remove the background, but you can play around with that if you want. Therefore, the full command to display this text box is 4B 0C 00. We can type this into HxD at the address we found previously, which gives us the following result: | The next step is to figure out which parameters we need to use to display this particular text box. In FF3usME, you can see that the text box we modified is at index 11, which is highlighted in the images above. Remember that 11 is in decimal, but our parameters are in hexadecimal. Looking at the Event Command Document, we can see that we will need to convert //12// (one greater than 11) to hexadecimal if we want to display the text box at index 11. In hexadecimal, this is $C, or $000C. Now we invert the bytes as we did previously, determining that 0C 00 should be our parameters. I see no reason to either move the text box to the bottom of the screen or remove the background, but you can play around with that if you want. Therefore, the full command to display this text box is 4B 0C 00. We can type this into HxD at the address we found previously, which gives us the following result: |
| |
| {{:ff3:ff3us:tutorial:events:hex_for_text.png|}} | {{:ff3:ff3us:tutorial:events:hex_for_text.png|}} |
| |
| Perhaps you want to take a look at the event as it is now. If nothing else, you might want to check that the event functions properly. Every event ends with the FE command, which tells the game to return from the current event. So finish the current event with the FE command, and save it in HxD. Now you can open it up in your favorite emulator and see the text box in action. | Perhaps you want to take a look at the event as it is now. If nothing else, you might want to check that the event functions properly. Every event ends with the $FE command, which tells the game to return from the current event. So finish the current event with the $FE command and save it in HxD. Now you can open it up in your favorite emulator and see the text box in action. |
| |
| {{:ff3:ff3us:tutorial:events:ended_after_text.png|}} | {{:ff3:ff3us:tutorial:events:ended_after_text.png|}} |
| |
| You may notice that the text box is displayed over and over again. This is because Terra is still standing on the event tile when the event ends, so the event is triggered again after it is done. We don't have the tools to fix that yet, so we will ignore the issue for now. | You may notice that the text box is displayed over and over again. The party is still standing on the event tile when the event ends, so the event is triggered again after it is done. We don't have the tools to fix that yet, so we will ignore the issue for now. |
| |
| === Red Flash === | ==== Red Flash ==== |
| |
| How about we add in a red flash, to show that something dangerous is coming? If we search for the word "flash" in the Event Command Document, we quickly come across command $55. The document tells us that there is only one parameter, which controls the color of the screen. To get a red color, the parameter should be 20. So our full command to flash the screen is 55 20. | How about we add in a red flash, to show that something dangerous is coming? If we search for the word "flash" in the Event Command Document, we quickly come across command $55. The document tells us that there is only one parameter, which controls the color of the flash. To get a red color, the parameter should be $20. So our full command to flash the screen is 55 20. |
| |
| === Force a Battle === | ==== Force a Battle ==== |
| |
| Finally, we want to end the event by forcing the player to battle some guards. Searching for the word "battle" in the Event Commands Document, you may come across command $4C. This command is obviously quite involved, and there are some extra notes explaining information that might be useful. In particular, NOTE1 tells us that we should be using command $4D to call a battle here, although we still need to look at this section for information about the parameters. Ignore NOTE2-NOTE5 for now; we don't have enough knowledge to decipher them yet. Read over the other two notes for yourself. | Finally, we want to end the event by forcing the player to battle some guards. Searching for the word "battle" in the Event Commands Document, you may come across command $4C. This command is obviously quite involved, so there are some extra notes explaining information that might be useful. In particular, NOTE1 tells us that we should be using command $4D to call a battle here, although we still need to look at this section for information about the parameters. Ignore NOTE2-NOTE5 for now; we don't have enough knowledge to decipher them yet. Read over the other two notes for yourself. |
| |
| This command has two parameters, like command $4B. Looking at EX1 and EX2, it looks like the first parameter controls which formation is encountered. The Event Command Document is directing us to look in FF3usME again. This time, we want to look under the "Packs" tab of the Formation Editor. If the first parameter is $00, it corresponds to formation 256 in this editor. This means that the player would encounter a single Lobo if we set the parameter to $00. | This command has two parameters, like command $4B. Looking at EX1 and EX2, it looks as though the first parameter controls which formation is encountered. The Event Command Document is directing us to look in FF3usME again. This time, we want to look under the "Packs" tab of the Formation Editor. If the first parameter is $00, it corresponds to formation 256 in this editor. This means that the player would encounter a single Lobo if we set the parameter to $00. |
| |
| {{:ff3:ff3us:tutorial:events:ff3usme_lobos.png|}} | {{ :ff3:ff3us:tutorial:events:ff3usme_lobos.png |}} |
| |
| From the second example, we can see how to specify the encounter that we really want. The parameter is being added to 256, and the result is the formation that will be fought by the party. If the parameter is $01, the party will fight formation 257. If it is $02, the party will fight 258. If it is $19, the party will fight 256 + $19 (which would be 256 + 25 = 281 in decimal). Now we just need to figure out which formation contains two guards. Thankfully, we don't need to look very far, as this is formation 257. Therefore, the first parameter should be $01. | From the second example, we can see how to specify the encounter that we really want. The parameter is being added to 256, and the result is the formation that will be fought by the party. If the parameter is $01, the party will fight formation 257. If it is $02, the party will fight 258. If it is $19, the party will fight 256 + $19 (which would be 256 + 25 = 281 in decimal). Now we just need to figure out which formation contains two guards. Thankfully, we don't need to look very far, as this is formation 257. Therefore, the first parameter should be $01. |
| |
| {{:ff3:ff3us:tutorial:events:ff3usme_guards.png|}} | {{ :ff3:ff3us:tutorial:events:ff3usme_guards.png |}} |
| |
| The second parameter controls the background of the encounter. EX1 shows us that each background corresponds to a specific ID that we could look up in FF3usME. However, EX2 gives us a better alternative in this case. The parameter $3F is special, as it instructs the game to use the background for the area that the party is currently in. Since we're in Narshe, it will use the Narshe background. That is exactly what we want, so let's set the second parameter to $3F. | The second parameter controls the background of the encounter. EX1 shows us that each background corresponds to a specific ID that we could look up in FF3usME. However, EX2 gives us a better alternative in this case. The parameter $3F is special, as it instructs the game to use the background for the area that the party is currently in. Since we're in Narshe, it will use the Narshe background. That is exactly what we want, so let's set the second parameter to $3F. |
| === Delays === | === Delays === |
| |
| The next issue is more of a stylistic one. Usually, a flashing effect doesn't occur at the same time as a mosaic effect. I think that there are too many visual effects on the screen at the moment when the battle is about to begin. You may disagree (and you are certainly free to do whatever you want), but I want to prevent the flash from overlapping with the mosaic effect. To that end, we can put a delay in the script. Each delay pauses the execution of the event script for a certain number of "units". These units of time are very short. Rather than try to calculate exactly how long you should pause the game for, I recommend simply playing with the delays until you get a result that //feels// right. | The next issue is more of a stylistic one. Usually, a flashing effect doesn't occur at the same time as a mosaic effect. I think there are too many visual effects on the screen at the moment when the battle is about to begin. You may disagree (and you are certainly free to do whatever you want), but I want to prevent the flash from overlapping with the mosaic effect. To that end, we can put a delay in the script. Each delay pauses the execution of the event script for a certain number of "units". These units of time are very short. Rather than try to calculate exactly how long you should pause the game for, I recommend simply playing with the delays until you get a result that //feels// right. |
| |
| The simplest delay commands are $91 through $95. One of these will generally be sufficient for most purposes. You can experiment with them all if you want. The final event will look something like this, where the highlighted value is replaced by the delay that you are using: | The simplest delay commands are $91 through $95. One of these will generally be sufficient for most purposes. You can experiment with them all if you want. The final event will look something like this, where the highlighted value is replaced by the delay that you are using: |