WIP: fix(vk): one slow load no longer takes an install back to loading before the title #94

Draft

HumanBean wants to merge 3 commits from HumanBean/Longshot:fix/load-wait-rule into main

pull from: HumanBean/Longshot:fix/load-wait-rule

merge into: MagicBeanDev:main

MagicBeanDev:main

Conversation 1 Commits 3 Files changed 6 +94 -21

HumanBean commented 2026-11-13 02:31:38 +00:00

Owner

• Copy link
• Copy Markdown

Why

Loads at create calls have a safety net: a session whose first uses wait too long for their loads leaves longshot_load_start.txt, and every later start loads all listed programs before the title again. One wait over 100 ms was enough to leave it, and the marker is permanent and costs memory at every later start. On an RTX 3090, while other work was taking the PC's memory, one first use waited 261 ms for a load (322 ms in that session). The next start of that healthy install loaded everything before the title: 8.6 GB of heap in use in the first area where the session before had 4.2 GB.

What changed

• vk, the rule (gpu/vk/load_default.h, used from gpu/vk/vk_programs.cpp; the preparation's cleanup in gpu/vk/vk_draw.cpp):
  • Only waits longer than 20 ms count.
  • Over 2 s of them in one session: the marker at once.
  • Over 500 ms: the marker only if the session before was over it too. The first such session leaves longshot_load_start.txt.waited, which the next start takes away, so it is two sessions running, not two ever. A preparation removes it with the marker.
• Counting only long waits also stops a long healthy session from reaching the total by many small waits.
• The price: a PC between 500 ms and 2 s a session has two such sessions before it goes back to loading before the title, where it had one.
• docs: the RX_VK_LOAD row of docs/development.md describes the new rule.
• tests: tests/test_load_default.py and tests/load_default_test.cpp: the measured sessions below against the rule, the strike file written and taken once, a preparation removing it.
• The branch has main merged in (the rename to Longshot).

Flags and settings

None. No switch, menu row or ini key is added or changed. What changes is when the default of RX_VK_LOAD goes back to start (the rule above), and one new file beside the marker in the game folder, longshot_load_start.txt.waited.

Measurements

main: 4dd972a8 (2026-11-12)
this PR: fix/load-wait-rule @ 3a297868
Hardware: RTX 3090, Linux, and RTX 4070 SUPER, for the healthy sessions and the injected runs; RX 580, 16 GB, for the sessions where loads at create do not work (drivers, CPUs and the other PCs' RAM not recorded in this description)
Scene: a short session: the first area, a teleport, a second area (a tour)
Method: the first-use waits for loads each session logged, and the files it left; for this PR, real starts in a folder of its own prepared by --prepare-shaders (the table under "Game runs")
How to reproduce: prepare a game folder with --prepare-shaders, start it with RX_VK_LOAD=create, play the first area, a teleport and a second area, and read the log's line on the first-use waits and whether longshot_load_start.txt or longshot_load_start.txt.waited is in the game folder after; then start without the switch to see what the default picks

What each column is, and on which commit. The main column is the old rule, as main @ 4dd972a8 has it (the commit this change was made on), applied to each session's waits. The sessions that ran on main itself (the one bad moment, and the RX 580's two sessions below) ran on main before this change; their commits are not recorded in this description. The game runs of this PR were made on 3a297868, the commit before the merge of main that brought the rename (same code, old file names), because the build tool at hand could not build a game folder from the renamed tree; the branch's final commit, d0dd2a4c, has not run in a game. The RX 580 has not run the new rule: its row is the rule applied to its measured sessions.

	main @ 4dd972a8	this PR @ 3a297868
healthy (RTX 3090, RTX 4070 SUPER): 10-25 ms of waits a tour, the longest 2-7 ms	nothing	nothing (none of them counts)
one bad moment on a healthy PC: one wait of 261 ms, 322 ms in all	marker	nothing
loads at create do not work (RX 580, 16 GB): tours of 2.5-4.7 s of waits, the longest 0.7-1.3 s; also one session of 62.6 ms	marker in each session over the limits; nothing for the 62.6 ms one	the same: marker in its first session over 2 s

The RX 580 on the old rule, for reference

Main before this change, loads at create calls forced (RX_VK_LOAD=create), a cold preparation and two sessions of the same tour:

	session 1 (first start after the preparation)	session 2
first-use waits for loads	3 waits, 62.6 ms	17 waits, 2,558.9 ms
listed pipelines in no cache at their load	0 of 11,261	0 of 11,264
draws and dispatches left out	10	2
marker after	not written	written
peak memory (limit 12 GB + 4 GB swap)	14.7 GB	15.0 GB

The new rule gives the same result on these two sessions: nothing after the first, the marker after the second (over 2 s). That PC is not over the limit in every session; it is taken back at the first one that is.

Game runs

RTX 3090, Linux, a folder of its own prepared by --prepare-shaders; each row is a real start and a short session (the first area, a teleport, a second area), started with RX_VK_LOAD=create. The "next start" column is a start without that switch, to show what the default picks.

The long waits were injected: a test-only switch, not part of this change, makes the first N first uses that meet an unfinished load take a set time longer, inside the time the safety net measures. The rule's own code ran unchanged. No long wait could be produced without it on this PC (see the last row).

session, in the order run	waits counted (over 20 ms)	what the log said	files after	next start
healthy, first start after the preparation	27 ms (8 first uses met a load, 31 ms in all)	nothing	none
one wait of 300 ms	300 ms	nothing	none	create
two waits of 300 ms	601 ms	"over 500 ms. Once is let pass"	.waited
one wait of 300 ms, right after	300 ms	nothing	none: the strike was taken and not renewed	create
healthy	0 ms (23 first uses met a load, 32 ms in all, longest 5.9 ms)	nothing	none
two waits of 300 ms	600 ms	"Once is let pass"	.waited
waits of 600 ms, right after	over 500 ms at the first	"over 500 ms, as the session before this one was"	marker	start
two waits of 300 ms, the marker already there	600 ms	"Once is let pass"	marker and .waited
a preparation (--prepare-shaders)			none: both removed	create
healthy, first start after it	0 ms (11 first uses met a load, 6.6 ms in all)	nothing	none
one wait of 2,100 ms	2,136 ms	"over 2000 ms, so the next start loads every listed program before the title again"	marker	start
no load workers at all (RX_VK_LOAD_WORKERS=0), nothing injected	0 ms: 1,157 first uses ran their load themselves, 1,743 ms in all, the longest 16.2 ms	nothing	none

• The last row is a real difference from the old rule, which would have left the marker there (over 500 ms in all): many waits that are each under 20 ms no longer count, however many there are. That is what keeps a long healthy session from adding up; it also means a PC whose every first use runs its own load in under 20 ms is not taken back.

Not measured: the bug reproduced and gone as one pair of runs at two named commits (the bad moment happened once on main and could not be produced again on this PC without the injection); fps and frame times, which this change does not target. The log lines are quoted in the table in part, not pasted whole.

Testing

Tested:

• tests/test_load_default.py: the measured sessions above against the rule, the strike file written and taken once, a preparation removing it.
• The other tests that read the touched files pass. The renderer builds on Linux.
• The renderer build and these tests were run after main (the rename to Longshot) was merged into the branch.
• In the game: the runs under "Game runs" (RTX 3090, Linux), on the commit before the rename, with the long waits injected by a test-only switch that is not part of this PR.

Not tested:

• Long waits that are real and not injected: none could be produced on this PC. A slow PC (the RX 580) has not run the new rule.
• That the RX 580's seconds of waits are mostly waits over 20 ms is assumed (longest waits of 0.7-1.3 s; 2,559 ms over 17 waits in the run above), not counted.
• The full test suite (tests/run_all.py).
• A game built from the renamed tree, and so the branch's final commit, in the game.

Needs other testers:

• A PC where loads at create are slow (an RX 580, with RX_VK_LOAD=create): the tour above after a preparation, expecting longshot_load_start.txt after the first session whose counted waits are over 2 s, and nothing after a session under 500 ms (request to open)

Screenshots

Nothing on screen.

Risk and rollback

A PC between 500 ms and 2 s of counted waits a session now has two such sessions before it goes back to loading before the title, where it had one. A PC whose every first use runs its own load in under 20 ms is not taken back at all, however many there are. There is no switch for the rule: RX_VK_LOAD=start forces loading before the title on any install, and reverting the commit brings the old rule back. A leftover longshot_load_start.txt.waited is removed by the next start or by a preparation.

Reviewer notes

Read gpu/vk/load_default.h first (the rule and the strike file), then its use in gpu/vk/vk_programs.cpp. The test-only switch that injected the waits is not in this PR, on purpose.

Issues

None.

Checklist

For everyone

• One topic.
• The title is a Conventional Commit (type(scope): description).
• Rebased on current main. (Not rebased: main was merged into the branch, and main has moved on since that merge.)
• python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above). (Not run: only the tests that read the touched files.)
• Tested in the game, or what wasn't is named under Testing.
• Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). (Filled in; the test request is still to open.)
• Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (The sessions on main ran on commits not recorded here, the PR's runs on the commit before the rename with injected waits, and the slow PC has not run the new rule.)
• No game files, dumps, build output or generated files.
• third_party/ untouched (a new folder with a PROVENANCE.md instead).
• The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

• AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
• Flags table filled in; README / docs/development.md switch reference updated. (No flag added; the RX_VK_LOAD row of docs/development.md is updated.)
• Screenshots for a change that shows on screen. (n/a)
• A row in docs/tested-configurations.md for each measured run. (Not added.)
• MKWVK_API_VERSION bumped (gpu/vk/vk_api.h's MkwVkHost or MkwVkRenderer changed). (n/a)
• The SPIR-V headers regenerated with glslang (a shader changed). (n/a)
• A game-free test added for the fix, failing on main and passing here. (tests/test_load_default.py is extended for the new rule; it was not run against main.)
• A check under tests/ that reads changed source updated in this PR, not weakened.
• Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (The renderer builds on Linux; Windows not built.)
• Docs updated.

## Why Loads at create calls have a safety net: a session whose first uses wait too long for their loads leaves `longshot_load_start.txt`, and every later start loads all listed programs before the title again. One wait over 100 ms was enough to leave it, and the marker is permanent and costs memory at every later start. On an RTX 3090, while other work was taking the PC's memory, one first use waited 261 ms for a load (322 ms in that session). The next start of that healthy install loaded everything before the title: 8.6 GB of heap in use in the first area where the session before had 4.2 GB. ## What changed - vk, the rule (`gpu/vk/load_default.h`, used from `gpu/vk/vk_programs.cpp`; the preparation's cleanup in `gpu/vk/vk_draw.cpp`): - Only waits longer than 20 ms count. - Over 2 s of them in one session: the marker at once. - Over 500 ms: the marker only if the session before was over it too. The first such session leaves `longshot_load_start.txt.waited`, which the next start takes away, so it is two sessions running, not two ever. A preparation removes it with the marker. - Counting only long waits also stops a long healthy session from reaching the total by many small waits. - The price: a PC between 500 ms and 2 s a session has two such sessions before it goes back to loading before the title, where it had one. - docs: the `RX_VK_LOAD` row of `docs/development.md` describes the new rule. - tests: `tests/test_load_default.py` and `tests/load_default_test.cpp`: the measured sessions below against the rule, the strike file written and taken once, a preparation removing it. - The branch has main merged in (the rename to Longshot). ## Flags and settings None. No switch, menu row or ini key is added or changed. What changes is when the default of `RX_VK_LOAD` goes back to `start` (the rule above), and one new file beside the marker in the game folder, `longshot_load_start.txt.waited`. ## Measurements main: 4dd972a8 (2026-11-12) this PR: fix/load-wait-rule @ 3a297868 Hardware: RTX 3090, Linux, and RTX 4070 SUPER, for the healthy sessions and the injected runs; RX 580, 16 GB, for the sessions where loads at create do not work (drivers, CPUs and the other PCs' RAM not recorded in this description) Scene: a short session: the first area, a teleport, a second area (a tour) Method: the first-use waits for loads each session logged, and the files it left; for this PR, real starts in a folder of its own prepared by `--prepare-shaders` (the table under "Game runs") How to reproduce: prepare a game folder with `--prepare-shaders`, start it with `RX_VK_LOAD=create`, play the first area, a teleport and a second area, and read the log's line on the first-use waits and whether `longshot_load_start.txt` or `longshot_load_start.txt.waited` is in the game folder after; then start without the switch to see what the default picks **What each column is, and on which commit.** The main column is the old rule, as main @ 4dd972a8 has it (the commit this change was made on), applied to each session's waits. The sessions that ran on main itself (the one bad moment, and the RX 580's two sessions below) ran on main before this change; their commits are not recorded in this description. The game runs of this PR were made on 3a297868, the commit before the merge of main that brought the rename (same code, old file names), because the build tool at hand could not build a game folder from the renamed tree; the branch's final commit, d0dd2a4c, has not run in a game. The RX 580 has not run the new rule: its row is the rule applied to its measured sessions. | | main @ 4dd972a8 | this PR @ 3a297868 | |---|---|---| | healthy (RTX 3090, RTX 4070 SUPER): 10-25 ms of waits a tour, the longest 2-7 ms | nothing | nothing (none of them counts) | | one bad moment on a healthy PC: one wait of 261 ms, 322 ms in all | marker | nothing | | loads at create do not work (RX 580, 16 GB): tours of 2.5-4.7 s of waits, the longest 0.7-1.3 s; also one session of 62.6 ms | marker in each session over the limits; nothing for the 62.6 ms one | the same: marker in its first session over 2 s | ### The RX 580 on the old rule, for reference Main before this change, loads at create calls forced (`RX_VK_LOAD=create`), a cold preparation and two sessions of the same tour: | | session 1 (first start after the preparation) | session 2 | |---|---|---| | first-use waits for loads | 3 waits, 62.6 ms | 17 waits, 2,558.9 ms | | listed pipelines in no cache at their load | 0 of 11,261 | 0 of 11,264 | | draws and dispatches left out | 10 | 2 | | marker after | not written | written | | peak memory (limit 12 GB + 4 GB swap) | 14.7 GB | 15.0 GB | The new rule gives the same result on these two sessions: nothing after the first, the marker after the second (over 2 s). That PC is not over the limit in every session; it is taken back at the first one that is. ### Game runs RTX 3090, Linux, a folder of its own prepared by `--prepare-shaders`; each row is a real start and a short session (the first area, a teleport, a second area), started with `RX_VK_LOAD=create`. The "next start" column is a start without that switch, to show what the default picks. The long waits were **injected**: a test-only switch, not part of this change, makes the first N first uses that meet an unfinished load take a set time longer, inside the time the safety net measures. The rule's own code ran unchanged. No long wait could be produced without it on this PC (see the last row). | session, in the order run | waits counted (over 20 ms) | what the log said | files after | next start | |---|---|---|---|---| | healthy, first start after the preparation | 27 ms (8 first uses met a load, 31 ms in all) | nothing | none | | | one wait of 300 ms | 300 ms | nothing | none | create | | two waits of 300 ms | 601 ms | "over 500 ms. Once is let pass" | `.waited` | | | one wait of 300 ms, right after | 300 ms | nothing | none: the strike was taken and not renewed | create | | healthy | 0 ms (23 first uses met a load, 32 ms in all, longest 5.9 ms) | nothing | none | | | two waits of 300 ms | 600 ms | "Once is let pass" | `.waited` | | | waits of 600 ms, right after | over 500 ms at the first | "over 500 ms, as the session before this one was" | marker | start | | two waits of 300 ms, the marker already there | 600 ms | "Once is let pass" | marker and `.waited` | | | a preparation (`--prepare-shaders`) | | | none: both removed | create | | healthy, first start after it | 0 ms (11 first uses met a load, 6.6 ms in all) | nothing | none | | | one wait of 2,100 ms | 2,136 ms | "over 2000 ms, so the next start loads every listed program before the title again" | marker | start | | no load workers at all (`RX_VK_LOAD_WORKERS=0`), nothing injected | 0 ms: 1,157 first uses ran their load themselves, 1,743 ms in all, the longest 16.2 ms | nothing | none | | - The last row is a real difference from the old rule, which would have left the marker there (over 500 ms in all): many waits that are each under 20 ms no longer count, however many there are. That is what keeps a long healthy session from adding up; it also means a PC whose every first use runs its own load in under 20 ms is not taken back. Not measured: the bug reproduced and gone as one pair of runs at two named commits (the bad moment happened once on main and could not be produced again on this PC without the injection); fps and frame times, which this change does not target. The log lines are quoted in the table in part, not pasted whole. ## Testing **Tested:** - `tests/test_load_default.py`: the measured sessions above against the rule, the strike file written and taken once, a preparation removing it. - The other tests that read the touched files pass. The renderer builds on Linux. - The renderer build and these tests were run after main (the rename to Longshot) was merged into the branch. - In the game: the runs under "Game runs" (RTX 3090, Linux), on the commit before the rename, with the long waits injected by a test-only switch that is not part of this PR. **Not tested:** - Long waits that are real and not injected: none could be produced on this PC. A slow PC (the RX 580) has not run the new rule. - That the RX 580's seconds of waits are mostly waits over 20 ms is assumed (longest waits of 0.7-1.3 s; 2,559 ms over 17 waits in the run above), not counted. - The full test suite (`tests/run_all.py`). - A game built from the renamed tree, and so the branch's final commit, in the game. **Needs other testers:** - A PC where loads at create are slow (an RX 580, with `RX_VK_LOAD=create`): the tour above after a preparation, expecting `longshot_load_start.txt` after the first session whose counted waits are over 2 s, and nothing after a session under 500 ms (request to open) ## Screenshots Nothing on screen. ## Risk and rollback A PC between 500 ms and 2 s of counted waits a session now has two such sessions before it goes back to loading before the title, where it had one. A PC whose every first use runs its own load in under 20 ms is not taken back at all, however many there are. There is no switch for the rule: `RX_VK_LOAD=start` forces loading before the title on any install, and reverting the commit brings the old rule back. A leftover `longshot_load_start.txt.waited` is removed by the next start or by a preparation. ## Reviewer notes Read `gpu/vk/load_default.h` first (the rule and the strike file), then its use in `gpu/vk/vk_programs.cpp`. The test-only switch that injected the waits is not in this PR, on purpose. ## Issues None. ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [ ] Rebased on current `main`. (Not rebased: main was merged into the branch, and main has moved on since that merge.) - [ ] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). (Not run: only the tests that read the touched files.) - [x] Tested in the game, or what wasn't is named under Testing. - [ ] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). (Filled in; the test request is still to open.) - [ ] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (The sessions on main ran on commits not recorded here, the PR's runs on the commit before the rename with injected waits, and the slow PC has not run the new rule.) - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [ ] Flags table filled in; README / docs/development.md switch reference updated. (No flag added; the `RX_VK_LOAD` row of docs/development.md is updated.) - [ ] Screenshots for a change that shows on screen. (n/a) - [ ] A row in `docs/tested-configurations.md` for each measured run. (Not added.) - [ ] `MKWVK_API_VERSION` bumped (`gpu/vk/vk_api.h`'s `MkwVkHost` or `MkwVkRenderer` changed). (n/a) - [ ] The SPIR-V headers regenerated with glslang (a shader changed). (n/a) - [ ] A game-free test added for the fix, failing on `main` and passing here. (`tests/test_load_default.py` is extended for the new rule; it was not run against main.) - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (The renderer builds on Linux; Windows not built.) - [x] Docs updated.

HumanBean added 3 commits 2026-11-13 02:31:38 +00:00

fix(vk): one slow load no longer takes an install back to loading before the title ... 3a2978689f

Loads at create calls have a safety net: a session whose first uses wait too long for their loads leaves
hookshot_load_start.txt, and every later start loads all listed programs before the title again, 4-5 GB more memory for
good. One wait over 100 ms was enough. On an RTX 3090, with other work taking the PC's memory, one first use waited
261 ms (322 ms in that session), and the next start of a healthy install was in start mode: 8.6 GB of heap where it had
4.2 GB.

The rule now:
- only waits longer than 20 ms count. A healthy session's are 2-7 ms each (10-25 ms a tour), so they no longer add up
  over a long session either;
- over 2 s of them in one session: the marker at once. The PC where loads at create do not work (RX 580, 16 GB) had
  2.5-4.7 s in every tour;
- over 500 ms: the marker only if the session before was over it too. The first such session leaves
  hookshot_load_start.txt.waited, which the next start takes away, so it is two sessions running, not two ever. A
  preparation removes it with the marker.

The 261 ms session leaves nothing. Not run in a game: the rule and the strike file are unit tested, the source check
covers the wiring.

Co-Authored-By: Claude Fable 5.2 <[email protected]>

Merge main (the rename to Longshot) into the load safety net's wait rule ... c01c7dea74

Conflicts in docs/development.md, gpu/vk/vk_draw.cpp, gpu/vk/vk_programs.cpp and tests/test_load_default.py: this
branch's side with the rename as main made it on the same lines (longshot_load_start.txt, longshot_module_ids.bin). The
strike file follows the marker's name (longshot_load_start.txt.waited), in the code, the source check and the unit test.

Co-Authored-By: Claude Fable 5.2 <[email protected]>

docs(vk): the wait rule's comment says what the RX 580 really measured ... d0dd2a4c39

It said every session of that PC was over 2 s of first-use waits. A run of main there had one session of 62.6 ms
followed by one of 2,559 ms: the rule takes it back at its first session over 2 s, not always at its first. The unit
test has the 62.6 ms session too.

Co-Authored-By: Claude Fable 5.2 <[email protected]>

HumanBean commented 2026-11-13 02:36:53 +00:00

Author

Owner

• Copy link
• Copy Markdown

The description is now in the template's sections. No code changed and no new numbers: the same facts as before, with the commits the measurements were taken on named, and the checklist ticked only where true. It stays work in progress: the full test suite was not run, the test request is not open, and the game runs were on the commit before the rename.

The description is now in the template's sections. No code changed and no new numbers: the same facts as before, with the commits the measurements were taken on named, and the checklist ticked only where true. It stays work in progress: the full test suite was not run, the test request is not open, and the game runs were on the commit before the rename.

Some checks failed

Hide checks

Game-free source regressions / Python source checks (windows-2022, part 1/2) (pull_request) Waiting to run

Details

Game-free source regressions / Python source checks (windows-2022, part 2/2) (pull_request) Waiting to run

Details

Linux AppImage / appimage (pull_request) Failing after 2s

Details

Linux AppImage / Release asset (pull_request) Has been skipped

Details

Game-free source regressions / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Failing after 7m31s

Details

Game-free source regressions / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Failing after 4m13s

Details

Game-free source regressions / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Failing after 33s

Details

Game-free source regressions / Workflow lint (actionlint) (pull_request) Successful in 3s

Details

Windows builder / Longshot Builder package and setup (pull_request) Has been cancelled

Details

Windows builder / Windows Vulkan back end (llvm-mingw) (pull_request) Has been cancelled

Details

Windows builder / dav1d for Windows (llvm-mingw) (pull_request) Has been cancelled

Details

Windows builder / Release assets (pull_request) Has been cancelled

Details

PR description / Description follows the template (pull_request_target) Successful in 2s

Details

This pull request is marked as a work in progress.

This branch is out-of-date with the base branch

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u 'fix/load-wait-rule:HumanBean-fix/load-wait-rule'

git switch 'HumanBean-fix/load-wait-rule'

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

accessibility

Barrier affecting people with disabilities

  

autorelease: pending

  

autorelease: tagged

  

bug

Something isn't working

  

dependencies

Pull requests that update a dependency file

  

documentation

Improvements or additions to documentation

  

duplicate

This issue or pull request already exists

  

enhancement

New feature or request

  

github_actions

Pull requests that update GitHub Actions code

  

good first issue

Good for newcomers

  

help wanted

Extra attention is needed

  

invalid

This doesn't seem right

  

needs measurements

Waiting for before/after measurements

  

question

Further information is requested

  

testing wanted

Wanted: a test on other hardware (posts a test request in #test-requests)

  

wontfix

This will not be worked on

No labels

accessibility

autorelease: pending

autorelease: tagged

bug

dependencies

documentation

duplicate

enhancement

github_actions

good first issue

help wanted

invalid

needs measurements

question

testing wanted

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

MagicBeanDev/Longshot!94

No description provided.