Zombeaver

Sure, no problem! CCS64 is the emulator I use for C64 and controller automation's close function doesn't work with it - I can't actually use the above script in that situation though because you do need to use Esc for navigating the emulator's UI. For it I use the following script, which closes it when I press the End key: $End:: { Process, Close, {{{StartupEXE}}} } What would actually be better is to create an AHK script that uses a combination of controller buttons to send the specific key or combination of keys that the emulator uses to close normally. For CCS64 that's Alt+F4 and for Atari 800 it's F9. I'm not enough of an AHK wizard to do that though haha. Maybe @ckp can help work some magic. No problem!

If the Controller Automation close function doesn't work with Altirra you could go to your emulator entry for it in LB, go to the AutoHotkey tab, and enter the following: $Esc:: { Process, Close, {{{StartupEXE}}} } The Controller Automation close function will work at that point. Keep in mind though that 1) if ESC is a key you need to use to navigate the UI this isn't going to work, because now pressing ESC will exit the emulator and 2) exiting by this method is actually force-closing the application so if it saves settings on exit they won't be saved when you do this. Atari 800, by default, only saves them when you manually tell it to save your settings - I'm not sure how Altirra does it. This isn't necessarily something I'm recommending, but it is a workaround for getting the close function to work in situations where it doesn't normally.

Controller automation (including closing) is working fine for me. Keep in mind that it just doesn't work with certain emulators. MAME, for example, doesn't accept it because it doesn't accept simulated keyboard inputs. With MAME, however, you can actually accomplish the same thing as controller automation's close function by opening the tab menu, going to "Input (general)" -> "User Interface" -> and then going to "UI Cancel" and entering your combination of buttons that you want to use to exit. CCS64 is the emulator that I use for C64 emulation and controller automation's close function doesn't work with it. One option in such a scenario is to go to the relevant emulator entry in LB, going to the AutoHotkey tab, and entering the following: $Esc:: { Process, Close, {{{StartupEXE}}} } Controller automation's close function will work at that point, though keep in mind that by doing this you're force-closing the emulator, so if it saves settings on exit, they won't be saved. As to the crashing/hanging issue... that's a question for @Jason Carr. I'm not sure what would be causing that.

Yes, for the purposes of emulation via the Steam Link (which is actually what I bought mine for) you're more than likely going to need to disable the overlay. Some things get along with it okay, others don't. At the very least it's something you should consider trying for the purposes of troubleshooting. I've had a Steam Link since day one and I've gotten along just fine without the overlay.

Vaporwave is friggin' weird (but I kinda sorta like it). "why does it go from super calm and nice to satanic and trappy?" "idk" "Oh my god this is way too chill I'm melting f***" "Listening to it while high has twice the effect" "This is what happens when you leave music in the microwave for too long."

.confs, in general, will still work but the issue is that the paths would have to be updated since you're now directing it to a zip rather than a folder. LB is kindof unique in that it injects paths into the .conf based on the file paths of what you import for a LB library entry. I think for this to work in LB you'd actually need to leave those paths blank in a LB entry and then manually add the paths and commands (like I list in the above post) into custom .confs. The rest of the .conf settings would be normal.

Thank you for looking into this! I had previously altered the "scrollingnotesmod" in the view xaml to "scrollingnotes" per @keltoigael's instructions though so I'm not sure what to do at this point The video I posted is with it set to "scrollingnotes".

I know you were well intentioned! You just gotta remember that while some of us work on this stuff every day for others its entirely new; and some things might not be so obvious if that's the case. Everybody's gotta start somewhere. @jeck11 is a new member to the community so let's not scare him off just yet

Launchbox is portable but it does have certain dependencies (as will most emulators like Retroarch) like Direct X and .NET Framework; both of these should be included when installing/updating LB however. If you're unable to actually install software and those dependencies aren't met, you may be out of luck unfortunately. The specific .dll that's mentioned in the error is installed by Direct X. @neil9000 assistance is always appreciated, but tone it down a little bit - not everyone is tech savvy; there are plenty of people out there that might not know things that some of us take for granted. @jeck11 has been polite and courteous, so try to be the same.

