Game: the Deku Tree floor web stays visually rigid above 60 fps #86

New issue

Open

opened 2026-11-13 02:27:27 +00:00 by mooki · 0 comments

mooki commented

2026-11-13 02:27:27 +00:00

Longshot version

Original report: Hookshot v2.1.0. Reproduced again on Longshot main d3bd2805; the relevant carry table remains unchanged on main 6b2dafefe.

What kind of problem

Graphics (missing, black or wrong-coloured things, lighting, flicker)

What happened

yoanmenard008-eng reported a web that does not react in the Great Deku Tree, then clarified that collision still works but the web stays visually fixed. I reproduced the above-60 case and posted the original fix.

Longshot pull request 49 carries the fix and fresh Longshot evidence. Two interleaved high-rate comparisons on Linux/RTX 4090 showed zero delivered web steps and one unchanged height vector on main, versus about 60 steps per second and hundreds of changing height vectors with the fix. These rates establish the above-60 condition, not a speed improvement.

The web discards fractional simulation time before its existing step limit. The fix carries the fraction per web object using the existing mechanism. It is not yet on main and does not claim to repair every above-60 gameplay fault. The open pull request addresses this specific report in full within its stated scope.

Until a build includes the fix, a 60 cap is the known workaround. Windows and AMD gameplay and the reporter's exact hardware have not been checked by me. Movement is subtle in still pictures; the step/height observations are the primary proof.

Where in the game

Great Deku Tree, jumping onto the floor web.

How often

Every time in the original report; reproduced in both completed Longshot high-rate baseline runs.

Graphics card and driver version

Reporter supplied only “AMD,” no model or driver. My Longshot comparisons: RTX 4090, NVIDIA 615.78.08.

CPU, RAM and operating system

Reporter supplied only “7800”; model, RAM and OS unknown. My comparisons: Core i9-13900K, 94 GiB usable RAM, Arch Linux kernel 7.2.15-1-omarchy.

Changes from the defaults

Reporter did not list changes. My comparisons used 1280×720, the game's upscaler at 50%, frame generation off, Real time and caps 60/240; the high-rate pairs actually exceeded 60.

Other software hooked into the game

Reporter says none. My comparisons were windowless with read-only web observations. Original log and comparison evidence remain linked from the report and pull request.

Reported on GitHub as NotRexed/Hookshot#2667; taken on there by mooki.

### Longshot version Original report: Hookshot v2.1.0. Reproduced again on Longshot main `d3bd2805`; the relevant carry table remains unchanged on main `6b2dafefe`. ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened [yoanmenard008-eng reported](https://github.com/NotRexed/Hookshot/issues/2667) a web that does not react in the Great Deku Tree, then clarified that collision still works but the web stays visually fixed. I [reproduced the above-60 case and posted the original fix](https://github.com/NotRexed/Hookshot/issues/2667#issuecomment-6834996469). [Longshot pull request 49](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/49) carries the fix and fresh Longshot evidence. Two interleaved high-rate comparisons on Linux/RTX 4090 showed zero delivered web steps and one unchanged height vector on main, versus about 60 steps per second and hundreds of changing height vectors with the fix. These rates establish the above-60 condition, not a speed improvement. The web discards fractional simulation time before its existing step limit. The fix carries the fraction per web object using the existing mechanism. It is not yet on main and does not claim to repair every above-60 gameplay fault. The open pull request addresses this specific report in full within its stated scope. Until a build includes the fix, a 60 cap is the known workaround. Windows and AMD gameplay and the reporter's exact hardware have not been checked by me. Movement is subtle in still pictures; the step/height observations are the primary proof. ### Where in the game Great Deku Tree, jumping onto the floor web. ### How often Every time in the original report; reproduced in both completed Longshot high-rate baseline runs. ### Graphics card and driver version Reporter supplied only “AMD,” no model or driver. My Longshot comparisons: RTX 4090, NVIDIA 615.78.08. ### CPU, RAM and operating system Reporter supplied only “7800”; model, RAM and OS unknown. My comparisons: Core i9-13900K, 94 GiB usable RAM, Arch Linux kernel 7.2.15-1-omarchy. ### Changes from the defaults Reporter did not list changes. My comparisons used 1280×720, the game's upscaler at 50%, frame generation off, Real time and caps 60/240; the high-rate pairs actually exceeded 60. ### Other software hooked into the game Reporter says none. My comparisons were windowless with read-only web observations. Original log and comparison evidence remain linked from the report and pull request. Reported on GitHub as NotRexed/Hookshot#2667; taken on there by mooki.

mooki referenced this issue from a pull request that will close it,

2026-11-13 02:39:10 +00:00

fix(runtime): let the floor web react above 60 fps #49