Save OpenRetro-Config-Changes in fs-uae

[Wulfman]

Hello,

I use fs-uae Launcher 3.0.5 / Windows. For this purpose, I registered with OpenRetro and included it in fs-uae accordingly. Now, however, I would like to make small changes to some games:

Bubble Bobble WHDL: here I get an Amiga 600 configured by OpenRetro. Unfortunately CPUs before 68010 can't do a quitkey (in my case: F10). Unfortunately, the highscore is only saved by EXITING the emulation via Quitkey. If I exit via F12 and "X", the high score is not saved. FS-UAE also notes that I should use the Quitkey.

Solution: I change the Amiga 600 in the config to an Amiga 1200. F10 now works. Highscore is saved.

Other game: The Settlers. To skip the intro, a CUSTOM1=1 is added to the arguments. Works. But when I select the game the next time, the setting is gone.

How can I save such config changes without losing the OpenRetro data (Screenshots etc.)? If I write something in "Own configuration" (gear at the top), it is not saved.
amiga_model = A1200/020
chip_memory = 2048

Same with Joystick-Changes etc.

[thevoice]

hi,

the best idea would be to make a comment about the quit key in the game entry. i found this one more or less by random luck. but i have changed the amiga model for bubble bobble to a1200 now to get the quit key working.

as for the customX=X to enable cheats and as you mention to skip intros. this i cant change because there is no possibility to do. and also such a change will have an effect for everyone using the database. so if you want to permanently skip the intro does not mean everybody wants to do so.

so the best deal in such cases is to go to the whdload mantis bug tracker and nicely ask if the maker of the .slave is willing to update the slave with whdload v17 functionality so you can use a checkmark to enable/disable different custom settings up on start of the game.

hope that helps a bit.

[Wulfman]

Well, on the fs_uae side, that would be nicely possible.

Feature Request?
Each game and its variant already has its own UUID - e.g. a83a41e4-8ffe-5a52-8e87-8e1f8cfca8a0 for 1000cc Turbo WHDLoad v1.0; 5f28333d-9c70-5779-938c-58f083154cd is one of the ADF variants.

Now one could deposit a custom-config for each game. A "save button" that appears as soon as something has been changed. Rule: Custom > Retro. The custom-config always uses the UUID as identification. FS_UAE also shows that a custom config is now active (for "troubleshooting" - delete config etc. u know).

Done ... In the custom-config you can adjust EVERYTHING for YOURSELF. Unfortunately, it's not only the WHDLoad arguments and the CPU that can't be changed in OpenRetro - I also had a game with Chip-Ram "?" - didn't start that way -> until the correction is done in OpenRetro, the game only runs by manually changing it - at every start. Even if you want to change the mouse-joystick setting for the joystick ... or another shader that works very well for the game - but unfortunately is rather bad for many others (shaders are understandably not in OpenRetro). A UUID-based custom config would give a lot of freedom here.

so the best deal in such cases is to go to the whdload mantis bug tracker and nicely ask if the maker of the .slave is willing to update the slave with whdload v17 functionalit

unfortunately not a good deal. The new WHDLoad with changed slave must first be inserted into OpenRetro ... and this happens very slowly (no reproach! I know that OpenRetro is only administrated by Frode!). I have loaded a lot of WHDLoads from EAB-FTP that are not yet covered by OpenRetro (1.3 is in OpenRetro, 1.4, 1.5 or even 1.7 not yet!). If all slaves were adapted now, we would have nothing of this in FS_UAE - many incompatible versions - no more Therefore, I see a custom-config as the only solution to this problem (i.e. the config problem - newer WHDLoad versions is another topic).

... or is the topic already planned for 4.0? Actually, the function already exists? But it is not active?

[thevoice]

hi,

actually whdload slaves should be updated once every month or every two months.
and as you figured out already frode is doing all this stuff on his own. i can just trigger changes on existing configurations. so importing new/updated titles we all have to wait for frode.
in the past there was an idea from frode to auto update whdload installs and some other stuff. but for now nothing like this exists.
i will try to reach him and bugger him to trigger an whdload update

[FrodeSolheim]

Originally Posted by Wulfman

Now one could deposit a custom-config for each game. A "save button" that appears as soon as something has been changed. Rule: Custom > Retro. The custom-config always uses the UUID as identification. FS_UAE also shows that a custom config is now active (for "troubleshooting" - delete config etc. u know).

Yes, I am planning something like this for FS-UAE Launcher 4. There are some details I'll need to work out first, but it is on my mind.

- It *is* desirable to allow for local adjustments, since there is no configuration that will suit everyone.
- But I don't want to end up with a situation where everyone makes local modifications instead of submitting changes to the online database.
- So I'll probably need to (not necessarily to begin with) make a function to easily (by the press of a button) submit changes as a suggestion to the online database, to make it as easy as possible for users to do the right thing (tm) and send in fixes. I'll also eventually need help to assemble a team of reviewers to review these changes
- Alternatively, upload all changes done by users (opt-in of course) and create a system to suggest changes on openretro.org if several people use the same overrides. A nice bi-effect of this would be that the overrides are linked to your account and could be synced between your setup on different computers.
- A complicating factor is that some configuration options on openretro.org does not map 1:1 to FS-UAE (Launcher) options. Not a deal-breaker, but something that needs to be taken care to implement a proper and simple save button saving only the changes.

It is possible I sidestep the above considerations to begin with, and start with allowing users to manually enter overrides, to get something useful up and running sooner.

