nietzsche666

I just realized I probably don't even have to modify my general Teknoparrot arguments. I could just create a new emulator entry for Teknoparrot Version 2 or so, for Contra (and similar cases) only and can leave the rest as it is, very nice.

YES! Works, and I have no picture duplicates because it tricks Launchbox to assume a different filename. Great idea. Going to have to modify my Teknoparrot Arcade entries because my basic TP emulator syntax has changed now, but it's only about 10 games so far, no big deal. I was thinking about batch files autostarting the emulator and games automatically and let go of Launchbox using emulator by itself for these few games, but I'm not sure if and how that even works with Teknoparrot. Thank you very much!

@skizzosjt: True, it's not the first time I had this problem with importing games to Launchbox. It happens rarely, but it happens for a handful of cases. Not Rampage for me, but it happened two or three times with other games. I just can't remember what the other ones were right now. I'm going to have a look at my collection, maybe I remember then. If you found a method to sort this out, it would be great to know.

Ok, I see. It even happens again after deleting both entries completely, restarting the system, and creating two entries from scratch, just adding pictures manually and not letting Launchbox automatically download anything. As soon as I point the Contra:Evolution entry to the contra.xml, the Contra pictures show up in the other entry. Well, it's an old Launchbox version, that is true. I'll probably not update LB on that system anymore for a minor nuisance like that. I found a hack-y workaround by organizing the image files for the Contra game as game over and highscore pictures only, the Contra Evolution screenshots as title and select - pictures, so the problem isn't that apparent anymore when I'm just clicking and starting these games. And the front box pictures for Evolution is set to box-front, and the one for Contra as advertisement flyer, so the Contra Evolution entry prioritizes its correct front image. But I still wonder if there is a less crude way to get done with that buggy behaviour in that older version.

@Retro808: Oh, I think we wrote both posts at the same time. Thank you for answering! Yes, Launchbox 8.4 already gives the images seperate names for both entries. As I wrote, it's Contra_ Evolution-01.png in Box - Front folder and Contra-01.png for the older game in the same folder. But strangely, Contra-01.png will be shown as front box image for Contra: Evolution, too, messing up the entries.

Correction - It's actually not vice versa. It's just that everything I download or load up as image for Contra will inevitably show up in the entry for Contra: Evolution. But it doesn't seem to happen the other way round. It's just that all pictures for Contra will override the Contra: Evolution entry and show up in its entry. It's strange, because I checked and the images in the images folder of Launchbox are even named differently. Contra_ Evolution-01.png, Contra_Evolution-03.png vs. Contra-01.png, Contra-03.png. But the latter ones still always show up for the other entry, too.

I'm wrapping my head around an annoying problem that occurs to me in a few singular cases when trying to import games to Launchbox. I'm sure there must be a simple solution for it, but I just fail to find it right now. I'm using an older Launchbox version 8.4 for one of my Win10 systems, and want to have one platform for all Arcade games, regardless if the games are emulated through mame, Teknoparrot, Supermodel and so on. No subcategories. Launchbox seems to refuse to import images for games seperately in some cases, if their rom names are similar. My specific case: I want to import the old classic Contra arcade game into Launchbox and emulate it via mame, but I also want to import the new Contra: Evolution game for the same Launchbox arcade platform, using Teknoparrot. For mame, I need to import a file called contra.zip, for Teknoparrot I need to import a file called contra.xml. It's unfortunate that Teknoparrot doesn't have a more specific title for its setup file I need, but it's what I have to deal with. You can't change the name of the files for these emulators or they won't run these games iirc. Now, I can point two seperate entries to two seperate DB IDs for both games, and they get recognized as different games from different years, they have the different titles "Contra" and "Contra: Evolution", and have all the data correctly for each of their seperate entries, but all artwork and screenshots images I download for one show up for the other entry, too. And if I delete the wrong pictures for Contra Evolution, they will be missing for the entry of the other game, and vice versa. I assume this is probably happening because except for the suffix the names of the "rom files" (the xml is not a rom file ofc, but for Teknoparrot Launchbox has to treat it as if it were) Launchbox gets pointed at are identical. Is there a simple workaround for this problem?

