Add a new Pack pocket - pret/pokecrystal GitHub Wiki

This tutorial is for how to add a new Pack pocket. As an example, we'll add a Berry Pocket.

Define pocket-related constants
Give the pocket a name
Update the item types
Update the Pack graphics
Add space in WRAM for the new pocket
Initialize the new WRAM
Update HasNoItems and CheckRegisteredItem to check the new pocket
Update standard inventory routines
Update the Pack engine
Update the Crystal-only Pack engine
Update Kurt's Apricorn script
Fix build errors

1. Define pocket-related constants

 ; item types
 	const_def 1
 	const ITEM     ; 1
 	const KEY_ITEM ; 2
 	const BALL     ; 3
 	const TM_HM    ; 4
+	const BERRIES  ; 5

 ...

 ; pack pockets
 	const_def
 	const ITEM_POCKET     ; 0
 	const BALL_POCKET     ; 1
 	const KEY_ITEM_POCKET ; 2
 	const TM_HM_POCKET    ; 3
+	const BERRY_POCKET    ; 4
 NUM_POCKETS EQU const_value

 MAX_ITEMS     EQU 20
 MAX_BALLS     EQU 12
 MAX_KEY_ITEMS EQU 25
 MAX_PC_ITEMS  EQU 50
+MAX_BERRIES   EQU 17

Notice that the "item types" constants are in a different order than the "pack pockets" constants. So don't mix them up. Also we name the item type "BERRIES" because "BERRY" is an item, so don't mix those up either.

The MAX_* constants are the storage capacities of their respective pockets. We defined MAX_BERRIES as 17 because there are 17 items that will go in the Berry pocket, as we'll see later; that way you can conveniently carry one stack of each Berry. (Likewise, MAX_BALLS is 12, and 12 items belong in the Ball pocket.)

2. Give the pocket a name

Edit data/items/pocket_names.asm:

 ItemPocketNames:
 ; entries correspond to item type constants
 	dw .Item
 	dw .Key
 	dw .Ball
 	dw .TM
+	dw .Berry

 .Item: db "ITEM POCKET@"
 .Key:  db "KEY POCKET@"
 .Ball: db "BALL POCKET@"
 .TM:   db "TM POCKET@"
+.Berry: db "BERRY POCKET@"

The phrase "the BERRY POCKET." has to fit on one line for the message "PLAYER put the ITEM in the POCKET." So a pocket name can be up to 13 characters long, plus a "@" at the end.

3. Update the item types

Edit data/items/attributes.asm, changing the relevant items' types from ITEM to BERRIES:

BERRY
GOLD_BERRY
PSNCUREBERRY
PRZCUREBERRY
BURNT_BERRY
ICE_BERRY
BITTER_BERRY
MINT_BERRY
MIRACLEBERRY
MYSTERYBERRY
RED_APRICORN
BLU_APRICORN
YLW_APRICORN
GRN_APRICORN
WHT_APRICORN
BLK_APRICORN
PNK_APRICORN

Note that all of these items have the CANT_SELECT property. The only items without it are BICYCLE, ITEMFINDER, OLD_ROD, GOOD_ROD, and SUPER_ROD, which are all Key Items. I haven't tried creating a non–Key Item that can be registered to the Select button, but suspect that it would cause glitches.

4. Update the Pack graphics

Edit gfx/pack/pack.png:

gfx/pack/pack.png

Edit gfx/pack/pack_f.png:

gfx/pack/pack_f.png

And edit gfx/pack/pack_menu.png:

gfx/pack/pack_menu.png

The pack.png and pack_f.png graphics are in this order, from top to bottom: Key Items, Items, TM/HM, Balls. We've split the Ball pocket in half and turned the right half into a Berry pocket, with its graphic appended to the bottom of the image. (Note that this doesn't match the order of either set of constants. We'll see later that the offsets of each pocket's individual picture are hard-coded in a table, not calculated directly from a constant.)

The pack_menu.png graphic is a set of 80 tiles in no particular order, except for the 20 sequential tiles that form the "◀▶ POCKET ▼▲ ITEMS" header. We've added the new "Berries" subtitle sequentially, but that's just to be neat; we'll see later that the individual tiles of the subtitles are all hard-coded, so you can fit them into any of the unused tiles in the original:

gfx/pack/pack_menu.png

5. Add space in WRAM for the new pocket

Edit wram.asm:

 wPCItemsCursor::        db
 wPartyMenuCursor::      db
 wItemsPocketCursor::    db
 wKeyItemsPocketCursor:: db
 wBallsPocketCursor::    db
 wTMHMPocketCursor::     db
