Zombeaver

It's just regular Daum, but with a conf that I made for that specific game - Star Trek: The Next Generation - A Final Unity.

Stratosphere: Conquest of the Skies has now been added to Zomb's Lair.

Whatever works! Glad you got it sorted.

One last thing you can try if that doesn't work (and I don't know that this will help, but it's worth a shot) is to swap out DOSBox for DOSBox Daum. I've made a little update package that you can use for this, but you'll need to delete some files as well. Go into the installed folder and delete the following: Documentation [folder] Video Codec [folder] DOSBox.exe DOSBox 0.74 Manual.txt DOSBox 0.74 Options.bat Reset KeyMapper.bat Reset Options.bat Screenshots & Recordings.bat SDL.dll SDL_net.dll Then import these files into the folder and try again: DOSBox Daum STTNG.zip

There aren't any mouse configuration options in the game's setup program. I've tested on 3 computers and the mouse is working correctly on all three. Restart your computer, and if it's still not working maybe lookup your mouse model and see if anyone's reported issues with it in conjunction with DOSBox or this game specifically; beyond that there's not much else I can tell you. I can't fix something I can't replicate.

Uninstalling and reinstalling's not likely to do anything. It's just moving files. If it doesn't work now it's not going to work when it moves the same files. Whatever the issue is, it's something on your end, but I don't know what it would be. There's nothing different about the mouse settings in the .conf than any other game I've done. There's very little configuration to speak of when it comes to the mouse and DOSBox. The only mouse-relevant settings in the .conf are: autolock=true sensitivity=100 Autolock makes the mouse lock to the DOSBox screen if you click on it. Sensitivity is... well sensitivity. Both of these are default settings. Now, you might be able to make some adjustments to the mouse in the game's own setup program, I don't recall. I can take a look later today.

If the game natively supports a gamepad, you can use something like a 360/XB1 controller (and presumably other Xinput controllers) by editing the .conf and changing joysticktype=auto to joysticktype=fcs and timed=true to timed=false. This works for things like Commander Keen, Bio Menace, Alien Rampage, etc. If controllers aren't supported by the game natively, you can use DOSBox's keymapper to achieve the same thing. You just press CTRL+F1 while DOSBox is running, choose the key that you want to send, then press add and then press the button you want to send that input; so, for example, selecting the up arrow, pressing add, and then pressing up on the left stick. Press save once you're done making your changes. A lot of games weren't designed for controllers so you'll just have to kindof create your own control scheme. Some games, like a lot of RPGs, aren't going to be very conducive to a controller layout regardless.

I'm not sure what to tell you there. It's working normally here. There's nothing unusual about how the mouse is handled for it - it's just default DOSBox settings for that. You can try pressing Ctrl+F10 - that's the capture/release mouse hotkey in DOSBox.