Ok, I actually solved the problem and am able to run the game via auto-mount batch file now. I don't understand the technicalities of WHY it works like this at all. But the trick was to set the mounting procedure as start /w, so the initiation of the game.exe waits until the mounting process is fully done with. It just takes a few seconds more to load, and for some reason the virtual scsi drive is only able to use its raw data reading / copy protection work-around abilities (or whatever this is about) if it waits for the image mounting to scsi virtual drive process to be fully terminated. So DTLite IS able to auto-mount these types of images in virtual scsi/ide drives via batch file, if you know what to do. This is my working batch file now, it's set up in a way that I already mounted a virtual scsi drive as "K" before I run it and that it ejects the image file after quitting the game: @echo off cd C:\Program Files\DAEMON Tools Lite start /w dtcommandline.exe -M -l "K" -p "C:\GAME ORIGINAL ISO BACKUPS\gamename\imagename_xxx.mds" cd C:\GAMES\gamefoldername start /w game.exe cd C:\Program Files\DAEMON Tools Lite start dtcommandline.exe -u -l "K" Also, it works the same for setting up a virtual drive as ide drive (ide drive is able to read protected mds/mdf files, too, I'm not too sure what the pros and cons of both drive types are for dealing with images like this).

Ran into an annoying problem using DTLite for an auto-mount batch file with an old Windows 98 game that otherwise runs fine with some tweaks on Windows 10 64. I hope someone around here might have a clue what I am doing wrong. The game runs off an mdf/mds - image file created with Alcohol 120% (current 2.1.1 trial version) from the original game cd I own. That was necessary, as the game has an ancient cd check copy protection relying on unreadable sectors. Additionally, It's one of those dated install pests that needs a windows install (creates an 80MB folder on the harddisk), but still leaves the majority of the game data and video and music files (about 500 MB) on the cd that has to be inserted for playing. It doesn't have a "maximum install" option like other games of that era, it's really the only way to play it. (No NOCD file or patched version of the game is around, as it is a pretty rare version and never had wide distribution.) So playing it from original cd will create hiccups and little breaks because it constantly has to read via physical drive from the original game cd. Using that mdf/mds image it runs smooth, though, so I absolutely want and need to run it via image file, and I also don't want to be dependent on that 20+ years old game cd for preservation reasons. It needs a scsi virtual drive for the game to accept that mdf/mds file as original game cd. I use Daemon Tools Lite 11.0 and re-enabled sptd drivers for WIn1064 via registry tweak, so I can mount a scsi virtual drive for the mdf/mds image. Regular dt virtual drive doesn't recognize the file as original game cd and the copy protection sets in. So far, so good - everything works fine when I manually mount the mdf/mds in a virtual scsi drive created by Daemon Tools Lite. But when I try to start a batch file to automatically mount the image file and start the game exe, I'm able to auto-start the game and have the game recognize the mounted image file, but it doesn't recognize it as scsi drive and the copy protection sets in again. @echo off cd C:\Program Files\DAEMON Tools Lite start dtcommandline.exe -m -t "scsi" -l "D" -p "C:\GAME ORIGINAL ISO BACKUPS\gamename\imagename_xxx.mds" cd C:\GAMES\gamefoldername start game.exe I tried a lot of different ways of mounting drive and image but this is my most basic command line argument that should work to set up a new scsi virtual drive as drive D, mount the mds/mdf image in this scsi drive, then start the game. Should work, but somehow doesn't. It acts as if the drive mounted is STILL a dt drive. After this failed batch command start, though, I can leave the image in the new d drive (which DOES gets depicted as SCSI drive within Daemon Tools Lite) and start the game exe manually and it works again, virtual drive is treated as scsi drive, and I can play the game without the copy protection setting in. It's only when I use the command line batch file it doesn't work. Am I missing something, some option or parameter I should have used? Or is this about some restriction for the free Daemon Tools Lite version for command line options that isn't explained on their info site?

Thank you so much, it works as you say, creating simple shortcuts for the FS UAE Launcher that way, exactly as I wanted it. It just needs the UUID title (the specific code/title of the UUID for the exact version of the game), not a path. (Kinda embarassing I didn't think of trying that before asking, sorry.) Thanks again for the help.

So this method is wonderful and I have used it successfully in Launchbox for years now, thanks to everyone putting their hard work into this. Now I'm sitting on my second system, a Laptop that doesn't have that many games and I didn't consider using Launchbox for the Amiga game collection that's on it. Still, I didn't want to load up the FS UAE launcher every time I want to play an Amiga game, so I'm trying to create simple batchfiles to start the games automatically with the FS UAE launcher, but directing them to the files created by the exporter doesn't work that easily. If I simply create a batch file like "launcher.exe [PATH TO FILE]\8058ab69-a1b2-5edf-8861-3cec4e193813", only the launcher gets started, not the game it should have autoloaded incl. its configuration. Is there an easy solution to creating batch files for FS UAE games and their configurations, or will I need Launchbox for starting the games with the files provided by the exporter?

Of course I'll do that, if I actually find a way eventually ... (I already described my one very dumb workaround before: Just set up copies of the emulator folder and set them up as something like "Mupen64Plus 2" + x or so in Launchbox. The emulator folders themselves don't eat up much space on your harddrive. I already have two versions of the emulator for all the games that need overscan for going true 4:3 fullscreen and those that don't. But if you don't really want to spam Launchbox with 20 versions of one emulator regarding all the settings you need, this is really a very bad solution for this problem.) Per-Game-Settings is the holy grail of N64 emulation IMO, anyway. Retroarch does it, but it isn't the best option for a lot of N64 games. I have the same trouble with Project64 2.3.2, by the way. I couldn't find any way to start specific configuration files with command line options. It's saving SOME specific game settings, even for the plugins, but it doesn't do it for the extra GlideN64 plugin that I use very often. And it doesn't save game-specific controller configurations, which is especially annoying, as the strange N64 pad needs very different mapping methods for a lot of games if you try to use a common Xbox Controller. At the moment, I use Xpadder for specific extra mappings I can't set up in Project64.

Thanks! I use Retroarch for other N64 games, but Retroarch is missing some tweaking options for the games I had in mind here, unfortunately. I think I will have a look at the no-gui version of mupen for these cases, there might be an option for loading up specific configurations by command line.

I'm trying to set up this version mentioned in this thread to properly work with Launchbox for N64 emulation: https://m64p.github.io/ Is anyone experienced enough with that emulator to provide some clues how to make Launchbox start up the emulator with game-specific settings? (I'm using the 64 version on Win 10 64.) Old command line options for other mupen versions I could set up in the game entry within Launchbox don't seem to work. AFAIK there is very little information and no proper tutorial about that gui version of mupen64, so I'm kinda out of ideas. It should be about modifying ini files like GLideN64.custom.ini. It seems to involve some specific names for each roms for modifying values like, say, Enable Overscan, or maybe the controller mapping. Right now, I'm using three copies of that program with different configuration file paths, but that is a pretty bad workaround for that problem. (I still have to set up about 20 individual games that all will probably have different optimal settings for gamepad mapping, graphics plugin and so on. Having 20 emulator copies of m64p GUI would be pretty ridiculous, I hope I can avoid that, lol)