+wBerryPocketCursor::    db

 wPCItemsScrollPosition::        db
 wPartyMenuScrollPosition::      db ; unused
 wItemsPocketScrollPosition::    db
 wKeyItemsPocketScrollPosition:: db
 wBallsPocketScrollPosition::    db
 wTMHMPocketScrollPosition::     db
+wBerryPocketScrollPosition::    db

 ...

+wDudeNumBerries::
 wDudeNumKeyItems:: db ; d292
 wDudeKeyItems:: ds 18
 wDudeKeyItemsEnd:: db

 ...

 wCmdQueue:: ds CMDQUEUE_CAPACITY * CMDQUEUE_ENTRY_SIZE

-	ds 40

 ...

 wNumBalls:: db ; d8d7
 wBalls:: ds MAX_BALLS * 2 + 1 ; d8d8

+wNumBerries:: db
+wBerries:: ds MAX_BERRIES * 2 + 1

Every pocket has a wNamePocketCursor and a wNamePocketScrollPosition byte for scrolling through it, a wNumNames byte that stores how many items are in it, and a wNames–wNamesEnd array for storing its items. wTMsHMs and wKeyItems are special, but normal item-storage pockets like wItems and wBalls have two bytes per possible item (one for the ID, one for the quantity) plus a byte for the end-of-list marker.

wDudeNumBerries just shares space with wDudeNumKeyItems because the catch tutorial dude only shows his Item and Ball pockets. It's probably possible to remove the data and code for his Key Item pocket entirely, but that's beyond the scope of this tutorial, and not necessary unless you really need some extra space.

Speaking of extra space: we used a total of 37 more WRAM bytes for the Berry pocket's data. Its WRAM bank has barely any free space left, so in general you'll need to remove as many bytes as you add. There was an unused ds 40 that conveniently saved 40 bytes. If you want larger pockets and need to free up more space, shortly below the pockets is an unused ds 13, then ds 49 after the wMapNameSceneID bytes, then ds 100 after the wTrainerFightCount bytes, and a ds 23 after wPhoneList. Any of those can be reduced to make more room for Pack pockets (or for more map scene IDs, or extending wEventFlags if you raise NUM_EVENTS, or so on).

6. Initialize the new WRAM

Edit engine/menus/intro_menu.asm:

 	ld hl, wNumItems
 	call .InitList

 	ld hl, wNumKeyItems
 	call .InitList

 	ld hl, wNumBalls
 	call .InitList
+
+	ld hl, wNumBerries
+	call .InitList

 	ld hl, wNumPCItems
 	call .InitList

As the .InitList comment explains, this "loads 0 in the count and −1 in the first item slot."

7. Update `HasNoItems` and `CheckRegisteredItem` to check the new pocket

Edit engine/pokemon/mon_menu.asm (or engine/menus/start_menu.asm in older versions of pokecrystal):

 HasNoItems:
 	ld a, [wNumItems]
 	and a
 	ret nz
 	ld a, [wNumKeyItems]
 	and a
 	ret nz
 	ld a, [wNumBalls]
 	and a
 	ret nz
+	ld a, [wNumBerries]
+	and a
+	ret nz
 	ld hl, wTMsHMs
 	ld b, NUM_TMS + NUM_HMS
 .loop
 	ld a, [hli]
 	and a
 	jr nz, .done
 	dec b
 	jr nz, .loop
 	scf
 	ret
 .done
 	and a
 	ret

Now edit engine/overworld/select_menu.asm:

 .Pockets:
 ; entries correspond to *_POCKET constants
 	dw .CheckItem
 	dw .CheckBall
 	dw .CheckKeyItem
 	dw .CheckTMHM
+	dw .CheckBerry

 ...

 .CheckBall:
 	ld hl, wNumBalls
+.StandardCheck:
 	call .CheckRegisteredNo
 	jr nc, .NoRegisteredItem
 	inc hl
 	ld e, a
 	ld d, 0
 	add hl, de
 	add hl, de
 	call .IsSameItem
 	jr c, .NoRegisteredItem
 	ret
+
+.CheckBerry:
+	ld hl, wNumBerries
+	jr .StandardCheck

There's no such thing as a Ball or Berry that can be registered, so I haven't actually tested this code; if there's a bug with the built-in handling of registered Balls, it will also apply to Berries. You're better off leaving Key Items as the only type that can be registered.

8. Update standard inventory routines

Edit engine/items/items.asm. Four routines here need updating, so let's take them one by one.

