retroNUC

The pull request has now been merged, and will be in version 2409-32 or later. Hopefully you should be able to use this combined with the Dolphin path from a user's emulator setup and we can get these badges working on .rvz? > .\dolphintool.exe verify -i "game.rvz" -a rchash 9be90fd0a49908be157f8c001794699e

If this PR gets accepted, you should be able to get the hash over command-line directly from Dolphin 🤞 https://github.com/dolphin-emu/dolphin/pull/13035

@C-Beats I've logged this over at the RALibretro repro to see whether RVZ reading support could be added to RAHasher - https://github.com/RetroAchievements/RALibretro/issues/415 There's also DolphinTool.exe in the emulator's directory, which is a command-line tool for converting and verifying all formats that Dolphin supports: > dolphintool.exe verify -i "file.rvz" -a crc32 9d473312 Would just need a new type added like "rahash" that could be returned for you folks to use.

Thanks. Can confirm that the issue is fixed in 13.12 Beta 3.

Ran a full RetroAchievements scan today, and all the RetroAchivement game IDs have been removed from my "Sega Mega Drive.xml" platform file. All other platforms scanned and updated just fine. The RetroAchivementHash field is still valid and populated for each entry, only the RetroAchievementId field has been stripped. At a guess, something to do with a custom platform name (like "Sega Mega Drive" instead of "Sega Genesis") not pairing up properly with the correct RA platform ID when requesting or pairing hashes? LaunchBox Version 13.11. Attached debug log, but couldn't see anything relevant to "cheevos" / "achivements" / "ra" / "hash" / etc. https://bitbucket.org/jasondavidcarr/launchbox/issues/8616/sega-genesis-mega-drive-games-no-longer Debug 2024-02-27 11-03-53 PM.zip

No, not a bug. It all depends exactly how a game is hashed - https://docs.retroachievements.org/Game-Identification/ ZIP is fine for ROM-based games, because it's really easy to access and hash a single whole file within a ZIP archive. But for disc images, the hasher needs to be able to mount the image and use the disc header data in order to then access and hash specific files within the image. It's impossible to access a file within an image when the entire image is compressed, so no choice but to spend the 30-60s extracting the full thing first. Then the easy solution is to switch clrmamepro to a name-only scan instead of name+hash. Disc-based collections are pretty static these days, it's not like MAME where parent/clone files within a zip constantly change. Or if you still want to hash things, just use one of the tools that does support CHD, like this one. CHD files store the original's MD5 hash in their header, so it's possible for files to expand and verify themselves for data integrity (and then compare that same hash against redump dats, like the tool I linked does). Far as I can tell, nothing has changed in RAHasher code since the last time those CHD fixes went in 8 months ago, and I imagine nothing would change unless you updated the included binary. Only way I can imagine it going wrong when called by LB was if the wrong Console ID was being passed in?

Had a quick check of the RAHasher code, which is the tool that LB uses to generate hashes. Confirmed it doesn't support disc-based files within ZIP archives, and that's for a good reason - For each game, it would have to spend a while to fully extract the entire ZIP file somewhere temporarily just so it can mount the CD and read the specific files it needs to within it. You can't do that while it's still packed in an archive file. You really shouldn't be zipping disc-based games, to be honest. It might work, but you're probably getting a really slow launch every time you try to run a game? Either LaunchBox or the emulator will be doing a full unzip/extract. Use other compression formats if you want to save space, pretty much everything supports CHD these days. Same kind of algorithm as a zip file, but only on the inner data and not the file headers needed for that random file access. https://retrogamecorps.com/2023/02/06/the-ultimate-rom-file-compression-guide/

Can't remember if I raised this previously when the RA API was going up and down, but the error/response checking seems to be broken on the "Test Login" button on the RetroAchievements options menu. If you enter an invalid Username or API Key and press the button, LaunchBox still always says "Connection to RetroAchievements successful." If you try and do a scan in that state, it'll wipe any the existing RetroAchievementId data in the platform XMLs. Edit: Another bug for the new version, I'm seeing infrequent freezes when adding/editing Additional Apps on game entries and closing the Edit Game window. No error/exception, just unresponsive and then need to force close the application. Seen several times this evening when updating ROM hacks on a bunch of games.