For me, whenever I did it I always exited afterwards and relaunched and it worked correctly.

Are you actually exiting and relaunching RA when you do that? I found that's what I had to do for that specifically.

I got Duke Nukem 3D to work with some finagling. I started with just a standalone .iso and, of course, I happened to be on an office computer that doesn't have any virtual drive software. You can of course just imgmount the iso in DOSBox like normal, no problem, but I wanted to test it archived so I mounted it, installed, zipped the installed folder into Duke3D.zip and then created a temp folder and mounted it as C: so I could imgmount the .iso and then "copy *.* C:\" to extract the contents of the CD into it (normally I'd just do this with DT but... office PC). I then took the extracted CD contents folder, zipped it as Duke3DCD.zip and mounted everything from scratch in Dosbox: Mount C "C:\Dosbox\Games\Duke3D.zip" Mount D "C:\Dosbox\Games\Duke3DCD.zip" -t cdrom C: cd Duke3D Duke3D Voila Saving and loading worked as well. It's neat as a proof of concept if nothing else.

It seems to mostly work, although some things are still giving me trouble. Daggerfall, in particular, is being problematic. I was finally able to get it booted up with zips for the game install (Dagger.zip) and the cd (DFCD.zip). However, shortly afterwards it crashed... Using the exact same files/commands but with normal folders doesn't crash so something is odd there. Some stuff seems to work fine though. I was playing Quake, saving, loading - continuing from one level to another - it seemed fine. I also can't quite seem to get mounting of subdirectories within zips to work yet. Based on this page I would have thought that it would just be a format of Mount C "Path\To\Zip\game.zip:/subdirectory" but when I do that it completely erases everything in the zip

I'm not a Hatari user, sorry I'll test it out in Steem tonight regardless, just to see if it acts unusual for me.

Yeah I've really really liked this update. It's the first time I haven't felt like I had to do a bunch of external backend crap to get things to work the way I wanted in a large variety of situations. Like I said earlier I've been in the ongoing process of sweeping through pretty much all of my stuff that's for systems that are more on the finicky side (things like NES or SNES I can basically just put in some settings and leave it alone but not as much for some platforms). Per-core/per-game overrides and remaps have covered about 99% of that but tonight I noticed that changes I made to core options stuck even if I saved a per-game override. "Content specific core options" is the way to set them per-game. Obviously this has even more niche use than overrides and remaps but there's a number of things you could do with it. You could with Mednafen PSX, for example, set a specific game to use the vulkan renderer and software for another, enable the widescreen hack for one game and disable it for another, set the internal resolution as X for one game and Y for another... Any number of things, depending on what's in the core options.

That's something different. Overrides and "content specific core options" aren't for the same thing. It's in the post Per-game and per-core overrides have no impact on altered core options.

Nice! One additional thing that I literally just discovered today that's relevant to this discussion is "content specific core options" (which is found in Settings -> Configuration -> "Load content specific core options automatically"). What this really should be called is "Per-Game Core Options" as that would fit with the Per-Core/Per-Game Overrides and Per-Core/Per-Game Remap naming scheme and be a little more obvious as to what it's for. So, ordinarily core options (quick menu -> options) just apply across the board for that core, whether you use any other overrides or not. If you make a change to the core options, whether you're using any core/game overrides it carries over. Overrides apply to things in the normal settings menu - input, audio, video, etc. but not to core options. When you enable "load content specific core options automatically", however, when you go into the core options you'll notice a new button at the top of the list that says "create game options file" followed by the game name. If you select that, it'll create a .opt file which will now be loaded for that game just like overrides (.cfg) and remaps (.rmp) but is used specifically for adjusting core options. So...what's the use scenario for this? Well, here's an example: Codename Tenka for PSX is kindof odd in that it only lets you start the game if you only have one memory card inserted (RA Mednafen uses two by default). There's a core option for Mednafen PSX of "enable memory card 1" (memory card 0 is actually the first card, 1 is the second). I wanted to be able to disable the second card for this game because of this quirk but I didn't want to actually disable it for everything. "Content specific core options" to the rescue! Load up Codename Tenka, go to the core options, disable the second card, "create game options file", problem solved. Obviously there are a lot of potential uses for this. Anything that's in core options that you want enabled/disabled/changed for one game but not for something else, this is the way to go. One final note is that, funnily enough, the "Load content specific core options automatically" enable/disable option itself is saved on a per-core or per-game override basis. So if you've got a core override and you normally have this set to off, you'll have to enable it and then save the core override. You can also technically enable it on just a per-game override basis and from that game save a core option file but I can't think of a good reason to do this; if you don't save a core option file they'll just work like normal anyway - carrying over from one game to another.

