Trouble with FS-UAE via command line

I intend to use FS-UAE from a front-end, and as such I need for it to be able to launch games with a command line. My collection happens to be the WHDLoad archive, which FS-UAE is capable of handling, though there seem to be tradeoffs.

I have three problems.

First, the apparent basic inability to point FS-UAE directly at a WHDLoad game .zip and have it work, even though it can handle things fine from within the GUI. I get this message:

"Did not find the specified WHDLoad slave. Check the WHDLoad arguments"

There is probably a solution to this, but let's move on to the next issue: I can't think of a convenient way to make FS-UAE load a game via its UUID, which seems to be the only way to force FS-UAE to use a custom config, which is a necessary step to get many games to play correctly. I found an app that can generate folders with the names of games, with empty files inside them whose filenames are the games' corresponding UUIDs, but this is only especially useful for one frontend (LaunchBox), which is useless to me. Plus, Launcher.exe doesn't like UUID text with a path included (like: Launcher.exe "WHDLoadGames/Turrican v1.3/sdf785693-2954u9s-3459sdsdfs"). Best I can come up with here would be maybe individual bat files, named after the games, that simply launch Launcher.exe with the appropriate UUID, and while that should work, I sadly wouldn't know how to automate the generation of 2000+ bat files like that. (Though I suspect the folder/UUID files I mentioned earlier would make it at least doable.)

Last problem: Even if I successfully launch FS-UAE with a UUID, it ignores my custom configs anyway. For example, I set up a custom config for APB because it needed an anti-Atari shader to avoid looking dark. According to tutorials I've watched, using the UUID should cause FS-UAE to use this custom config (which I gave the same name as the game). But it ignores it. So I'm missing something important here as well.

Anyway, that's what I'm staring at. Hopefully someone can offer some tips.

[gryf]

Yeah, you are right. FS-UAE doesn't support whdload zipped games. It is FS-UAE-Launcher feature. Since whdload games are basically small bootable HDs/Directories with launchable games, you can take a look into small utility I wrote, which can deal with compressed directories from commandline: https://github.com/gryf/fs-uae-wrapper

Originally Posted by gryf

Yeah, you are right. FS-UAE doesn't support whdload zipped games. It is FS-UAE-Launcher feature. Since whdload games are basically small bootable HDs/Directories with launchable games, you can take a look into small utility I wrote, which can deal with compressed directories from commandline: https://github.com/gryf/fs-uae-wrapper

Thanks for the help.

Well, if it's just a matter of using the correct executable, I'll use the correct one. I hadn't even known to check for a completely different exe. But... it's all moot because Launcher.exe works just fine to launch games either by their user-defined .fs-uae config or their UUID.

That leaves me with problems #2 and #3 from before, or alternatively:

4: I don't know how to (conveniently) create custom .fs-uae files for every single game in my collection, which, for the purposes of launching from a front end, is the only way to get any use out of them.

[gryf]

I can't help you with FS-UAE-Launcher (since I don't use it at all), I just cook up my own configurations for every game/system, which in the end doesn't differ much from each other.

First of all, I have prepared special Host.fs-uae, which will be read before any per-game configuration. There goes all the paths for kickstart/floppy/cdroms/whatever. Next is to provide an config for each game, like:

[config]
amiga_model = A1200/020
title = Chaos Engine

hard_drive_0 = $CONFIG/Chaos_Engine_ECS

zorro_iii_memory = 65536
floppy_drive_volume = 0

scanlines = 1
keep_aspect = 1

Where the only things to change are those in bold. You can add custom settings for each game individually and that's it. Note, that in this example you have to have whdload game unpacked and prepared in a way like this:

Chaos_Engine_ECS/
├── C
│ ├── DIC
│ ├── Patcher
│ ├── quituae
│ ├── RawDIC
│ ├── WHDLoad
│ └── WHDLoadCD32
├── ChaosEngine
│ ├── ChaosEngine.info
│ ├── ChaosEngine.Slave
│ ├── Disk.1
│ ├── Disk.2
│ ├── Manual
│ ├── Manual.info
│ ├── ReadMe
│ └── ReadMe.info
└── S
    └── startup-sequence

where startup-sequence looks like:

cd ChaosEngine
whdload Cache DCache PreLoad Slave=ChaosEngine.Slave SplashDelay=0

HTH.

Originally Posted by gryf

I just cook up my own configurations for every game/system, which in the end doesn't differ much from each other.
[...]
Next is to provide an config for each game, like:

If I can find a way, I think creating individual configs for each game, like you did, is the way to go. The problem is it doesn't seem to be something I could eventually do in batch. Here is a typical config file if I were to create them manually one by one:

# FS-UAE configuration saved by FS-UAE Launcher
# Last saved: 2017-06-26 02:58:34

[fs-uae]
amiga_model = A1200
fast_memory = 8192
hard_drive_0 = F:/Hyperspin/Emulators/Commodore Amiga/FS-UAE/WHDLoad_files/GalacticConqueror_v1.0.zip
shader = atari-color-fix.shader
x_whdload_args = GalacticConqueror.Slave PRELOAD

Each game is set up (by the online database) to be emulated on particular Amiga models (600, 1200, 500+ etc.), so that is a concern. Worse, the names of the .Slave files are all unique and rarely use the same exact text as the game's name or filename. I also don't have access to that information because it is tucked away in a .sqlite file and I have no idea how to open or parse it. If I did have that data in a sequential text file, I suppose in theory a .bat file could be created to generate the .fs-uae files I need.

[FrodeSolheim]

Originally Posted by Asterra

First, the apparent basic inability to point FS-UAE directly at a WHDLoad game .zip and have it work, even though it can handle things fine from within the GUI. I get this message:

"Did not find the specified WHDLoad slave. Check the WHDLoad arguments"

Are you using the stable version? The development version has much better support for WHDLoad archives, and should be able to run most of them fine via command line. It will also try to match the archive against the online database and use options from the database if it finds a match.

[For other readers, the OP is talking about FS-UAE Launcher. FS-UAE itself does not have any specific WHDLoad support].

Originally Posted by FrodeSolheim

Are you using the stable version? The development version has much better support for WHDLoad archives, and should be able to run most of them fine via command line. It will also try to match the archive against the online database and use options from the database if it finds a match.

Good guess. I had been using the stable. I switched over.

The sad truth is that while this does enable me to load WHDLoad archives directly, this still does not cause the launcher to recognize that I have set up custom config files in a few dozen cases (to fix shading and improve compatibility where needed). APB, for example, needs a special shader. This works if I launch the game via its config file. It does not work if I launch the game via its WHDLoad zip archive or its UUID. It doesn't matter whether I use Launcher.exe or fs-uae-launcher.exe.

Honestly this is pretty baffling, because everything I have read and every video guide I have scrutinized has insisted that making custom config files will cause the launcher to automatically make use of those configs. It sure would be nice if someone could explain either that everyone was completely mistaken or that I have missed an important step.

Edit: I managed to kludge a solution based on utilizing both the zips and the configs. I'll have to rename all of the files but at least it seems to be working. I will note for posterity that fs-uae-launcher.exe doesn't seem to like running from a front end if there is any kind of path included in its executable (/fred/bob/fs-uae/fs-uae-launcher.exe "/fred/bob/fs-uae/games/game.zip"). It gives a Python error. Fortunately, doing so is not strictly necessary.

Originally Posted by Asterra

It gives a Python error.

What kind of error?