Development of module-script generator for lr-mess, lr-mame and mame standalone
-
@dteam said in Development of module-script generator for lr-mess and mame standalone:
@folly
we weren't talking about the same thing, that's why we didn't understand each other.Indeed, that seems to be the case here.
For the hash file, could it be possible to generate a .doc list from the hash without the .xml extension and restart from that list to generate the list in retropie?
Basically it should be possible to generate a text file from a hash table and display this in the RetroPie-Setup within the module-script.
Here I am getting confused already because we don't use the hash tables to generate our module-scripts.Sometimes the potential problem is that the name.xml does not match the system.
Ok, I can imagine that. Because, as said in the
renameSET
described, names change all the time.
So if one hasn't changed in the hash-table with a source update, you will have a mismatch.I think, we can't use use things from the renameSET 0.229* because we are still in using mame 0.227in RetroPie, so then we would definitely have mismatches.
I will try to find a solution. In the mame software, they can use filters.
You should convert it to a schematic approach, because I still don't get it all. (sorry)
--
I did something more to understand :
I reread everything again to get the aha of it all.
I opened thecategory.ini
from the renameSET 0.229 that you were referring to.
I see that the systems are categorized as :- [Arcade / Pinball]
- [Ball & Paddle / Breakout]
- .
- [Handheld / Electronic Game]
- .
- etc.
And that is very much the same as what you/we did with the handhelds :
- konamih
- tigerh
- etc.
But our handheld-names are actually a subsections of [Handheld / Electronic Game].
Wouldn't you agree ?I can imagine using it to categorize it to make a better menu.
But this file is quite difficult to extract the info and it's, I think, based upon mame 0.229. Then we have a mismatch again with 0.227.--
Can you tell me, is there something in above reply that makes any sense referring to your conversation ?
If that is not the case, perhaps we have to leaf this part for a while, otherwise it's going to get too difficult, I think. -
@folly said in Development of module-script generator for lr-mess and mame standalone:
But our handheld-names are actually a subsections of [Handheld / Electronic Game].
Wouldn't you agree ?Yes, excepted for all_in1 system. I'm not sure if they categorized those games/systems properly. When I did my list, I looked for drivers and I did't paid attention if it was in Handheld or not. Same thing for Jakks, but for Jakks, they use only 2 drivers. It should be easy to isolated.
The way they play with the names are crazy. Did you see the renameSET.dat. It makes me dizzy
-
Ok, now we are getting somewhere.
You want a good categorization.We should look for clues and use the mame command and filter things out if possible.
Then we can make our own filter which is version independent.
Otherwise we have to do the sorting every time again when a new version comes.I think that should be the approach.
But we have to keep in mind that we can only use these filters on systems that are without (-media) and use the bios as the game, sort of speek.
Are we spot on ?
-
Two imperfect method :
1- Bash kgradius, bmsoccer, jak_dbz , etc. like you said to generate the system folder with the system name (like Jakks) and use mess.ini list in Retropie menu even if it's 0.229 and not 0.227. In the Retropie menu, It could be interesting to substitute kgradius by konamih like we said before.
2 - Start with your massive list and soustract stuff from (arcade.ini and Mechanical Arcade.ini)
If doable, isolate handheld systems is great idea you had.
-
Point 1 shouldn't be that difficult.
I think we should do it in the dialog module-script.
Just joining for example konamih to one game, like I did in the desired script.Point 2, I will have a look at that. I can't tell for sure how we can manage this, at this point. I we could it would reduce the list to useful systems, that is what you mean.
-
@folly said in Development of module-script generator for lr-mess and mame standalone:
I think that should be the approach.
But we have to keep in mind that we can only use these filters on systems that are without (-media) and use the bios as the game, sort of speek.
Are we spot on ?Yes.
-
@folly said in Development of module-script generator for lr-mess and mame standalone:
Point 2, I will have a look at that. I can't tell for sure how we can manage this, at this point.
If feasible, the result should be pretty close to what we expect. You have 33672 arcade games/sytem in arcade.ini in your list 38000.
-
Yes indeed, we subtract the mechanical's we can't use.
-
@folly
Mechanichal arcade is included in arcade.iniIn mess.ini, you have 4377 systems, so method 2 works with arcade.ini only . We dont need more files
-
@dteam said in Development of module-script generator for lr-mess and mame standalone:
@folly said in Development of module-script generator for lr-mess and mame standalone:
Point 2, I will have a look at that. I can't tell for sure how we can manage this, at this point.
If feasible, the result should be pretty close to what we expect. You have 33672 arcade games/sytem in arcade.ini in your list 38000.
You have to know my list isn't perfect due to imperfect code.
There are empty systems and lettes only, so the count isn't correct. -
-
@dteam said in Development of module-script generator for lr-mess and mame standalone:
@folly
Mechanichal arcade is included in arcade.iniIn mess.ini, you have 4377 systems, so method 2 works with arcade.ini only . We dont need more files
We keep that in mind and use it when we are ready to do so.
There is still much work to get the basics working.
But it's good to talk about it so we will be prepared a bit. -
@dteam said in Development of module-script generator for lr-mess and mame standalone:
mess.ini = 4377
arcade.ini = 33672
total = 38049You are not far !!
Ok that's nice to know.
Just summarizing again :
Basically we want to categorize the arcade into sections and subsections and we keep the mess systems as they are. -
@folly said in Development of module-script generator for lr-mess and mame standalone:
Just summarizing again :
Basically we want to categorize the arcade into sections and subsections and we keep the mess systems as they are.Final result could be something like that (similar to the previous sketch) . For # to Z = 4377 systems. Are you agree with that?
New edit: I forgot something, It's not A to Z but # to Z. Some systems start by a number. -
Nice schematic.
My idea is to share the code so we all can see how this evolves.
Agreed, I hope we can make it like this.
-
@folly said in Development of module-script generator for lr-mess and mame standalone:
Agreed, I hope we can make it like this.
I hope also. I hope what @valerino proposed could help for the menu part.
-
Here you can see the changes I made to the docsview.sh and trying to convert it to a base for our front-end.
https://github.com/FollyMaddy/RetroPie-Share/commit/07daf2f032dbdd3a06fb030ae2443151bf28e14aYou will see :
- I just changed the page string and the pages array into system and systems.
- I changed the command to get the mame system information into the array.
- I turned of some docsview choices.
-
Perhaps very premeture, but we can already create with the front-end script.
https://raw.githubusercontent.com/FollyMaddy/RetroPie-Share/main/00-workdir-00/add-mamedev-systems.shDownload to RetroPie-Setup :
( Edit : renamed the file on github as add-mamedev-systems-test1.sh which is saved with this command as add-mamedev-systems.sh )wget -q -nv -O /home/$(ls /home)/RetroPie-Setup/scriptmodules/supplementary/add-mamedev-systems.sh https://raw.githubusercontent.com/FollyMaddy/RetroPie-Share/main/00-workdir-00/add-mamedev-systems-test1.sh
Go to -> configuration / tools -> select (192) add (wait 20 sec.) -> view systems -> select a system -> it will generate and install (and will go back to the systems list again)
Then you still have to restart the RetroPie-Setup to see the new module-scripts.
Refresh added in third commit.Commit 1 :
This is what I changed to fix the ownership problem :
Perhaps a bit unconventional but I changed the generate-systems-lr-mess_mame-2v0-alpha.sh so it will create in /home/<user> .
(many times it will become the normal /home/pi though)
It will also change the ownership to the normal <user> .
https://github.com/FollyMaddy/RetroPie-Share/commit/6fa291756f11611204d2ce3262b52e203f0737e4Commit 2 :
Perhaps I also have to fix also the created directory in line 84.
I have to check this (fixed this too) :
https://github.com/FollyMaddy/RetroPie-Share/commit/53265236288a829382dfa6820313c23bb1215b12Edit : I will search for a better user/ownership solution.
It works for now, but it's not the perfect solution, I think.Commit 3 :
Added refresh, so no need to restart RetroPie-Setup :
https://github.com/FollyMaddy/RetroPie-Share/commit/8a3c7d6487b7371652f41a956733e989d158e93fCommit 4 :
Moved refresh to somewhere else, added clear, added unconventional way of installing the generated module-scripts directly :
https://github.com/FollyMaddy/RetroPie-Share/commit/debe1edd0fae83e8572ff9678a1fc2295ebff1ea
It is obvious to see I have to get the module_id with the ls command.
If the generated-script is within the front-en module we can just use those strings to install the generated-script. -
@folly
Wow, you are fast. I don't have time to test it right now, but I will do it ASAP. Great job! -
Yesterday I used the retropie_packages.sh within the front-end-module.
It was possible to directly install the generated module-scripts after generation.
So that is nice to know.I see the possibilities here :
- show systems in dialog menu
- select systems
- refresh modules after generation
- install generated modules directly after generation
But I also encounter some limits with the approach, that I took, with running the generation-script with curl from the front-end-test module,
because strings can't be exchanged easily between the front-end and the generator-script back and forth.
So perhaps it's better to implement the generator-script within the front-end module-script.I also have some concern about the filling of the array's.
I would like to display the systems descriptions instead of the systems names to get a better idea on what we choose/install.
Integrating the generation-script could be the better approach in this case.
Along with filtering can take more time as we build more things into it.
So I have to think about that.
Perhaps there is a way of doing this one time, making fixed array's that are faster, once created.
And then add a refresh option, so things can be refreshed/updated on demand.Well I have to think that a bit, hopefully I don't make it too difficult for myself and others.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.