Zombeaver

I do, yeah: http://steamcommunity.com/id/Zombeav I never had any luck getting Munt to work with XM6 Pro-68k The Munt monitor actually shows that XM6 is connecting to it when it's started, but it seems like it's not getting any actual input from the emulator. I use Munt for tons of stuff in DOSBox and it's great for MT-32 emulation there.

Huh? How are you planning on bulk-editing (or editing period) FS-UAE game configurations within Launchbox? Any changes that I make to a config are within FS-UAE itself. The only thing you're really doing in Launchbox is directing it to a specific config for a specific game. The only platform where LB actually hooks directly into configuration editing is DOSBox.

If I recall, the media/metadata scraper uses the first option and appends numbers on the end (-01, -02, etc.) for each image you download in a given category (it does this even if you only download one image). I don't believe there's a way to actually specify that you want it to name them in a specific alternate format. There might be a way to bulk-rename them with some kind of separate utility for such things, but I don't think there's a way to do it via LB. The list I provided was designed to show people how your media filenames could be formatted and still have it automatically match in LB.

Haha no worries Glad it's working! I'll have to check out that other version. The one from Bethesda's site does include the 1.07 patch but obviously not the rest of that stuff.

Indeed! They're apparently working on a reboot (or prequel?) to Escape from New York at the moment, although I don't think Snake's role has been filled in yet - originally it was going to be Gerard Butler but he's backed out and the most recent name that I've heard is Jeremy Renner. I don't think anything's final at this point though. They're also remaking Big Trouble In Little China and apparently The Rock is playing Jack Burton... I actually like Dwayne Johnson but I'm not sure about this one. I guess we'll see. Then again, Big Trouble In Little China is cheesy and campy as crap, and Johnson tends to be great at that haha

-freesize has nothing to do with cycles. It's designating a set amount of free space on the drive that you're mounting. It's necessary in some cases in order for the game to "see" that you have enough free space to install the game.

Also the totally awesome Takeshi's Castle a.k.a. MXC. And of course a lot of other legitimately great stuff. I love Takeshi Katano so I'll have to check Outrage out. Have you ever seen his incarnation of Zatoichi? I love all the old Zatoichi films (even though they're kindof all the same movie) and really enjoyed Katano's interpretation. A lot of people of course associate him with Battle Royale, but I've always considered that one a bit overrated - not bad mind you, just not as amazing as some people make it out to be. The last thing I watched was The Thing (1982) - it's my yearly Halloween ritual (and my favorite horror movie of all time). I'm planning to go see Dr. Strange this week. I'm a big fan of Benedict Cumberbatch so I'm looking forward to it.

I got it to work with -freesize 1000. I used the version available directly from Bethesda's website which I assume is the version you're referring to. 1) Extracted it to C:\Dosbox\Games\ 2) Move the "DFCD" folder into the "Dagger" folder (you don't actually have to do this, but I like to keep things cleaner with everything contained in one game folder) 3) Opened DOSBox and entered the following: mount c "C:\Dosbox\Games\" -freesize 1000 mount d "C:\Dosbox\Games\Dagger\DFCD\" -t cdrom -label Daggerfall (this part is a bit unusual, but I can confirm it's necessary - if you don't, it will tell you you've inserted "the wrong CD" when you try to actually start the game) D: Install 4) Select "Install the game to your hard drive" 5) Select "Change the install size" 6) Select "Huge installation (450MB)" 7) Select "Yes, this installation size is fine" 8) Select "Yes, I want to install the game here" 9) Select "Go ahead and install the game" 10) Once the install is complete, select your SFX and MIDI cards of choice and save Optional) Once back in the DOSBox UI in C:\Dagger\ enter dag213 and it'll patch the game to 1.07 Voila!

The -freesize switch is probably the right answer, but 614400 but seems awfully high. That specific number does appear to be what's recommended on the DOSBox wiki page for Daggerfall though... I seem to recall running into this issue when I originally installed Daggerfall as well. I'll test a fresh install and see what I can come up with.

Yep, Citadel crashes unless you use the A1200 as I mentioned in the video; the WHDLoad version anyway, I can't comment on the other versions. It's an instance where the built-in config from the OAGD is actually wrong. It's fairly rare but you will run into it every once in a while. But yes, I can't stress enough that you really have to use the real Kickstart roms. The replacements are better than nothing (some games do work okay with them) but it's not uncommon to run into problems with them.

