eXo

The short answer is, I give both options because certain people have certain preferences. If I forced dosbox, there would be people asking for ScummVM support. If I forced ScummVM, there would be people complaining that some games aren't "original" in ScummVM. Giving the option puts the choice in each person's hands. That said, ScummVM does fix a few bugs here and there that were never officially fixed by the original developers. It also offers different scaling options than DOSbox. From an audio perspective, it supports MT32, which while possible in DOSbox, is much harder to get working. ScummVM also offers enhanced soundtrack support for some games. So unfortunately, yes, it is on a per game basis and it has to do with how much advantage each person wants to take of the extra features that ScummVM offers. I would say that in just about every way, playing a game via ScummVM is going to be a more stable experience as it is vigorously bug tested. I generally stick to ScummVM myself on games where I have that option. But I can see why folks might prefer DOSbox in some cases. It really is a matter of preference, but if you want my advice, go with ScummVM. If it happens to be a game you grew up on and means a lot to you, try it both ways and see which one feels more authentic to you.

Eh... I think it is easy enough for someone to take my scummvm collection and add the games they so choose to their launchbox setup. Unlike dos games, they don't require any setup and launchbox already has scummvm support. It seems redundant to me to release games I've already released simply because they aren't DOS games, so that probably won't happen.

Usually it means it was released for Windows/Mac. However some games in the collection predate DOS and were only released for the Apple II.

If it's a DOS game, it's in my collection. DOS games that are supported by ScummVM will prompt you on launch as to whether or not you want to play the game in DOSbox or ScummVM. There are some ScummVM games that are not in eXoDOS, simply because they aren't DOS games. I happen to maintain a separate collection called The Complete ScummVM Collection, however I don't have any plans in place currently to shove it into launchbox. I may do something at some point though.

i went and changed every launch file for all 5 packs. I've also created zip files that contain all the fixes for Adventure and RPG packs. Adventure patch includes: Fixed launch files that no longer show console window fixed 7th guest conf file that now loads the right cd images fixed Jame's Clavell's Shogun, which had the game file missing note: the Shogun and 7th Guest issues are also both fixed by adding RPG 3.1 RPG patch includes: Fixed launch files that no longer show console window fixed Shadow Sorcerer conf file which was calling the wrong executable fixed Might & Magic 6 cycles I now need to write a batch file that applies the patch properly. I'll probably get to it tomorrow and then post the patch online and give a link here.

I am doing the same thing, just with a different tool. I will be creating zip files that contain all of the launch files for Vol 1 and another for all of Vol 2 that have the proper directory structure, so if they are extracted from the proper folder - they will overwrite the old launch files. Apart from adding them to the strategy pack, I will also post them on a file share site for anyone who wants to grab them separately once they are complete.

yea, I had just edited that out

You have to type the line & place a file in your exodos\util\ folder The file is called "setconsole.exe" and can be found her: http://prozandcoms.stefanoz.com/setconsole-exe-console-window-control/ after you place it in your util folder, you then have to go to the launch file and add this line right under the @echo off line: ..\..\..\util\setconsole.exe /minimize

As mentioned in my first post, I have a solution. It is a file called "setconsole". Implementing it is not difficult, even though it requires an edit of every launch file. The difficulty is finding the best way to write and distribute a patch that fixes the 2 volumes I've already released.

A: It needs to delete those files after dosbox is launch B:It won't process any commands after it launches DOSbox until dosbox terminates. So even if I didn't care about the files it creates, it won't process the exit command until you exit the game. Thats why that window is floating there - it's waiting on you to finish. edit: Before any batch savvy folks try to bring this up, I am aware that the "start" command in a batch file will call dosbox and allow the batch file to keep processing. There are two problems with this. First are those irritating files I want my batch file to delete, and the only way to do that is to hang out until dosbox terminates. But more importantly, the "start" command can't seem to handle all the arguments that I have to pass on to dosbox. It expect to start a program, not start a program and pass an entire file path to a conf file along with 3 command line arguments.

