Extend 'save this disk config' to provide same facility for whdload archives?

[giantclambake]

Currently, one can load a floppy disk image file(s), configure the emulator to run that Amiga title as correctly as possible, and then one can both save a .uae config file to be manually loaded via the GUI, and one might also select the 'Load config with same name as disk' widget, and click on the 'Save config for disk' button, which should allow you (in theory, I've not tested it yet) to issue the command something like 'amiberry -G -0 diskname.adf' .... and amiberry should load the ADF + it's associated disk-name config, and launch straight into the emulation (for that title), all 'pre-configured' as it were, bypassing the GUI ops.

As I'm building a linux desktop based Amiga emulator using amiberry for that task, the above is a very handy feature, as it easily allows one to define a default action in qtfm, to invoke the above command if a name.adf icon is double-clicked/opened in qtfm itself ..(hopefully it works as expected =)

Amiberry's handling of whdload.lha archives is likewise a good feature, and thanks to the --autoload cmdline option it's easy to make a default action in qtfm, but it would be a feature add to be able to ie; 'Load config with same whdload name' widget, and click on the 'Save config for whdload file' button, so that when one invoked (j/k here 8) 'amiberry -G --autoload /path/to/whdloadname.lha , that too would launch straight into the emulation (for that whdload title), all 'pre-configured' as it were.

Would it be possible to add this feature to whdload.lha handing? Or..if this is supposed to already work, it's broken =) As it is now, you can save the whdload config for the emulator ..identified by the descriptor name.(AutoBoot Configuration [WHDLoad]) ...but just like in the floppy disk image scenario, it'd be a nice feature to be able to save/load the local emulator config, for a name.whdload.lha file to be used as it's default/defined config, when the --autoload cli option is used.

TIA

[midwan]

The booter is supposed to automatically lookup any saved config with the same name, and use that if found. Otherwise, it will fallback to the options found in the XML.

If you have a scenario where this doesn't happen, please provide the steps to recreate it and we'll check :)

[giantclambake]

//well, we've shot ourselves in the foot here, as the revamped GUI floppy config panel has dropped the 'Save config for //disk' option ~ I consider it's only a flesh wound though, and I'm thinking if we can get this 'right' as it were, it might be //an underlying feature-add for both disk-image & whdload.lha media handling....

For a working example, we'll stick with AddamsFamily_v1.3_0419.lha as it's such a handy Thing for this B)

If you load that archive into amiberry (via GUI or by using --autoload option), when the emulation starts and you see the game's title screen appear, the image is shifted to the left...ie; required tweaks to config are Display->AutoCrop needs to be unset ; Centering->Horizontal needs to be set. It is of course like this, as amiberry has found a match for the archive in the whdboot/game-data/whdload_db.xml file which sets the configurata here;

<game filename="AddamsFamily_v1.3_0419" sha1="a54a35018bb1d7928de291f70a0adae7cf94b0a4">
                <name>Addams Family</name>
                <subpath>AddamsFamily</subpath>
                <variant_uuid>09f31e16-4091-57d6-92f3-c6bac08a8604</variant_uuid>
                <slave_count>1</slave_count>
                <slave_default>AddamsFamily.Slave</slave_default>
                <slave_libraries>False</slave_libraries>
                <slave number="1">
                        <filename>AddamsFamily.Slave</filename>
                        <datapath />
                </slave>
                <hardware>
                        PRIMARY_CONTROL=JOYSTICK
                        PORT0=JOY
                        PORT1=JOY
                        SCREEN_AUTOHEIGHT=TRUE
                        SCREEN_CENTERH=SMART
                        SCREEN_CENTERV=SMART
                </hardware>
        </game>

Note: I believe those 3 SCREEN_* directives end up being analogous to AutoCrop=true in amiberry?

Thus, one creates a specific .uae config file to implement these tweaks (see attached), quit & restart amiberry (sanity), load/run or double-click on the 'Addams Family (AutoBoot Configuration [WHDLoad])' entry in the configuration panel, and game starts & runs, all centered correctly in the display window...start&play, no additional configuration required. For extra sanity, reboot the machine and reload this configuration and start/run the emulation = works as expected.

Now... knowing the 'conf/Addams Family.uae' config file exist & works, quit & restart amiberry again (more sanity), and again load that archive into amiberry (via GUI or by using --autoload option) to start/run the emulator...

