Modernization & Discovery Overhaul (v7.0.42 - .NET 8 WPF)

[DarksAces]

📌 Overview

This Pull Request bumps the Steam Achievement Manager (SAM) to v7.0.42, bringing a massive modernization effort by transitioning the Picker from legacy WinForms to a modern, high-fidelity WPF interface. Alongside the UI revamp, it completely fixes critical issues with game discovery that occurred due to deprecated Steam API endpoints, restoring the classic SAM exact library detection.

✨ Key Features & UI Changes

• WPF Interface Rewrite: Replaced the outdated WinForms GamePicker.cs window with a fully responsive, dark-themed MainWindow.xaml WPF interface.
• Real-time Search Filter: Introduced a responsive text-based search/filter bar exactly at the top of the grid to allow users to quickly find massive libraries instantaneously.
• .NET 8 Upgrade: Cleaned up the .csproj file to utilize .NET 8, taking advantage of better runtime performance while strictly maintaining x86 output (essential for steamclient.dll interop).
• Version Update: Correctly reflects the new target version natively in the application window as v7.0.42.

🐛 Bug Fixes & Engine Restorations

• Restored Full Library Discovery:
  The official ISteamApps/GetAppList web endpoints are heavily rate-limited and deprecated.
  Re-implemented the battle-tested, classic Gibbed discovery engine: This application now properly downloads the master games.xml list again and directly queries the local client API using SteamApps008.IsSubscribedApp(...). This restores 100% discovery precision and eliminates generic "App 1000" fallbacks.
• Fixed Missing Image Capsules:
  Images reliant on generic static store CDN locations (capsule_184x69.jpg) failed frequently because retired/delisted games return HTTP 404s. Reverted the image resolver to safely request cached metadata properties (small_capsule, logo) from the local client API (SteamApps001). Now, all graphics load gracefully and asynchronously.
• Process Start Pathing Fixed:
  Resolved an issue where users clicking on a game from SAM.Picker.exe encountered an error because it couldn't locate SAM.Game.exe in local debug/dev environments. The startup info now traverses the solution properly to gracefully link with the \bin\ execution directory.

🛠️ Technical Details

• Added GameInfoViewModel.cs for clean XAML databinding (INotifyPropertyChanged).
• Added global DispatcherUnhandledException handlers to capture and diagnose rendering/API execution exceptions silently rather than crash-to-desktop.
• Maintained compatibility with steam_api.dll and original Gibbed API hooks.

[lieberung]

Great job!

[nomnaut]

Will this cache the images rather than requiring re-downloading all the icon images each session?

[DarksAces]

@nomnaut No, the program does not cache images, so they are redownloaded from Steam at startup.

It works by downloading the icon and cover bytes in the background using WebClient and HttpClient directly into RAM to display them on screen.

Although the logic in Manager.cs (AddAchievementToIconQueue) and MainWindow.xaml.cs (LoadCapsule) avoids downloading the same image twice while in memory during an active session, all of this data is discarded upon closing the application, requiring them to be downloaded again in the next session.

[nomnaut]

Would it be difficult to cache the same images on local storage and then check there first for images? I feel like the small storage cost would be worth the time and api savings.

[DarksAces]

Would it be difficult to cache the same images on local storage and then check there first for images? I feel like the small storage cost would be worth the time and api savings.

I hadn't thought of that, so I'll see if it's feasible. I'm mainly worried about users with huge Steam libraries, as caching all those icons could end up taking quite a bit of disk space. I'll run some tests to see how to handle it properly!

[nomnaut]

I’m willing to test it. I have 1,352 games in my library spanning 22 years with plenty of storage space. I can clone the repo and apply your PR. (I imagine building the executable shouldn’t be difficult).

[DarksAces]

Haha that's amazing! I actually have a good amount of games myself, so I should be able to run tests on my end without issue. I won't be able to dive into this until tomorrow afternoon, but I'll update this thread once I start working on it and set up the code. Thanks for the offer!

[nomnaut]

GD, let me know if I can help lol. Also, at that point you might as well make a fork rather than waiting for the PR to be approved.

[DarksAces]

Turns out I was able to get to this earlier than expected! Caching is now implemented.

A few details on the implementation and testing:

Location: Cached images are stored in SteamAchievementManager\SAM.Picker\bin\x86\Debug\net8.0-windows\cache (relative to the executable).

Test results: Tested on my library of ~900 games and everything runs smoothly.

Footprint: The full cache for 900 games is only about 14 MB, so storage shouldn't be a problem unless someone has 10,000+ games—at which point RAM usage would likely become the bottleneck anyway.

I haven't done an extreme stress test beyond this to avoid hitting Steam API rate limits or potential temporary bans. If you know a safe way to simulate heavy load without triggering API limits, let me know!

[munchyi]

ai slop