Ah okay, gotcha. Yep, that's true. In those cases you'd want to just create your own custom config as I mention in the video (like for games that aren't actually in the OAGD). Interesting. I actually use dev 2.7.15 in my setup and .ihas work with it. Oh well, whatever works I guess No bother! Just wanted to make sure I was on the same page. Glad you found the video useful!

Read the description for the video. I put timestamps in it for a reason. It's at 26:53. Watch the entire video please. It took more than a week of work for me to make it, you can take the hour to watch it. No. I have all of the Kickstarts that it wants. You know it has the right one because the box next to each one in the scanner turns to a green checkmark. The built-in configs aren't infallible. They're fairly reliable but some have problems; and among those that were problematic, most of them happened to be WHDLoad configs that used the A600. All of this is covered in the video. I have no clue what you're talking about here. I've not run into any such thing. Sounds like you've either got some screwy Kickstart files or doing something weird with a configuration. .iha is a compressed archive format just like zip; it just so happens to be used for some WHDLoad Amiga games. FS-UAE can read compression one-layer deep - so you can have 1) a .zip that contains a game folder plus a game.info file (this is the format that KillerGorilla uses) or 2) you can have an .iha file. You cannot have an .iha in a .zip (an archive within an archive). If you have zips that contain .iha files, just extract the .iha files and they'll work just fine. If you have zips that contain a game folder and a game.info file those will work just fine as is. KillerGorilla's releases work perfectly with FS-UAE's OAGD integration. If you have packs of all the games within a specific letter, the individual game zips just need to be pulled out and then they'll import just fine into FS-UAE.

I believe @lordmonkus has used BizHawk so maybe he could tell you. I have no experience with it whatsoever. It looks like it does have some generalized command line parameters though. What happens if you just setup BizHawk as an emulator in Launchbox, don't add in any special parameters, and then just direct it towards a rom for a supported platform? Special parameters aren't always necessary (although they typically are for multi-system emulators, in fairness). I'm not sure if BizHawk uses any kind platform auto-detection or if you have to actually specify the platform via command line.

No problem! There's definitely some really neat stuff on the Amiga; a pretty huge library too. I think anybody that enjoys 16-bit era games should check out the Amiga. I don't know what you mean by this to be honest. WHDLoad.prefs is necessary in order to override the QuitKey for all your games; for FS-UAE at least. The QuitKey must be used in order to retain saves for WHDLoad games; again, this is for FS-UAE. I can't speak to how it worked for WinUAE as I never got into WHDLoad with it - I always used individual ADFs. Honestly, I don't think there's a way to do this. I can't say for certain though - I don't really have a good way to test this. This is something you'd probably need to ask Frode (the developer) either on the FS-UAE forums or on his website as I think it's something that would have to be specifically implemented.

No problem man! I'm glad it was useful! The Amiga has had this long-standing stigma for being daunting to get into (understandably, to be honest) and I just thought that was a shame because it's a great platform with a lot of neat and unique games; so that was a big motivator. I've seen plenty of comments in the past by people that were genuinely interested in Amiga emulation but found the whole process so convoluted and difficult that they gave up in frustration. Hopefully this will help some of those people get the answers they need and alleviate most of the hair-pulling

That's something that really only Jason could answer, but it would entail a level of interaction between frontend and emulator that simply doesn't exist currently in LB. Even RocketLauncher only kinda does some of this stuff, and it's a convoluted mess as far as I'm concerned. Some people love it, and more power to them, but I'm not one of them. Retroarch itself already automates control inputs, though you can of course tweak as you see fit. Turning on overlays/shaders isn't something that's automated by Launchbox, but there are ways to setup multiple "profiles" via separate emulator entries in Launchbox so that you can switch between them from one game to the next relatively simply. I've done that pretty extensively in my setup. We can get into that if we need to, but that probably warrants a separate thread if so. Core selection itself can be somewhat subjective. Again this goes back to there not always being a one-size-fits-all solution in some (or even many) cases, so this isn't something I'd even necessarily want to be automated. However, it's not unreasonable to think that some generalizations could/should be provided that would at least make this selection process easier, and that's basically what the auto-populated platform command line-parameters (from a fresh RA emulator entry in LB) are designed to do. How up to date those are at this point, I'm not entirely sure as I've changed so many things since I first added in Retroarch, there's no telling how much of it is original (suggested by LB) and how much of it is custom. I know that's a point that Jason is certainly well aware of though. There are ways to somewhat automate the process of keeping them up to date though, if you so choose - things like Stellar. I still do it the old fashioned way myself though. And again, I think that's perfectly reasonable in theory. I've certainly spent hours of my life yelling at my computer because something just isn't doing what it should. I wish that wasn't the case; and I certainly don't wish that on anyone else either. Being able to just press a button and have everything work would be great. It's just when you consider how many separate brains, how many lines of code, how many disparate pieces of hardware and software, and just as disparate developer personalities are involved across the huge spectrum of emulation, that's often easier said than done.

