Remove <details>

6 files changed, 10 insertions, 44 deletions

diff --git a/Add-a-new-item.md b/Add-a-new-item.md
index cfd8c14..3ce09a9 100644
--- a/Add-a-new-item.md
+++ b/Add-a-new-item.md
@@ -497,13 +497,7 @@ In other words, adding an effect for `HELD_EVIOLITE` won't involve updating any
 
 Eviolite's effect is pretty similar to Metal Powder, which boosts Ditto's defenses. Searching through the battle engine code for references to `METAL_POWDER` finds that it's implemented as a `DittoMetalPowder` routine, which gets called in two places, one for the player and one for the enemy. (Note that it checks directly for whether the held item is `METAL_POWDER`, not whether the held item's effect is `HELD_METAL_POWDER`. Either check would be okay, though.)
 
-<details>
-
-<summary>
-
-Anyway, edit [engine/battle/effect_commands.asm](../blob/master/engine/battle/effect_commands.asm): (click to expand)
-
-</summary>
+Anyway, edit [engine/battle/effect_commands.asm](../blob/master/engine/battle/effect_commands.asm):
 
 ```diff
  DittoMetalPowder:
@@ -596,8 +590,6 @@ Anyway, edit [engine/battle/effect_commands.asm](../blob/master/engine/battle/ef
  	ret
 ```
 
-</details>
-
 The implementation of `UnevolvedEviolite` is very similar to `DittoMetalPowder`, except the simple check for whether the species is `DITTO` has been replaced by a check for evolutions, similar to the check in `MoonBallMultiplier` in [engine/items/item_effects.asm](../blob/master/engine/items/item_effects.asm). (Also, instead of checking whether `[hl]` is `EVIOLITE`, we check whether `b` is `HELD_EVIOLITE`; either would be fine, since `GetOpponentItem` returns "the effect of the opponent's item in `bc`, and its id at `hl`", as explained in a comment.) `bc` gets repeatedly saved on the stack with `push` and `pop` because it contains the defense stat, and we don't want the various pre-boost checks to corrupt the original value.
 
 In general, if you're implementing a custom held item effect, think about which items have similar effects, and which other code might already do something like what you want.
diff --git a/Allow-more-trainer-parties,-with-individual-DVs,-stat-experience,-and-nicknames.md b/Allow-more-trainer-parties,-with-individual-DVs,-stat-experience,-and-nicknames.md
index 1c43195..7590af1 100644
--- a/Allow-more-trainer-parties,-with-individual-DVs,-stat-experience,-and-nicknames.md
+++ b/Allow-more-trainer-parties,-with-individual-DVs,-stat-experience,-and-nicknames.md
@@ -71,8 +71,7 @@ Edit [wram.asm](../blob/master/wram.asm):
 
 The `wOtherTrainerType` byte will store the trainer type while their data is being read.
 
-<details>
-<summary>Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm): (click to expand)</summary>
+Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm):
 
 ```diff
  ReadTrainerParty:
@@ -255,7 +254,6 @@ The `wOtherTrainerType` byte will store the trainer type while their data is bei
 +
 +	jp .loop
 ```
-</details>
 
 We've replaced the four routines `TrainerType1`, `TrainerType2`, `TrainerType3`, and `TrainerType4` with a single `ReadTrainerPartyPieces` routine. If you compare them all side by side, you'll notice how the chunks of `ReadTrainerPartyPieces` are all taken from the old routines, but now they don't need repeating.
 
@@ -336,8 +334,7 @@ Edit [constants/trainer_data_constants.asm](../blob/master/constants/trainer_dat
 
 I'm not bothering to define new `TRAINERTYPE_*` constants for every combination of {moves, item, nickname}. You can just combine flag values, like `TRAINERTYPE_NICKNAME | TRAINERTYPE_ITEM` for a trainer with Pokémon that have nicknames and held items.
 
-<details>
-<summary>Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm) again: (click to expand)</summary>
+Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm) again:
 
 ```diff
  ; add to party
@@ -381,7 +378,6 @@ I'm not bothering to define new `TRAINERTYPE_*` constants for every combination
  ; item?
  	...
 ```
-</details>
 
 Then edit [engine/battle/core.asm](../blob/master/engine/battle/core.asm):
 
@@ -486,8 +482,7 @@ Edit [constants/trainer_data_constants.asm](../blob/master/constants/trainer_dat
 
 Again, I'm not bothering to define new `TRAINERTYPE_*` constants for every combination of {moves, item, nickname, DVs}. You can just combine individual flag values.
 
-<details>
-<summary>Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm) again: (click to expand)</summary>
+Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm) again:
 
 ```diff
  ; add to party
@@ -579,7 +574,6 @@ Again, I'm not bothering to define new `TRAINERTYPE_*` constants for every combi
 
  	jp .loop
 ```