If you manually close the window the only negative impact is you may find the files "stdout.txt" and "stderr.txt" in your exodos folder. These files are created by the SVN versions of DOSbox and the console window (which is a visual representation of the batch file) goes and deletes these after the game exits. They don't hurt anything being there, but I just like keeping things clean, so my files delete anything they create along the way. You can also minimize the window if you want it out of sight.

correct. The program itself (d-fend.exe or whatever) is calling dosbox and providing the parameters to define the conf file and such. In my case, the batch file is calling dosbox, which means you get a windows console. If you install the game and select fullscreen, you'll never see this console window. It's only in window mode it is visible.

that version is being launched directly and not via a batch file. Anytime you use a batch file, a windows console opens up. I have no way to change my collection to not use batch files. Programs like defend are just that, programs. My entire project is simply batch files designed to run games with conf files I have designed to make the game run well from a front end that has assets and metadata for each game that I've curated. What my project is not is an executable file, as I'm not a coder by trade. My project would have to be an executable to do something like what d-fend does, but that would also mean it would no longer work on linux machines or older systems as it would be dependent on code instead of batch files, and the batch files are fairly universal.

That is assuming he wants to play in fullscreen. I know that I usually stick to window mode as I am multitasking on other projects while testing or playing games. Full screen mode is great if thats the only thing you are doing, but it is a real pain to alt-tab to other programs and the monitor has to change resolution, etc...

That is actually not the console window. If you remove the "-noconsole" line from the launch batch and run it again you will see a third window pop open. The window you are referring too is windows running the batch file. I have looked into ways to hide it, but so far, none of the native options have worked. Ironically, a few days ago I did discover a program (setconsole.exe) that can be called from within a batch file to force it to minimize. For this to work though, I have to have every launch file edited to include this line and then have the file placed in the util directory of exodos. This in itself is not a difficult task using the proper find and replace tools, however, short of re-releasing the Adventure and RPG packs, I'm not sure how I could go about adding this fix to those packs as well..... I could potentially write a patch that overwrites all the old launch files. I just have to come up with a few logic checks to first see if the user has downloaded the adventure or rpg packs, and then have it run the patch based on that condition..... I'll look into it and see what I can do. If I get it working, I'll make it so the Strategy pack is already fixed and has the capability of going back to fix the adventure and rpg packs. If I ever do eXoDOS updates again after this, I'm just going to release one massive torrent of all 5 packs. This genre splitting thing is tiresome and makes everything more difficult.

Are you asking if that would work? Sure, I don't see why not.

1. Fallout is in the RPG pack. It was a DOS game, look again. Fallout 2 was not a DOS game, but it wasn't a Win3X game either. It was a Win9x game. SO that one is not in my packs. 2. You'd have to take the MS-DOS.xml from my set and the one from your current install and merge them together. But that would still lead to duplicates, as every game you have is in my sets as well (unless you have some obscure foreign language games that I opted to leave out). To eliminate duplicates, you would have to delete the game entry from my set and then add the entry from your set. I suppose I would tackle that by making/printing a list of games you have and then deleting all of those entries out of my MS-DOS.xml file, and then merging them. To merge them isn't difficult. Just watch out not to mess up the xml headr and footer.

If I revisit these packs, I will likely look into doing it and completely killing the meagre support. As for now, since I have opted to keep meagre support in this set of releases, it doesn't strike me as a necessity. I have mentioned before that currently, I consider the 3.0/3.1 releases of exodos to be "final". The games I am missing are small shareware packages and freeware releases. I haven't seen an actual commercial title that was missing pop up in several years. While I like many of the shareware games, I also feel like they dilute the quality of the pack to a certain degree. If there was one thing I wish I had done before releasing these final packs, it would have been to mark commercially released games and homebrew/shareware/freeware games. I think it would have been nice to be able to "hide" certain types of games. A set with just commercially released games would like quite nice, with every box front filled in and such. Anyways, after win3x and the rest of exodos I will be stepping away from all of this for a bit. So maybe in a few years I'll decide to revisit exodos and add a few new features like this.