@ Jason Carr. It's ok. I will probably just pay, as I have been planning for months.

@neil9000: It says I have to go premium for changing anything there. I might actually do this at some point, still it would be nice if the team might think about letting that option remain free for the next update. Especially if old Launchbox style isn't available anymore at that point.

Yes (I think). I mean the box in which the box art is embedded in the Lnext design. The graphic you show doesn't have it. Could you please tell me where I can change this?

(I hope I'm not repeating anything, couldn't find anything about this so far.) LNext looks good and seems to work somewhat faster, the only thing that bothers me so much I would refrain for getting the next LB update that will make LNext mandatory is the new frame style in which the box art is embedded. I prefer the old style, with just a gallery of just the original authentic box art covers like in a game museum, very much. The frame is kinda altering this "feel" in a way I don't like. It should be easy to just include an option to return to classical "frame-less" display. But I didn't find anything yet. Did I just overlook something? Or will this be implemented in the next update of Launchbox?

Dunno, I use only non-payed lite version and don't have problems of that sort. It has these annoying update popups, but that's it, it seems. I used to have really messed up problems years ago with Daemon Tools completely crashing my OS, mostly due to the image drive drivers breaking windows etc. Then I had this problem that after a Windows upload I couldn't deinstall Daemon Tools. It was hell to get out of that. But other than that, newer versions on WIn10 64 don't pose these problems anymore. Glad you could figure out the DTCommandline.exe thing. Hope your batch files will work with it.

Ok, my version is 10.8. though, not 10.3. DTAgent command line options worked with 10.7. And with 10.8 now as I described. Maybe u just try to download the upgrade? DTCommandline.exe should appear then; I'd say.

