oblivioncth

Interesting. I'm at a complete lost on what could of happened because it changed so suddenly and I only picked up on it soon after getting 11.2 beta to work and don't remember changing anything with my system. Strange.

@Jason Carr Also just meant to let you know that starting with 11.1 beta 1 (it may have been 11.0 beta 1) the speed of any filtering (i.e. searches, changing platforms, changing views) became painfully slow, often taking up to 20 seconds for the scroll view to refresh, but now at 11.2 official the speed is the fastest its ever been, with searches for example often being returned after just 1-2 seconds or so. This is with a collection of 60,000+ titles. So if this isn't a coincidence and you did make changes in the backend related to populating the games view, note that for me at least the current implementation is stellar.

Ok after reverting to 11.1 stable and then enabling debug logs, I reinstalled 11.2 stable and started LB again while watching for the Logs folder to be populated. As you guessed previously, the initial entry that was last in the log while the it was stuck initializing was "Libraries Initialization: Extracting ThirdParty folder...". Deleting the folders as you suggested doesn't seem to allow it to get any further. Not sure exactly what the hold up was (I did mess with the ScummVM folder previously, though I thought I had reverted all my changes), but I then tried deleting every folder under the ThirdParty folder except for 7-Zip, and that ultimately allowed it to start.

I don't have the machine at the moment. I will ask the friend who does to leave the process go for like 30 minutes to see if anything happens. As I said previously I let it go for a few under 10. If nothing happens I'll get a debug log.

Nope. Just D:\LaunchBox on an NVMe drive.

No. Windows 10 Pro if it matters.

Unfortunately this didn't change anything. After doing this I watched as the program re-deleted and re-re-created those two folders upon startup as they should. This did make it so the 7-zip process was no longer present but LB still hung at "Initializing" on the splash screen. When the 7-zip process is running it does do some work for a few moments before becoming inactive. The installer for 11.2 final seems to have just gone up (just one beta?) and that too results in a stuck startup for me. Using the 11.1 installer to revert to that non-beta version has allowed me to start it again. Not sure what the issue is, but both my Logs folder and error.log are empty (I'm assuming these are only populated if an actual error occurs and there is no verbose logging) so I'm not sure how I can provide much more information other than anything you'd request specifically.

Could be something particular with my install but after updating to 11.2 beta 1 LB never gets past the Initializing splash. I've let it go for about 10 minutes; however, I suspect that no amount of time will result in anything as the process shows no CPU or disk utilization, with the only noteworthy detail being that it has a 7-zip console as a child process that also shows no activity.

So I just read over the Flashpoint update post that I missed from back in May and unfortunately it mentions that on the next update of their launcher (which may or may not be the next update itself) they will be moving to using an sqlite database instead of the Launchbox based XMLs. This doesn't make importing the collection impossible, but does make it more complex (the degree of which will depend on how their new database is set up) as I will have to parse the database file and create new Platform XMLs from scratch for Launchbox instead of being able to just modify the existing ones. Luckily some aspects of the import tool, like its UI, and the command-line helper application are still fixed in function and will not need to be modified due to this particular change in FP, so I will continue working on those aspects; however, if this new launcher version is not released by the time I have everything else finished, I may pause and hold off on creating the FP data interpreter portion of the conversion tool until it is released since they are likely to keep using that format for some time and it makes no sense for me to setup everything with the current XML scheme only to have to completely throw it all out as soon as FP is updated, which for all I know could happen a few days after I'd release this tool. The command-line utility is basically done at this point other than some more extensive testing to cover all use cases. I get held up for a while because of a bizarre error with a library I'm using that made no sense because it turned out the compiler was incorrectly not display a warning that specified the exact issue as it should have been and so all that I was seeing was a secondary error caused by the first issue that seemed completely unrelated. It also didn't help that a particular piece of documentation for the library didn't explicit mention why you couldn't do what I was trying to do and only vaguely implied it in another location. I'm about to start on the import tool and like I said I'll focus on the general UI and initialization/clean-up of the import process first and leave the core conversion procedure for when FP updates. I plan on making it so that you can use the tool to do a fresh import or update your collection within LB to match the latest FP version, allow you to select exactly which Platforms/Playlists you want imported, and other than those selections and some path input have the entire process be automated. Exactly what they do with their new database format is a bit of a whammy here but I'm still fairly confident this should all work out in the end.

The C++ program that acts as a command line interface for Flashpoint is nearly done. Then I just have to convert my MATLAB scripts into another application that takes care of the conversion/import process. So maybe a bit less than half way? Sorry it's taking so long but like I said before I can only work on it a small amount of the time.

