JoeViking245

Set to anything (such as Arcade) and be sure NOT to check "Default Emulator". At least I think that should work. Just DO NOT check "Default Emulator". If for some reason you have to have a "default emulator", go ahead and check it. It will next ask something like do you want to make this default for all games in Arcade? NO.

FileCopyDir, "%dir%", C:\GameLaunch\Game, 1 ;1 = Overwrite existing files. But ya, most all systems emulated won't see a drastic improvement (loading or playing) between being on an SSD vs a HDD. Conversely (as you stated) next gen (and even many current, hue-jass) PC games would. But to copy them per-launch... ugh. lol Though I do love a successful proof-of-concept. May not have been 'acceptable'...

#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases. SendMode Input ; Recommended for new scripts due to its superior speed and reliability. SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory. GameFullPath := %1% ;E:\SUPERHOT MIND CONTROL DELETE\SHMCD.exe SplitPath, GameFullPath,, dir ;E:\SUPERHOT MIND CONTROL DELETE SplitPath, GameFullPath,game ;SHMCD.exe FileCopyDir, "%dir%", C:\GameLaunch\Game ;added quotes just in case sleep 1000 ;pause 1 second for whatever reason run "C:\GameLaunch\Game\%game%" ;added quotes for games that have spaces in them Return $Escape:: WinClose, ahk_exe "%game%" ;a better option ; Process,Close,"%game%" ;fixed my oops and added quotes for games with spaces in the name ; Run,taskkill /im "%game%" /F ;added quotes for games with spaces in the name sleep 1000 ;give it a sec to close down FileRemoveDir, C:\GameLaunch\Game, 1 sleep 100 ExitApp return I assume all these games are executable's (vs needing their own external emulator). I'm guessing the 'rhyme or reason' is some paths and/or game_names had spaces in them. Added quotes here and there. Changed the game close process and added a pause before deleting. But ya, if the game files/folders are large, it's almost self defeating. Still not tested, but does look a little better.

Call this a "One and Done". Compile this to an exe. #NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases. SendMode Input ; Recommended for new scripts due to its superior speed and reliability. SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory. GameFullPath := %1% ;E:\SUPERHOT MIND CONTROL DELETE\SHMCD.exe SplitPath, GameFullPath,, dir ;E:\SUPERHOT MIND CONTROL DELETE SplitPath, GameFullPath,game ;SHMCD.exe FileCopyDir, %dir%, C:\GameLaunch\Game run C:\GameLaunch\Game\%game% Return $Escape:: Process,Close,SHMCD.exe Run,taskkill /im %game% /F FileRemoveDir, C:\GameLaunch\Game, 1 sleep 100 ExitApp return Create a new emulator in LB pointing to the above exe. Uncheck these boxes.Edit the game(s) to use this emulator. Not tested. But looks good on 'paper'.

@Jayinem Sounds like your game is on an external HDD and when you unplug the drive then plug it back in, it doesn't [always] connect using the same drive letter. Sometimes it's W:\ and sometimes it U:\. What you need to do is tell Windows that when external HDD (1) in plugged in, always assign it to drive W:\. When external HDD (2) is plugged in, always assign it drive letter T:\. and so on. A search on one of those popular internet search engines should help. "force external hhd letter"

With changes that have been made during LaunchBox's evolution since 2 years ago, that whole line of the code ("string platformAHK.....") won't work anyway. You may want to look under Help & Support - Request a Feature and see if there's already a request for this feature and UpVote it. If not, make a new request.

click Browse (under [next to] Application Path) and browse to the file you normally would have right clicked on.

So it looks like it might be fairly straight forward. You'll need to create a new emulator and point the emulator executable to LEProc.exe. Then for the game, have it use that 'new' emulator. If it helps, here's a sample command line I found by Googling "run LEProc from the command line". F:\Locale.Emulator.2.4.1.0\LEProc.exe "D:\Yori\Locale.Emulator.2.4.1.0\MakingLovers.exe"

