Development of module-script generator for lr-mess, lr-mame and mame standalone

Folly

Gray screen !, Seems you still miss some bios files.
Have a look in your /dev/runcommand.log if some bios file aren't found.

I've downloaded the required BIOS files and placed them in the MAME folder but still no joy.

Bios files go into :
~/RetroPie/BIOS/mame

I just did an electron reinstall.
A good first test is to run "hopper" from the "electron_card" softlist zip file.
Run hopper.zip with lr-mess of mame with -cart1 option.

Folly

@DTEAM

Just a few questions :
Do you have the add-mamedev-systems.sh script and the generated scripts still in RetroPie-Setup/scriptmodules/* ?
Shall we work towards using the ext directory structure for better future compatibility ?

DTEAM

@Folly

My setting now is based on the instruction in the first post.

Folly

@DTEAM

Technically it doesn't really matter where add-mamedev-systems.sh is.
I will basically detect if runs from the normal or the ext directory and places the created module-scripts it the directories (normal or ext) accordingly.

However, quite some time ago I made the add-ext-repos.sh script.
With this people are able to download multiple module-scripts in 1 go from a few different 3rd party repositories.
These are then dowloaded into the Retropie-Setup/ext/<repo-subdirectory>/.
That way all 3rd party repositories are separated from the normal/original Retropie module scripts.

So when I want to give advise if someone want's to add a different module-script of me.
Then I can just say copy and run add-ext-repos.sh from the config/tools section of the Retropie-Setup and then the instruction will be somewhat the same for every "install".

Duplicate errors can occur if the same module scripts are in the normal directory and also in the ext directory.
However my add-ext-repos.sh will skip downloading module-script if it finds module-scripts with the same name.
So when somebody has my add-mamedev-systems.sh script in the normal directories and also adds add-ext-repos.sh. I could mean that it still works.
However in this situation 3rd party module scripts are not concentrated in the same directory structure.

Summarized, it would be better if everything goes directly to the ext directory from the start, so no confusion can occur, no possible duplicate errors can occur and everything is nicely separated.

Long story, but do you get it ?

DTEAM

@Folly said in Development of module-script generator for lr-mess, lr-mame and mame standalone:

Summarized, it would be better if everything goes directly to the ext directory from the start, so no confusion can occur, no possible duplicate errors can occur and everything is nicely separated.

I get It. Good point.
For the formalization in Retropie, any progress?

Folly

@DTEAM

Ok good !
When I have time I will try change the instruction in the first post on how to install in the ext directory.
And how to convert from an earlier install to an ext install.
Will take some time I think.

For the formalization in Retropie, any progress?

You mean converting the script in a way so it will be accepted by RetroPie as a pull request ?

DTEAM

@Folly said in Development of module-script generator for lr-mess, lr-mame and mame standalone:

You mean converting the script in a way so it will be accepted by RetroPie as a pull request ?

yes

Folly

@DTEAM

Basically, that's a difficult one.
We only know that the part for generating module-scrips is something that they don't like and therefor it will never be accepted.
At some point I have been thinking, can I just install a system or even remove a system without generating a module script.
It might be possible to just use, for example, the functions mkRomDir, addEmulator and addSystem from within the script without the use of a generated module script.
Though, when above is possible, installing a system via the commandline using ./retropie_packages would, probably, not be possible because of the different structure of the module-script.
So that is also something that, I think, will not be liked too.
So basically what I am saying is that it's very difficult to make something that will be liked. unless there is a proper discussion and everything is build from the ground up.
I think that is the only way to prevent unnecessary loss of time and commitment.

Folly

@Widge

I would like to ask you, are you already familiar with the arcade "categories" I implemented in the script ?
( shooter, puzzle etc )

Soon I will be able to update the database to mame 0.245.
This means that I probably can add the category "lightgun" to the database too.

Would that be a nice option ?

Widge

@Folly
Thanks for asking me. I apologise that it's taken so long to respond.

I'm not too familiar with the categories. All I did was use the script to install mess for Atari800, so I could see if I could use mess to play the Atari lightgun games.

Ultimately, I found that whilst mess has lightgun support the drivers for Atari800 do not appear to make use of it.
This file seems to indicate that all types of mouse-like input for A800 are completely off the table: https://github.com/libretro/libretro-atari800/blob/master/libretro/core-mapper.c

Adding a lightgun category to your database does sound like a good option to have, but at present I'm not familiar enough with your script to give a qualified answer.
But again, thank you for thinking of me.

Folly

@Widge

Ultimately, I found that whilst mess has lightgun support the drivers for Atari800 do not appear to make use of it.

indeed, seems to be a problem with some drivers for MAME/lr-mame/lr-mess.

This file seems to indicate that all types of mouse-like input for A800 are completely off the table: https://github.com/libretro/libretro-atari800/blob/master/libretro/core-mapper.c

Correct, for that a800 libretro-core it looks like mouse is disabled when no android is used.
You could open a new topic, and try to change or patch the source to test adding mouse support to it.

Adding a lightgun category to your database does sound like a good option to have, but at present I'm not familiar enough with your script to give a qualified answer.

When I can I will try to update the database with lightgun info.
I am still waiting for updates on : https://www.progettosnaps.net/index.php .

Folly

The script has been updated to use the mame 0.245 data.

Within the 0245 database the lightgun data has been added.
So it's now possible to install the arcade category "lightgun".
Because there are no vertically playable lightgun roms the "lightgun90º" entry's are missing.

Although the category lightgun exists now, there are no artwork files or overlays files yet to support the sinden lightgun.
So if you want to make use of that, you still have to add that manually.

From the restricted part 122 of 329 lightgun games are available.

testudo

@Folly
Added the latest add-mamedev-systems.sh scriptmodule (0245.02) on my Ubuntu system and I am getting this error when trying to add new systems:

/home/testudo/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh: line 806: /home/testudo/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh: line 791: /usr/bin/dialog: Argument list too long: syntax error: operand expected (error token is "/home/testudo/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh: line 791: /usr/bin/dialog: Argument list too long")
/home/testudo/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh: line 809: /home/testudo/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh: line 791: /usr/bin/dialog: Argument list too long: syntax error: operand expected (error token is "/home/testudo/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh: line 791: /usr/bin/dialog: Argument list too long")

Any idea on what I have done wrong?

Folly

@testudo

I am aware that there is somehow one bug in the script, only when using a x86 or x86_64 cpu or other OSes.
The bug was there from the start of the front-end.

The issue is that when you want to display all the systems, and install one from there, then the error occurs.

When selecting system in alphabetical order there should be no problem

So :
Are you able to go into front-end ?
Did you select to install a default system from the whole list ?
Do the other menu options work ?

testudo

@Folly

Yes, I was attempting to access the full list of default systems. It has been awhile since I added anything new, so I may have forgotten that bug existed.

Anyway, I am able to use the alphabetical listing options and get systems added, so all good now.

Thanks for the instructions.

Folly

@testudo

Not sure why the error occurs because on a raspberry pi it's no issue.
Perhaps I will dig in it once more.
On the other hand, is it a solution to just remove the menu options 1 and 2 ?
What do you think ?

testudo

@Folly said in Development of module-script generator for lr-mess, lr-mame and mame standalone:

@testudo

Not sure why the error occurs because on a raspberry pi it's no issue.
Perhaps I will dig in it once more.
On the other hand, is it a solution to just remove the menu options 1 and 2 ?
What do you think ?

Removing the menu options seems like a logical fix, be it temporary or permanent.

Folly

@testudo

Seems I found the issue and did an update :
https://github.com/FollyMaddy/RetroPie-Share/commit/e23e2a058872b2a8c05f391ef4020c8bcde092e1

Can you test it for me ?

EDIT :
Just tested both "description list" and "systems list".
Seems the issue is in the"description list".
So the error is not fixed yet.
I will have a second look ;-)

Folly

@testudo

I turned "Display all upon descriptions" off for x86 and x86_64 PC's.
You will now get a message.
Can you test it for me ?

https://github.com/FollyMaddy/RetroPie-Share/commit/8bbaa26a88521183fe1330c1e31ec02ba190e36f

testudo

@Folly said in Development of module-script generator for lr-mess, lr-mame and mame standalone:

@testudo

Seems I found the issue and did an update :
https://github.com/FollyMaddy/RetroPie-Share/commit/e23e2a058872b2a8c05f391ef4020c8bcde092e1

Can you test it for me ?

EDIT :
Just tested both "description list" and "systems list".
Seems the issue is in the"description list".
So the error is not fixed yet.
I will have a second look ;-)

@Folly

I received the following errors:
script errors.png