Just wanted to give an update: Due to various situations that are too involved to explain, I only have access to my machine with LB and Flashpoint for some days and not others. Currently I've been away from it for some time, but I am still continuing to work on an importer and will resume doing so every time I'm back where the machine is. I've gotten a lot more games in using the start of an automatic process and they all seem fine. I last finished getting the necessary binaries on the machine to start writing the C++/Qt based replacement launcher (that will be used in-place of Flashpoint.exe), as it will ultimately be easier to do it on the machine itself instead of on my laptop. Can't exactly say how long it will take but so far I have seen no reason that this can't be accomplished in a reasonable amount of time and result in a process that's fairly streamlined for the user. Once things seem to be working for the most part I'll upload a beta release (I'm sure there will be bugs) and will fix any issues that people report that I personally don't run into. There are quite likely to be a few given how many games are in the Flashpoint collection that use various combinations of different software tools to make them work.

Yea, it would be unfortunate, though since in it's current state at least it doesn't seem it will take too much effort, I'm going to see what I can do. One annoyance is that FP names its media files by Game ID (which I actually like better; its straightforward and deterministic), whereas LB uses the game's title. While this is fine for simple games, ones with certain symbols or characters from other languages are handled differently and it may be a pain to make sure all cases are covered. Won't know for sure until I run my first attempt at having the conversion performed pragmatically and then see how many games are missing their images due to unexpected naming convention differences. First impressions are good. I was able to alter a random flash game a bit and use some simple batch files to start/end Flashpoint's supportive programs, like its redirector, to get it into Launchbox with its main picture and so that it can successfully be started by just clicking on the game in LB (instead of having to also have the Flashpoint.exe running first or something, like previous methods other forum users have used). I will probably end up using a C++ application to handle these tasks instead of a batch file in the final product to keep things silent and clean. The batch files run automatically on upon starting and closing the game and do not launch the game itself. This way the LB/BB pause functionality should still work correctly. There may be some unexpected difficulty in getting the other Platforms (i.e. web Unity) to work, but for no I see no reason to believe so.

I didn't know that such a hotkey existed, that can definitely be useful, thanks. I also forgot there was a seperate Views ection under BB options as I was used to changing them within the page for the theme itself. So yes, the options are still there, the only downside is that there is no preview for them now because the Views option screen is only text and no images, but I guess it isn't a huge deal if you just use the hotkey method to change them in real time to get instant feedback.

Perhaps it was unintentional, but there definitely is a bit less customization in 0.9 vs 0.7 (at least in the Dark Theme). I know you split the themes up, which isn't an issue, but to clarify, here is what I'm talking about: In the above for 0.7 (regardless of dark or light), you could choose things like say, if you wanted your Platform List to use a Text List view, or a Wheel View (options 1 and 2 respectively in the screenshot) which would result in the following two different ways to browse your platforms. Text List: Wheel: But now in 0.9 there is no View selection so you're stuck with the defaults: Such as a Wheel for the Platform View and Text List for Games View. At the moment I happen to like of the default Views in 0.9, but may find I'd prefer something else for one of them. Just figured I'd point this out so that the different view options that already existed in the combined 0.7 theme could be re-added to the View options in the separate dark/light themes in the next version, before you worried about creating entirely new ones.

Thanks for coming through with this despite everything. I'm glad that there is a 100% dark theme now and this version is much snappier with my large collection (60.000 plus) than 0.7. 0.9 seems to have a much more bare-bones options screen in the BB theme manager and there are no longer multiple Views to pick from compared to 0.7. While I actually prefer the list view for the games list over the clear logo "one at a time" list that 0.7, I'm just curious as to whether or not you took out the options because you're working on new/revised ones? Or if you feel that the current default/only views in 0.9 are the best of the bunch and are only keeping those moving forward?

I took a glance at the data files and they are still mostly the same as the xml files that LB uses. This does make me a little worried that they will still change them significantly in the future, but perhaps there will still be a significant amount of time before this. Luckily this means that ultimately all that should need to be done is some mild processing of the Flashpoint xmls to remove any fields that LB doesn't use (or potentially rename them to the closest thing LB has) and add anything missing that LB needs and hopefully they can just be added directly to LB the same way that eXoDOS is. I will definitely start playing with that when I can get around to it.

