MagicBeanDev/Hookshot

Archived

Watch

Fork 0

Stuck at inventory when given the Kokiri Emerald #2007

Closed

opened 2026-11-10 23:28:44 +00:00 by Elvitt0 · 4 comments

Elvitt0 commented

2026-11-10 23:28:44 +00:00

(Migrated from github.com)

Hookshot version

2.0.14

What kind of problem

Crash, freeze or black screen

What happened

Since version 2.0.9 the game gets stuck in the inventory screen right when the deku tree gives link the Kokiri Emerald.
It doesn't crash, the game is still running at 60fps, even the particle effects from the menu keep moving. But nothing happens.

Where in the game

Deku Tree, after beating Queen Gohma

How often

Every time

Graphics card and driver version

rtx 5070ti 595.112.07

CPU, RAM and operating system

ryzen 9 5900XT NobaraOS

Changes from the defaults

No response

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

Screenshots or video

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version 2.0.14 ### What kind of problem Crash, freeze or black screen ### What happened Since version 2.0.9 the game gets stuck in the inventory screen right when the deku tree gives link the Kokiri Emerald. It doesn't crash, the game is still running at 60fps, even the particle effects from the menu keep moving. But nothing happens. ### Where in the game Deku Tree, after beating Queen Gohma ### How often Every time ### Graphics card and driver version rtx 5070ti 595.112.07 ### CPU, RAM and operating system ryzen 9 5900XT NobaraOS ### Changes from the defaults _No response_ ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.txt](https://github.com/user-attachments/files/34657192/hookshot_log.txt) ### Screenshots or video <img width="2560" height="1440" alt="Screenshot_20261110_202014" src="https://github.com/user-attachments/assets/fe609c6f-a9f4-4965-bfc8-bea524d05bb6" /> ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

NotRexed commented

2026-11-11 00:17:05 +00:00

(Migrated from github.com)

Thanks. What's your Frame rate cap in the Insert menu? Above 60, some frame-counted parts of the game stop advancing (#1742), which can leave the game stuck in a menu or cutscene; please try the cap at 60 and say whether you can get past the Kokiri Emerald then.

Elvitt0 commented

2026-11-11 00:54:36 +00:00

(Migrated from github.com)

Where do I see that? I haven't changed anything, I just launched it once it finished recompiling.

mooki000 commented

2026-11-11 04:56:40 +00:00

(Migrated from github.com)

A data point from the same kind of machine (Linux, RTX 4090, NVIDIA 615.78.08), and something in the logs that may tie this to #1929.

On current main the ending plays through here. From a save in Gohma's room, at the default settings (cap 60), headless: the blue warp, the Deku Tree's talk, the story movie to its end, the Kokiri Emerald, the pause menu's Key Items page with the emerald in its first place (the first tab reads "Key Items", where your screenshot has "???"), and back to the Deku Tree. One run on main at bdfe09c, on a heavily loaded machine, so it rules nothing out by itself.