Double click on "LEProc.exe" If that doesn't do anything, click once on the address bar in the space after "2.4.1.0" (red arrow), type "cmd" (no quotes) and press Enter.This will open your Windows Command Prompt. Now type "LEProc" (again, no quotes). And press Enter. Note: Yours won't show "D:\LaunchBox>". Capital/Lower case letters don't matter. You don't need to type ".exe".

@legolas119 It looks like that program may have a command line option to run. If you know that, you could be good to go. I say "could" because I'm not sure how 'tricking' the program you're about to run affects currently running Windows applications (i.e. LB/BB). Go to the folder where the Locale Emulator program is and run "LEProc.exe". From what I can tell, that's the main program and by just running that, it'll pop up a message saying how to use it from a command line. (You may need to run that from from the Command Prompt instead of just double clicking it in Windows Explorer to see the message.)

Did the 'random' file have any peculiarities about it compared to other video files? Size/aspect/file_type/.... Or was it truly random in that it varied by different videos? If it was a specific video file, could it have been one that people are getting from EmuMovies that we should be aware of?

No offense taken. I was stuck looking at the 'left hand', while you were simply talking about the 'right hand'. They do connect in the middle, just sit on opposite sides. lol It's all good.

"Default" being how you set up your custom config file. Yes. But if you initially setup all possibilities (Player1 left side of cab, Player2 right side of cab, Player1 "XInput Player 1", Player2 "XInput Player 2"......) it should all be good in the 'hood. For the rare game that may have something different, you can always create a 2nd cfg file (MyControls2.cfg) for it and then override the mame.ini ctrlr line by adding to the custom command line parameter for that game "-ctrlr MyControls2". Or if you want to get real crazy, you can create and custom ini file (copied from mame.ini), and name it the same name as the driver source file, or the BIOS set, or the parent [rom] system, or the system[game][rom] itself. Then set the ctrlr line in it. Loading the ini becomes automatic through MAME. No extra custom command line parameters required. https://docs.mamedev.org/advanced/multiconfig.html (But ya, that's going a bit far. ) Same goes for softlists. (i.e. spectrum.ini) Useful for setting "ui_active" and "autoboot_command".

No. Thank goodness! MAME will only read your custom controls file that you created/saved in the ../ctrlr/ folder, and 'pointed' to in mame.ini. No need to to make the 'new' cfg file readonly. So if you forget to plugin any or all of your controllers, your custom config file won't get wiped out. So when you DO forget... curse!, exit MAME, plug your stuff in, restart MAME, apologize for cursing, and play games.

There's really no rhyme nor reason on how Windows assigns controllers on boot. But MAME does have a fix for that. Read (and try to make sense of) this: https://docs.mamedev.org/advanced/devicemap.html And if/when you get all confused by that, try this. - Plug in all your controllers. - Start MAME and configure all your controllers, light guns, keyboard, mouse etc... - Save Configuration. - Exit MAME. - From the Windows Command Prompt and in your ../MAME/ directory, Enter in mame64 -v >ouput.txt and press Enter. - Exit MAME and close the Command Prompt window. - In the ‘../MAME/cfg’ folder, copy “default.cfg” and paste it into the ‘../MAME/ctrlr/’ folder. From here you can rename it to something like “MyControls.cfg”. - Now open ‘../MAME/output.txt’. (the text file created from the Command Prompt above) - Scroll down until you see the “Input: Adding” lines. There will be several. - Look for signs of your specific controller(s). In my case I only have a single Xbox controller (ignoring “keyboard #0”, “mouse #0”, “mouse #1”…) Input: Adding joystick #0: XInput Player 1 (device id: XInput Player 1) - Open your ‘new’ ‘../MAME/ctrlr/MyControls.cfg’ file. - Near top, right after the “<input>” line, (using info from the output.txt file) add in something like <mapdevice device="XInput Player 1" controller="JOYCODE_1" /> "XInput Player 1" is the part AFTER “device id:”. (Not to be confused with the part after “#0”.) "JOYCODE_1" is for player 1. ("JOYCODE_2" would be for player 2. Etc.) From the example in the above link, their “output.txt” has the line Input: Adding Gun #5: HID-compliant mouse (device id: \?HID#VID_D209&PID_1601&MI_02#9&375eebb1&0&0000#{378de44c-56ef-11d1-bc8c-00a0c91405dd}) Note what part of the info they used to create the “<mapdevice device=>” line(s) <mapdevice device="VID_D209&amp;PID_1601" controller="GUNCODE_1" /> - after "device id:" started at “VID” - added “amp;” after the ampersand (&) - set it to player 1 ("GUNCODE_1") After you’ve added your controllers (and light guns), save MyControls.cfg. - Now open “../MAME/mame.ini” - Scroll down to the section “CORE INPUT OPTIONS”. - On the “ctrlr” line, set the value to "MyControls". (Do not put the ‘cfg’ file extension) # # CORE INPUT OPTIONS # coin_lockout 1 ctrlr MyControls - Save and close - Play games