-</details>
 
 Then edit [engine/battle/core.asm](../blob/master/engine/battle/core.asm) again:
 
@@ -679,8 +673,7 @@ Edit [constants/trainer_data_constants.asm](../blob/master/constants/trainer_dat
 +PERFECT_STAT_EXP EQU $1337 ; treated as $FFFF in enemy party data
 ```
 
-<details>
-<summary>Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm) again: (click to expand)</summary>
+Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm) again:
 
 ```diff
  ; add to party
@@ -765,7 +758,6 @@ Edit [constants/trainer_data_constants.asm](../blob/master/constants/trainer_dat
 
  	jp .loop
 ```
-</details>
 
 (If you're using an older version of pokecrystal where `NUM_EXP_STATS` is not defined, then replace `ld c, NUM_EXP_STATS` with `ld c, 5`.)
 
@@ -877,8 +869,7 @@ Edit [data/trainers/party_pointers.asm](../blob/master/data/trainers/party_point
 
 We're just replacing `dw` with `dba` everywhere. Each table entry now has a third byte to declare which bank it's in, instead of expecting all the entries to be in `BANK(Trainers)`.
 
-<details>
-<summary>Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm) again: (click to expand)</summary>
+Edit [engine/battle/read_trainer_party.asm](../blob/master/engine/battle/read_trainer_party.asm) again:
 
 ```diff
 +GetNextTrainerDataByte:
@@ -1185,7 +1176,6 @@ We're just replacing `dw` with `dba` everywhere. Each table entry now has a thir
 -INCLUDE "data/trainers/parties.asm"
 +INCLUDE "data/trainers/party_pointers.asm"
 ```
-</details>
 
 That's a long series of edits, but they're all basically the same: instead of getting data directly from `[hl]` in the current ROM bank (i.e. the bank that this code is in), we call `GetNextTrainerDataByte` to switch banks while reading party data. We also have to account for the new bank byte in each `TrainerGroups` table entry.
 
diff --git a/Allow-tiles-to-have-different-attributes-in-different-blocks-(including-X-and-Y-flip).md b/Allow-tiles-to-have-different-attributes-in-different-blocks-(including-X-and-Y-flip).md
index d087685..554c483 100644
--- a/Allow-tiles-to-have-different-attributes-in-different-blocks-(including-X-and-Y-flip).md
+++ b/Allow-tiles-to-have-different-attributes-in-different-blocks-(including-X-and-Y-flip).md
@@ -128,8 +128,7 @@ If you followed [the `PRIORITY` color tutorial](Allow-map-tiles-to-appear-above-
 
 Now that all the \*_attributes.bin files are created, delete all the \*_palette_map.asm files. Also delete [gfx/tileset_palette_maps.asm](../blob/master/gfx/tileset_palette_maps.asm).
 
-<details>
-<summary>Edit [gfx/tilesets.asm](../blob/master/gfx/tilesets.asm): (click to expand)</summary>
+Edit [gfx/tilesets.asm](../blob/master/gfx/tilesets.asm):
 
 ```diff
 +SECTION "Tileset Data 8", ROMX
@@ -262,7 +261,6 @@ Now that all the \*_attributes.bin files are created, delete all the \*_palette_
 +TilesetAerodactylWordRoomAttr:
 +INCBIN "data/tilesets/aerodactyl_word_room_attributes.bin"
 ```
-</details>
 
 All we're doing here is `INCBIN`-ing each of the \*_attributes.bin files with an appropriate label. Of course, if you've added or removed any tilesets, they'll need their own labels and `INCBIN` statements. It doesn't matter which section any of them go in, or whether you create new sections.
 
@@ -405,9 +403,6 @@ We deleted `FarCallSwapTextboxPalettes`, so now `OverworldTextModeSwitch` just c
 
 Anyway, `LoadMapPart` calls `LoadMetatiles` to load certain data from the \*_metatiles.bin files, and we're going to define a `LoadMetatileAttributes` routine that does the same thing with the \*_attributes.bin files, so this is where it will be called.
 
-<details>
-<summary>(Click to expand the edits to `LoadMetatiles`.)</summary>
-
 ```diff
  LoadMetatiles::
  	; de <- wOverworldMapAnchor
@@ -500,7 +495,6 @@ Anyway, `LoadMapPart` calls `LoadMetatiles` to load certain data from the \*_met
  	jp nz, .row
  	ret
 ```
-</details>
 
 This routine copies data from \*_metatiles.bin (pointed to by `[wTilesetBlocksAddress]`) into `wSurroundingTiles`. We've made two small changes to it.
 
@@ -510,9 +504,6 @@ Two, tile IDs in \*_metatiles.bin have their high bit masked out. That used to b
 
 (Strictly speaking, we could just store values $00–$7F in \*_metatiles.bin to begin with, and rely on bit 3 of the values in \*_attributes.asm to indicate which tile range is being used ($00–$7F or $80–$FF, VRAM bank 0 or 1). But that would break compatibility with Polished Map even worse than it already is, and it would necessitate editing the \*_metatiles.bin files too.)
 
-<details>
-<summary>(Click to expand the edits to `LoadMetatileAttributes`.)</summary>
-
 ```diff
  LoadMetatiles::
  	...
@@ -611,7 +602,6 @@ Two, tile IDs in \*_metatiles.bin have their high bit masked out. That used to b
 +	jp nz, .row
 +	ret
 ```
-</details>
 
 `LoadMetatileAttributes` is very similar to `LoadMetatiles`: it copies data from \*_attributes.bin (pointed to by `[wTilesetAttributesAddress]`) into `wSurroundingAttributes`. However, `wSurroundingAttributes` is not in the same RAM bank as `wTilesetAttributesAddress` (whereas `wSurroundingTiles` is), so we have to switch banks at one point.
 
diff --git a/Expand-tilesets-from-192-to-255-tiles.md b/Expand-tilesets-from-192-to-255-tiles.md
index 6e945e4..b76df85 100644
--- a/Expand-tilesets-from-192-to-255-tiles.md
+++ b/Expand-tilesets-from-192-to-255-tiles.md
@@ -51,8 +51,7 @@ Note that the textbox frames aren't present in these graphics. That's because th
 
 ## 2. Update the character set
 
-<details>
-<summary>Edit [charmap.asm](../blob/master/charmap.asm): (click to expand)</summary>
+Edit [charmap.asm](../blob/master/charmap.asm):
 
 ```diff
 -; Actual characters (from gfx/font/font_extra.png)
@@ -172,7 +171,6 @@ Note that the textbox frames aren't present in these graphics. That's because th
  	charmap ",",         $f4
  	charmap "♀",         $f5
 ```
-</details>
 
 
 ## 3. Load the updated font graphics
diff --git a/Improve-the-outdoor-sprite-system.md b/Improve-the-outdoor-sprite-system.md
index 7e17b06..ac71c71 100644
--- a/Improve-the-outdoor-sprite-system.md
+++ b/Improve-the-outdoor-sprite-system.md
@@ -119,8 +119,7 @@ Now sprites will be loaded into VRAM in whatever order the list specifies. So if
 
 If you're replacing all of Crystal's maps with your own, you won't need these exact sets; but they're a good reference anyway for how the new sets work.
 
-<details>
-<summary>Edit [data/maps/outdoor_sprites.asm](../blob/master/data/maps/outdoor_sprites.asm): (click to expand)</summary>
+Edit [data/maps/outdoor_sprites.asm](../blob/master/data/maps/outdoor_sprites.asm):
 
 ```diff
 -PalletGroupSprites:
@@ -399,7 +398,6 @@ If you're replacing all of Crystal's maps with your own, you won't need these ex
 +	; 0 of max 9 walking sprites
 +	db 0 ; end
 ```
-</details>
 
 Now we're done! These new sets are easier to define and debug than before. For example, here's the one for Olivine City's map group:
 
diff --git a/Replace-stat-experience-with-EVs.md b/Replace-stat-experience-with-EVs.md
index 1504e78..ef24100 100644
--- a/Replace-stat-experience-with-EVs.md
+++ b/Replace-stat-experience-with-EVs.md
@@ -213,8 +213,7 @@ That will format all the base data files correctly, but with zero EV yields. You
 
 ## 3. Gain EVs from winning battles
 
-<details>
-<summary>Edit [engine/battle/core.asm](../blob/master/engine/battle/core.asm): (click to expand)</summary>
+Edit [engine/battle/core.asm](../blob/master/engine/battle/core.asm):
 
 ```diff
 GiveExperiencePoints:
@@ -324,7 +323,6 @@ GiveExperiencePoints:
 +	jr .ev_loop
 +.evs_done
 ```
-</details>
 
 Now instead of gaining the enemy's base stats toward your stat experience, you'll gain their base EV yields toward your EV totals. Having Pokérus will double EV gain.