oblivioncth

No problem. Yea, the image thing is unfortunate but there's nothing I can do about it unless I wrote a LB plugin that tries to download the images live, but that's a bit more than I care to do, at least for now. There is a Force Download Images option in FIL, but it's somewhat slow (for reasons I both do and do not understand) vs scrolling around in Flashpoint, so it's only really useful if you're importing a small subset of games. Even with Flashpoints faster fetch speed, it would take a really long time to download every image if you're going for a full import. What matters is that the image files exist, so while you can use Ultimate, if you want to save a bit of space you can download just the "Images_x.zip" files from Ultimate and extract them into Infinity if you still want the games themselves to be downloaded on the fly. As for re-importing, no. Unless I'm forgetting something, there is no way to end up with duplicates (with the exception of the annoyance that sometimes the Flashpoint project renames Platforms or Playlists between releases and if you import later after that happens you'll need to manually delete the one with the old name, see a few posts back). Just make sure you select everything you want again, as it will only attempt to import images based on your selections, so even if you're just trying to get the images added, you need to select everything again and re-import it all.

Ok, luckily it was just a simple oversight. The fix that was supposed to be in 0.8.3.2 didn't actually make it in. Try 0.8.3.3.

Sorry about this, the last couple releases all rely on some major changes under the hood that clearly have some issues. I more or less know what the issue is based on what you're showing, it's just been a bit tricky to fix the overall issue without breaking something else. I'll tackle the problem again ASAP and test the tool more extensively before uploading a fix.

The latest release has fixed the Platform Category issue for Playlists

Sorry that I missed your response. The second issue is obviously a bug that I'll double check. The first I'm unlikely to act on at the moment, unless I can come up with a particularly clever idea. The issue is that once the name for a Platform/Playlist no longer matches exactly what's in the Flashpoint database, there effectively becomes no way to differentiate previous FP item names from unrelated Platforms/Playlists. The feature you suggested would only work if one is using LB solely for FP, as otherwise any non-FP lists they have would be deleted as well. I could have it try some basic heuristics, like ignoring leading/trailing spaces when looking for a match, but outside of keeping an ever expanding list of "past names" for all Playlists/Platforms (which is a bit silly), there is no surefire way to know that two Platforms/Playlists with different names are actually different versions of the same list. Although extremely unlikely, a user could theoretically name their own Playlist/Platform to a "past" name of a FP one and have it errantly picked up as such. Given that one of my priorities is minimizing data loss and disturbance of other user files, I'd rather not throw something in haphazardly. I know it's annoying, but the current advice is to simply delete the old versions manually. I can only hope that FP stops renaming its entries slightly so often XD.

It should relace them with the newer copies. If that was your intention, I'd be curious to know if this did indeed work properly for you. I haven't even tried running the experimental launcher lol, I just looked at the source for it on GitHub to try and replicate the behavior as best I could XD. I'm sure they'll fix it in due time. Thanks. I missed the new Media Packs feature. Initially I was worried that it would make handling image imports more complicated, but as demonstrated by the path you noted, it has a handy default fallback via the "Nostalgic" packs. It seems I'll need to account for this not only for Platform icons, but also Playlists and Platform Categories.

I was able to get around to testing this myself and ironing out the kinks. The latest release has the feature included.

Wow... I guess it still has that many small files? It's the legacy folder and most games have been posted to the Game Zip system at this point so I'm really surprised. I always just walked away during extraction so I haven't kept pace with how many files that folder still has. Unfortunately there's nothing I can do about that as even the experimental launcher can't load those files unextracted as far as I can tell. I mean, I could try to add that feature independently, but I don't have the time to be that adventurous at the moment.

You need to extract everything except for the Game data zips (which is the same for everyone using the experimental FP launcher, minus the exception of the Images zips), and make sure the GameData zips end up placed under FP/Data/ArchiveData as per that Discord announcement.

Ah NP. Well at least you didn't potentially waste time extracting the zips when you might not need to.

Alright, more guinea pig time XD. https://github.com/oblivioncth/CLIFp/actions/runs/17571628676 (Windows static is what you want of course) Even if its suboptimal, I figured i'd just throw something together that should work. I haven't finished downloading Ultimate yet, so if you can be bothered, please try starting a game with this build with Ultimate setup such that none of the Game_X.zip files have been extracted, and are instead placed in the 'ArchiveData' folder as the Discord message you referenced instructs. In theory, it should pull the correct game out of there and then run it. Whether it works or not, I'd appreciate it if you could upload the log after trying.

Yea, you'd only have to extract the images but the games could stay in the Game_x.zip files. Hmm, I've never had that happen personally, but I've never tried starting Launchbox after removing FP files (deleting or removing an external device), so it may indeed have to do with that.

Playing the games seems somewhat straight forward, they just get extracted from the archive zip on the fly (though I need to check more of their code to see how they handle the fact there are multiple ZIPs). The images are... a problem. From what I can tell by looking briefly, the Launcher streams the images directly from the ZIP in that mode, though it doesn't even really matter as obviously CLIFp isn't run by just looking at the images, so I can have no influence over image access between when you initially run FIL and when a game is started. The stock launcher is special, since it has all of these mechanisms to load images from different sources on the fly, which of course LaunchBox, nor any of the other supported launchers do. Outside of plugin, which I feel like is beyond the scope of this project and would only work for LB (and I actually have no idea if the plugin-API supports altering how images are loaded), these other launchers just expect to load an image from disk, and that's that. Without creating some other somewhat convoluted application that tried to somehow hijack loading the file from disk (it would probably require implementing a virtual file system, which requires a driver on Windows, or at the very least an app running in the background at all times), which again would be pretty nuts, the only thing I can think of is making it so FIL supports extracting the images during import using the "Copy" mode, but then you overall end up using even more space, because then the images are both there in the ZIP and copied somewhere else, vs just extracting them and then using Link. I figure this isn't the end of the world though as all of the images are already in JPG/PNG format which don't further compress well, so the size difference between the Ultimate zip for images extracted vs not is almost 0. Plus, the image zips aren't that big in the end and at least for now there's only two, so they don't take that long to extract. So tl;dr, it's unlikely I can do much about the image zips, though it shouldn't be a big deal to just extract those. I can, when I get to it, add support for loading games from the Game zips, which should save a lot of time/effort since they're far larger. Those don't really save space either as the games within them are already zipped themselves, but still it would save the hassle of extracting them.

Sorry about that. There was an oversight in CLIFp (the tool within FIL that lets you actually run the games) that could cause this. I fixed it a bit back, but forget to publish a update to FIL that was bundled with that new version. I've done so now. Just run the new version, but instead of doing an import, use the tools menu and select the "Deploy CLIFp" option in order to update your CLIFp version. Then you should be good to go.

Cool. Thanks for testing. Third time's the charm I guess.