Skip to content

Add page: offer the game's fixes right after a Fetch - #40

Closed
cheapmanga wants to merge 1 commit into
madoiscool:mainfrom
cheapmanga:feature/fetch-fix-banner
Closed

Add page: offer the game's fixes right after a Fetch#40
cheapmanga wants to merge 1 commit into
madoiscool:mainfrom
cheapmanga:feature/fetch-fix-banner

Conversation

@cheapmanga

Copy link
Copy Markdown

After a Fetch on the Add page, when the game has published fixes, a banner names them and takes you there:

This game has 2 fix(es) available: SteamTools Achievements Fix, voices38 (crack). [ See fixes ]

The button opens the Fixes page with that game already unfolded — the same route luatools://fix/ takes.

Why it names the kind. The endpoint is /api/denuvo/listings, but of the 1759 games it returns, 1621 are tagged "Online Fix" and no tag named "Denuvo" exists at all. Calling them Denuvo fixes would be wrong nearly every time, so the banner uses the tags the Fixes page already shows as pills. No tags on a game's fixes → plain sentence, no kinds.

Three behaviours worth knowing:

  • The lookup runs alongside the source check, never before it: whether a fix exists has no bearing on fetching manifests, so a Fetch is never held up by it.
  • A result that lands after the user moved on is dropped, so the banner can't advertise the previous game's fixes.
  • Games only — a DLC's fetch is about its depots, and a fix belongs to the base game. API unreachable means no banner, never an error.

FixLookupService fetches the listing once per session and keeps an appid → summary map, so the check is free after the first lookup.

Both strings are translated in all 29 languages; scripts/check-i18n.py passes. dotnet build -c Release: 0 warnings, 0 errors.

Independent of #39 — different files, no shared code, mergeable in either order.

Fetching a game showed its manifest sources and stopped there, even when the
game had published fixes a page away. A Fetch now also looks the game up in the
fix listing and, when there is one, the page shows a banner naming what is
waiting - "This game has 2 fix(es) available: SteamTools Achievements Fix,
voices38 (crack)" - with a button that opens the Fixes page on that game.

The kinds are named on purpose. The listing endpoint is called
/api/denuvo/listings, but of the 1759 games it returns, 1621 are tagged "Online
Fix" and no tag named "Denuvo" exists at all, so calling them Denuvo fixes would
be wrong nearly every time. The tags come from the same field the Fixes page
already renders as pills; a game whose fixes carry no tag falls back to a plain
sentence.

- FixLookupService loads the listing once per session and keeps an appid ->
  summary map, so the check costs nothing after the first lookup. A failed load
  isn't cached and shows no banner: it is never an error.
- The lookup runs alongside the source check, not before it. Whether a fix
  exists has no bearing on fetching manifests, and the fetch shouldn't wait.
- A result that lands after the user moved to another game is dropped, so the
  banner can't advertise the previous game's fixes.
- Games only: a DLC's fetch is about its depots, and a fix belongs to the base
  game.
- Both wordings are translated in all 29 languages.
@cheapmanga

Copy link
Copy Markdown
Author

Closing this one: folding it into #39 instead, so there is a single pull request to review. Sorry for the noise.

@cheapmanga cheapmanga closed this Aug 29, 2026
@cheapmanga
cheapmanga deleted the feature/fetch-fix-banner branch August 29, 2026 15:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant