Shaeree

All ^ that ^ script does is launch the .exe in a maximized window, but that's definitely not the limit to what VBScript can do! It's also an easy way to (just for example): launch multiple programs at once (like your game and your gamepad/joystick mapper with a specific profile); and/or control whether programs/games launch maximized/minimized/etc (e.g. hide Dolphin's or Xpadder's main program windows). The advantage to VBScript over Batch or Powershell is that it doesn't pop up any ugly console windows.

What I did for Windows games was create a fake emulator, associate it with the 'Windows' platform, and then "import" the games' .exe files as if they were ROMs. Any game--Steam, Blizzard, technically any .exe file will work. The scraper even works in this configuration. If you're interested: Create a text file, and name it "WindowsGame.vbs". Make sure its extension isn't actually .txt; Windows' default is to hide known file extensions. Its icon should change to a white sheet with a blue-ish scroll on it. Paste this into it, and save it: Set sh = CreateObject("Wscript.Shell") sh.Run """" & WScript.Arguments(0) & """",3,0 In LaunchBox, add a new emulator, and call it something like "Windows Game". Its Application Path will be C:\Windows\System32\wscript.exe, and its Command-Line Parameters will be the full path to the .vbs file you just created. Associate the "Windows" platform with your new fake emulator. Now you can import your games' .exe files as if they were ROMs. Don't forget to select 'Use the files in their current location'! During import, don't bother with searching for box art, because it won't find anything relevant. After the game's imported, right-click -> Edit, and change the game's Title to something you think a scraper can actually find (e.g. World of Warcraft instead of 'wow'), and click the Search for Metadata button. You should end up with something similar to what I ended up with in the attached picture.

Groovy, thanks! I found that I could force BigBox to show the image I want by setting the region on the individual game... Edit: Also looks like appending (USA) to the end makes LaunchBox correctly identify the region during import.

So... When I right-click, edit, there's a list of images in the lower right-hand corner... But how do I "set" one of those as the boxart to use for the game? (It seems to always want to pick the MegaDrive versions, when I'd rather have the Genesis version.) Edit: I just found 'Flip Box' which appears to cycle through all boxart... Will that persist through app/computer shutdowns, and is it the only way to explicity choose a boxart image? Edit 2: BigBox doesn't show the new images I picked out after 'flipping' to the alternate image--so BigBox and LaunchBox are showing different images from each other. I can go in to the game details and flip the box, but it doesn't stick. Is there any way to fix this? Edit 3: Digging around in the image folders, I noticed the images I don't want are all in the other regions' folders--is there a way to tell LaunchBox that I want it to prefer images from my own location/region?

Me: Wouldn't it be cool if... Y'all: NO. Me: Wouldn't you like it if there was an option to... Y'all: NO. ... And I'm the one with the attitude. No, I'm done. I thought this was the right place to offer suggestions and ideas, to bounce them off other people before they turned into actual feature requests, but it isn't. Thanks, I'll use Bitbucket.

Round and round in circles... Never mind. NEVER. MIND. Forget I said anything. LaunchBox is perfect for everyone in its current state. There is nothing wrong with LaunchBox. It's totally perfect. Jesus...

The explanations, however, end up sounding like "We like it designed that way, and we don't see why you want an option for it to be the other way, so your request is invalid." It's actually getting really frustrating. Everyone talks about how they like LaunchBox because "it's simple," yet, when I suggest an option for an enhancement which would make it simpler in my use case, I get (paraphrased) "no, you just need to use it the way I use it."

Okay... I'm getting a lot of pushback when I suggest design enhancements, and totally I get it. You guys like it the way it is, you've got a lot of time invested in it, and you don't want some newb jerkface coming out of nowhere saying its design could be better. I'm not asking for anyone to relinquish control here. If you haven't used Plex, its detection and scraping are fully automated, but of course it makes mistakes, which is why it has the ability to override with a manual edit or manual re-scrape. I'm not asking for anything that hasn't already been done by LaunchBox or some other emulation frontend. Ignoring .bin files--or even ignoring only the .bin files which have a matching .cue--is pretty easy code to write, and as an added bonus, it would be the first step toward full automation. I'm not asking anyone to solve cold fusion here. Just a baby step that would help, oh, most of your paying customers.