Lambda (more specifically, a slightly modified version I made that can be found here).

Also seeing this myself in 13.4-beta-3 when attempting to add a game to an existing playlist via right-click on List View. The calling thread cannot access this object because a different thread owns it. App: LaunchBox Version: 13.4-beta-3 Type: System.InvalidOperationException Site: Void VerifyAccess() Source: WindowsBase at System.Windows.Threading.Dispatcher.VerifyAccess() at System.Windows.DependencyObject.GetValue(DependencyProperty dp) at System.Windows.Controls.Primitives.Selector.get_SelectedItemsImpl() at Unbroken.LaunchBox.Windows.Desktop.ViewModels.ListContentViewModel.Populate(List`1 newGames, String title, Guid instance, IList`1 idsToSelect, Double newScrollOffset, String overrideSortType) at ModelCreator.FindObservableUtils(Object , List`1 games, String title, Guid populationInstance, IList`1 idsToSelect, Double newScrollOffset, String overrideSortType, ModelCreator ) at Unbroken.LaunchBox.Windows.Desktop.ViewModels.SideBarViewModel.AwakeSimpleRules(Boolean movefirst, Boolean iscounter, Node rule, Playlist t2) at ReaderCreator.FindObservableUtils(Object , Boolean movefirst, Boolean iscounter, Node rule, Playlist t2, ReaderCreator ) at Unbroken.LaunchBox.Windows.Desktop.ViewModels.SideBarViewModel.<>c__DisplayClass80_0.ComputeSimpleTemplate() at Unbroken.LaunchBox.Windows.Threading.<>c__DisplayClass0_0.InstantiateCompositeServer(Object ) at Unbroken.LaunchBox.Windows.Threading.<>c__DisplayClass0_0.EnableRemoteSetter() at System.Threading.Thread.StartHelper.Callback(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) --- End of stack trace from previous location --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() Recent Log: 21:43:01 Exception

Hey folks. RAHasher has another update release that fixes some more CHD identification issues. Could you please update it in an upcoming Beta update? Thanks in advance! https://github.com/RetroAchievements/RALibretro/issues/371 https://github.com/RetroAchievements/RALibretro/releases/tag/1.6.0

That would require the LaunchBox database storing hashes of all possibly know game files, which is a bit of a nightmare and probably crosses the line of linking LaunchBox to dumped ROM files. Honestly, for completionism, that's what Redump, No-Intro and TOSEC databases are for. Use their dat files with clrmamepro or another ROM manager to compare against your local collection.

Hm, not seeing any issues with .7z NDS files here, everything in my collection seems to have been fine with DS titles since the beta release. For Pokemon Conquest in particular, I'd check which file you have - The (USA) (Rev 1) version is not supported, only the original version. Oh, and thanks for getting the RAHasher fix in with Beta 2, that should relieve a lot of people's issues