Thanks! I've got several other shelves of stuff, but those are the ones I'm most proud of. I've pretty much run out of room at this point though Always need more shelves. Big box PC stuff, especially, takes up a lot of space. Yep, that's what I do. I actually rip my own stuff as much as possible too. It's weirdly super satisfying to throw a 20 year old disc in my PC and then install it through DOSBox haha. I used to visit /r/gamecollecting quite a bit but whenever the topic of emulation came up and I voiced my opinion on the matter (that they're not mutually exclusive and that emulation is a good thing for collectors, not a detriment) it was universally met with some really illogical, vitriolic nonsense. People need to understand that all this stuff is going to stop working at some point. All of it. It might not be tomorrow, or a year from now, or even in our lifetime (although it absolutely can be if you don't take care of it), but eventually all this physical media is going to stop functioning; and when it does, then what? Suddenly we just no longer have access to that history of games because somebody arbitrarily decides that emulation is "bad"? People need to think more than 5 minutes in front of their face. Collectors, of all people, should be the biggest advocates of emulation, not detractors. Emulation is the only way to ensure that this stuff is preserved for future generations. 75% of all silent films produced in the US are lost forever. Why? Because nobody thought it was important to preserve them for the future. I'm a huge fan of Lon Chaney, but I'll never get to see London After Midnight because of that. The Mona Lisa was completed in 1506. The photographic process as we now know it was in its infancy in the early 1820s with the earliest surviving photograph dated 1826 or 1827. Let's say that in 1825 there was a tragic fire and the Mona Lisa was reduced to ash. Barring forgeries, without the photographic process, that piece of artwork would be lost forever. Would the world be better off if that were the case? I think few would argue that it would be. So why in the shit do people act as though emulation is high treason? People need to grow up. They seem to think that it's somehow harmful to the value of collections. Not only is that completely ignoring the preservation aspect, it's frankly just not true. Plenty of games that were obscure at the time are worth considerably more now purely because they were popularized through emulation. Speaking personally, I've bought quite a few games physically as the direct result of playing them emulated first. The notion that emulation devalues physical copies is just nonsense. The average guy that downloads Suikoden II rather than paying $120 for it on Ebay isn't likely to do the latter regardless of the existence of emulation; or, if they're me, they play through it emulated, discover that it's amazing, then drive to another state, nearly get run over by a giant dump truck in the process, and buy it used at a Gamestop for $60 (the fact that I probably lost most of the savings in gas is irrelevant) as the direct result of emulation. Sorry haha /rant

I do both; and I curate both. I collect the stuff that's good and of interest to me - not just "everything ever." PSX, PS2, DC, and big box PC are the main things I collect physically but I've got a little bit of everything. It seems like there's this weird notion that emulation and physical collecting are somehow mutually exclusive but they're really not. It's a hobby, like anything else. Both are fun for me.

Star Trek: The Next Generation - A Final Unity has now been added to Zomb's Lair.

Well controller navigation I kindof expected not to work, but automation not working surprised me - I figured that was more backend.

It has to be something in the .cfgs, I'm just not sure what it would be. I don't see anything wrong with your setup as far as LB is concerned. These are my configs for them, though I don't know if there's anything in them that would cause them to not work for you. You'll need to make sure you have updated shaders at least as those contain the border+shader combos. Gambatte_GB.cfg Gambatte_GBC.cfg EDIT: Resolved.

So this is a weird one - Controller input (for navigation) and Controller Automation aren't working correctly for me in Next, but works fine in normal LB. I'm not sure if controller navigation is supposed to work at this point but I assumed that Controller Automation still would. The hotkey input screen doesn't recognize any inputs though.

Looks normal there. Okay, let's take a look at screenshots of 1) the core .dll in Retroarch\cores and 2) the Launcher and Emulation tabs of a relevant game in your LB library and 3) the Emulator Details tab of your Retroarch emulator entry.

It definitely still works. Show screenshots of 1) your full associated platform list and 2) the actual name of the relevant platforms in your library.

I added a section about splitting out VirtualMidiSynth into separate virtual devices which, while by no means required, is pretty handy for specific scenarios.

It might be, it's just the one I've always used since it's the one they recommend in the "Remap Joystick" section of the site. It works fine for most things, and identifies the joystick number, etc. but I wouldn't be surprised if it wasn't pretty out of date at this point.

It shouldn't. It's never made any difference for me between wired and wireless but that's with the caveat that I use the USB dongles for both 360 and One controllers; and I can confirm that AHK does have some issues with recognizing inputs when using a One controller over bluetooth specifically. Last time I tried that, the test script didn't recognize any inputs when it was over bluetooth but worked fine with the wireless dongle. Hmm, very weird... Yeah, definitely. One more button is one more button.

Hmm. I'll give that a try. The test script has never shown anything for me when I press the home button on either a 360 or One controller.

Or, better yet, try out the free version and see if you like it. There's quite a bit you can do with LB without paying anything. If, after that, the premium features are something you'd like access to after you've settled in, get a premium license. There are quite a few really good premium features that are worth getting, but there's no reason to jump right into them without trying the free package out first. If you like it and decide to buy a premium license, you'll get a discount code which you can use over at Emumovies too. I recommend Lifetime for both as you'll most definitely get your money's worth, but you should decide whether or not it's a front end that you want to use first.