Expected behavior -- amiberry will scan/parse the conf/*.uae files to find a match for the whdload.lha filename of AddamsFamily_v1.3_0419.lha that has been loaded (eval for config_description=AutoBoot Configuration [WHDLoad] then if true parse the filesystem2/uaehf2 lines to match whdload.lha filename or similar), and if found use that configuration in preference to the 'default' configuration as defined by the whdload_db.xml file.

( Note: it would be nice if amiberry handled floppy disk image filenames in the same way...ie; scan for matching .uae file ~ this would effectively replace the (removed) 'save config for disk' button, as basically this feature would always be on =)

Current behavior -- amiberry uses the 'default' configuration as defined by the whdload_db.xml file even if a specific .uae configuration file exists for the whdload.lha

Usage scenario: This a lot desktop app ease of use stuff ~ on the emulator systems I'm building, I want it to be as simple as possible, with a lot of stuff 'pre-configured' as it were. Now that the --autoload bug got squashed by midwan, I can have a typical workflow of ...download whdload.lha file ->open qtfm->double-click whdload.lha file icon->game loads and starts

Unfortunately due to the above current behavior, I can't achieve that warm fuzzy works OOTB pre-configured goal =)

Addams Family.uae.gz

[midwan]

For scenarios like the above, the best course of action is of course to correct the entry in the XML, going forward. I will of course look into the config situation, but you might want to submit a relevant request for the XML change to Horace's repo: https://github.com/HoraceAndTheSpider/Amiberry-XML-Builder

[giantclambake]

Had thought of that, but realized the whdload_db.xml file may get overwritten upon any subsequent update.

Thanks for the heads-up to Horace's repo ~ that's going to be a lot of changes =) As I've the inclination/time to go through and check all the archives on whdownload for example, I already have found/know of multiple titles, for which the above scenario is true...ie; small tweaks to display settings for the most part.

Query: Before I launch into that, can you tell me why the whdload_db.xml is so 'out of step' with amiberry-5.6.x ?

This is to say, I would have thought the game XML for AddamsFamily_v1.3_0419.lha to be 'correct' and not need any sort of modification? Has this situation come about due to changes/improvements in amiberry, or has no-one bothered to go back and rechecked the whdload_db.xml file in some time?

Reason for this query is I am unsure whether the XML changes only relate to amiberry improvements, or whether I'm coming across them merely due to the fact I'm using amiberry in a linux desktop environment ; I don't want to proffer changes that may adversely impact handheld devices for example (which I cannot check, as I don't have that hardware). Any insights here?

[giantclambake]

//Answer to question above is likely still pertinent to me =)

I discovered what's going on here... quoting from https://github.com/BlitterStudio/amiberry/wiki/WHDLoad-Auto-booting

"I have changed an individual game's settings with the emulator menu, how do i make sure these are reloaded
 next time i play the game?

Simply save the .uae file from the Configurations panel of Amiberry, and this file (Created by matching the 
.uae file  with the loaded .lha file) will automatically be set when you next load the game, bypassing any 
XML or .WHD stored settings.

If you no longer require a setting file to be loaded, simply delete it using the Configurations panel also."

It is not that simple =)

The game filename MUST be "AddamsFamily_v1.3_0419" as that's how the parsing resolves it. (strip extension)

Ergo ;

mv conf/"Addams Family.uae" conf/AddamsFamily_v1.3_0419.uae

This results in (amiberry.log);

WHDBooter -  /home/amiga/Amiberry/conf/AddamsFamily_v1.3_0419.uae found. Loading Config for WHDload options.
target_cfgfile_load(): load file /home/amiga/Amiberry/conf/AddamsFamily_v1.3_0419.uae
load config '/home/amiga/Amiberry/conf/AddamsFamily_v1.3_0419.uae':3

With this the game loads & runs incorporating the local display tweaks as referenced above.

The issue is one of either amiberry not propagating the stripped filename into the Configurations-Name: field ...or ...users should not be offered the opportunity to name the file what they want (the Description: field is propagated with the '(AutoBoot Configuration [WHDLoad]' string )

I'm not sure of the best resolution here, but essentially this is the problem =)

HTH

[midwan]

Oh, you had a different name for your config file then? That explains why it wasn't picked up. The name must match that of the WHDLoad archive exactly (minus the .lha/.uae extension of course).

I've updated the wiki to clarify that a bit better.

[giantclambake]

Thanks ~ although I have serious reservations about the comprehension/reading skills of modern society, the wiki revision spells it out clear enough for me (I would not have ended up here, if the wiki had read like it does now =)

I'll close this now ; title has become defunct (save this disk config NLA), and question answered