Dan, What I posted above is the solution to your issue with some of the hint books and such missing. If you don't want the entire !dos subfolder expanded, but you still want the files that it links to in those folders, you are going to have to put some effort in to discovering which files it calls from the !dos folder and deleting the rest. Here is why. I use a primitive tool to try and convert the ini files for each game that meagre uses into the ms-dos.xml file that launchbox uses. It grabs *most* of the data fields and brings them over. It then tries to grab all the manuals and copy them to launchbox's manuals folder, however it makes mistakes along the way - such as not paying attention to the file type and assuming every manual is a pdf. It is also supposed to grab the title shots and gameplay shots I have in meagre, and it handles png's ok, but it totally screws up and drops any jpg or gif files. There are some other issues as well. Essentially, the tool creates a framework for me. I then have to go into launchbox, and scroll through each game, fixing missing data, adding missing genre's, adding missing artwork or screenshots, renaming screwed up manuals, and manually linking any "extras", as the import process can't handle these at all. In meagre, extras are things like copy protection sheets, code wheels, hint books, etc... I treat them like external applications in LB. When I was working on the adventure pack and first realized that none of the extras had copied over and that many of the manuals were screwed up, I began linking them to their versions that existed in the meagre subfolder. It wasn't until I was nearly done with the adventure pack that I realized the reason manuals weren't working was due to the naming process. Not only where the extensions getting modified by the import process, but it couldn't handle spaces or apostrophes without crapping the bed. So for the RPG pack, I simply fixed the manual's file names, and didn't have to link to manuals in the !dos folder. Extras on the other hand, don't get copied into LB's folder structure. They always reside in the !dos subfolder. So - if you want the extras/external applications, then you have to keep that folder. Your only other option would be to manually create an "extras" folder in launchbox, copy all extras over to it (while also renaming each one to reflect the game and type of extra it is), and then manually go through and modify the external application link for each one of these. By using a search feature in the ms-dos.xml file you could easily identify all of the manuals and extras it links to. But the renaming and relinking process is probably a good 15-20 hours worth of work. It is something I will consider doing if I ever do an update to these packs, but that is a LOT of time to put into something that most people will get no benefit from. It just cleans things up a bit and saves a gigabyte or two of disk space. I don't know about you, but I'm not in the habit of spending 20 hours to save a a few gigabytes. So, you it appears your options are to either have no extras, keep the !dos folder and have all the extras, or manually move the extras/manuals and relink them and delete the !dos folder. I didn't initially plan on spending this much time responding to this, but I think some people take it for granted how much time it takes to do things like this, and so I'd rather spell out the challenge than just seem as though I am flippantly disregarding the question. eXo

If you want to fix the hint book issue, go to the games folder, right click the gamesadv.zip file, and choose extract here. If you don't see that option, then you may have a different extracter, but the concept is the same. As far as keeping the games in different locations than the front end, you would have to use symbolic links. Other posts in this thread have given details on this. I don't directly support it myself.

The !dos folder is no longer required if you don't plan on using meagre. That folder can be removed. All the files in it reside in zip files in the pack, so you aren't loosing them forever by deleting that folder. I got to thinking about this, and it is incorrect. Deleting that folder will make it impossible to launch games.

win3xo update will follow all 5 exodos volumes.

Torrents aren't for everyone and not everyone wants to wait until Christmas to get the stuff they want. I get it. Unfortunately, there aren't many ways to distribute large files like this. I have never stopped anyone from uploading my packs to other torrent trackers. I just can't maintain them all myself. That said, this awesome little site came to my attention recently.... https://the-eye.eu/public/Games/eXo/ The versions are still 2.0, but 3.0/3.1 will be added there once they are all out.

the archive.org sets are out of date, but yet, it does exist there. There is currently no place to get v3.1 without building ratio or being a member of a private site. The longer it has been out, the more sources will exist for it.

If you *don't* have your packs combined, you can use torrentcheck to take a .torrent file and compare it to your folder and see what differences there are (and even have it remove the differences. However, if it is combined, it will strip out the pack you already added