OpenEmu is an emulator. Retroarch is an emulator. Multi-faceted? Yes. Have their own UIs (not run from command-line)? Yes. Do those UIs aim to serve the same basic function of organizing games (albeit atrociously in the case of RA)? Yes. Does that make them in any way comparable to Launchbox? No. They support what they support and that's it. You can't take ePSXe and drag it onto Retroarch and now you've got an ePSXe core. They're self-contained collections of emulator modules, not a true frontend. Launchbox is not, has never been, and was never designed to be an emulator. Again, in and of itself, it doesn't emulate anything. It's a frontend. It allows you to plug whatever emulators you want into it, even multi-faceted ones like Retroarch; but it doesn't hook into them to the same degree as what's being suggested because it's not working within that kind of limited architecture (because it's not an actual emulator). If you have a garage, and a car in that garage, and a CD in that car's stereo, are you going to complain that the car lets you hit the skip button to change tracks but the garage doesn't? I hope not, because why would you? The garage is there to store the car (or a fleet of cars if it's big enough), which happens to have a stereo. It's not there to control the stereo. That's not to say that you can't sit in the garage, get in the car, and start up the stereo, just that it doesn't make much sense to bemoan the garage's feature set for something it was never designed to do.

The problem with all this is that Launchbox keeps getting compared, incorrectly, to something like Retroarch or OpenEmu - they're just not the same thing at all. Launchbox shares more DNA with Windows Explorer than it does with Retroarch. At the end of the day it's basically a visually-appealing organized collection of shortcuts. It takes X and throws it at Y, and possibly injects Z (launch parameters) into the chain if you so choose, and that's it (just like a Windows shortcut). It doesn't emulate anything. It doesn't even have to be used with emulators at all if you didn't want to - you could throw in a bunch of CBR (comic book archive) files and associate them with CDisplay if you wanted to. Because again, all it's doing is taking one thing and throwing it at another, with a pretty UI on top. If you wanted a greater amount of granular control over the emulators themselves, you could always look into something like RocketLauncher; it does a number of things that are being discussed here, but if simplification is what you're looking for, that's certainly not where I'd start. EDIT: Aaaaaand I was a minute too late in posting haha.

Yes - provide as much useful information as possible in order to ease the process as much as is feasible; which is what's already taking place. Yes, the video tutorials are designed to be used in conjunction with Launchbox, but in general they're still applicable whether you use Launchbox or not - they just include instructions for incorporation into Launchbox which you're free to disregard (with the caveat that in a few cases there are some nifty little tricks that are part of Launchbox that make the process significantly easier). The first 2/3 of the Amiga tutorial I did is completely independent of Launchbox and in no way requires it in order to get the emulator and games running. Yes and no. That can certainly be a big issue, but in some cases there's more to it than that. Bios files, the hardware and software that you're running the emulators on, etc. There definitely are some cases though where one or two knobs just need to be turned but people aren't aware of it. It depends on the emulator but typically yes. In most cases, I don't think so. The primary reason is that in the most consistently problematic (or at least fiddly) emulators there is no one-size-fits-all settings solution. Retroarch, DOSBox, PCSX2, and Dolphin are all examples of this. There just aren't simple set it and forget it settings for these; in some cases from one game to the next, let alone from one computer to the next. The best we can do is make an effort to explain what the settings do in order for people to make more informed decisions. I'm pleased to see that RA has been working to improve that recently. That stuff's been far too opaque for far too long, honestly. Some of these will always require some amount of experimentation and testing though, simply because what works in one case won't necessarily work in another. Having the kind of "packs" you're talking about would really only work in a situation where there are definitive settings in all situations; and in most cases where that'd actually be feasible it probably wouldn't be for the emulators that you'd actually want these packs for. And this is of course ignoring the fact that there are myriad cases in emulation where things are just purely subjective (in terms of visuals, certainly), which doesn't exactly lend itself well to "this is what everyone should use." I like the idea, I just don't think it'd work in the current emulator ecosystem.

Yep. I mean my gosh how much of that have we already seen just with Launchbox itself across multiple hardware and OS environments? Jason's already dedicated a significant amount of time just to optimizing it to accommodate as wide a range as possible, and that's without the additional layer of complication brought on by individual emulator implementation. What it's become is academic. That's what it's been for a while now. I'm not sure what prompted all this BS but I'm quite sure it wasn't necessary. I'm sorry you found it condescending for me to state the reality of the situation with verbiage that's more elaborate than you'd like. That's just the way I talk - both on and offline. I'm extremely detail-oriented, period. I've found that to be an asset in a variety of settings but certainly not the least of which is emulation, given the amount of minutia it often presents. That's not going to change nor will I be apologizing for it. At no point have I ever told someone here "No, I'm not going to help you." or "Why can't you figure this out?" or "Git gud." In fact, I've always made it a point to do whatever I can and take as much time as is necessary to get the issue resolved so long as it's within my ability. Why? Because the emulation scene is chock full of actual condescending elitist jerks that would sooner tell you to pound sand than take the time to be even remotely helpful; and I hate that shit. If you or anyone else chooses not to take advantage of the resources available to you (video tutorials, written tutorials, and these forums), that's on you - not me or anyone else. Nobody's going to be able to help you address questions that you don't ask. Huh? I don't even disagree with @robwired in sentiment. I don't think anyone here does. I have no problem with streamlining (so long as meaningful functionality isn't compromised) or with improving efficiency. Those are good things! At the same time, I'm not going to blindly endorse something that sounds nice in theory but simply isn't realistic or when the ramifications of what's being proposed aren't being taken into account.

I've had a few unexpected health issues lately that have, unfortunately, taken up a good deal of my time and energy of late so I haven't been able to be as active around here recently as I'd like. Thankfully they've mostly sorted themselves out at this point so things should be getting back to normal. In any case, I just wanted to jump in here and say that while, on a basic level, the idea of simplification over convolution is both sound and understandable, the problem is that, as has been established multiple times just within the confines of this one thread, the real world doesn't always leave room for such things once you really dive into the finer details. Echoing @lordmonkus's sentiments, the utopian-altruistic-emulator-developer world that would be a prerequisite for what you're asking for simply does not exist. Feel free to read over this thread if you need any evidence of that - pay attention to the posts by RealLibretro. Real swell guy that one. byuu? The Higan dev? Complete narcissistic asshole that treats his own fans like utter garbage. The scene is full of nutcases, frankly; and I'd just as soon that @Jason Carr, being the nice guy that he is, not go near some of these devs with a 30-foot pole, let alone have the kind of entangled development relationship that you're talking about. And by equal measure, I'd just as soon those people not come anywhere near Launchbox's development. I'm content to let some of these guys duke it out in a war of their own making and let the chips fall where they may - we'll still be over here doing just fine with our popcorn and our sweet, meticulously organized library, that it just so happens we can hook whichever emulator we choose into. And the alternative to that is...what? In-house emulator development? That's just not gonna happen. You understand that some of these devs, despite being borderline sociopaths, have dedicated literally years (more than a decade in some cases) to the development of emulators for single platforms right? And in some cases that's including multiple developers working on the project. That's not even remotely feasible or practical for what we're talking about. Again, it's not that there's anything wrong with wanting things simpler, it's just that the reality of this hobby is far from simple, for social, technical, and even legal reasons. Is the current system perfect? Of course not, but it's by far the best experience I've ever had with any sort of front-end environment, both because of the relative ease of the software itself and because of our community which is one of the nicest and most helpful you'll find on such things. And as lordmonkus said, practically everything imaginable is already covered in existing tutorials, people just have to make the small amount of effort to watch and follow them; and if there isn't an existing tutorial, one of us can probably help get it sorted out anyway; and hey - that means we'll have something new that can be covered in a tutorial video There are very real and tangible improvements that can still be made to Launchbox that would require only a tiny fraction of the kind of developmental effort you're talking about, and for most of us, those smaller improvements are going to be more beneficial than the kind of monumental overhaul that you're talking about. I also think the idea that the userbase would "expand significantly" as result of that kind of overhaul is pretty overstated. Emulation is, has always been, and by all accounts will remain to be niche. There's a particular group of people that are passionate about it, and a much larger group that simply doesn't care and will never care regardless of how painless you make it - these people aren't going to suddenly be super interested in X68000 emulation simply because you've streamlined the process a bit. So strap on your nerd-goggles like the rest of us and jump in - you'll make it, I promise. There are plenty of skilled lifeguards around these parts.

I'm happy to report that the review was completed after about 15 minutes, I got my key, and it worked just fine in Steam!

Just a bit of a PSA that Dark Souls 3 is on sale (with 3 days remaining) on Gamesplanet for $29.12~ and the Digital Deluxe edition (DS3 + Season Pass) is $48.55~. The price is in pounds which is why the amounts are a bit odd. The normal full price on these are $60 and $85 respectively at the moment, so that's pretty darn good. https://uk.gamesplanet.com/game/dark-souls-iii-steam-key--2978-1 https://uk.gamesplanet.com/game/dark-souls-iii-deluxe-edition-steam-key--2978-2 Full disclosure, I've not used this site before, but I found multiple game deal subreddit threads saying that the site is legit. I went ahead and purchased the Digital Deluxe version so I'll report back when everything's complete. It would seem they have some kind of payment review process (which I guess is probably reasonable considering I'm purchasing internationally) so my purchase is currently "in review". You also have to link your account to your public steam profile or one of several social media sites; that's not exactly unusual either. Anyway, if anyone is interested but is hesitant about the site itself, I'll be the guinea pig

Some further testing is below. All of these have working cracked versions already that work just fine in CCS64 and other emulators, but it's interesting to see that some of the Preservation Project (.nib) files actually work in CCS64 once converted to .g64 format. I started by using MNIB + DOSBox to convert them, but 1) that's kinda time consuming and 2) didn't yield working results as often as using Nibtools. Nibtools seems to just be easier and more reliable all around. You can find it here. All you have to do is drag a .nib file onto the "nibconv.exe" file and it will convert them into .g64 which you can load in CCS64 or other C64 emulators. Working in CCS64: Aztec Challenge Ballblazer Boulder Dash Bruce Lee Captain Blood Dig Dug Hawkeye The Last Ninja Legacy of the Ancients Master of the Lamps H.E.R.O. Hacker Impossible Mission Koronis Rift Little Computer People Montezuma's Revenge The Movie Monster Game Rad Warrior Raid on Bungeling Bay Raid Over Moscow Rampage Rescue on Fractalus Skate or Die! Summer Games Not working in CCS64: Artillery Duel - crashes Beach-Head - some garbled graphics Beach-Head II - has a hilariously preachy message about software piracy and then hangs Bop 'n Rumble - hangs Choplifter - garbled graphics; works in Hoxs64 Times of Lore - hangs after character selection screen; works in Hoxs64 First Samurai - seems to actually work but requests password to start IK+ - crashes Mr. Robot And His Robot Factory - plays but is missing some sounds Project Firestart - hangs Psi 5 Trading Company - hangs Shadowfire - hangs Spy Hunter - doesn't load The Train - hangs Zorro - hangs

So this is kinda exciting. I just discovered how to convert .nib files to .g64 and .d64 (and .g64 to .d64). Success rate when running them in an emulator seems a bit mixed so far though, which I guess is to be expected. More testing to be done. EDIT: It figures that the first game I tried this on (Times of Lore) uses V-MAX! protection The .g64 conversion works in Hoxs64 but in CCS64 you can't get passed the character selection screen. EDIT 2: The Last Ninja conversion (to .g64) seems to be working great in CCS64. EDIT 3: Ballblazer conversion is working great in CCS64. It would seem that a normal boot (i.e. not fast-boot) is required for these to work, but the Maximum 1541 Speed option in CCS64 doesn't seem to interfere with it and works great with .g64. Normal vs Fast boot is basically a non-issue with Maximum 1541 Speed enabled anyway.