Definitely convenient for people who are starting fresh, and yea this seems like the way to go. I don't know of any other way to import such things without drag and drop other. I don't really know how exactly the built-in version handles things but I had no idea that its targets were hardcoded. This is definitely an issue since like we said the names are not at all guaranteed to be the same between systems. No clue if Jason will ever have the time or care to get to it, but a built-in import option that reads the INI directly and more or less does what we did through scripting would ultimately be ideal.

Ah sorry, since there was a bit of ambiguity as to what you were referring to given the poorly defined ScummVM terms due to the lack of documentation, I figured I'd just explain everything I did to be safe. Wasn't aware the entries were referred to as Targets. Good to know. I wasn't aware of that issue that LB would have while splitting games. Since each game ultimately has its own ID there would be no issue with keeping the folder derived name on both. I guess after splitting there will be some manual adjustments needed anyway, during which you can fix the name, but that is definitely still annoying. I agree with you in that I think whoever made the Retroarch docs for ScummVM is conflating gameid and short names. I am also surprised about the lack of documentation concerning many games that ScummVM definitely supports. It is a shame that so much processing is require to get the games in correctly but I suppose it's still better than having to add them all one-by-one.

Ok so here is the deal. Like you mentioned, every game that ScummVM officially supports has a (sort of) unique identifier that is its short name. While I don't remember what the ScummVM docs say about this, what I am referring to is the abbreviated name that is used as the header for each game entry within your scummvm.ini. There is a "gameid" for each entry, but this is most certainly not unique as it seems to me like it is more of an "engineid", i.e. telling the Scumm engine which base interpreter to use for that entry, and obviously there are only so many of these that are shared between various games within the ScummVM set. To clarify, here is an example of the entry for the CD/DOS/German version of "Indiana Jones and the Fate of Atlantis" in my INI: [atlantis] description=Indiana Jones and the Fate of Atlantis (CD/DOS/German) path=D:\LaunchBox\RAI\ScummVM\Standard\German\Indiana Jones and the Fate of Atlantis (CD DOS, German)\ gameid=atlantis language=de guioptions=lang_German The shortname I am referring to is "atlantis" here. Funny enough a lot of these short names seem to be undocumented, or at least are hard to find. Now, as much as this system seems to work like how MAME handles roms where each game has a truly unique shortname that you can just pass as an argument when starting it and as long as its in your ROMs directory the game will be started without needing to provided a direct path to the rom, it seems that these are rather just default or "preferred" names for each game. This is demonstrated in two ways: First, when you have multiple versions of a game ScummVM, while scanning them in, handles them just like most file systems do when something automatically gets assigned a name that is already taken; it simply appends a number onto the end, with the number simply corresponding to the order in which the versions were found during the scan. Correspondingly, here is all of the entries of have for my versions of the above game: https://pastebin.com/RWK5UT4x The "(CD/DOS/German)" version was found first due to its alphabetical position from its folder name, so it was assigned atlantis, while the "Floppy/DOS/English" version was found second during the scan (again due to its folder name) so it was assigned atlantis-1. You will notice that some versions also have their own short names, like atlantis-amiga, but ultimately these are handled the same way in that if you have multiple versions, of that version, -N (where N is the next available number) will simply be appended to the end. So unlike MAME where each game has a fixed internal name that is used to launch it, the short names in ScummVM are more or less an an index for each individual's scummvm.ini to let ScummVM which entry to refer to when starting. There tends to be a lot of overlap between any two person's INIs due to the "prefered" names that are used, but as you add variants of games to any INI, the exact short names that appear will differ depending on the exact variants and folder names that an individual has/used. So this is how you handle launching any specific version of a game. You have to check what short name it received within your INI and then use that in the command line to start it. Second, use of the "preferred"/default short names is not at all enforced. In my INI I can change atlantis to thisisadifferentname and then do: scummvm.exe thisisadifferentname and it will still launch the CD DOS German version of Indiana Jones and the Fate of Atlantis. Again, this reinforces the idea that while there are default names, the short names ultimately used for each game are technically unique to each install and are not universal. As for how I got my collection into Launchbox correctly, I did the following: Add standalone ScummVM 2.1.1 as an emulator with No Quotes and Name Without Extension checked Create a new empty folder to hold onto named whatever you want (in my case, a folder called "Launch Files" under the root of where my ScummVM game files are stored Create a file/folder hierarchy with sole purpose of adding the games to Launchbox in the most optimal way. This is done using my MATLAB script which is explained in the following steps Iterate over each game entry within the INI, which is easy since they always start with '[', and store the short name and data in the "description=" field to their own variables. For each entry, create a folder under that new root folder (i.e. Launch Files) with the name from the description=" field, and then within that folder create a file with the entries short name and ".scummvm" as an extension Optionally, for better compatibility with Retroarch ScummVM, write the short name of the game only to that file (i.e. atlantis.scummvm will contain the text "atlantis" and nothing else) Once the script is finished, go into LB and import using the "ROM" files option, point it to the root folder used (Launch Files), tell it to scan sub folders, and tell it to use the folder names as the game title instead of the file names This way, each game gets the correct title, and the "rom" file for each game in my LB database is effectively shortname.scummvm, which makes it clear what the file is for in my file-system, but since the "Don't use extensions" option is checked only the short name will be passed to scummvm.exe when starting a game. So while that whole folder/file structure you end up creating holds no actual game data, it is ideal for getting games to start correctly with launchbox and ensuring each game receives the correct metadata. This has worked perfectly for all my ScummVM games. Now, I did need to do some manual auditing of my game folder names and the "description=" fields in my INI (these are also not strict and you can change them to whatever you wish) due to some games that used the same exact description (I used a separate script to find these) and clean up a few other things, but once that was done the main script took care of 95% of the work. If it helps clarify what I did you can see it here: https://pastebin.com/y4tMrh0j

Hmm, I personally haven't experienced any of these issues but I'd believe they exist. I use standalone 2.1.1 so I can't speak for how Retroarch handles starting games, though I did try to mold my setup in a way that would make it easy to change to Retroarch's ScummVM core if I so choose. I don't have access to my setup at the moment but will later today and I don't want say anything about how I ultimately imported my ScummVM games that is untrue in the event that I remember something wrong. So, once I'm in front of it later tonight I'll check the couple details I'm fuzzy with and get back to you. I remember most of how I handled it, I just want to double check a few things. I have a full set so I know what you mean when it comes to the duplicate short names, but at least in 2.1.1 that is a non-issue mostly.

Don't worry, I've been following it closely. I haven't had access to my LB machine for a bit and haven't actually finished the torrent yet because of slow wifi were it is and its also been sleeping most of the time (long story, Covid related, blah blah blah). I am curious to see what the next status update says because I'm not totally sure they've fully moved to their new database format yet but I am going to take a look at 8.0 when I can and also what you can do with LB plugins to see which route is the best to take (plugin vs external app). My priority is to try and keep pause functionality working, but it will comedown to how the FP games are handled across the board. Since there are various engines behind each game ill either need the user to set up multiple emulators or have each game use a overriden launch command. May take me a bit but I would every much like to have flashpoint games work from launchbox so I'm definitely going to test the waters.

I had accidentally unchecked the "Don't use Quotes" box when I took the screenshot I previously attached, so that is working correctly when used. As for the launch parameters it seems like they do work when used under the associated platforms tab, which despite being a weird issue that they don't work in the main tab like they do for every other emulator, it is good enough for me. Thanks for the help.

I am using the checkboxes you noted, hence why in Procmon the only appended command was simply "pajama" (though it's strange that there are still quotes around the file name), but I have not tried placing the default arguments in the platform association window instead of the main emulator window. I'll give that a shot and get back to you. The games launch fine it's just that since the arguments are ignored it isn't using the .ini I want and starting in windowed mode. Thanks.

This is on 10.14 I don't have this issue with any other platform and suspect the issue is related to the fact that ScummVM is whitelisted as an exception to be handled by the built-in ScummVM distribution that is present in the third party folder. Because I always wan't to use the latest development build and have more control over the install, I use a standalone install of ScummVM that is added as en emulator and everything else about it works fine; however, despite having these options for the Default Command-line Parameters: --no-console --fullscreen --config="D:\Launchbox\Emulators\ScummVM\scummvm.ini" and LB showing this as a sample command: scummvm.exe --no-console --fullscreen --config="D:\Launchbox\Emulators\ScummVM\scummvm.ini" File none of them are used when a game is started, and I am certain this is an issue with LB thanks to ProcessMonitor (great tool), see the attached image. As shown only the path to the EXE and the name of the ROM file are used, and you can even see that there is an extra space in the full command that was used because LB added the space that should be after the default CLI arguments but the arguments themselves are missing. The behavior doesn't change if "Don't use quotes" or "Use file name only" are unchecked. Just wanted to see if anyone else has ran into this issue and possibly has a solution before I submit this to the issue tracker.

I'm in the same boat actually, other than that I have played a few games here and there as I got some of the setup done ahead of time on another PC and then migrated everything over, but polishing the metadata of my local database of 70,000 plus games is going to be a never ending effort lol XD.