@ Mile Panic: Ok, thanks a lot for the info. By now, I have exchanged all my launchbox settings for use with DTCommandline.exe manually, it took some time. But I'm still really angry about this unwanted change they coerce you into without telling you anything about it. All this I suppose just to press people into buying the pay versions of Daemon Tools. A lot of people will have to rewrite millions of batch files and frontend settings for this for no reason. Grrrr. I don't use batch files for my auto-mount settings. I use additional apps within launchbox. What I do to make it work is already in my post. I repeat: For automount I have to point add. app to DTCommandLine.exe, then add -M -l "E" -p "D:\GAMES\XXX\XXX.ccd" in the command line section. -M is for mount, -l (small L) is for Letter of the Drive, "E" is the drive letter I wanted to use(has to be in quotation marks). -p is for path. And everything in q.marks after that is of course just the path to your CD/DVD image file. For Unmounting I just use another additional app pointing to DTCommandline.exe and use -U in the command line section (It's for unmount drives). DTCommandLine.exe is a exe that's in your DTLite installation folder. I don't know if it was there in elder versions, but now it is the way to go. The info about the new command line options is in the DTLite help link I posted before. I hope this helps a bit if you want to set up batch files. You will just have to exchange all DTAgent references with DTCommandLine references and command lines, I guess.

If anyone had similar problems with automatic DTools Lite 10.8 image mounting within Launchbox like me recently, please let me know. I'm on newest version WIN 10 pro 64. I've been looking for infos about this problem all over the net, but I didn't find anything. My recent problems: After ignoring DTools Lite 10.7's pleas to update to 10.8 for months, I finally gave the new update a try today. I don't really trust DaemonTools updates, I had other problems before at times with some old functionality not working anymore after auto-updates, but I was annoyed by the constant update info popups and just went on. And I was right to hesitate with the update, again DTools messed up my Launchbox usage settings in a very annoying way. Before I could easily use DTAgent for auto-mounting as additional app and have done so without problems. I could just point the add. app. to DTAgent and put in a command line parameter like this: "-mount dt, "D:\GAMES\XXX\XXX.ccd" and set it to start before main program. The same for "-unmount E" and set "start after main program" for unmounting automatically after game stop. After I did the update to 10.8 however, none of these methods worked anymore. DTAgent just refused to mount or unmount anything. The commands were worthless and nothing happens. Now I fiddled around a bit and luckily noticed I can just use an alternative method to auto-mount/unmount using DTCommandLine.exe. It uses other types of command line options. For automount I have to point add. app to DTCommandLine.exe, then add -M -l "E" -p "D:\GAMES\XXX\XXX.ccd". It works the same, seems even a bit faster in executing the mount commands. It opens a COM window shortly, which is slightly ugly and annoying, but not a huge problem. But now I have to exchange every game using the old DTAgent method manually to the new DTCommandLine method. This will take some time, and I still don't know what actually happened with Daemon Tools. Could anyone please enlighten me and confirm the following: Did they really just change the command line methods with the most recent 10.8 update? Or did they even make this non-free for the future out of sheer sadism? I noticed that the "command line" section on the Daemon Tools help section only refers to DTCommandLine for DTools Lite by now, but has entries about DTAgent on its DTools Pro site. http://daemon-help.com/additionally/command/ http://daemonpro-help.com/additionally/command_line_integration/ Or is there some bug in my system or in my install process causing this DTAgent failure? I'd prefer to change that back to its old DTAgent functionality before I will really have to edit all my iso-bound games, which will take days...

The "loop check" script works fine! Started the game for 5-6 times now without any troubles mounting the first CD. Case closed, it seems. Thanks a lot!

I just found out the secret about the problem with the "admin" mod. My necrono.exe was set on WIn98 compatibility mode. I must have played around with it at some point and forgot about it. It is indeed a very old game, but WIN98 compatibility is not even necessary, game exe works fine without compatibility setting. If compatibility mode is not set, there is no need for setting the AHK script to "admin" for making the hotkeys work in game environment. But that could still pose a problem if a game actually needs compatibility modes to run.

Ok, sorry for the long break before my reply. I got into work trouble last week and subsequently lost track of this little thread. My bad! But the good news is: YES, method works as it should, exactly as I imagined it before. I just tried Option 2 without "Insert CD1 nag". I don't see anything too complicated about writing up two text files, so I didn't bother with option 1 at all. Script files + Instructions are perfect. One thing I still had to find out and do by myself: I still had to compile the second AHK Script for the swapping setup and set it to "run as admin". Otherwise, it doesn't recognize the hotkeys within the game. I think it has to be compiled for the admin setting, but I'm actually not sure about this. But with this method and admin setting, nothing gets minimzed and no "flickering" or anything. It just changes the isos in the background as wished. For some reason, WinCDEmu fortunately behaves quite differently than Daemon Tools Lite. With WinCDEmu method, the "Close all running applications" lock gets overridden and I can swap the isos at any time. (Game will of course crash, if it's not the right moment for that and it still needs the other disk, but that is just obvious and expected.) I get the WIN10 "mount/unmount drives" info sounds with the WinCDEmu method at the start, end and when swapping the isos. This might annoy others, but I'm happy with it like this, as I know the Ahk-Script worked and the isos were actually swapped. I have a slight problem that in about 1 of 10 cases of starting the game, the first script messes up and doesn't get to load the first iso. I know this problem from working with Daemon Tools and Launchbox additional apps in other games. Sometimes the mount process takes too long and the game subsequently crashes. I usually just check the "wait for exit" box for the "Mount Disk 1" additional app. This method won't work here, of course. But it seldom happens, and so I'm hardly bothered by this. I'd recommend posting the fine AHK Script files for WinCDEmu-Swap-method for other users in the Hotkey-Script - Threads. I think by now the thread title here is somewhat misleading. It should be posted as something like "Hotkey-Script for easy ISO-Swap for old Windows Games", so others having trouble with similar cases don't have any troubles finding this method when browsing the LB forums.