[ChakraFusion]

The follow-up #84 left out: settings files the game database doesn't list are recognised by their contents.

Detection (presets/detectsettings.go):

• A file is taken for a game's settings by its contents: the vocabulary of one machine's display (resolution, vsync, shadow quality, upscaler), matched inside identifiers split at case changes and separators (_enableFrameGeneration, r_materialAniso), in UTF-8 or UTF-16. Unreal Engine's Config/<platform> folder is taken by convention.
• Names only add weight. Measured over the game database's own labels, "settings" names 1,521 settings files and 70 saves, and ".ini" 1,831 and 137, so a name never decides on its own.
• A name with a save word in it rules a file out unless the contents are overwhelming. The game database's save locations, logs, binaries, long files that are only partly settings, and Syncthing's conflict copies are never taken.

Giving back what is a save: a file taken for settings that changes like a save is given back for good (verdict "save", which also overrules the game database):

• before it is left out, and at every later run, the game's snapshots are asked whether it changed in most of the snapshots in which the rest of the save changed (snapshot/history.go);
• while it is left out, every change here and every manifest another device sends count whether it changed when the rest of the save did. Three such changes, outnumbering the times it stayed put, give it back (daemon/detectsettings.go).

Storage and UI: verdicts are kept per game (migration 0042: settings_files, settings_observations, and marks for when each game was last judged). They're applied through the device settings from #84, so hashes recorded under the old list are carried over as before. The game's file list says why each excluded file is excluded, and unticking one syncs it. The configuration tab's new text is in the catalogs: en, plus zh-Hans and zh-Hant as a first attempt for @Janlhin to correct. SyncIgnoreEditor isn't extracted yet, so its new labels are plain English like the rest of it.

On my machine: 74 files in 25 games detected, among them Crimson Desert's, DOOM Eternal's and Elden Ring's settings, and 12 games the game database doesn't cover. None of them is a file the snapshot history shows changing with the save.

Tests: presets/detectsettings_test.go, snapshot/history_test.go, daemon/devicesettings_test.go (TestObserveSettings_GivesBackWhatChangesLikeASave).

Checks: the full unit and e2e suites pass locally on today's dev-public.

🤖 Generated with Claude Code

[vercel]

@ChakraFusion is attempting to deploy a commit to the sivadaboi's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Omar-VF]

Thanks, the detection and the give-back checks are thorough. Two changes before we can merge:

1. 0042_settings_files.sql creates settings_files, settings_observations and marks with plain CREATE TABLE. Builds of the earlier draft stack created settings_files (0043) and marks (0041) with the same schema, and a database from those builds would now fail to start with "table already exists". We saw exactly this last week with sync_device_settings. Please use CREATE TABLE IF NOT EXISTS for these.
2. Files found by their contents should not be left out of sync automatically. A wrong guess means part of a save stops syncing without the user knowing, which is a bigger risk than Keep each device's game settings out of sync #84's database-listed files. In this version, detected files should be shown in the game's configuration tab as suggested settings files, and keep syncing until the user confirms them there. The game database's files stay automatic, as they are now.

[ChakraFusion]

Thanks, both done:

1. Migration (cb5c9e7): CREATE TABLE IF NOT EXISTS for all three tables. TestSettingsFilesMigrationOpensOverTheDraftsTables opens a database that holds them with 0042 unrecorded; with a plain CREATE TABLE it fails with "table settings_files already exists".

2. Suggestions instead of automatic (1a4c278): a file found by its contents is now only suggested. It keeps syncing, and the game's configuration tab lists it with Keep on this device and Keep syncing.

   • Keep on this device leaves it out like the database's files, and the give-back checks watch it as before.
   • Keep syncing records declined, so it isn't suggested again.
   • A suggestion that the snapshots show changing with the save is withdrawn.
   • The game database's files stay automatic.

   The tab answers through POST /api/games/{id}/suggested-settings. The new text is in all three catalogs, and the Chinese is a first attempt for @Janlhin to check. TestSuggestedSettings_SyncUntilConfirmed covers detection leaving files syncing, both answers, and a second detection run changing neither.

The branch also has today's dev-public merged in (the catalogs from #112).

🤖 Generated with Claude Code

[ChakraFusion]

One more change, in the spirit of your review on #106: ChangesLikeASave (the snapshot-history check that gives back a file changing like a save) read every file of each of a game's last 40 snapshots, just to tell whether the rest of the save changed. For a quarter-million-file save that's some ten million rows each time detection ran. For a snapshot without a recorded file list, it even unpacked and hashed the whole archive.

In 899ccce it changed:

• The database compares two snapshots (store.SnapshotsDiffer, stopping at the first difference).
• Only the files being judged are read (SnapshotPathHashes).
• A snapshot without a recorded list is left out instead of unpacked. ArchiveFiles and filesOf are gone.

TestChangesLikeASave passes unchanged, and TestSnapshotsDiffer covers the comparison. Full unit and e2e suites pass locally.

🤖 Generated with Claude Code