Custom parameter change of uae-file not recognized anymore (BattleIsle_v1.10_1991.lha) since new amiberry menu feature "WHDLoad"

[NoobieMaks]

Some times ago I reported in the XML repo that I this game does not start properly but with customizing the uae-config-file it works.
Changing the line"whdload_custom1=0" to "whdload_custom1=3" was the working solution.
HoraceAndTheSpider/Amiberry-XML-Builder#131

from the XML repo:
...
The game does not really start and shows the AmigaDOS message:
--- The data/disk-files are damaged
or it is an unsupported version.
1 > ---
...

@midwan:
I made a new uae-config-file with amiberry 5.7.0 and did a manual change from 0 to 3 in line "whdload_custom1=0".
Under amiberry 5.6.6 and 5.6.8 that trick made the game run.
I guess with the new WHDLoad menu in the amiberry GUI only settings done there are recognized anymore,
but how can I do this generally and especially in this game, it does not have a Custom1 on default?

Tested with:
buster + RePi 4.8.6 + Amiberry 5.7.0 (WHDLoad 18.9.6601)

[midwan]

This should really be fixed on the slave level. Currently, Amiberry shows all available Custom options coming from the slave, so if it doesn't show Custom1 as available, it won't be enabled.

@HoraceAndTheSpider is this something you can help with?

[HoraceAndTheSpider]

@midwan if the requirement is for custom1=0 to be set (which in itself I agree should be fixed by the slave level) then perhaps the problem here is that when custom1=0 in the config, we are setting it as "blank" (ie nothing in the startup sequence)

Perhaps - if ANY variable is passed from the uae file (even zero), we could push that into the startup-sequence?

---

Edit: perhaps I am reading this wrong (it's late) but surely we are still passing values from the config into the gui and then into the startup sequence?

[midwan]

@HoraceAndTheSpider
We're only utilizing the custom1-5 fields if they:

• have a type (defined in the slave)
• have a value other than zero

This specific game does not have Custom1 defined as any type, so it's not being passed/generated in the startup-sequence, even if you manually add it in the config file. If the slave is updated, then a non-zero value will be used.

Zero is a special case, since it's set as the default value for relevant custom field types. We could send the zero as well, but that would mean that custom1-5 would be almost always specified in the startup-sequence, even when not used by the slave or specified by the user. I'm not sure what kind of consequences that would have.