Okay so after testing my backup (which has 7.7-beta-15) it would seem that the issue is present in it as well, but what had thrown me off is that it seems to vary by platform. Both seemed to handle my arcade stuff equally well and both handled NES equally poorly. I've got a video rendering currently that shows what I'm talking about. I'm using 7.7-beta-15 in the first part of it and 7.8-beta-3 in the second part but the performance difference between the two versions when going over the same platforms was basically the same. EDIT: And I just tested and it's unchanged in beta 4. Setting a "Wheel Minimum Speed" of 100ms mostly covers it up at least. That makes me think it has something to do with the image transition or something...

Count me as another interested party. I think this is a great idea! I added my vote.

Well by "hacky" I mean using a script to edit the registry to change controls for a PSX game haha; not the implementation of said script within Launchbox. "Alright now the first thing ya gotta do is disable UAC, then disable yer firewall, install TeamViewer, double click on this handy script, just ignore the command prompt it'll go away in a second, and then you too can watch Netflix!" Flexibility and fostering the "to each their own" approach is one of Launchbox's greatest strengths, so I'd never tell someone "You need to use X" since chances are they can do whatever they want to do with whatever they want to use via LB (with more or less complication depending on what you're dealing with); but if someone (on these very forums) hadn't told me at one point "Hey, you can do that and a lot of other neat things with Retroarch! Here are some useful things you can do..." then I would still be using ePSXe too - and I'm saying this as someone who did use ePSXe for many years in the past. I'm just throwin' it out there as a convert with no regrets haha.

I mean I understand that point of view, and don't get me wrong, I appreciate that you're helping another user no matter what form that takes - a solution is a solution, even if it's not ideal. Sometimes you just have to work with what you've got. And when it comes to emulation there's almost always multiple solutions to the same problem. My point is that this is a situation that Retroarch has features that are specifically designed to address. This is a single one-off situation, sure, but what happens when another one arises unforeseen later on down the road? Another hacky solution could be used for that one-off situation, and the next... or you could use something that has the necessary infrastructure in the first place to deal with those situations. Switching emulators is more time consuming, no argument there, but RA provides a great foundation to do a lot of things that aren't quite so easy to accomplish elsewhere. There's also no shortage of RA tech support around these parts since tons of us use it haha. Brad also has about a bajillion video tutorials that use it

"Nothing" has actually changed on my computer though, not that should have this sort of impact. Everything was fine on 7.7 which obviously wasn't too long ago. I'm pretty sure I have a LB backup that was using a 7.7 beta build so I may try that tonight.

I'm not entirely sure if that would work simply because if the batch is set as the emulator it's going to try to direct the rom file to that in attempt to use it as the emulator. You could, however, uncheck "use an emulator", direct the rom path field to the batch, and then add an additional app directed to the emulator with the rom path added in the custom command line parameters field (along with any other needed command line parameters) and tell it to "automatically run after main application". Alternately, and frankly a much less hacky option, would be to simply use Retroarch which has the capability of per-game control remapping. Load a game -> change the controls -> save game remap. Now it'll load automatically whenever you start that game.