Introduction Let's start off with the obvious question: why should you care? Well, do you like DOS games? Would you like to have really high quality music in your DOS games? If the answer is yes to these, then you should definitely care. As an example of the difference this can make for General Midi games, check out these two clips. The first is using Adlib/Sound Blaster audio, and the second is using the FluidR3 soundfont (which we can use with VirtualMidiSynth). Now let's take a look at the difference we can achieve for MT-32 supported games via Munt. The beginning to 2:02 in the below clip is using Adlib audio. 2:03 to the end is using MT-32 audio. We'll be doing this with a couple tools that we can hook into in DOSBox that will function as virtual midi devices - VirtualMidiSynth for General Midi audio and Munt for Roland MT-32 audio. Think of these as virtual sound cards but specifically for music. Back in the day, a number of dedicated midi audio devices were available but were prohibitively expensive for most gamers - they were designed primarily with music production in mind, not gaming, but thanks to groups like Sierra which made extensive use of the MT-32 in their games it gained legendary status and set the bar for video game music quality. Prior to General Midi, the MT-32 and similar devices used banks of instruments arranged in their own arbitrary fashion which meant that midi music had to be composed for specific devices - you couldn't just take music composed for one specific device and swap that device for another as the instruments would be wrong, because they'd be arranged differently. General Midi was a standardization of midi devices which made the arrangement of instruments uniform, so a single track could be used for multiple midi devices. Because of this, the MT-32 eventually faded away, but you'll want to have access to both because in the period prior to General Midi, MT-32 was generally the best choice available. Okay, let's get started. Installing VirtualMidiSynth The first thing we need to do is install VirtualMidiSynth. You can find it here. You'll also need a soundfont to go with it. Several good ones are listed there. FluidR3 is my recommendation as I think it's probably the best all-rounder. Timbres of Heaven and Omega GMGS2 are both very good too. Omega GMGS2 isn't listed on that page but you can find it here. An important note here is that a number of the soundfonts are in a compressed format called .sfArk. These are not usable in VirtualMidiSynth and need to be decompressed. There's a dedicated program for doing this, but an easier solution is using cloudconvert. You select the sfArk file to upload, select sf2 as the output format (this should already be set), click the "start conversion" button at the bottom to convert it, then download it. You can find a comparison of quite a few different soundfonts here. That one doesn't include Omega GMGS2 but you can find the same song using Omega GMGS2 here. Once you've installed VirtualMidiSynth, open up the Configurator and click the + button on the right side of the window, and find the soundfont(s) that you want to use. Click the button to the left of the soundfont name to enable/disable it. Green means it's enabled and gray means it's disabled. Once you're done, click Apply and then Ok. I would also recommend enabling the "Start automatically at logon" box in the Options tab if you haven't already. Installing Munt Now we need to install Munt. You can find it here. You'll also need the MT-32 roms to go with this. I can't supply these to you but Google is your friend. The two that I use, specifically, are named "MT32_CONTROL.1988-09-30.vX.XX-patched.ROM" and "MT32_PCM.ROM". Once you've installed Munt, open it and go to Options -> Rom Configuration, click the "..." button to browse to the rom location and then click the checkbox next to those two files. Enabling them in DOSBox Okay, so that's it for setting up the programs themselves. Now we just need to mess with DOSBox a bit. Open up DOSBox - you can do this by right-clicking on a DOS game in your library that has DOSBox enabled and selecting the option to start DOSBox, or by going into Launchbox\DOSBox\ and starting DOSBox.exe. In the window, type the following: mixer /listmidi What you'll then see is a list of numbers. These correspond to the various midi devices available to it. Now that we've installed VirtualMidiSynth and Munt, we should see 3 numbers (Microsoft GS Wavetable Synth is installed by default with Windows): Make note of which numbers correspond to which devices. You should really be making configurations (.conf files) for every game, but that's a discussion for another time. Whether you do or don't, you're going to need to edit the .conf that you're currently using to tell it to use the device that you want to use. In the above case, if I want to use VirtualMidiSynth I'll need to indicate that I want to use device 0. If I want to use Munt, I'll need to indicate that I want to use device 2. I use VirtualMidiSynth as the default as it has wider coverage, but for those earlier games where I want to use MT-32 specifically I'll need to create a separate .conf for them and choose the different device. You do this by finding the line "midiconfig=" in your dosbox.conf and placing the number of the device you want to use after the equals sign. Keep in mind that all this is doing is setting up DOSBox to be able to use VirtualMidiSynth or Munt, it's not enabling GM or MT-32 audio within each game. You'll still need to setup the games themselves to use GM or MT-32 audio, just like you would if you wanted to specify Soundblaster or any other audio device. Most DOS games come with a separate setup.exe/install.exe/sound.exe/setsound.exe that'll let you choose the audio device (Soundblaster, Ultrasound, MT-32, etc.) so you'll need to use them and set the audio device to GM or MT-32. Launchbox normally does a pretty good job of picking out which .exe to use for this, but you can double-check by editing the library entry, and in the Launcher tab the top .exe should be for the game itself, and the bottom one should be for the setup .exe. You can start it by clicking on the "Configure" option in the right-click menu for a game. Note that there will be some cases where "General Midi" isn't listed but "MPU-401" is - VirtualMidiSynth usually works well with MPU-401 (but it's terrible for MT-32). If both GM (or MPU-401) and MT-32 are available, you'll have to experiment to see which you prefer - remember that you'll need to change the midiconfig= number to do this. Not all games support MT-32, and not all games that support MT-32 necessarily sound best with it (some were designed specifically with MT-32 sound in mind, and others weren't). The vast majority of instances where it's available though it's going to be a huge improvement. If both MT-32 and GM are available, it can be a toss-up. For MT-32, I'd recommend starting with some early Sierra games (Police Quest 2, Space Quest 3, etc.) as those are about as clear an example of good MT-32 usage as any - if you've got everything setup right, you'll definitely know one way or the other. There's a list of games that support MT-32 here. It's pretty long though I'm fairly certain it's not entirely complete. For GM you're going to be looking at games from the early to mid 90s as this is when it became the standard. As time went on, music shifted to CD-audio where these became mostly irrelevant, but there's a solid period of time from the late 80s to mid 90s where you're gonna see a huge difference with these. Anyway, I think that's pretty much everything. Have fun blasting your awesome new music! Bonus (Multiple VirtualMidiSynth Devices) This is by no means necessary, but thought I should mention it here as well. You can actually split out VirtualMidiSynth into up to four different devices each setup to use a different soundfont. This is actually quite handy since it means you can make a separate device specifically for, say, Roland SC-55 (the followup to the MT-32) for example for use with the Roland Sound Canvas option that some games offer. You do this by going to the "Options" tab in VirtualMidiSynth and then clicking the drop-down for "Number of devices". Then restart VirtualMidiSynth and you'll notice new boxes to the left of each soundfont based on the number that you chose. Click the button with 1 for the font that you want to use for device 1, 2 for 2, etc. Now, when you use mixer /listmidi again you'll notice that you now have a corresponding number of new devices. All the same rules for selecting the midiconfig= number in the .conf still apply here. Note that if you plan on splitting them out like this, do it sooner rather than later since, as you can see, this shifts the device numbers around (what was "1" is now "2", and what was "2" is now "3") which could obviously create a problem for existing .confs that you've created where the number has now changed. Again, you don't have to do this. If you want to just flip between them with one device within VirtualMidiSynth, that's okay too, but I think it's a good idea to have a separate one dedicated to Sound Canvas at least.

No, you'd make them separate lines, like $4:: { Process, Close, {{{StartupEXE}}} } $3:: { Process, Close, {{{StartupEXE}}} } Scroll up to my CCS64 script above if you want a more complex example.