Rooba
/
pokeemerald
mirror of https://github.com/pret/pokeemerald.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity

more intuitive wording for getexp deep dive

DavidJCobb 2023-11-16 02:03:46 +01:00
parent e9b0c0873b
commit ceb1acc376
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
Implementing-Catch-EXP.md

@ -138,23 +138,23 @@ Here's the clever devilry: `getexp` doesn't increase `gBattlescriptCurrInstr` wh
1. The script sets `gBattleScripting.getexpState` to 0.
1. The script runs `getexp`, so `gBattlescriptCurrInstr` points to the `getexp` instruction in the script.
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is 0, so it runs the zeroth batch (computers start counting from zero, not one).
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is 0, so it runs the first batch (computers count from 0, not 1).
1. `Cmd_getexp` finishes running and increases `gBattleScripting.getexpState` to 1 on its way out.
1. The battle script engine wants to run the next command, which is the command at `gBattlescriptCurrInstr`... except that we didn't increase `gBattlescriptCurrInstr`, didn't move it forward, so it *still points to the `getexp` instruction.*` The one we just ran.
1. The battle script engine wants to run the next command, which is the command at `gBattlescriptCurrInstr`... except that we didn't increase `gBattlescriptCurrInstr`, didn't move it forward, so it *still points to the `getexp` instruction.* The one we just ran.
1. ...So the script runs `getexp` again.
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is now 1, so it runs the first batch (humans would call this the "second" batch).
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is now 1, so it runs the second batch.
1. `Cmd_getexp` finishes running and increases `gBattleScripting.getexpState` to 2 on its way out.
1. The battle script engine wants to run the next command. We still haven't increased `gBattlescriptCurrInstr`, so...
1. ...we run the same `getexp` instruction *yet again*.
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is now 2, so it runs the second batch (humans would call this the "third" batch).
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is now 2, so it runs the third batch.
1. `Cmd_getexp` finishes running and increases `gBattleScripting.getexpState` to 3 on its way out.
1. The battle script engine wants to run the next command. We still haven't increased `gBattlescriptCurrInstr`. Do you see what we're doing here?
1. We run the same `getexp` instruction again.
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is now 3, so it runs the third batch (humans would call this the "fourth" batch).
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is now 3, so it runs the fourth batch.
1. `Cmd_getexp` finishes running and increases `gBattleScripting.getexpState` to 4 on its way out.
1. The battle script engine wants to run the "next" (haha) command.
1. We run the same `getexp` instruction again.
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is now 4, so it runs the fourth batch (humans would call this the "fifth" batch).
1. `Cmd_getexp` sees that `gBattleScripting.getexpState` is now 4, so it runs the fifth batch.
1. `Cmd_getexp` finishes running and increases `gBattleScripting.getexpState` to 5 on its way out.
1. The battle script engine wants to run the "next" (haha) command.
1. We run the same `getexp` instruction again.
@ -166,7 +166,7 @@ So now that we know how `getexp` is structured, it'll be easier to read it. All
### So where's that music coming from?
I'll save you some time: it's in what humans would call the "third" batch, or `case 2`. Beginning at line 3345:
I'll save you some time: it's in the third batch, or `case 2`. Beginning at line 3345:
```c
// music change in wild battle after fainting a poke