Edit _ReceiveItem:

 _ReceiveItem::
 	...

 .Pockets:
 ; entries correspond to item types
 	dw .Item
 	dw .KeyItem
 	dw .Ball
 	dw .TMHM
+	dw .Berry

 ...

 .Ball:
 	ld hl, wNumBalls
 	jp PutItemInPocket
+
+.Berry:
+	ld hl, wNumBerries
+	jp PutItemInPocket

Edit _TossItem:

 _TossItem::
 	...

 .Pockets:
 ; entries correspond to item types
 	dw .Item
 	dw .KeyItem
 	dw .Ball
 	dw .TMHM
+	dw .Berry

 .Ball:
 	ld hl, wNumBalls
 	jp RemoveItemFromPocket
+
+.Berry:
+	ld hl, wNumBerries
+	jp RemoveItemFromPocket

Edit _CheckItem:

 _CheckItem::
 	...

 .Pockets:
 ; entries correspond to item types
 	dw .Item
 	dw .KeyItem
 	dw .Ball
 	dw .TMHM
+	dw .Berry

 .Ball:
 	ld hl, wNumBalls
 	jp CheckTheItem
+
+.Berry:
+	ld hl, wNumBerries
+	jp CheckTheItem

And edit GetPocketCapacity:

 GetPocketCapacity:
 	ld c, MAX_ITEMS
 	ld a, e
 	cp LOW(wNumItems)
 	jr nz, .not_bag
 	ld a, d
 	cp HIGH(wNumItems)
 	ret z

 .not_bag
 	ld c, MAX_PC_ITEMS
 	ld a, e
 	cp LOW(wNumPCItems)
 	jr nz, .not_pc
 	ld a, d
 	cp HIGH(wNumPCItems)
 	ret z

 .not_pc
+	ld c, MAX_BERRIES
+	ld a, e
+	cp LOW(wNumBerries)
+	jr nz, .not_berries
+	ld a, d
+	cp HIGH(wNumBerries)
+	ret z
+
+.not_berries
 	ld c, MAX_BALLS
 	ret

In most of these cases we just based the Berry pocket case on the Ball pocket case. The TM/HM and Key Item pockets are special, and the Item pocket is sometimes treated as a "default" case with different handling. But the Ball pocket is non-default and just stores regular items, so it's safe to copy.

9. Update the Pack engine

