summaryrefslogtreecommitdiff
path: root/engine/hidden_object_functions17.asm
diff options
context:
space:
mode:
Diffstat (limited to 'engine/hidden_object_functions17.asm')
-rwxr-xr-xengine/hidden_object_functions17.asm39
1 files changed, 27 insertions, 12 deletions
diff --git a/engine/hidden_object_functions17.asm b/engine/hidden_object_functions17.asm
index 01787e3e..aad8c468 100755
--- a/engine/hidden_object_functions17.asm
+++ b/engine/hidden_object_functions17.asm
@@ -71,7 +71,7 @@ DisplayMonFrontSpriteInBox: ; 5dbd9 (17:5bd9)
ld de, vChars1 + $310
call LoadMonFrontSprite
ld a, $80
- ld [$ffe1], a
+ ld [hStartTileID], a
coord hl, 10, 11
predef AnimateSendingOutMon
call WaitForTextScrollButtonPress
@@ -311,7 +311,7 @@ VermilionGymTrashText: ; 5ddf7 (17:5df7)
GymTrashScript: ; 5ddfc (17:5dfc)
call EnableAutoTextBoxDrawing
ld a, [wHiddenObjectFunctionArgument]
- ld [wcd5b], a
+ ld [wGymTrashCanIndex], a
; Don't do the trash can puzzle if it's already been done.
CheckEvent EVENT_2ND_LOCK_OPENED
@@ -320,12 +320,12 @@ GymTrashScript: ; 5ddfc (17:5dfc)
tx_pre_jump VermilionGymTrashText
.ok
- bit 1, a
+ CheckEventReuseA EVENT_1ST_LOCK_OPENED
jr nz, .trySecondLock
- ld a, [wd743]
+ ld a, [wFirstLockTrashCanIndex]
ld b, a
- ld a, [wcd5b]
+ ld a, [wGymTrashCanIndex]
cp b
jr z, .openFirstLock
@@ -337,7 +337,7 @@ GymTrashScript: ; 5ddfc (17:5dfc)
SetEvent EVENT_1ST_LOCK_OPENED
ld hl, GymTrashCans
- ld a, [wcd5b]
+ ld a, [wGymTrashCanIndex]
; * 5
ld b, a
add a
@@ -349,12 +349,21 @@ GymTrashScript: ; 5ddfc (17:5dfc)
add hl, de
ld a, [hli]
- ld [$ffdb], a
+; There is a bug in this code. It should calculate a value in the range [0, 3]
+; but if the mask and random number don't have any 1 bits in common, then
+; the result of the AND will be 0. When 1 is subtracted from that, the value
+; will become $ff. This will result in 255 being added to hl, which will cause
+; hl to point to one of the zero bytes that pad the end of the ROM bank.
+; Trash can 0 was intended to be able to have the second lock only when the
+; first lock was in trash can 1 or 3. However, due to this bug, trash can 0 can
+; have the second lock regardless of which trash can had the first lock.
+
+ ld [hGymTrashCanRandNumMask], a
push hl
call Random
swap a
ld b, a
- ld a, [$ffdb]
+ ld a, [hGymTrashCanRandNumMask]
and b
dec a
pop hl
@@ -364,15 +373,15 @@ GymTrashScript: ; 5ddfc (17:5dfc)
add hl, de
ld a, [hl]
and $f
- ld [wd744], a
+ ld [wSecondLockTrashCanIndex], a
tx_pre_id VermilionGymTrashSuccesText1
jr .done
.trySecondLock
- ld a, [wd744]
+ ld a, [wSecondLockTrashCanIndex]
ld b, a
- ld a, [wcd5b]
+ ld a, [wGymTrashCanIndex]
cp b
jr z, .openSecondLock
@@ -381,7 +390,7 @@ GymTrashScript: ; 5ddfc (17:5dfc)
call Random
and $e
- ld [wd743], a
+ ld [wFirstLockTrashCanIndex], a
tx_pre_id VermilionGymTrashFailText
jr .done
@@ -398,6 +407,12 @@ GymTrashScript: ; 5ddfc (17:5dfc)
jp PrintPredefTextID
GymTrashCans: ; 5de7d (17:5e7d)
+; byte 0: mask for random number
+; bytes 1-4: indices of the trash cans that can have the second lock
+; (but see the comment above explaining a bug regarding this)
+; Note that the mask is simply the number of valid trash can indices that
+; follow. The remaining bytes are filled with 0 to pad the length of each entry
+; to 5 bytes.
db 2, 1, 3, 0, 0 ; 0
db 3, 0, 2, 4, 0 ; 1
db 2, 1, 5, 0, 0 ; 2