But first of all, I'll do a round of importing variants based on the latest WHDLoad slave updates

[Wulfman]

Thanks for the answer

- But I don't want to end up with a situation where everyone makes local modifications instead of submitting changes to the online database.

I am with you If everyone pulls a DB excerpt from you and then "improves" everything and saves it locally - OpenRetro unfortunately has none of that! With that I am basically kicking my own "feature request". Very strong argument from you!

But isn't there a risk that some people will think "I'll make a new," free "configuration for the game"? The configuration changes then also do not go to OpenRetro

But what just occurred to me. My original problem was the missing Quitkey (there is also a 68000 Quitkey - but has to be implemented first ...) and therefore the saving of high scores (e.g. Bubble Bobble - uh, has that changed? I just don't see that now starts as A1200 ?!) works. From this I derived this "I want to save individual changes" thread.

In the Pi scene (Retropie, Recalbox, Batocera), WHDLoad recommends placing this in the A1200 folder - so the games always start with an A1200 config - idea for this: "Switch" in FS_UAE "WHDLoad: System < Always start A1200 as A1200 ". In this way, all WHDLoad games would run with a Quitkey-compatible config. Perhaps this would be a faster workaround for the original problem for you.

It is possible I sidestep the above considerations to begin with, and start with allowing users to manually enter overrides, to get something useful up and running sooner.

&

So I'll probably need to (not necessarily to begin with) make a function to easily (by the press of a button) submit changes as a suggestion to the online database,

Small idea:
2 steps:
Step 1: User can customize shaders etc. As soon as a change is made, a uuid.fs-uae config file is created. Complete. System changes do not work at first (unless someone writes them manually in the appropriate fs-uae). Another reason for my post was e.g. the "MadNews" problem (it's not a WHDLoad now, but I was talking about settlers there) - so I probably need shaders other than the standard for some games.
Step 2: If I change the system later => Notice "Help the community: Send system change to OpenRetro?"
(Transmit to OpenRetro is certainly more difficult (security) than securing a few things locally)

Off-Topic:
Savestate-Dir: Bubble Bobble (Amiga, WHDLoad, v1.3, 2518). What if I e.g. a v1.4 game - then my savestate is gone. Would it be better to name the savestats after the parent_uuid? Doesn't it change?

[thevoice]

In the past every whdload install was set to a1200 model by default. which entirely defeated the quitkey not working on 68k speak a600 model. then at some point frode wanted those whdload installs which work fine with a600 to be set as a600. which makes it a pita when newer whdload installs get imported because if there is a new version it wont copy over the old versions setting for the model.

so i was always lobbying to keep the entire whdload setup as a1200 model.

the save state issue after version changes is also something i dont like at all for the exact reason you mentioned.

and having people become able to submit changes without moderation, is something nobody wants for real. beside of database vandalization, there is always the "experts" requesting changes like omg just add 12 disk drives to this game or this game never ever run with less then 8mb chipmen even on real amigas. or just add 8mb fastmem to this 1987 kick 1.2 only game which run only with 512kb chip because how can i noob not know that games with fastmem run several times faster because of fastmem. another good one is games which support only df0: for loading by default is of course fs-uae fault not to support more drives.
believe me i have dealt with crap like that for the past few years over there xD.

[Wulfman]

There are 2 possibilities with the configs:

Emulate "Realistic Hardware". Then I play Bubble Bobble on an A500 / A600. Or just "Functioning Hardware" ... then saving also works when Bubble Bobble is running on an A1200 Emu. I am more in favor of "functioning".

I don't think you have to make a big philosophy out of it for OpenRetro. Except for a few special features, all games run on A1200 or A500 emulations with standard settings. But of course you still have to make sure that not all crap ends up in the database. Doesn't even have to be malicious! Noob: "I'll use 8Mbyte FastRam for Bubble Bobble! ... oh I should upload that -> okay" ....

But as already said: it's not just about the hardware ... but also how I want to emulate: other joystick, shader xyz for just this game, etc. And the part has nothing to do with OpenRetro

Well let's see what the 4 brings.

Regarding savestats I opened a new thread ...

[FrodeSolheim]

I am open for discussing the default model for WHDLoad variants going forward. The thing I like about A600 is that the emulation is cycle-exact and quite accurate, so, games should not break when updating the UAE core. A1200 (cycle-exact or not) is less accurate, so there could be compatibility issues when updating UAE. Also, A1200 (cycle exact) is much more demand to emulate.

On the other hand, A1200 without cycle exact is much easier on the host system (comparable to A600 cycle exact). And many WHDLoad games are patched to be less dependent on exact system timing (to work better on different kinds of Amigas, including high-end). So maybe a non-cycle-exact A1200 model as default is a good idea. Someone needs to do some testing and come up with a good config for this model - to be as compatible with WHDLoad games as possible. Memory cycle exact? Compatible CPU or not? Immediate blitter? I'm not sure what set of options would be the ideal base here.

[FrodeSolheim]

And to comment the other couple of issues discussed here. Yes, submitting changes without some moderation is not going to happen

About saves, I recognized that it is a problem that needs to be solved. I commented it also in the other thread (https://eab.abime.net/showthread.php?t=108689).

And finally, just to make it clear - there is going to be some way to override database configs locally. I just haven't decided how it's going to look and work yet

[FrodeSolheim]

I created a new and separate thread for the discussion about what Amiga model/options to use for WHDLoad games going forward: https://eab.abime.net/showthread.php?t=108746