We've saved editing the longest file for last: engine/items/pack.asm. Let's go over it piece by piece. (Don't worry, a lot of it is just copy+pasting chunks of code with the word "Berry" substituted for "Ball" or "Item".)

 ; Pack.Jumptable and BattlePack.Jumptable indexes
 	const_def
 	const PACKSTATE_INITGFX            ;  0
 	const PACKSTATE_INITITEMSPOCKET    ;  1
 	const PACKSTATE_ITEMSPOCKETMENU    ;  2
 	const PACKSTATE_INITBALLSPOCKET    ;  3
 	const PACKSTATE_BALLSPOCKETMENU    ;  4
 	const PACKSTATE_INITKEYITEMSPOCKET ;  5
 	const PACKSTATE_KEYITEMSPOCKETMENU ;  6
 	const PACKSTATE_INITTMHMPOCKET     ;  7
 	const PACKSTATE_TMHMPOCKETMENU     ;  8
+	const PACKSTATE_INITBERRYPOCKET
+	const PACKSTATE_BERRYPOCKETMENU
 	const PACKSTATE_QUITNOSCRIPT       ;  9
 	const PACKSTATE_QUITRUNSCRIPT      ; 10

These are jumptable indexes. Jumptables are a common design pattern you'll see for interfaces with a lot of different states and transitions between states, like the Pokédex and Pokégear. In general, there's a table of pointers corresponding to these index constants, and each pointer is to a different subroutine. Control jumps to whichever pointer corresponds to the value in wJumptableIndex, which usually starts at 0. Each subroutine can change wJumptableIndex, often by incrementing it to automatically reach the next state in the table, or by setting particular values depending on which buttons are pressed.

Notice the pattern to this table: for each pocket, there's a PACKSTATE_INIT*POCKET state followed by a PACKSTATE_*POCKETMENU state. They happen to be in the same order as the *_POCKET constants, although that isn't actually significant; all that matters is that the default pocket be the first one (since the PACKSTATE_INITGFX state increments wJumptableIndex and advances to the next state, which should thus be the default pocket's INIT state).

 Pack:
 	...

 .Jumptable:
 ; entries correspond to PACKSTATE_* constants
 	dw .InitGFX            ;  0
 	dw .InitItemsPocket    ;  1
 	dw .ItemsPocketMenu    ;  2
 	dw .InitBallsPocket    ;  3
 	dw .BallsPocketMenu    ;  4
 	dw .InitKeyItemsPocket ;  5
 	dw .KeyItemsPocketMenu ;  6
 	dw .InitTMHMPocket     ;  7
 	dw .TMHMPocketMenu     ;  8
+	dw .InitBerryPocket
+	dw .BerryPocketMenu
 	dw Pack_QuitNoScript   ;  9
 	dw Pack_QuitRunScript  ; 10

Here's the first jumptable corresponding to those constants. It's the "core" jumptable for when you enter the Pack via the Start Menu.

 .KeyItemsPocketMenu:
 	...
-	ld b, PACKSTATE_INITBALLSPOCKET ; left
+	ld b, PACKSTATE_INITBERRYPOCKET ; left
 	ld c, PACKSTATE_INITTMHMPOCKET ; right
 	call Pack_InterpretJoypad
 	ret c
 	call .ItemBallsKey_LoadSubmenu
 	ret

 ...

 .InitBallsPocket:
 	ld a, BALL_POCKET
 	ld [wCurPocket], a
 	call ClearPocketList
 	call DrawPocketName
 	call WaitBGMap_DrawPackGFX
 	call Pack_JumptableNext
 	ret

 .BallsPocketMenu:
 	ld hl, BallsPocketMenuHeader
 	call CopyMenuHeader
 	ld a, [wBallsPocketCursor]
 	ld [wMenuCursorPosition], a
 	ld a, [wBallsPocketScrollPosition]
 	ld [wMenuScrollPosition], a
 	call ScrollingMenu
 	ld a, [wMenuScrollPosition]
 	ld [wBallsPocketScrollPosition], a
 	ld a, [wMenuCursorY]
 	ld [wBallsPocketCursor], a
 	ld b, PACKSTATE_INITITEMSPOCKET ; left
-	ld c, PACKSTATE_INITKEYITEMSPOCKET ; right
+	ld c, PACKSTATE_INITBERRYPOCKET ; right
 	call Pack_InterpretJoypad
 	ret c
 	call .ItemBallsKey_LoadSubmenu
 	ret
+
+.InitBerryPocket:
+	ld a, BERRY_POCKET
+	ld [wCurPocket], a
+	call ClearPocketList
+	call DrawPocketName
+	call WaitBGMap_DrawPackGFX
+	call Pack_JumptableNext
+	ret
+
+.BerryPocketMenu:
+	ld hl, BerryPocketMenuHeader
+	call CopyMenuHeader
+	ld a, [wBerryPocketCursor]
+	ld [wMenuCursorPosition], a
+	ld a, [wBerryPocketScrollPosition]
+	ld [wMenuScrollPosition], a
+	call ScrollingMenu
+	ld a, [wMenuScrollPosition]
+	ld [wBerryPocketScrollPosition], a
+	ld a, [wMenuCursorY]
+	ld [wBerryPocketCursor], a
+	ld b, PACKSTATE_INITBALLSPOCKET ; left
+	ld c, PACKSTATE_INITKEYITEMSPOCKET ; right
+	call Pack_InterpretJoypad
+	ret c
+	call .ItemBallsKey_LoadSubmenu
+	ret

We're doing two things here.

One, we insert the Berry pocket in-between the Ball and Key Item pockets. Originally you can scroll left and right through the pockets in order: Items ↔ Balls ↔ Key Items ↔ TM/HM ↔ Items again. This is done by explicitly hard-coding each pocket's left and right ones. So the Berry pocket just had to be coded in.

Two, we actually write the subroutines that we just added pointers to in the jumptable. Really they're just copy+pasted from the Ball pocket's subroutines, but with "Berry" substituted for "Ball". (As we discussed earlier, the Ball pocket is safe to use as a base, since it stores regular items and isn't a default like the Items pocket.)

 BattlePack:
 	...

 .Jumptable:
 ; entries correspond to PACKSTATE_* constants
 	dw .InitGFX            ;  0
 	dw .InitItemsPocket    ;  1
 	dw .ItemsPocketMenu    ;  2
 	dw .InitBallsPocket    ;  3
 	dw .BallsPocketMenu    ;  4
 	dw .InitKeyItemsPocket ;  5
 	dw .KeyItemsPocketMenu ;  6
 	dw .InitTMHMPocket     ;  7
 	dw .TMHMPocketMenu     ;  8
+	dw .InitBerryPocket
+	dw .BerryPocketMenu
 	dw Pack_QuitNoScript   ;  9
 	dw Pack_QuitRunScript  ; 10

This is another jumptable, but for using the Pack during battle. Again, we add pointers for the Berry pocket, and will next have to define them.

 .KeyItemsPocketMenu:
 	...
-	ld b, PACKSTATE_INITBALLSPOCKET ; left
+	ld b, PACKSTATE_INITBERRYPOCKET ; left
 	ld c, PACKSTATE_INITTMHMPOCKET ; right
 	call Pack_InterpretJoypad
 	ret c
 	call ItemSubmenu
 	ret

 ...

 .InitBallsPocket:
 	ld a, BALL_POCKET
 	ld [wCurPocket], a
 	call ClearPocketList
 	call DrawPocketName
 	call WaitBGMap_DrawPackGFX
 	call Pack_JumptableNext
 	ret

 .BallsPocketMenu:
 	ld hl, BallsPocketMenuHeader
 	call CopyMenuHeader
 	ld a, [wBallsPocketCursor]
 	ld [wMenuCursorPosition], a
 	ld a, [wBallsPocketScrollPosition]
 	ld [wMenuScrollPosition], a
 	call ScrollingMenu
 	ld a, [wMenuScrollPosition]
 	ld [wBallsPocketScrollPosition], a
 	ld a, [wMenuCursorY]
 	ld [wBallsPocketCursor], a
 	ld b, PACKSTATE_INITITEMSPOCKET ; left
-	ld c, PACKSTATE_INITKEYITEMSPOCKET ; right
+	ld c, PACKSTATE_INITBERRYPOCKET ; right
 	call Pack_InterpretJoypad
 	ret c
 	call ItemSubmenu
 	ret
+
+.InitBerryPocket:
+	ld a, BERRY_POCKET
+	ld [wCurPocket], a
+	call ClearPocketList
+	call DrawPocketName
+	call WaitBGMap_DrawPackGFX
+	call Pack_JumptableNext
+	ret
+
+.BerryPocketMenu:
+	ld hl, BerryPocketMenuHeader
+	call CopyMenuHeader
+	ld a, [wBerryPocketCursor]
+	ld [wMenuCursorPosition], a
+	ld a, [wBerryPocketScrollPosition]
+	ld [wMenuScrollPosition], a
+	call ScrollingMenu
+	ld a, [wMenuScrollPosition]
+	ld [wBerryPocketScrollPosition], a
+	ld a, [wMenuCursorY]
+	ld [wBerryPocketCursor], a
+	ld b, PACKSTATE_INITBALLSPOCKET ; left
+	ld c, PACKSTATE_INITKEYITEMSPOCKET ; right
+	call Pack_InterpretJoypad
+	ret c
+	call ItemSubmenu
+	ret

Just like before, we insert the Berry pocket between the Ball and Key Item pockets, and base the Berry pocket's subroutines on the pre-existing Ball pocket ones.

 DepositSellPack:
 	...

 .Jumptable:
 ; entries correspond to *_POCKET constants
 	dw .ItemsPocket
 	dw .BallsPocket
+	dw .BerryPocket
 	dw .KeyItemsPocket
 	dw .TMHMPocket

 ...

 .BallsPocket:
 	ld a, BALL_POCKET
 	call InitPocket
 	ld hl, PC_Mart_BallsPocketMenuHeader
 	call CopyMenuHeader
 	ld a, [wBallsPocketCursor]
 	ld [wMenuCursorPosition], a
 	ld a, [wBallsPocketScrollPosition]
 	ld [wMenuScrollPosition], a
 	call ScrollingMenu
 	ld a, [wMenuScrollPosition]
 	ld [wBallsPocketScrollPosition], a
 	ld a, [wMenuCursorY]
 	ld [wBallsPocketCursor], a
 	ret
+
+.BerryPocket:
+	ld a, BERRY_POCKET
+	call InitPocket
+	ld hl, PC_Mart_BerryPocketMenuHeader
+	call CopyMenuHeader
+	ld a, [wBerryPocketCursor]
+	ld [wMenuCursorPosition], a
+	ld a, [wBerryPocketScrollPosition]
+	ld [wMenuScrollPosition], a
+	call ScrollingMenu
+	ld a, [wMenuScrollPosition]
+	ld [wBerryPocketScrollPosition], a
+	ld a, [wMenuCursorY]
+	ld [wBerryPocketCursor], a
+	ret

Here's a jumptable for when the Pack is opened to deposit or sell an item; it has entries for each individual pocket, less complicated than the previous jumptables with their intermediate INIT states. Since DepositeSellPack isn't hardcoded like the others, we will move dw .BerryPocket to after dw .BallsPocket in order to nagivate the pockets in the same order as the overworld. As usual, we just look at how the other pockets work and do what they do but with the word "Berry" in the right places.

 .d_left
 	ld a, [wJumptableIndex]
 	dec a
-	maskbits NUM_POCKETS
+	cp -1
+	jr nz, .left_ok
+	ld a, NUM_POCKETS - 1
+.left_ok
 	ld [wJumptableIndex], a
 	push de
 	ld de, SFX_SWITCH_POCKETS
 	call PlaySFX
 	pop de
 	scf
 	ret

 .d_right
 	ld a, [wJumptableIndex]
 	inc a
-	maskbits NUM_POCKETS
+	cp NUM_POCKETS
+	jr nz, .right_ok
+	xor a
+.right_ok
 	ld [wJumptableIndex], a
 	push de
 	ld de, SFX_SWITCH_POCKETS
 	call PlaySFX
 	pop de
 	scf
 	ret

This is somewhat tricky to notice. Here the code is decrementing or incrementing wJumptableIndex (that is, subtracting or adding 1) when you press Left or Right. But doing that can go beyond the valid range, since it might decrement the minimum or increment the maximum. When there were only four pockets, they neatly took up two bits, so a bitmask could be used to efficiently clamp them within the valid range. But five pockets requires more explicit checks so that the minimum and maximum values (0 and NUM_POCKETS − 1) wrap around.

 TutorialPack:
 	...

 .dw
 ; entries correspond to *_POCKET constants
 	dw .Items
 	dw .Balls
 	dw .KeyItems
 	dw .TMHM
+	dw .Berries

 ...

 .Balls:
 	ld a, BALL_POCKET
 	ld hl, .BallsMenuHeader
 	jr .DisplayPocket

 .BallsMenuHeader:
 	db MENU_BACKUP_TILES ; flags
 	menu_coords 7, 1, SCREEN_WIDTH - 1, TEXTBOX_Y - 1
 	dw .BallsMenuData
 	db 1 ; default option

 .BallsMenuData:
 	db STATICMENU_ENABLE_SELECT | STATICMENU_ENABLE_LEFT_RIGHT | STATICMENU_ENABLE_START | STATICMENU_WRAP | STATICMENU_CURSOR ; flags
 	db 5, 8 ; rows, columns
 	db 2 ; horizontal spacing
 	dbw 0, wDudeNumBalls
 	dba PlaceMenuItemName
 	dba PlaceMenuItemQuantity
 	dba UpdateItemDescription
+
+.Berries:
+	ld a, BERRY_POCKET
+	ld hl, .BerriesMenuHeader
+	jr .DisplayPocket
+
+.BerriesMenuHeader:
+	db MENU_BACKUP_TILES ; flags
+	menu_coords 7, 1, SCREEN_WIDTH - 1, TEXTBOX_Y - 1
+	dw .BerriesMenuData
+	db 1 ; default option
+
+.BerriesMenuData:
+	db STATICMENU_ENABLE_SELECT | STATICMENU_ENABLE_LEFT_RIGHT | STATICMENU_ENABLE_START | STATICMENU_WRAP | STATICMENU_CURSOR ; flags
+	db 5, 8 ; rows, columns
+	db 2 ; horizontal spacing
+	dbw 0, wDudeNumBerries
+	dba PlaceMenuItemName
+	dba PlaceMenuItemQuantity
+	dba UpdateItemDescription

Another jumptable, this time used by the catch tutorial dude. Once again, we just add an entry to the jumptable for the Berry pocket and base its code and data on whatever the Ball pocket does.

 PackGFXPointers:
 	dw PackGFX + (15 tiles) * 1 ; ITEM_POCKET
 	dw PackGFX + (15 tiles) * 3 ; BALL_POCKET
 	dw PackGFX + (15 tiles) * 0 ; KEY_ITEM_POCKET
 	dw PackGFX + (15 tiles) * 2 ; TM_HM_POCKET
+	dw PackGFX + (15 tiles) * 4 ; BERRY_POCKET

This is a table of pointers to the individual highlighted pocket pictures in pack.png and pack_f.png. Remember how they were out of order compared to the constants? That's why this table is necessary. For example, the first (#0) picture was of the Key Item pocket, and KEY_ITEM_POCKET is 2, so the third (#2) entry here points to the first picture. Anyway, all we have to do is add a pointer for the Berry pocket again.

 .tilemap
 ; ITEM_POCKET
 	db $00, $04, $04, $04, $01 ; top border
 	db $06, $07, $08, $09, $0a ; Items
 	db $02, $05, $05, $05, $03 ; bottom border
 ; BALL_POCKET
 	db $00, $04, $04, $04, $01 ; top border
 	db $15, $16, $17, $18, $19 ; Balls
 	db $02, $05, $05, $05, $03 ; bottom border
 ; KEY_ITEM_POCKET
 	db $00, $04, $04, $04, $01 ; top border
 	db $0b, $0c, $0d, $0e, $0f ; Key Items
 	db $02, $05, $05, $05, $03 ; bottom border
 ; TM_HM_POCKET
 	db $00, $04, $04, $04, $01 ; top border
 	db $10, $11, $12, $13, $14 ; TM/HM
 	db $02, $05, $05, $05, $03 ; bottom border
+; BERRY_POCKET
+	db $00, $04, $04, $04, $01 ; top border
+	db $1a, $1b, $1c, $1d, $1e ; Berries
+	db $02, $05, $05, $05, $03 ; bottom border

These are tilemaps for the pocket name labels in pack_menu.png. Each one is three rows of five tiles each, with tile indexes starting at 0. Take a look at pack_menu.png and notice how the hexadecimal indexes here correspond to tiles that form sensible pictures.

_NOTE: In newer versions of pokecrystal, this is controlled via gfx/pack/pack_menu.tilemap. You will need to edit it with Tilemap Studio, expand its size, and add the hex values for BERRY_POCKET.

Alternatively, if you don't know how to edit the tilemap, you can place the table after the tilemap import.

.tilemap: ; 5x12
; the 5x3 pieces correspond to *_POCKET constants
INCBIN "gfx/pack/pack_menu.tilemap"
+; BERRY_POCKET
+	db $00, $04, $04, $04, $01 ; top border
+	db $1a, $1b, $1c, $1d, $1e ; Berries
+	db $02, $05, $05, $05, $03 ; bottom border

 BallsPocketMenuHeader:
 	db MENU_BACKUP_TILES ; flags
 	menu_coords 7, 1, SCREEN_WIDTH - 1, TEXTBOX_Y - 1
 	dw .MenuData
 	db 1 ; default option

 .MenuData:
 	db STATICMENU_ENABLE_SELECT | STATICMENU_ENABLE_LEFT_RIGHT | STATICMENU_ENABLE_START | STATICMENU_WRAP | STATICMENU_CURSOR ; flags
 	db 5, 8 ; rows, columns
 	db SCROLLINGMENU_ITEMS_QUANTITY ; item format
 	dbw 0, wNumBalls
 	dba PlaceMenuItemName
 	dba PlaceMenuItemQuantity
 	dba UpdateItemDescription

 PC_Mart_BallsPocketMenuHeader:
 	db MENU_BACKUP_TILES ; flags
 	menu_coords 7, 1, SCREEN_WIDTH - 1, TEXTBOX_Y - 1
 	dw .MenuData
 	db 1 ; default option

 .MenuData:
 	db STATICMENU_ENABLE_SELECT | STATICMENU_ENABLE_LEFT_RIGHT | STATICMENU_ENABLE_START | STATICMENU_WRAP ; flags
 	db 5, 8 ; rows, columns
 	db SCROLLINGMENU_ITEMS_QUANTITY ; item format
 	dbw 0, wNumBalls
 	dba PlaceMenuItemName
 	dba PlaceMenuItemQuantity
 	dba UpdateItemDescription
+
+BerryPocketMenuHeader:
+	db MENU_BACKUP_TILES ; flags
+	menu_coords 7, 1, SCREEN_WIDTH - 1, TEXTBOX_Y - 1
+	dw .MenuData
+	db 1 ; default option
+
+.MenuData:
+	db STATICMENU_ENABLE_SELECT | STATICMENU_ENABLE_LEFT_RIGHT | STATICMENU_ENABLE_START | STATICMENU_WRAP | STATICMENU_CURSOR ; flags
+	db 5, 8 ; rows, columns
+	db SCROLLINGMENU_ITEMS_QUANTITY ; item format
+	dbw 0, wNumBerries
+	dba PlaceMenuItemName
+	dba PlaceMenuItemQuantity
+	dba UpdateItemDescription
+
+PC_Mart_BerryPocketMenuHeader:
+	db MENU_BACKUP_TILES ; flags
+	menu_coords 7, 1, SCREEN_WIDTH - 1, TEXTBOX_Y - 1
+	dw .MenuData
+	db 1 ; default option
+
+.MenuData:
+	db STATICMENU_ENABLE_SELECT | STATICMENU_ENABLE_LEFT_RIGHT | STATICMENU_ENABLE_START | STATICMENU_WRAP ; flags
+	db 5, 8 ; rows, columns
+	db SCROLLINGMENU_ITEMS_QUANTITY ; item format
+	dbw 0, wNumBerries
+	dba PlaceMenuItemName
+	dba PlaceMenuItemQuantity
+	dba UpdateItemDescription

We saw BallsPocketMenuHeader used in the subroutines for the Start Menu Pack and the battle Pack, and PC_Mart_BallsPocketMenuHeader in the subroutine for the Pack when depositing or selling. Here they're finally being defined. And since we created the corresponding names BerryPocketMenuHeader and PC_Mart_BerryPocketMenuHeader, they need defining too; as usual, we can just copy whatever the Ball pocket does and substitute "Berry" for "Ball".

10. Update the Crystal-only Pack engine

Edit engine/items/pack_kris.asm:

 PackFGFXPointers:
 	dw PackFGFX + (15 tiles) * 1 ; ITEM_POCKET
 	dw PackFGFX + (15 tiles) * 3 ; BALL_POCKET
 	dw PackFGFX + (15 tiles) * 0 ; KEY_ITEM_POCKET
 	dw PackFGFX + (15 tiles) * 2 ; TM_HM_POCKET
+	dw PackFGFX + (15 tiles) * 4 ; BERRY_POCKET

This is just like PackGFXPointers, but for the Crystal-only girl's Pack.

11. Update Kurt's Apricorn script

If you did not change the Apricorns' pocket, then skip this step.

Kurt's script to turn Apricorns into Balls assumes they're still in the Item pocket. Fixing this is thankfully quick and easy. Edit engine/events/kurt.asm. There are five places in the code where we need to do this:

-	ld hl, wNumItems
+	ld hl, wNumBerries

Kurt_GetQuantityOfApricorn
Kurt_GiveUpSelectedQuantityOfSelectedApricorn
Kurt_GetAddressOfApricornQuantity
Kurt_GetRidOfItem
Kurt_GetRidOfItem.okay

Just use your text editor to find all five occurrences of "wNumItems" in the file, and make that one-line change to all of them.

12. Fix build errors

We're almost finished, but if you run make now, it gives an error:

error: engine/items/pack.asm(1243) : Value must be 8-bit

Line 1243 of engine/items/pack.asm is jr .DisplayPocket.

So, jr and jp both jump to the given label. But jp encodes the full two-byte address of the label, while jr saves a byte by encoding a one-byte distance to jump. That means it can only reach −128 to 127 bytes away from its own location. Some of the code we added must have made .DisplayPocket more than 128 bytes away from this jr instruction. Anyway, the solution is simple: change it to jp.

 TutorialPack:
 	...

 .Items:
 	xor a ; ITEM_POCKET
 	ld hl, .ItemsMenuHeader
-	jr .DisplayPocket
+	jp .DisplayPocket

(If you're adding more pockets, you might have more errors like this.)

We're finally done!

Screenshot

There are many other pockets you could add. Gen 4 had Medicine, Mail, and Battle pockets; there could also be a separate pocket for held items, or for a new type of item entirely.

Add a new Pack pocket - pret/pokecrystal GitHub Wiki

Contents

1. Define pocket-related constants

2. Give the pocket a name

3. Update the item types

4. Update the Pack graphics

5. Add space in WRAM for the new pocket

6. Initialize the new WRAM

7. Update `HasNoItems` and `CheckRegisteredItem` to check the new pocket

8. Update standard inventory routines

9. Update the Pack engine

10. Update the Crystal-only Pack engine

11. Update Kurt's Apricorn script

12. Fix build errors

⚠️ GitHub.com Fallback ⚠️

Add a new Pack pocket - pret/pokecrystal GitHub Wiki

Contents

1. Define pocket-related constants

2. Give the pocket a name

3. Update the item types

4. Update the Pack graphics

5. Add space in WRAM for the new pocket

6. Initialize the new WRAM

7. Update HasNoItems and CheckRegisteredItem to check the new pocket

8. Update standard inventory routines

9. Update the Pack engine

10. Update the Crystal-only Pack engine

11. Update Kurt's Apricorn script

12. Fix build errors

⚠️ **GitHub.com Fallback** ⚠️

7. Update `HasNoItems` and `CheckRegisteredItem` to check the new pocket

⚠️ GitHub.com Fallback ⚠️