Zombeaver

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

Hmm... I assume you've tried using AutoConfig profiles? It's basically saved controls for specific input devices. I use them for switching between my 360 controller/arcade stick (which uses xinput) and a USB SNES pad (which reverses the up and down inputs unless I turn off the setting that makes the left analog stick send d-inputs). After setting up AutoConfig profiles for each of them I can disconnect one and use the other and it knows which settings to use for which. I don't know if the ds4 software's emulation would interfere with this though.

Yeah I actually really like the way it works now, once I got used to it. It makes it really easy to fine tune stuff on a game by game basis which I really like; and once you get used to doing it it just takes a few seconds to do. Eh? You kinda lost me there. I don't use PS4 controllers at all though so I'm not sure if I could help anyway.

Yeah I figured. That just seems like a rather extreme solution to what should be a matter of just rescanning or even a simple click-on-name-and-press-delete affair. Based on that old EAB post by Frode it sounds like it's not actually working as intended currently. A non-ideal solution is a solution nevertheless though, so at least there's some way to do it currently. Thanks for figuring that out.

I assume that just removes them all then? At which point you can rescan?

I found this thread on the EAB. Original poster: Frode's response: That doesn't actually seem to work though. I just tested it as well. I tried updating both the file database and the game database.