oblivioncth

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.

@SiriusVI Turns out that LB seems to be enforcing some changes to playlist file names that I don't believe it was in the past. That, or it wasn't an issue previously because there weren't any playlists with the right name to make the issue apparent. So it keeps tweaking the file names after an import, causing the mismatch (I kind of already said this in my initial post on the issue, but the problem affected things more broadly than I thought. So, I still would delete those two playlists, since they seem to have names with the issue. Then, try out this build and let me know if that fixes the issue for you with a re-import. I did more through testing and things appear to be in order now after the changes that went into it. Obligatory "backup your files first".

I might be forgetting a few other changes that would be needed in other XML files. If you have the time I'd just redo the import once again with the latest upload. You should probably also delete the Player-Produced Perlis XML, and then run LB to let it clean out everything related to it in order to make sure the old one doesn't stick around since the filename will be different and it won't see them as the same playlist. Ok hold on, there might still be an issue. Investigating.

Strange. It seems that LB doesn't like hyphens being used before a space in a playlist filename... kind of overly specific if you ask me. What happens is the ":" in the filename is swapped with a "_" (as has been the case for a long time) by FIL, and then when you open LB it replaces the "-" with a "_", so the playlist filename ends up different than the icon filename. I updated FIL to swap all hyphens with underscores to be on the safe side, so what you need to do to match the new changes without re-running the import is: 1) Rename "<LAUNCHBOX_DIR>\Images\Platform Icons\Playlists\First Past The Post- Continued.png" to "First Past The Post_ Continued.png" 2) Rename "<LAUNCHBOX_DIR>\Images\Platform Icons\Playlists\Player-Produced Perils.png" to "Player_Produced Perils.png" 3) Rename "<LAUNCHBOX_DIR>\Data\Playlists\Player-Produced Perils.xml" to "Player_Produced Perils.xml"

And we're back. Well overdue, but I finally had time to crank out the update for FP13. @SiriusVI Of course let me know if there's any issues you stumble upon. @oniotaku Assuming you had done everything right before with Ultimate 12, you may also have to refresh all of the images within LB to get them to show up in the list; however, at this point you should probably just try 13 Ultimate since that's out now and it fixed the issue outright.

Due to a litany of obligations I currently can't, but it will come.

The current version should work with the latest release of Infinity (12.1) and Ultimate (12), though the Ultimate release has some issues that need correction as mentioned elsewhere.

Really having to spell this out... lol. If you are using Ultimate 12 and have this issue, you will have an extra level of the "Images" folder that isn't supposed to be there, as shown in SiriusVI's screenshots above. So you'll see "<FLASHPOINT_DIR>\Data\Images\Images" where both the inner and outer have "Logos" and "Screenshots" directories. To fix this you need to make it so there is only one images sub-folder, with the contents of the inner one being merged to the outer one.

Its just a matter of moving the folder how you would move any other. Whether via a cut and paste or two separate windows, just move the inner folder next to the outer Images folder and accept the merge.

You just need to move the nested image folder next to the top level image folder so that they get merged together. That is, collapse Data/Images/Images into Data/Images.