Thanks for the DS RA fix. Hashing problems for CHDs has been fixed pending merge (https://github.com/RetroAchievements/RALibretro/pull/370), so hopefully we can get a new RAHasher release soon to include before 13.3 goes final 🤞 Are you expecting any big incompatibilities for plugins/libraries with the .NET 3.1 to .NET 6 changeover, or should most continue to work as expected?

Best people can do for now is do a side-by-side against the platform lists on RetroAchievements - https://retroachievements.org/gameList.php?c=21 In theory, a plugin could be created, as you can pull all the data/hashes for a single platform through the API then compare it against LaunchBox entries - https://retroachievements-api-js.vercel.app/v1/consoles/get-game-list.html

I'm struggling to understand your request, but I think you're suggesting that 'Additional Apps' associated to a game should also be scanned/hashed? As a user, I agree that would be useful - Some of the ones that the automatic scan missed were ones were only variants were associated with RA titles and not the default game. A good example of this is Final Fantasy X on PS2 where the default game is (USA) with no cheevos, but I have an additional version that is (Japan) which is linked to cheevos. If the default game file does not match but an additional app does, it would be nice if the UI requests (badge, details panel) fell back to show the info/cheevos for the matching additional app instead. However, I can see this getting complicated if the default didn't match but there are multiple additional apps that match - Fine for the badge, but which one should RA show info for in the details pane? In these cases, I'm fine with manually setting the hash/id on the default game of the exact one I want, but it would be nice if this was made more easily visible/editable in the Add/Edit window.

Only thing that RAHasher does is takes a file and returns the hash ("identifier") of that file. This is the bit of data that emulators, LaunchBox, and other apps can send to the RetroAchievements server going "Do you know anything about this file?" and returns "Yeah, hash XYZ matches game ID 123 in our database, here's the cheevos info". Any other functionality would be on LaunchBox's side, but I don't think what you're suggesting is feasible - How can LaunchBox populate a playlist with game entries that don't actually exist in your own database? You'll be best off going through the platform lists on the RetroAchievements website and checking manually, like most of us do. But at least this new LB functionality gets us 95% of the way there instead of everything having to be fully manual!

Quick way I use to reset that data is the following: - Close LaunchBox - Open up the platform XML file in Notepad++ - Ctrl+F to open search box, move to Mark tab, tick the 'bookmark lines' checkbox and search/mark lines with "COULDNTFILEHASH" - You'll see a blue bookmark circle next to all lines that matched - From the top bar, Search > Bookmarks... > Remove Bookmarked Lines - Save, open LaunchBox back up, rescan

Still need to talk with various parties across GitHub projects as to where the fault lies and how it should be fixed properly, but I've put together a new version of RAHasher that now works properly with all CHD files. Download the attached file and replace the one located at "...\launchbox\ThirdParty\RetroAchievements\RAHasher.exe" Resanned my PS2 CHD collection with a 99%+ success rate. I'm not sure if LB will force retry entries already marked as COULDNTFILEHASH on a rescan, or whether you'll need to remove those lines before the rescan? https://www.virustotal.com/gui/file/383ff365c89255e8d12e2580ae49e3af55ed59c3f2099e8eb173f0f231bba762 RAHasher_Fix.zip

Of course, I'll add any info/logs you request to the issue tickets once I get a chance. Sorry for the misunderstanding, and apologies for my tone.

I'm using rahasher too, on the command line. Can't tell you why .nds files don't seem to be processed through LB - Not even "COULDNTFILEHASH", doesn't seem to be adding any changes back out to the platform XML at all. Perhaps wrong platform ID, or passing down the zip/7z forces it to go down the wrong algorithm? Also can't say why CHD files are failing when ISO ones work fine (because rahasher doesn't support CHD, it's up to the app using it to mount/translate it first through something like libchdr).

The hashing/identification issues I'm logging at BitBucket are all games that work fine with RAHasher/RALibretro https://bitbucket.org/jasondavidcarr/launchbox/issues/7624/retroachievements-scan-inconsistent-spotty https://bitbucket.org/jasondavidcarr/launchbox/issues/7649/retroachievements-scan-not-working-on

I think if it fails once, it'll always fail. I've bugged up situations where it's failing (CHDs, NDS files, etc.) over at BitBucket, but we're just gonna have to wait for updates from LB. There's some tools that may make the XML editing easier (Ximple is a good one), Tempted to write my own wrapper/lookup for the problematic ones, or if someone does it manually for all the games on a platform, it should be possible to extract a list of LaunchBoxID/RetroAchievementsHash pairs to merge in with anyone else's existing collection.

Likely you're editing while LB is open, and your manual edits are getting stomped when it shuts down. Close LB, add your hashes manually and save, open up LB, then rescan the platform for achievements. That's been working for me.

Hey @Jason Carr, thanks for the beta update. Theme documentation doesn't seem to be updated, though? Still dated June 2.