Jump to content
LaunchBox Community Forums

Shaeree

Members
  • Posts

    24
  • Joined

  • Last visited

Posts posted by Shaeree

  1. 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.

     

  2. 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:

    1.  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
       
    2.  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.
       
    3. 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'!
       
    4. 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.

     

     

     

    LaunchBox-WindowsPlatform.png

  3. 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.

  4. 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?

  5. 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.

  6. 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...

  7. 4 minutes ago, lordmonkus said:

    You aren't getting any push back, you are simply getting explanations about something that is completely unnecessary and I already told you that you can use the scan for added / removed roms tool that is available.

    You are using Plex and EmulationStation as examples but those are very specific needs programs, they both know exactly what files are used by the system in place. In the case of Plex it knows to look for specific video files and in the case of EmulationStation it is using Libretro cores and again knows specifically what file types it needs. Launchbox is far more open ended and leaves all of that to the end user because different users use different emulators which of course have their own unique way of handling different files.

    And just for the record, both myself and Dos76 are paying customers as well, we are not paid employees here.

    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."

  8. 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.

     

  9. 29 minutes ago, lordmonkus said:

    As far as "like EmulationStation" is concerned I would much rather have things the way they are then having the frontend arbitrarily decide what it's going to import. I want full control and easy management like the way it is now then to have the frontend deciding just because it finds some new files that I maybe don't want in the list for whatever reason.

    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.

  10. 1 minute ago, DOS76 said:

    Adding ROMs either way works the same the only thing is with LB if you are importing your multi-file disc games into LB's game folder and you use the search method it won't move all of your files to the folder and then nothing will work (unless that has changed in one of the newer updates). If you are importing them but are leaving them in their original location then everything should work fine.

    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?

  11. 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.

     

  12. 3 minutes ago, lordmonkus said:

    Are you talking about during the import process ? If so then you can have your file manager only show .cue files by typing *.cue in the search or you can only select your .cue files in your file manager and drag them in to import them.

    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.

  13. 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."

  14. 1 hour ago, SentaiBrad said:

    If you have it in certain places on your C drive, sometimes you need to do that. It doesn't make it less portable, you can move your entire install to an external, and as long as the paths were relative or your games aren't changing paths, it will work just fine. If it's in a certain location that you need to run as admin, that's Windows fault.

    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.

     

     

  15. 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?

  16. 7 minutes ago, ckp said:

    Sure, I understand what you're saying, but you see how it's designed at this moment. So for the time being, I was hoping we could provide you with some settings that may help you to achieve a happy-medium. 

    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.

  17. 30 minutes ago, DOS76 said:

    Okay I'm confused now when you say games view what do you mean? How can you start in the games view you have to start in the platform view I believe some of the confusion might be that you are calling everything that isn't the menu the games view which is inaccurate because it consist of the Platform view which shows your lists of systems and then the games view which shows all of the games available for that platform and then it goes to the details view where you see the option to play the game, mark it a favorite, view all of your images so on and so forth that is why you need a back button to navigate up and down through those menus.

    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.

  18.  

    1 hour ago, lordmonkus said:

    But if you make the "starting point" the games view where all your systems are like it is currently all you see are your game systems and nothing more unless you choose to go "back". 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.

    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. To me going back makes the most sense especially when you can lock users out of the options menu with a simple pin code and you can back up one menu where you can pick different ways of viewing your library and a search function. This menu gives you extra functionality without cluttering up the main "systems" and "games" lists and you don't need to worry about some extra hidden hotkey to bring you into the options.

    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? <<

     

     

    1 hour ago, ckp said:

    Everyone has their own preferences. So does @DOS76 suggestion about changing the key solve the problem for you? It seems to me that this would solve the problem you originally stated, which is accidentally hitting "escape" after exiting a game. 

    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.

  19.  

    18 minutes ago, lordmonkus said:

    it looks the problem is accidental exiting of games using the controller

    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.

  20. 14 minutes ago, DOS76 said:

    the game view how would you get back out

    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.

  21. 14 hours ago, DOS76 said:

    unmapping it would make the program unusable

    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?

    11 hours ago, kpop said:

    I was asking the same question about this, as I've just put BB on my bartop, when I had mala and maximus on it,they had the option to just right click and access the options of the FE.

    I'm not sure what any of those things are... What's a Bartop? Or mala, or maximus? LOL.  New to the emulation scene.

  22. 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?

     

    • Like 2
  23. This is totally doable without AHK, so you can use this with other frontends as well.  Here's how I did it:

    1. In Dolphin: Graphics Configuration -> un-tick Render to Main Window
    2. 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

       

    3. 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!

     

×
×
  • Create New...