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.