See, I also use Plex, and I think that is the way it (detection and scraping) should be--full automation. I don't like doing busy-work that can and should be automated.

Good point about the importing. I didn't even think of that, because, like most of the people here, I experiment with lots of different frontends and emulators, so yeah, those ROMs need to stay in an app-agnostic location. Honestly, I'm not even sure what the target audience is for the "move-your-ROMs-to-your-frontend's-folder" feature. In any case, I was just trying to point out that you'd solve a lot of people's frustration if you just had the "folder" selection for PlayStation ignore .bin files by default. There's always the option to import individual edge-case files in addition to that, but aren't the vast majority of psx roms .bin/.cue?

Yes, I was talking about importing. Also about design. Right now, importing is manual, but that's not exactly optimal. An inability to auto-detect which file is the correct one in a series would seem to affect the program's ability to automatically find added/deleted ROMs in your playstation platform folder, as well as any future ability to auto-detect like EmulationStation does.

Well, I meant when you select "folder". I don't really want to have to manage or import each game individually either. Ideally, I put games in platform folders and LaunchBox takes care of the rest automagically, so I'd like to get as close to that as possible.

Is there any chance of just having LaunchBox only detect .cue, or ignore .bin, by default for the PlayStation platform? I kind of went off on a "how do I convert my .bin/.cue to ISO" tangent there for a couple hours as well, until I realized the games are in that format for a reason. Customers never ask for what they want, they ask for what they think someone can do about their problem and the problem for most of the people asking this question is "I don't want 52 instances of my game showing up in LaunchBox just because it has 51 .bin files."

Butwaitwaitwait. I'm having a logic problem with this--I moved it from somehwere else. It had already been launched. Shouldn't that one-time change it needed to make have already been made, if it was indeed a change inside the LaunchBox folder?

You're right--it was 'Windows' fault.' It's in a C:\Games folder I created where 'Authenticated Users' has modify+inherit... But I did copy it from an NTFS partition, and occasionally inheritance doesn't merge the way a person thinks it should during file copies, so I probably had broken inheritance somewhere. Hope that's helpful in case it happens to anyone else.

I moved BigBox to a brand-new Windows 10 install earlier. On launch, it hung indefinitely until I killed it and started it "As Administrator." It launches without prompting for elevation since. The workaround's pretty simple, I'll admit, but now I'm wondering... What's it writing to that it needs elevation? Doesn't that make it not really portable?

An option for separating the 'menu/options' and 'search/sort/change view' functions from the 'back' key/button binding, as well as the ability to create independent key/button bindings for those functionalities, would be sweet.

I set my Default Startup View to 'All Games'. BigBox launches in CoverFlow view, displaying every game, because I'm not interested in hierarchies or lists or folders on my 10' interface.

Because I can't figure out how to break the quote markup into parts: You go back if you want to access the options and other features that you do not want straight forward access from the "systems" and "games" list. I understand that's how it is now, and that's how you've been visualizing it. I'm asking you/the devs to consider thinking of the Games view as the root node of the UI workflow, where everything else you do stems from the Games view (or whatever their Default Startup View is), because I think that's where the users are usually going to want to start. In that scenario, 'back' to get to the menus doesn't make sense. To do it the way you are asking for (or at least what I think you are asking for) means you are either now putting extra stuff in the "systems" and "games" menu which you do not want people to access and gets in the way of picking your games. No, no no. The menus are fine. I just want a separate key binding for the menu(s) that isn't/aren't the same as 'back'. you can lock users out of the options menu with a simple pin The only reason I've considered disabling the menu is because I couldn't figure out how to prevent accidentally getting into the menu. I don't have any reason to lock people out you can back up one menu where you can pick different ways of viewing your library and a search function. Again, this isn't (in my opinion) back-style functionality. Other apps don't work like this, and using 'back' this way breaks cohesiveness. This menu gives you extra functionality without cluttering up the main "systems" and "games" lists I use the 'CoverFlow' view for 'All Games', and when I hit 'back', there aren't two levels--just one monolith menu with all that stuff in it. Maybe search/sort/change view should have its own keybinding too. and you don't need to worry about some extra hidden hotkey to bring you into the options. My Spidey-sense tells me you think having individual keybindings for separate functionality is a bad idea? I disagree, on the grounds that BigBox, by its very nature, needs to play nice with other apps and various human interface devices. So the more keyboard/controller binding options you can give it, the better. >> To sum up: How about independent key bindings for the menu and search/sort/view functions? << As I mentioned, that's a symptom of a systemic problem. It works for that one specific scenario, but then suddenly my binding for 'going back from submenu to menu' isn't the same as my global 'back' any more.

