Closed nemo93 closed 8 years ago
i agree with non-merged sets...some games that were playable before (non-merged) is no longer playable when merged.
another ex: hammering Henry in merged set does not launch
irrelevant, link is posted below
I see this same issue. Non-merged sets are not playable without a parent present. Which defeats the purpose of having a non-merged set.
a split set is also in circulation..I believed the latest libretro database is split
For people who have an issue about non-merged ROMs appearing in the RetroArch database/playlist generator: I have created an issue in the more appropriate location for that conversion: https://github.com/libretro/libretro-database/issues/248
okay...yes..non-merged will be my vote..so confusing with these naming...explanation between merged vs split vs non-merged is at https://github.com/libretro/Lakka/wiki/Arcade
I prefer split sets, but it would be a good thing to have support both (actually i checked and i don't understand why non-merged roms wouldn't load, nothing on the libretro code seems to force this behavior, standalone fba works with non-merged sets ?)
I second the correct integration of non-merged sets. I use non-merged roms and I only keep one version of a game. I only use the most recent revision of a game's country of origin rom version. For example, I only keep and play the latest japanese revision of Final Fight and delete all other versions. I only keep rtypej and delete rtype and rtypeu. As long as you use non-merged rom sets, a clone version should work without having to have the parent rom set. But this doesn't work with fba-libretro. For example rtypej will only run if rtype is present. Or maglordh will only run if maglord is present. So you have to have doublets of games, even if you only ever want to play one specific version. MAME 2003 works with non-merged sets as intended, but I would very much prefer using fba on the Rpi3.
(@Baron-von-Blubba can you tell me whether RetroArch currently will build a full playlist when it scans a non-merged MAME 0.78 set? I'm trying to keep a table up to date in the forums to answer this kind of question.)
Sorry, actually I don't know how to scan roms and create gamelists with RetroArch. I'm using Recalbox (which is pre-configured and uses EmulationStation as frontend) on the RPi3. On the PC I use current MAME with Attract Mode as frontend. I don't have a full non-merged 0.78 set anyway as I only keep one version of every game I want to play. The RPi3 is obviously too slow for current mame, but it's fast enough for current fba (at least for all games I'm interested in.) Therefor I would much prefer using current fba on the RPi than an 13 year old version of mame, but It's a real problem for my method of rom organization that non-merged clone sets only work when their parent set is present. (Which by the way makes non-merged sets totally useless because the non-merged rom sets are bigger then split sets and their advantage (the elimination of parent/clone relationships) doesn't work.
I should remember that this core is not used only by RetroArch :) I normally only hang out in their repos.
It should be solved
When recently rebuilding my FBA romset to the latest 0.2.97.38 and for my Retropie I decided to go for the non-merged sets (parents and clones in their own stand-alone .zip files) as I did for Mame. More space on disk but less pain on the long term (when you want the 2player version instead of the 4p for instance).
Yet it seems that this version of FBA doesn't care about non-merged sets and split sets have to be used anyway.
An example? sure. Let's go with V*V (Vee Five). The parent set is grindstm.zip (Grind Stormer) and the "clone" is vfive.zip. Yet I want to play only to vfive.zip as the game system is one I'm used to and good at :) Despite my vfive.zip being complete I still need to have grindstm.zip at the same location if I want vfive.zip to launch properly.
Is this expected behavior? Any chance to have support for non-merged sets please?
I'm using a RPi2 and Retropie 4.0 beta-3.