What differs in the logs. In your log, right after the story movie's decoder starts, the movie player's own threads are let run without a virtual core (the escape of #1929); three lines of it, others left out:

[hos MovieOperateThread] video: AV1 decoder ready (1920x1080)
[hos ムービー入力読込] vcores: ムービー入力読込 (priority 17) ran without a core after 250.7 ms: core 5: BaseProcExecutor5 (16);
[hos MovieEventHandleThread] vcores: MovieEventHandleThread (priority 17) ran without a core after 250.7 ms: core 4: BaseProcExecutor4 (16);

I counted this in every log attached here and to #1919 (the white screen in the same scene), and in my own runs:

Logs	Version	Movie decoder starts	Escapes in all	Escapes by the movie's threads
#2007 (1 log) and #1919 (5 logs)	v2.0.14	1 or 2 per log	20 to 27 per log	1 to 5 per log; in every log at least one within 200 log lines of a decoder start
8 runs of mine with a movie (title, new game, this ending)	main `bdfe09c`	14	50	0

(Movie threads: MovieOperateThread, MovieEventHandleThread, MovieMediaSourceClient and the input reader ムービー入力読込.) Two of the #1919 logs end with MovieOperateThread: joining ムービー入力読込 for 10 s, the same input thread that escapes here.

So a guess, not a finding: an escaped movie thread sharing a core's state with its holder breaks the movie player, and what follows the movie (the emerald screen here, the white screen in #1919) never finishes. bdfe09c has 9f42700e ("WaitAny's scan makes no vcore checkpoint while it holds mw_lock"), and so does v2.1.0; #2127 is meant to make escapes rarer still.

@Elvitt0, could you try the same save on v2.1.0? If it still sticks, the log of that run would show whether the movie's threads still escape.

Corrected 2026-11-11 16:37 UTC: my own runs since then do not support the guess above. On v2.0.14 here (Linux, RTX 4090, cap 60, the game held to 12 CPUs) the whole ending passed in 3 of 3 runs while the movie's threads escaped as in your log: 2 or 3 escapes at the story movie's start, 19 to 25 escapes per run in all. So an escaped movie thread at the movie's start does not by itself stick this screen. What does is not found yet; I have not reproduced the stuck page on any build.

A data point from the same kind of machine (Linux, RTX 4090, NVIDIA 615.78.08), and something in the logs that may tie this to #1929. **On current main the ending plays through here.** From a save in Gohma's room, at the default settings (cap 60), headless: the blue warp, the Deku Tree's talk, the story movie to its end, the Kokiri Emerald, the pause menu's Key Items page with the emerald in its first place (the first tab reads "Key Items", where your screenshot has "???"), and back to the Deku Tree. One run on main at bdfe09c, on a heavily loaded machine, so it rules nothing out by itself. **What differs in the logs.** In your log, right after the story movie's decoder starts, the movie player's own threads are let run without a virtual core (the escape of #1929); three lines of it, others left out: ``` [hos MovieOperateThread] video: AV1 decoder ready (1920x1080) [hos ムービー入力読込] vcores: ムービー入力読込 (priority 17) ran without a core after 250.7 ms: core 5: BaseProcExecutor5 (16); [hos MovieEventHandleThread] vcores: MovieEventHandleThread (priority 17) ran without a core after 250.7 ms: core 4: BaseProcExecutor4 (16); ``` I counted this in every log attached here and to #1919 (the white screen in the same scene), and in my own runs: | Logs | Version | Movie decoder starts | Escapes in all | Escapes by the movie's threads | |---|---|---|---|---| | #2007 (1 log) and #1919 (5 logs) | v2.0.14 | 1 or 2 per log | 20 to 27 per log | 1 to 5 per log; in every log at least one within 200 log lines of a decoder start | | 8 runs of mine with a movie (title, new game, this ending) | main bdfe09c | 14 | 50 | 0 | (Movie threads: `MovieOperateThread`, `MovieEventHandleThread`, `MovieMediaSourceClient` and the input reader `ムービー入力読込`.) Two of the #1919 logs end with `MovieOperateThread: joining ムービー入力読込 for 10 s`, the same input thread that escapes here. So a guess, not a finding: an escaped movie thread sharing a core's state with its holder breaks the movie player, and what follows the movie (the emerald screen here, the white screen in #1919) never finishes. bdfe09c has 9f42700e ("WaitAny's scan makes no vcore checkpoint while it holds mw_lock"), and so does v2.1.0; #2127 is meant to make escapes rarer still. @Elvitt0, could you try the same save on v2.1.0? If it still sticks, the log of that run would show whether the movie's threads still escape. *Corrected 2026-11-11 16:37 UTC: my own runs since then do not support the guess above. On v2.0.14 here (Linux, RTX 4090, cap 60, the game held to 12 CPUs) the whole ending passed in 3 of 3 runs while the movie's threads escaped as in your log: 2 or 3 escapes at the story movie's start, 19 to 25 escapes per run in all. So an escaped movie thread at the movie's start does not by itself stick this screen. What does is not found yet; I have not reproduced the stuck page on any build.*

NotRexed commented

2026-11-11 21:24:37 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #2506, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #2506 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.

Commenting is not possible because the repository is archived.