That's kind of a tangent, actually. I see that as being a symptom, where the actual problem is that the 'back' functionality shouldn't be dumping me into the menu, because the starting point should be the games view, so while you're in the games view, there shouldn't be any place to go "back" to. You should be able to go into the menu, and then back to the games view, not the other way around. Like if it were a flowchart, the games view would be the root object. Sorry if I didn't make myself clear at first--Honestly, I wasn't sure anyone would listen to "Hey, I think your UI workflow is backward" without coming up with a reason for why that's a problem.

That's what I'm saying. I don't want to get out of the game view, at least not accidentally. The problem is 'Esc' is also the emulators' exit button. Sometimes, while exiting an emulator, 'Esc' would get pressed multiple times or queued up in the buffer multiple times, and I'd end up in BigBox's menu instead of my list of games, which is pretty annoying. I submitted a request for the devs to re-evaluate BigBox's workflow from a more user-centric perspective. In the interim, I just re-mapped 'back' to some keyboard-only button, which is kludgy, but does keeps me from accidentally ending up in the menu when I don't want to be.

Correct me if I'm wrong, but it wouldn't make BigBox unusable, so much as un-configurable... and for my use case, that's desired behavior. I'm looking for a sort of kiosk mode, where the user can't accidentally get to the options menu or quit. But that's a tangent. What bugs me most, I guess, is the inconsistency--'Esc' quits the emulators, but once you get back to BigBox, it doesn't quit--it goes to the menu, which seems counterintuitive to me for a couple reasons: First, 'Esc' should never be a way to get in to something, and second, getting into the menu should always be a deliberate action, not an accidental one. I know what's going on here: The developers see the menu as being the starting point for everything you do with BigBox, so when you hit 'Esc', it's going "back" to that starting point. But the users see their list of games as being the starting point, and the menu as a place you go from there... so when a user hits 'Esc' from their list of games, what they intuitively expect to happen is BigBox exits. I created a request to update BigBox's workflow here. So are there any keybinding settings for BigBox? I'm not sure what any of those things are... What's a Bartop? Or mala, or maximus? LOL. New to the emulation scene.

Is there any way to un-map 'esc' from going back to the BigBox menu? During configuration and testing, due to the combination of it being the button you use to exit an emulator and latency, I'm like constantly accidentally hitting it when I totally don't want to be in the menu, and it's extremely disruptive to my workflow. I'm also thinking that it might be confusing for small children and less tech-savvy people. So can we bind 'menu' to something else, or maybe even have a kiosk mode?

This is totally doable without AHK, so you can use this with other frontends as well. Here's how I did it: In Dolphin: Graphics Configuration -> un-tick Render to Main Window Create Dolphin.vbs in Dolphin's folder, with this in it: scriptFolder = Left(WScript.ScriptFullName,InstrRev(WScript.ScriptFullName,"\")-1) Set shell = CreateObject("WScript.Shell") Set regex = New RegExp Dim args() regex.Pattern = "^[\/\-]" For i = 0 to WScript.Arguments.Count-1 ReDim Preserve args(i) If regex.Test(WScript.Arguments(i)) Then args(i) = WScript.Arguments(i) Else args(i) = """" & WScript.Arguments(i) & """" End If Next shell.Run scriptFolder & "\Dolphin.exe " & Join (args), 2 In LaunchBox, change Dolphin's Emulator Application Path to C:\Windows\System32\wscript.exe and the Default Command-Line Parameters to X:\Path\to\Dolphin\Dolphin.vbs /b /e The most important bits are the "Render to Main Window" option, which lets you use a different window activation/show state than the one you want to use for the games, and the "2" at the very end of the script which tells Dolphin to launch "Minimized but active". I'd use Powershell, except it's got the same problem as Dolphin, with the annoying window popups!