Changes for upcoming Skyscraper 3.11

Lolonois

Hi guys

Please note that with the next release (most likely 3.11) of Skyscraper the accompanied RetroPie scriptmodule will no longer have it's own set of configurations.

What does that mean for you?

If you use Skyscraper from the command line (not from within retropie setup / dialog based): Nothing.
If you use Skyscraper from within retropie setup / dialog based: Set any configuration to the config.ini of Skyscraper instead within the scriptmodule. These setting stored in /opt/retropie/configs/all/skyscraper.cfg will then no longer be evaluated. However, you will still be able to scrape with the dialog based module.

Rationale: The part of the scriptmodule is neither from Lars nor from me and it caused users and me trouble more than once. I did the mistake to let the same dog bite me twice but the last bite was one too much!

Thank you for your understanding.

mitu

@Lolonois said in Changes for upcoming Skyscraper 3.11:

Please note that with the next release (most likely 3.11) of Skyscraper the accompanied RetroPie scriptmodule will no longer have it's own set of configurations.
Rationale: The part of the scriptmodule is neither from Lars nor from me and it caused users and me trouble more than once. I did the mistake to let the same dog bite me twice but the last bite was one too much!

The scriptmodule is part of RetroPie, but I don't recall any issues with it or Lars raising any issues with it. In fact, the dialog based scraping UX was designed largely by Lars during the lifetime of Skyscraper. Can you detail what issues does it have and why it should be removed ?

Lolonois

Even if it has been around ever since, the scriptmodule opens a separate config path outside the config ini and it is not transparent to the user that some flags are hardwired in the scriptmodule.

I ditched the initial idea to have exactly one config source thus, to have any config switch set in/get from the scriptmodule as it would be a royal annoyance to rewrite the evaluation/precedence logic of the config ini in bash.

As a compromise I would see that the all applied switches from the scriptmodule are prompted to the user before he/she starts the scraping and/or have the skipped flag also configurable.

mitu

Even if it has been around ever since, the scriptmodule opens a separate config path outside the config ini and it is not transparent to the user that some flags are hardwired in the scriptmodule.

I understand that this may cause some confusion, but as I said, I'm not aware of any reported issues related to this.

I ditched the initial idea to have exactly one config source thus, to have any config switch set in/get from the scriptmodule as it would be a royal annoyance to rewrite the evaluation/precedence logic of the config ini in bash.

I don't see why would be necessary. Ultimately the dialog based UI maintained in RetroPie is just a wrapper over the CLI options, meant to be used by users who don't need many options besides maybe turning on 'video' downloads. Avanced/experienced users are using the CLI to scrape and can (and do) ignore the UI. For the former users, the current .cfg is (ubenknownst to them) the config.ini, since they just use a couple of options to scrape and don't seek or need other parameters.

As a compromise I would see that the all applied switches from the scriptmodule are prompted to the user before he/she starts the scraping and/or have the skipped flag also configurable.

Yes, I can see this working - start anew without any .cfg so the user would always need to set the parameters and those parameters (including the skipped flag if we don't want to default to a safe value) are not persisted to any configuration. We can make also make it more clear that options set in the UI override the config.ini options.