2 Commits

Include renames

Author	SHA1	Message	Date
The412Banner	d1b0ac4df1	Windows components: picked automatically by each game's source (#554) ... Each game's Windows components now come from the list its own source trusts, and the ones that list names turn on by themselves. The user's own on/off switches always win; each automatic row says why it is on. - Steam games: the Steamworks Shared redistributables Steam installs with the game (appmanifest SharedDepots, else the client's appinfo.vdf). Steam keeps its install scripts marked as already run. - GOG: the build manifest's dependencies. Epic: the manifest's prerequisite (Unreal's maps to VC++ and DirectX). Amazon: fuel.json PostInstall. Older GOG/Epic installs get their list fetched once with the saved sign-in; game files are never downloaded again. - Custom games (the + button, Add all, migrated folders): one shared Steam match per game, also used for artwork. An appid from the game's files turns components on; a name-only match stays Recommended; no match falls back to the folder scan. - Steam app info for apps the client never saw comes from an anonymous Steam PICS lookup (CM websocket, anonymous logon, product info), cached per appid; the user's Steam sign-in is never used. - Missing components download in the background on one low-priority worker that pauses during sessions and waits on battery saver, heat or a metered network unless the user asked. A game Steam installs during a session is readied right away so it can be played without ending the session; the launch waits up to 10 s only for a component still on its way. - Page: "On for this game" with reasons, a quiet "Checking what this game needs..." only for games never worked out, rows that ease in, pieces that need a download greyed out while offline. The intro names no other app. - The folder scan skips Unity's *_Data/Managed (Mono, not .NET Framework).	2026-10-10 21:15:56 -04:00
The412BannerandThe412Banner	d61af961c1	Windows components for Steam and added games; no more redist installer prompts (#287) ... * Put a game's Windows components into its Proton prefix at launch droiddeck-wincomponents copies the DLLs of the components picked for a game into compatdata/<appid>/pfx before Proton starts and hands their overrides to WINEDLLOVERRIDES, so the registry is never touched. It re-checks every launch (an older Proton deletes the files it once placed), takes a component's files out again when it is turned off, and forgets Proton's config_info then so Proton puts its own builtins back. * Windows components for added games: picker, packages and their catalog Settings > Games lists a Windows components row under each added game. Its dialog switches components on per game; the first switch-on for any game downloads the package (a catalog of its own beside desktop.json, installed with the desktop package installer to /opt/droiddeck/wincomponents/<id>). The picks are kept in the app and published to the runtime at every session start for droiddeck-wincomponents to apply. tools/wincomponents/package.py builds the packages: Bannerlator's eight wincomponents archives re-rooted, and OpenAL from OpenAL Soft's release (soft_oal.dll placed as OpenAL32.dll, 32- and 64-bit). * Windows components: list the installed ones when the catalog cannot be reached Offline the dialog only looked up ids it already knew - the catalog's and the game's picks - so a component downloaded earlier never showed. * Windows components: Bannerlator's list with Recommended, on the game's launch settings The picker moves from Settings to a Windows components card in an added game's launch settings. It offers Bannerlator's whole catalog (components.json on winlator-contents): what the game's folder points at first (Bannerlator's DependencyDetector, mapped to the DLL-copy twin where there is one, oalinst -> oalinst_dll), then every component that installs here, then the ones that need a Windows installer, greyed until DroidDeck can run one. A component installs by running its catalog steps into the runtime once: archives downloaded (one download per archive for a batch), DLLs found by name as Bannerlator does and copied to /opt/droiddeck/wincomponents/<name>, overrides and bundled components written to component.json. The launch script now takes catalog names (xaudio2.7), expands bundles (directmusic), places files one level down (drivers/gm.dls) and keeps an override's own mode (dsound=n). Drops the hand-made packages and their script. * Windows components: Steam games too, and a pad that can drive the list The card shows on a Steam title's launch settings as well, keyed by its appid - the compatdata folder droiddeck-game-env reads - and Recommended scans the game's install folder. With a pad: Done takes focus while the catalog loads and the first component once it is there (the list was not drawn yet when the dialog asked for focus, so nothing had it); switches stay enabled during a download and a press then is ignored (a disabled switch dropped the pad's focus); LB/RB jump between Recommended, All, the installers and Done. * Redist markers from games' own install scripts; VC++ runtime as installed The client still started a game's own _CommonRedist installer - its script sits in the game's folder, often with another version in the value name, and only Steamworks Shared's were read. On ARM64 Proton the x64 VC++ 2015-2022 bundle then stops with "Microsoft Visual C++ 2015-2022 Redistributable (arm64) is required" (reported on an AYN Odin 2 Portal Max). - Read installscript*.vdf from every installed game in each library as well; the list is cached until an appmanifest changes, since this runs every quarter minute. - Record the VC++ 2015-2022 runtime as installed where its installers look (VisualStudio\14.0\VC\Runtimes\{x86,x64,arm64}, both registry views), so any bundle - the client's or a game's own - finds it and exits; Proton's msvcp140/vcruntime140 serve the game. - Join the Wow6432Node path instead of sub(): mawk and gawk read the replacement's backslashes differently (gawk, the runtime's, was right). * Mark a game's install-script processes as run just before the client evaluates them An Odin 3 bundle (0.3.1, Proton Experimental ARM64) shows the client running its install-script evaluator on the first launch of three new titles (409710, 2161700, 3404260) while their Steamworks Shared redistributables (VC++ 2010/2012/2019/2022, DirectX) were still downloading - 2161700 at 22:03:22, the shared app finished at 22:03:29 - so the periodic seeder had nothing to mark yet and the installers ran. The client writes the exact steps to legacycompat/evaluatorscript_<id>.vdf and starts iscriptevaluator.exe through our launcher. droiddeck-game-env now hands that script to droiddeck-seed-redists first, which marks every process in it in the template and the prefixes before the evaluator reads them. The seeder's reader no longer assumes a depth: a block with a HasRunKey is a process named by the key it opened under, wherever it sits. * Windows components: keep a file that was not Proton's, put it back when turned off A component's DLL replaced whatever had that name in the prefix, and turning it off deleted ours, so a file a real installer (or the user) had put there was gone for good. Before replacing a file that is neither Proton's own (a symlink into Proton, or a Wine builtin/placeholder DLL) nor an earlier copy of ours, keep it under compatdata/<id>/.droiddeck-wincomponents-backup and move it back when the component is turned off. The launch note says how many went back. * Windows components: recommend what Steam installs, say what the game already has - Steam titles: the appmanifest's SharedDepots (Steamworks Shared, app 228980) list the VC++ 2005-2022 and DirectX redists Steam installs with the game; they live outside the game folder, so the folder scan never saw them. They join Recommended as "Steam installs VC++ 2010 with this game" (SteamRedists). - Bannerlator's PrefixInstalledDetector, on compatdata/<id>/pfx: OpenAL32, Mono, PhysX and Games for Windows Live that are already there from elsewhere show "Already in this game". Files droiddeck-wincomponents placed itself do not count. - The game page passes the prefix and, for Steam titles, the appid. * Windows components: friendly names The list showed catalog keys (oalinst_dll, vcredist2010_dll, dotnet452, d3dcompiler_47). Bannerlator's catalog has no display name and some of its descriptions do not fit the entry, so WinComponentNames gives one: families by pattern (Visual C++ <year>, .NET Framework x.y[.z], XAudio, D3DCompiler, MSXML, Wine Mono, DirectMusic parts), the rest from a table, the key itself for anything new. The key stays in the row's detail for logs and bug reports; both lists sort by the name, and the game page's card names the picks the same way. --------- Co-authored-by: The412Banner <the412banner@users.noreply.github.com>	2026-10-06 10:46:27 -04:00