Glad it's all working! As for your 'upcoming' questions, 1st try a search on the forums (or even Google adding "LaunchBox" in the search ). And if that doesn't get you what you need, start in the forums' Home page and whittle your way down to a topic section that's most closely related to your question. Just DON'T post the same questions in multiple locations! And most importantly, setting up you cab and LB/BB can be exciting and yet sometimes overwhelming. So don't forget to actually play (not just test) your games, and have fun.

if !WinExist("ahk_exe BigBox.exe")

The gauges are awesome!!

Did you by chance do any firmware upgrades and change something-or-another to put you iPAC-Mini into XInput mode? That's the only thing I can think of that would make that command line cause issues. If your MAME revision was older, we could blame that. But you said you have 0.213.

Try removing the Default Command-Line Parameter for the MAME emulator and see if that changes anything. If that doesn't change anything, at that same (now empty) location, put in -ctrlr 4Player

What do your MAME emulator settings look like? Can you provide some screen shots please (Details, Associated Platforms, Running AutoHotkey Script)? I assume (again with my assumptions.. lol) that MAME games will load through LB/BB. It's just that the controls are all wonky. Which, as I think about it doesn't completely make sense. Even if MAME loaded it's default.cfg (instead of your 4Player.cfg) you should still have you left joy tied to Up/Down/Left/Right and your Player 1 buttons 1-6 tied to Ctrl/Alt/Space/Shift/Z/X. Unless you remapped (through WinIPAC.exe) your controls. For the screen shots, I'm mainly looking that you don't have any extracurricular command-Line Parameters. (The Running AutoHotkey Script tab should be blank). Also in your Edit [Arcade] Game in the Launching section, only the ROM File field should have something in it.And in the Emulation section, there should be no Use custom Command-Line Parameters: listed (un-checked).

When you say 'default.cfg', any chance you mean "mame.ini"? I'm going to assume your talking about MAME directly and not using Retroarch's Mame as your emulator. Is your mame.ini file located in MAME's root folder or in ../MAME/ini/ subfolder? If it's in the ini folder, move it to the root folder. If for some reason it's in both, put the good one in the root folder and get rid of [rename, backup, delete] the other one. After it not working through LB/BB, when you go back and start MAME (mame64.exe) again and start a game, are the all the controllers still working like they're supposed to?

If you setup your debugger to copy the compiled dll over to the Plugins folder, then launch D:\LaunchBox\LaunchBox.exe, the debugger will exit as soon as the LB exe file exits. Which will pretty much be right away as that exe redirects to LaunchBox.exe in the Core folder, thus exiting itself. Not an anti-debugger. The program exited. "Simple fix"... set the debugger to launch the exe in the Core folder. Problem now is an innate [default] limitation of Visual Studio of debugging a NET Framework class library through a NET Core application. If you look around, there is a way to 'tell your debugger' that you want to debug your library through a NET Core application, and you can get it to work. At least according to the folks on Stack Overflow.

Did you set your IPac to XInput? If not, it acts just like a keyboard. i.e. Player-1 button-1 is 'tied' to the Ctrl key.

That works , if you have the buttons available (or if you can simply 'add them in'). Obviously you don't want to use the players' buttons for "Escape" [exit-game]. But those (players' buttons) can be mapped for BigBox {Select and Back] as they won't conflict for in-game.