JoeViking245

I can't attest to this being "the issue", but I do know that drives not formatted NTFS can have issues with the symlinks LaunchBox creates and uses at runtime. (at least that was the case when I wrote that in my notes about a year ago)

I recall that previous post now. If I'm understanding correctly, the concern is not that when you restart BB, it doesn't start on the last platform you left on. But that it's not physically writing to the BigBoxSettings.xml file every time you select a different platform. It's only writing to the xml file if: a) you go into the platform [to look at the games] then go back to platform View b) when shutting down Big Box Is that correct? Or did I miss something [again] (which I sometime do, and I apologize for that).

Can you elaborate a little on "do something"? Unless by "do something" you mean restart LaunchBox, I don't think it's the same thing as AzgoRAth was experiencing in Big Box. Also, I just started up LaunchBox and it opened to my "last" platform. (vs. defaulting to "All"). I just tested here and Big Box [for me] did startup in last Platform I had opened. There may be something else in a setting somewhere (e.g. starting in Platform View) but I haven't finished my 1st cup of coffee to "think" about it. The only other possibility I can think of is how is BB being shut down and is it getting a chance to properly save the "Last Platform" used? Edit: I did not check for, if it was remembering the last game.

How frequent are there updates? How do you know when there's an update? You have to run the QT Launcher to find out, don't ch'ya? Because I doubt the command-line launcher will check. Or do you check the main web page or GitHub site periodically? Or maybe get a notification from the GitHub site? Then manually update it? Whatever your method for checking and updating, maybe make a simple batch file that will copy the file for you. After doing the update process, just run the batch file. I still don't know where the saves are actually saved to, but looks like another possible option is if you look in Settings, and click on the Paths tab, there's something about Saves. Which I presume sets the save path. You could probably look in the folder it shows and see if your saves are actually in there. The maybe create that /user/ folder under Pre-Release as discussed earlier, copy the /home/ folder in the main directory to it. Set the above to this new location. Play a game and make a new save and confirm it goes into that new folder location.

Yes, when editing the individual games, the other 2 do have and show their own images. These are Custom Badges I made. These 3 games actually all point to the same ROM file but are setup to use different emulators (as depicted by the badges). Normally you would just have the one game, then right-click and select Launch With and choose an emulator. But this is on my test-build and I set it up the way I did while I was still testing and comparing between the 3 emulators. The 3 emulators are the model2 emulator, SM2-Emu and MAME. You can create your own custom badges using JayJay's app.

This may be because of how they were imported or added to your collection. I don't know. That'd make sense. You can select one game, then press Ctrl+A (to select all) then press F5 to refresh the images to find out for sure. I believe you are correct. Here's what I was going off of in my tests. 3 games, same Title, separate images. The one with the red arrow is the one I changed the Title to (added "mame"). The image filename 'was' similar to the two below it before I changed the Title. After changing the Title, LB renamed the file to match the [new] Title.

No. Each game added to LB will have its own image(s). When you have parent/clone games that are not combined, or import a game again or just somehow have 2 games with the exact same name, the image file filename for the individual games will be the_game_title.the_games'_guid-01.png. Here it adds the [dot] game_guid number after the [duplicated] Title to distinguish it for that game. At least that's what's supposed to happen. And just now testing, I had 3 games with the same title and their respective image files had the guid in their filenames. I edited one of the games and changed only the Title and clicked ok to save and close and the image file (for that one game only) got renamed to the_new_title-01.png. LB does not store data of each games' associated images and videos like it does for its metadata (Notes, etc.). Essentially, it grabs the associated images (and videos) on-the-fly. So there really isn't a way to have games with different Titles share one image. A note on image filenames, typically they're named after the games Title. But can also be name after the games ROM filename. e.g. Donkey Kong-01.png Donkey Kong.7eb50c8d-472b-40b6-b47d-69bb8cf355b1-01.png dkong-01.png

I'd start with looking at the page where you downloaded the plugin from and read the comments to see if anyone else has had or is having the same issue. If not leave a comment yourself. This way the plugin author will get notified and can take a look, offer advice and or fix/resolve the issue with the plugin. Also in leaving a comment there, if other users experience the same issue, they'll (hopefully) see "the fix".

Sorry I should have clarified, I don't use this emulator and don't know where the games are saved to. "Inside the emulator folder" is pretty broad. But if I had to take a guess, by design, the QT launcher and the command line launcher will look for and save all data under one folder. /AppData/Roaming/ShadPS4/. But, to make them portable simply add a /user/ folder. With the caveats of: If you launch a game though shadPS4QtLauncher.exe, all data for that game (including save states) is saved into its neighboring /user/ folder. If, instead, you launch a game via the command-line executable shadPS4.exe, all data for that game (including save states) is saved into its neighboring /user/ folder. Which if correct, tells me these 2 exe's work independently of each other in regard to "being portable" and where to look for the /user/ folder. Which would make sense. If I had a game to test, I would try copying the file "shadPS4.exe" from the /Pre-release/ folder to, next to the shadPS4QtLauncher.exe file. This would put a /user/ folder below it in which I presume the saves are located (inside the vast emulator folder). The saves created when launching it from the QT exe. Then point LB to this "shadPS4.exe" and see what happens.

Oh... for the game saves, I don't know where they're saved to. The respective /user/ subfolders look pretty similar. So if the game is launched via QT, does it create the save in its /user/ folder? vs. if it launched from the command line using the pre-release exe file, does that method save it to the pre-release /user/ folder?

How exactly are you launching a game from outside of LaunchBox? I'm guessing via the QT launcher. And I presume it's this method that will also load the save state when launching a game. LaunchBox only looks for the file you tell it to execute. And LB won't create any folders for an emulator (except when you ask it to install one for you). That said, there are a few layers to making ShadPS4 completely portable. For the QT launcher, it needs a user subfolder. For the command-line launcher exe, you put it under launcher/versions/ folder. This you've already done. Then to keep the command-line launcher exe portable, it needs its own user subfolder. Emulators\shadPS4\shadPS4QtLauncher.exe Emulators\shadPS4\user\ Emulators\shadPS4\launcher\versions\Pre-release\shadPS4.exe Emulators\shadPS4\launcher\versions\Pre-release\user Without the respective \user\ folders, those exe's when executed individually will create the folder under AppData.

Yeah, doing that will definitely make them unable to get updated. I suggest not doing that. What version of LaunchBox are you running?

What theme are you using. Subsequent to my reply above, I was playing around with the Omni theme and experienced the same thing. But could not reproduce it with the Default theme.

Pretty sure I never had combine enabled (but stranger things have happened). All tests were ROMs imported from an internal HDD. Fortunately/un-fortunately, my 4 tests this morning were all under 15 seconds. With each import of 10 [different] ROMs being faster than the previous one. e.g. 15 sec, 13 sec, 11 sec and the last, seemingly near instant. The only difference from previous test was, today, the local db didn't get updated alongside the import process. And to clarify, all Saving Games times mentioned (1 minute, 4 minutes...) by me were from the time Saving Games appeared, to the end. aka, They did not include the update local db time. I'll try again tomorrow and see if I can find something in my/the process that triggers the anomaly.

An <Image /> (the line below your highlighted section that binds to the x:Name in your highlighted section) cannot display (have its Source be) an mp4 video file. It doesn't know what to do with it.